企业官网建设流程全解析

知识图谱这个方向，很多人第一次接触时脑子里想的都是"我要抽多少实体、设计多少种关系"，但真正把项目做上线的人会发现，第一个卡住你、而且事后最难返工的环节，往往是存储和可视化。我见过一个团队花了两周把本体模型打磨得很漂亮，结果第一批量数据灌进去就发现单机磁盘撑不住，图谱查询从毫秒掉到十几秒，前端画出来的图一团乱麻，节点挤在中间像毛线球。后面推倒重来，把存储层换成"图库 + 对象存储 + 缓存"的三层结构，前后又花了三周。

这篇就按我自己的实操顺序，把知识图谱的存储和可视化这两块拆开讲。会涉及 Neo4j 的建模与批量写入、MinIO 这类对象存储的定位、Redis 在链路里的真实作用、以及可视化从选型到布局收敛的调参思路。适合已经跑通 hello world 级别 Demo、准备往生产环境推的人看；如果你还在纠结要不要用图数据库，前面的选型对比部分也能帮你做判断。

1. 存储选型先于建模：知识图谱最容易本末倒置的一步

1.1 三元组到底能放在哪几种存储里

先把概念拉平：知识图谱的本质是一堆(头实体, 关系, 尾实体)的三元组。既然是三元组，理论上放哪儿都能存，区别在于你查起来要付多大代价。

• 原生图数据库：Neo4j、NebulaGraph 这类。存储引擎就是按"节点—边—属性"组织的，走的是无索引邻接（index-free adjacency），查一度邻居基本是常数时间。
• 关系型数据库：MySQL、PostgreSQL 建三张表或者一张三元组表。好处是团队都熟，坏处是多跳查询要写一堆 JOIN，三跳以上性能断崖式下跌。
• RDF 三元组库：Jena、Virtuoso 这类，标准规范做得好，适合做本体推理和学术场景，但工程生态和运维友好度要弱一些。
• KV / 宽表：HBase、Cassandra 自己拼邻接表。能扛住超大规模写入，代价是所有图算法、最短路径、子图匹配都得自己实现。

我自己的判断标准很简单：**如果你的查询里会出现"三跳以内找关系"，直接上图数据库，别犹豫。**如果是"按 ID 查单点属性"占九成，那关系型反而更省事。

1.2 四种存储形态的一次性对比

这张表里最容易被忽略的是"运维成本"这一列。很多团队选型时只看性能，忽略了图数据库对内存的胃口——Neo4j 的页缓存配不好，性能会比 MySQL 还难看。

1.3 容量估算：别等磁盘写满才想起来算账

存储大小这件事，一定要在建模阶段就估一遍。给个我实际用过的粗算法：

单个节点占用的字节数 ≈ 节点标签 + 主键长度 + 属性总长度 + 索引开销 + 约 30 字节的固定结构开销。 单条关系 ≈ 关系类型 + 属性总长度 + 约 40 字节固定开销（关系比节点多存两个指针）。

假设你有 500 万实体、2000 万条关系，平均每个实体带 8 个属性、总长度 300 字节，每条关系带 2 个属性、总长度 60 字节：

节点: 500万 × (300 + 30 + 索引约 60) ≈ 500万 × 390 B ≈ 1.95 GB 关系: 2000万 × (60 + 40) ≈ 2000万 × 100 B ≈ 2.0 GB 索引与属性再乘 1.5~2 倍冗余系数 ≈ 总量 8 GB 左右

听着不大，但这是裸数据。Neo4j 的 store 文件会因为事务日志、空闲页碎片、删除标记膨胀，实际占用往往是估算值的 1.5 到 2 倍。所以上面这个例子，生产环境我会按 20 GB 预留磁盘，同时给页缓存配 8 GB 以上内存。

提示：如果你的图谱里要挂原始文档、图片、音频这类非结构化内容，绝对不要把二进制塞进图库的属性字段。这是新手最容易犯的错，一个 5 MB 的 PDF 存进属性里，查一次邻居就能把内存打爆。

