要单独建边集合；边应存于独立edges集合，用字符串ID、复合索引和唯一索引保障性能与一致性，属性拆分至edge_attrs，避免嵌套与数组多值。
边文档要不要单独集合？
要，而且必须分。MongoDB 里把节点和边混在同一个集合，查邻居、删关系、更新权重时会触发全集合扫描或大量冗余读取。边本质上是二元关系，天然适合独立集合，比如 edges 集合存 from_id、to_id、relation_type、weight 这些字段。
常见错误现象：find({ $or: [ { from_id: "A" }, { to_id: "A" } ] }) 在混合集合里跑得慢，加索引也救不了——因为节点文档体积大、结构不一致，BSON 解析开销高。
- 边集合用复合索引
{ from_id: 1, relation_type: 1, to_id: 1 }支持正向遍历 - 反向查（谁指向 A）补一个
{ to_id: 1, relation_type: 1 } - 别在边文档里嵌套节点详情，哪怕只嵌 name —— 冗余写入 + 不一致风险
节点 ID 用字符串还是 ObjectId？
统一用字符串。ObjectId 是 MongoDB 自增时间戳+机器码生成的，对知识图谱没语义，且跨系统导入/导出时难对齐；而业务主键（如 "person_123"、"org_CN001"）可读、可验、可拼接、可做 sharding key。
使用场景：多源数据融合（比如从 MySQL 同步用户，从 Neo4j 导出机构），ID 必须能无损映射。用 ObjectId 会导致两边 ID 不一致，后续关联边时得额外建映射表，纯属自找麻烦。
- 节点集合
nodes的_id字段直接设为业务 ID 字符串 - 边集合的
from_id和to_id必须与节点_id类型完全一致 - 如果历史数据用了 ObjectId，别硬转，用
alt_id字段存原始业务 ID，主键仍用字符串
关系属性太多怎么存？
拆成两个集合：核心边（轻量）+ 边属性（可选扩展）。核心边只保留查询必需字段：from_id、to_id、relation_type、created_at；其余如 confidence、source、valid_from 等，存在另一个 edge_attrs 集合，用 edge_id 关联（edge_id 可以是 from_id + "_" + to_id + "_" + relation_type 拼接，或用独立 ObjectId）。
性能影响：单次查邻居只要 from_id，不需要加载全部属性；需要详情时再按需 lookup。否则边文档平均 2KB+，内存压力大，副本同步延迟高。
-
edges集合保持窄：5 个字段以内，总大小控制在 512B 内 -
edge_attrs上建索引{ edge_id: 1 }，避免$lookup全表扫 - 不要用数组存多值属性（比如
sources: ["web", "api"]），查某来源的关系时无法高效索引
如何避免边重复插入？
靠唯一索引，不是靠应用层判断。MongoDB 的 upsert 在高并发下可能产生双写，唯一索引才是最终防线。
容易踩的坑：只对 from_id 和 to_id 建唯一索引，漏了 relation_type —— 导致 “A 是 B 的员工” 和 “A 是 B 的投资人” 被当成同一条边拒掉。
- 在
edges集合上建唯一复合索引：{ from_id: 1, to_id: 1, relation_type: 1 } - 如果允许同一对节点存在多个相同类型的关系（比如不同时间点的两次合作），就加一个区分字段，如
version或timestamp，并纳入唯一索引 - 插入失败时捕获
11000 duplicate key错误，而不是重试或忽略
真正麻烦的是“关系方向模糊”的场景，比如“合作”“关联”这类无向边——得约定统一存储为小 ID → 大 ID，否则查一次得写两个条件。这个逻辑不在 schema 层，得压在写入 SDK 里，不然早晚乱。