2. Neo4j 之外的存储分层：对象存储、缓存与元数据如何各就各位

2.1 图库里只放"关系骨架"

我的做法是把图库当成一张地图，不是仓库。图库里只保留三类东西：

1. 实体节点，带少量用于筛选和展示的核心属性（名称、类型、创建时间、置信度）。
2. 关系，带权重、来源、时间等轻量属性。
3. 指向外部存储的引用，比如doc_uri、minio_key这样的字段。

// 节点只留可检索的核心属性 CREATE CONSTRAINT entity_id IF NOT EXISTS FOR (n:Entity) REQUIRE n.entity_id IS UNIQUE; CREATE INDEX entity_name IF NOT EXISTS FOR (n:Entity) ON (n.name);

约束一定要建，这不是可选项。没有唯一约束的MERGE会退化成全表扫描，而且并发写入时会产生重复节点——这个坑我在 3.4 节会细讲。

2.2 MinIO 承担实体原文与大文件

对象存储在这里的角色非常清晰：所有大块内容、原文、附件、模型文件、抽取中间结果，全部扔进去。MinIO 是私有化部署里最省事的选择，S3 兼容，单机也能跑，后面想迁到公有云的对象存储，代码几乎不用改。

一个典型的组织方式是按实体类型和时间分桶：

from minio import Minio import io, json client = Minio( "minio.internal:9000", access_key="xxx", secret_key="xxx", secure=False, ) def save_raw_doc(doc_id: str, content: bytes, meta: dict): key = f"raw/{doc_id[:2]}/{doc_id}.bin" client.put_object( "kg-raw", key, io.BytesIO(content), length=len(content), content_type="application/octet-stream", ) # 元数据单独存一份小的，方便列表查询 client.put_object( "kg-meta", f"raw/{doc_id}.json", io.BytesIO(json.dumps(meta, ensure_ascii=False).encode()), length=len(json.dumps(meta, ensure_ascii=False).encode()), content_type="application/json", ) return key

按doc_id前两位做一级目录，是为了避免单个目录下文件过多导致列举操作变慢。这个技巧在小规模时看不出差别，等你有几百万个对象时就是救命的设计。

图库里对应的节点只需要存一个minio_key：

MATCH (e:Entity {entity_id: $eid}) SET e.doc_uri = $key, e.updated_at = timestamp()

2.3 Redis 的定位：中间态、任务队列与热点缓存

Redis 在知识图谱链路里承担三个角色，别混用同一个实例。

• 异步任务的结果后端：抽取任务往往是分钟级的，不能卡在 HTTP 请求里。用 Celery 加 Redis 做 broker 和 result backend 是最常见的组合，任务提交后立刻返回 task_id，前端轮询状态。
• 热点查询缓存：图谱首页那种"展示全图概览"的查询，算一次要好几秒，缓存 5 分钟能省掉 90% 的重复计算。
• 去重与限流：爬取阶段用 Set 或 HyperLogLog 做 URL 去重，比每次查库快一个数量级。

from celery import Celery app = Celery( "kg", broker="redis://redis.internal:6379/0", backend="redis://redis.internal:6379/1", ) app.conf.update( task_serializer="json", result_serializer="json", accept_content=["json"], result_expires=3600, # 结果一小时过期，别让它无限堆积 worker_prefetch_multiplier=1, # 长任务关掉预取，避免任务分配不均 task_acks_late=True, # 任务执行完再确认，worker 崩溃可重跑 )

注意：result_expires一定要设。我踩过一次坑，抽取结果全部堆在 Redis 的 db1 里，两周后内存告警，才发现是几百万个任务结果没人清理。Redis 是缓存不是数据库，任何放进去的数据都要想过期策略。

顺带说一句，Redis 里的东西别靠命令行硬看，用Redis 可视化管理工具效率高得多。RedisInsight 和 Another Redis Desktop Manager 我都用过，前者官方出品、能看内存分析和慢查询，后者胜在轻量。查 key 的时候注意用SCAN而不是KEYS，生产环境敲一次KEYS *可能直接把实例卡住。

2.4 实体 ID 映射表：整条链路的黏合剂

这一层很少有人专门提，但它是保证幂等的关键。原始数据里的实体标识五花八门——有的是数据库自增 ID，有的是 URL，有的是一段文本的哈希。你需要一张稳定的映射：原始标识 → 全局 entity_id。

我的做法是放在关系型数据库里，就一张表：

CREATE TABLE entity_mapping ( source VARCHAR(32) NOT NULL, source_key VARCHAR(255) NOT NULL, entity_id CHAR(36) NOT NULL, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (source, source_key), UNIQUE KEY uk_entity (entity_id) );

有了这张表，无论上游数据重跑多少次，同一个来源的同一个实体永远映射到同一个entity_id，图里就不会出现重复节点。UUID 用 v4 随机生成或者用source + source_key做确定性哈希都行，后者在需要跨环境对齐时更好用。

3. 把原始数据真正灌进图谱：抽取、幂等、批量写入

3.1 数据来源梳理和清洗边界

动手写代码之前，先花半天把数据来源列清楚。我在项目里习惯画一张很土的表格：数据源、更新频率、数据量级、主键字段、有无疑似重复。这一步做扎实，后面能省掉大量返工。

清洗的边界要说清楚：**哪些脏数据是丢弃的，哪些是保留但打标记的。**我的原则是，只要不是完全无意义的噪声，就保留并打上quality属性，而不是直接删。因为知识图谱的价值往往在长尾数据里，你今天觉得没用的字段，下周做某个查询时可能就变成关键线索。

3.2 Python 抽取实体关系的实操写法

抽取环节的输入是文本或结构化记录，输出是标准的三元组列表。无论是调模型还是写规则，最后都要收敛到同一个数据结构：

from dataclasses import dataclass, field from typing import List @dataclass class Triple: head_id: str head_name: str head_type: str relation: str tail_id: str tail_name: str tail_type: str confidence: float = 1.0 source_doc: str = "" props: dict = field(default_factory=dict) def normalize(relation: str) -> str: # 关系类型统一大写、空格转下划线，避免同义关系散落 rel = relation.strip().upper().replace(" ", "_").replace("-", "_") alias = {"属于": "BELONGS_TO", "隶属于": "BELONGS_TO", "位于": "LOCATED_IN"} return alias.get(relation.strip(), rel)

normalize这一步看起来不起眼，但关系类型不做归一化，三个月后你的图里会同时存在BELONGS_TO、belongs_to、属于三种关系，查询的时候得写三遍。我建议维护一张关系别名词典，抽取时统一走一遍。

关于抽取方式的选择：规则抽取适合字段规整的结构化数据，速度快、可解释；模型抽取适合长文本，召回高但需要人工校验。实际项目里我一般让两者并行，规则跑全量打底，模型跑增量补充，然后按(head_id, relation, tail_id)做一次合并去重，置信度取最大值。

3.3 用 Celery 把任务从请求线程里摘出去

Python 爬虫可视化界面这件事，很多人第一反应是做个 Flask 页面加个按钮触发爬取。这个结构在 Demo 阶段没问题，一旦数据量上来，HTTP 请求会超时、进程会阻塞、用户会不停刷新。

正确做法是把链路拆成三段：提交任务、异步执行、轮询结果。前面 Celery 的配置已经给了，任务本身大概长这样：

@app.task(bind=True, max_retries=3, default_retry_delay=30) def extract_task(self, doc_id: str, text: str): try: triples = extract(text) # 抽取 entity_ids = resolve_entities(triples) # 映射到全局 ID bulk_write_graph(entity_ids) # 批量写图 cache_raw(doc_id, text) # 原文进对象存储 return {"status": "ok", "count": len(entity_ids)} except TransientError as exc: raise self.retry(exc=exc) except Exception as exc: return {"status": "failed", "reason": str(exc)}

注意这里TransientError和普通异常分开处理：网络抖动、数据库连接超时可以重试，数据格式错误重试一百次也没用，直接把失败原因返回给调用方。

3.4 幂等写入：MERGE 用错一次，整张图就脏了

这是我最想强调的一节。批量写入必须保证幂等，也就是同一批数据跑两遍，结果和跑一遍一样。

先看错误的写法：

// 反例：没有约束，也没有先匹配节点 MERGE (a:Entity {name: $head_name}) MERGE (b:Entity {name: $tail_name}) MERGE (a)-[:REL]->(b)

问题在于，MERGE在没有唯一约束时会退化成全标签扫描，几百万节点的库上跑一次要几分钟；更严重的是并发写入时，两个事务同时找不到节点，会各自创建一个，于是同一个实体出现两份。

正确做法是：约束建好，并且先用 entity_id 匹配，属性用 SET 更新。

UNWIND $rows AS row MERGE (h:Entity {entity_id: row.head_id}) ON CREATE SET h.name = row.head_name, h.type = row.head_type, h.created_at = timestamp() ON MATCH SET h.updated_at = timestamp() MERGE (t:Entity {entity_id: row.tail_id}) ON CREATE SET t.name = row.tail_name, t.type = row.tail_type, t.created_at = timestamp() ON MATCH SET t.updated_at = timestamp() MERGE (h)-[r:RELATES {edge_key: row.edge_key}]->(t) ON CREATE SET r.rel_type = row.relation, r.confidence = row.confidence, r.source = row.source_doc ON MATCH SET r.confidence = CASE WHEN row.confidence > r.confidence THEN row.confidence ELSE r.confidence END, r.updated_at = timestamp()

几个要点：

• 边的MERGE也必须有唯一标识（这里用edge_key，通常是head_id + relation + tail_id的哈希），否则同一对节点之间会生出多条同类型关系。
• ON CREATE和ON MATCH分开写，创建时写created_at，更新时写updated_at，不要每次覆盖创建时间。
• 置信度取最大值而不是覆盖，避免低质量数据的二次抽取把高质量结果冲掉。

批量大小怎么定？我的经验值是每批 1000 到 5000 条三元组。太小则事务开销占比高，太大则单个事务内存吃紧、失败后重试成本高。可以先按 2000 跑，观察服务端内存和提交耗时再调。

def bulk_write_graph(session, triples, batch_size=2000): rows = [t.to_row() for t in triples] for i in range(0, len(rows), batch_size): chunk = rows[i:i + batch_size] session.execute_write(lambda tx: tx.run(BATCH_CYPHER, rows=chunk))

数据量特别大的时候，可以用 APOC 的apoc.periodic.iterate做分批，但要注意它默认是并发执行的，parallel: true时对唯一约束的压力会显著上升，我一般先用parallel: false跑通再考虑提速。

4. 可视化不是画得好看，是让人查得动

4.1 三类可视化场景与对应的技术选型

知识图谱的可视化需求其实差别很大，混在一起谈很容易选错工具。我把它分成三类：

**第一类，探索式图视图。**用户点一个节点，展开它的邻居，一层层往下钻。这类需求要的是交互流畅、支持动态加载。AntV G6 和 vis-network 是主力选择，Cytoscape.js 在生物信息领域更常见，ECharts 的 graph 类型做静态展示够用但交互略弱。

**第二类，统计型看板。**实体数量分布、关系类型占比、时间趋势、地域分布。这类直接用 ECharts 或 Plotly 出图，配合 Python 侧的数据分析管线。

**第三类，大屏展示。**要给非技术人员看，强调视觉冲击和自动轮播。可视化大屏适配是这里最费劲的部分，后面 4.3 单独说。

选型上有个反直觉的结论：**别一上来就用最重的方案。**我见过用 Three.js 做三维力导向图的，效果确实炫，但用户根本没法在密密麻麻的三维空间里找到目标节点，最后还是退回二维。

4.2 图布局算法与"收敛"这件事

力导向布局的原理是把节点当成带电粒子、边当成弹簧，反复迭代直到系统能量最低——这个过程叫收敛。很多人不调参数，图跑出来要么一直在抖，要么几个节点飞出屏幕，问题都出在收敛参数上。

以 d3-force 为例，关键参数就三个：

const simulation = d3.forceSimulation(nodes) .force("link", d3.forceLink(links) .id(d => d.id) .distance(d => 40 + 20 * (1 - d.weight))) // 权重高的边更短 .force("charge", d3.forceManyBody() .strength(-180) // 斥力，绝对值越大越分散 .distanceMax(600)) // 限制斥力作用半径 .force("center", d3.forceCenter(width / 2, height / 2)) .force("collide", d3.forceCollide().radius(12)) // 防重叠 .alphaDecay(0.03) // 衰减速度 .alphaMin(0.001);

alphaDecay是最值得调的。默认 0.0228，图谱节点多的时候收敛很慢；调到 0.03~0.05 收敛快，但布局质量会下降。我的经验是：节点数 200 以内用 0.02 求质量，超过 1000 用 0.05 求速度，超过 3000 就别跑力导向了，改用分层布局或按社区聚簇预计算坐标。

力导向还有个硬伤：复杂度是 O(n²)（加 Barnes-Hut 近似后是 O(n log n)），节点过万时浏览器直接卡死。这种情况要在服务端预先算好坐标存起来，前端只做渲染。

社区发现算法（Louvain、Label Propagation）也可以用来给节点上色。按社区着色之后，原本看不出结构的图会立刻显出聚类，这是我做过的最划算的一次可视化优化。

4.3 大屏适配与前后端职责划分

可视化大屏适配踩过的坑集中在两件事上。

第一件是屏幕分辨率。设计稿按 1920×1080 出，实际投到 4K 屏上元素全挤在左上角。解决方案是整体缩放：给容器加transform: scale()，按实际宽高与设计稿的比例取最小值缩放，同时用transform-origin: left top对齐。

function fitScreen(el, designW = 1920, designH = 1080) { const ratio = Math.min( window.innerWidth / designW, window.innerHeight / designH ); el.style.transform = `scale(${ratio})`; el.style.transformOrigin = "left top"; el.style.width = designW + "px"; el.style.height = designH + "px"; // 居中偏移，避免宽高比不一致时贴边 el.style.position = "absolute"; el.style.left = (window.innerWidth - designW * ratio) / 2 + "px"; el.style.top = (window.innerHeight - designH * ratio) / 2 + "px"; } window.addEventListener("resize", () => fitScreen(document.getElementById("screen")));

第二件是数据刷新。大屏往往要轮询或定时刷新，但刷新时不能重建整个图，否则每次都会重新跑布局、画面剧烈跳动。正确做法是保留 simulation 实例，只 diff 数据、更新节点属性，位置尽量沿用上一帧。

前端职责边界也要划清：渲染、交互、缩放归前端；聚合计算、路径查询、社区发现归后端。我见过把最短路径算在前端做的，几十个节点时没问题，上千节点直接把页面冻住。后端算好返回结果集，前端只负责画。

4.4 查询性能直接决定交互体验

可视化的流畅度，七成取决于查询快不快，两成取决于渲染，一成取决于布局。所以图视图的每个交互动作，背后都应该是经过优化的 Cypher。

展开邻居这种高频操作，要限制返回量：

MATCH (n:Entity {entity_id: $eid})-[r]-(m:Entity) WHERE r.confidence >= 0.6 RETURN m.entity_id AS id, m.name AS name, m.type AS type, type(r) AS rel, r.confidence AS conf ORDER BY r.confidence DESC LIMIT 50

LIMIT一定要加，而且要在ORDER BY之后按置信度排序，保证返回的是最相关的那批。不要担心"漏掉了邻居"，交互上应该给用户一个"加载更多"，而不是一次拉几千个节点。

如果某个查询特别慢，先看执行计划：

EXPLAIN MATCH (a:Entity {name: $name})-[r]->(b) RETURN b LIMIT 10;

出现AllNodesScan说明索引没生效，检查约束和索引是否建在正确的标签和属性上。这是排查图谱查询慢最有效的第一步。

5. 上线之后：备份、压测与可视化运维面板

5.1 备份策略：图库和对象存储不能共用一套逻辑

存储备份这块，图库和对象存储的特性完全不同，必须分开设计。

图库的备份要求是一致性快照。Neo4j 企业版支持在线备份，社区版只能停机做 dump，这是个现实约束，选型时就得考虑进去。

# 停机备份（社区版） neo4j-admin database dump neo4j --to-path=/backup/neo4j/$(date +%F) # 恢复 neo4j-admin database load neo4j --from-path=/backup/neo4j/2024-06-01 --overwrite-destination=true

停机备份对业务有影响，所以我的做法是搭一个只读从库，每天凌晨在从库上做备份，主库不动。数据量大到单机扛不住时，就退化成"每周全量 + 每天增量"。

对象存储的备份逻辑是另一回事。MinIO 支持跨集群镜像，用mc mirror把生产桶同步到备份集群，天然增量、可断点续传：

mc alias set prod http://minio-prod:9000 ACCESS SECRET mc alias set backup http://minio-backup:9000 ACCESS SECRET # 持续同步，新对象自动复制 mc mirror --watch --preserve prod/kg-raw backup/kg-raw

提示：mc mirror默认是单向的，加上--remove会删除目标端多余的对象。这个参数慎用，我第一次用的时候差点把备份桶里多留的历史版本全清了。

Redis 侧不用做全量备份，但建议开启 RDB 定期快照，出问题时至少能恢复任务队列的状态。缓存本身丢了不影响正确性，这是把缓存当缓存而不是当数据库用的前提。

5.2 写压力测试怎么做才有意义

存储压力测试不是跑个工具看 QPS 就完事。图库的写压力测试要覆盖三种模式，因为它们对存储引擎的压力完全不同：

• 纯新增：全部是新节点新关系，考验写入吞吐和索引维护开销。
• 纯更新：全部命中已有节点，考验MERGE的匹配效率和锁竞争。
• 混合读写：模拟真实负载，同时跑读查询和写事务，看读是否会因为写锁而变慢。

我通常用 Python 写并发脚本，因为可以直接复用正式写入的代码路径，测出来的数才有参考价值：

import random, time from concurrent.futures import ThreadPoolExecutor def write_batch(session, rows): t0 = time.perf_counter() session.execute_write(lambda tx: tx.run(BATCH_CYPHER, rows=rows)) return time.perf_counter() - t0 def stress(session_factory, total=100_000, batch=2000, workers=8): def worker(wid): latencies = [] with session_factory() as s: for _ in range(total // (batch * workers)): rows = gen_rows(batch, seed=wid) latencies.append(write_batch(s, rows)) return latencies with ThreadPoolExecutor(workers) as ex: results = list(ex.map(worker, range(workers))) flat = [x for sub in results for x in sub] flat.sort() print(f"批次数={len(flat)} 平均={sum(flat)/len(flat):.3f}s " f"P95={flat[int(len(flat)*0.95)]:.3f}s P99={flat[int(len(flat)*0.99)]:.3f}s")

看结果时重点看P95 和 P99，平均值会掩盖长尾。P99 突然比 P95 高好几倍，通常意味着某一批触发了内存换页或者 checkpoint，这时候要去看服务端日志而不是继续加压。

另外，测试要在接近生产的硬件上做，且必须带着索引一起测。我见过不带索引测出来的 5 万 TPS，加上三个索引之后掉到 8 千，差距就是这么夸张。

5.3 用可视化工具盯住缓存和消息队列

知识图谱链路的健康度，很大程度反映在 Redis 和消息队列上。任务积压、消费延迟、内存碎片，这些指标不看图表很难及时发现。

• Redis：用 RedisInsight 看内存占用趋势、慢查询日志、大 key 分布。大 key 是图项目里最隐蔽的问题，一个存了几十万成员的集合，单次操作就能阻塞主线程。
• 消息队列：Kafka 可视化工具方面，Kafka UI 和 Kafdrop 都能看消费组滞后（lag）。滞后曲线持续上扬，说明抽取 worker 数量不够或者单任务耗时变长。
• 指标看板：Perses 可视化这类方案适合做统一监控面板，把图库、Redis、对象存储的关键指标放在一屏。它基于配置即代码的思路，仪表盘能进版本管理，比手工在界面点出来再导出 JSON 要靠谱得多。

指标采集的粒度建议：写入延迟按分钟聚合、队列滞后按 10 秒采样、磁盘使用率按小时。粒度太细会拖垮监控系统本身，太粗又发现不了瞬时尖峰。

5.4 几个高频故障的排查顺序

出问题时，按固定顺序排查能省很多时间。

症状一：写入越来越慢。先查磁盘 IO 和剩余空间，再看事务日志大小，最后看是否有超长事务未提交。图库对磁盘延迟极其敏感，机械盘换成 SSD 的提升经常是数量级的。

症状二：查询突然变慢但数据量没变。先看页缓存命中率，通常是被其他大查询挤占了内存。查一下最近有没有人跑了不带LIMIT的全图扫描。

症状三：前端图加载一半卡住。先看返回的节点数是不是超过了几千，再看布局算法是不是还在跑力导向。这时候应该在后端加聚合或分层，而不是继续优化前端渲染。

症状四：任务提交了但一直不执行。查 worker 进程是否存活、broker 连接是否正常、队列里是不是积压了。Redis 作为 broker 时，如果 db0 被其他业务写满了内存触发淘汰策略，任务可能直接丢失——所以 broker 用的 db 不要和缓存共用。

6. 踩过的坑和后来改掉的做法

把几个印象最深的写下来，都是文档里不会提的。

第一坑：把二进制内容塞进图库属性。一开始图省事，PDF 的文本提取结果直接存在节点属性里，单条几万字符。结果图库文件三个月涨到 400 GB，查询性能断崖式下跌。后来全部迁到对象存储，属性里只留 key，同样的数据图库缩到 30 GB。

第二坑：节点 ID 用名称。早期图省事用实体名称做唯一标识，很快遇到同名不同实体的问题——两个人叫同样的名字，直接被合并成一个。改成"来源 + 来源主键"生成稳定 ID 之后彻底解决。这个改动越早做越省事，等图里几十万节点再改，清洗成本高得离谱。

第三坑：大屏每次刷新重建整个图。布局重跑导致画面剧烈跳动，看着非常业余。改成增量更新节点属性、保留 simulation 实例之后，视觉上就平稳了。

第四坑：KEYS *干掉过一次缓存实例。排查问题时顺手敲了，Redis 直接卡住十几秒，所有接口超时。后来在所有环境都禁用了KEYS、FLUSHALL这类命令，用rename-command直接改名。

第五坑：备份只做了图库。有次误删了对象存储里的一个桶，图库备份完好但所有节点的doc_uri全成了死链，等于图谱只有骨架没有内容。后来把对象存储的跨集群镜像加进了例行任务。

最后分享一个我觉得挺有用的小习惯：给图谱的每次批量写入都打一个batch_id，记录在关系属性上。这样当发现某批数据有问题时，可以直接按batch_id定位并回滚，不用全量重跑。这个字段的成本几乎为零，但真出事的时候能救命。

至于后续怎么扩展，我目前在做的是把图谱的变更记录成事件流，这样不仅能回滚，还能做时间维度的图谱演化可视化——同一批实体在不同时间点的关系变化，用动画播放出来，比静态图直观得多。这块还在摸索，等跑通了再来写一篇。