【图数据库内核】引擎对照句：TigerGraph、Neptune、AGE、Memgraph 与原生/图层分叉

第 13 篇把「外置宽行图层」钉清楚后，选型现场仍会甩出一串产品名。本篇只做一件事：用本系列已建立的坐标系写成可复用的对照句——不测、不排延迟榜、不替第 16 篇下最终决策。

本文是「图数据库内核」系列第 14 篇（共 16 篇）。→ 系列目录

篇目	核心内容
第 13 篇 · TinkerPop / JanusGraph	外置邻接表
第 14 篇 · 引擎对照	架构分叉句
第 16 篇 · 选型与 GraphRAG	决策收束

版本锚定：TigerGraph DB 文档（4.2 / current）Internal Architecture、Continuous Availability、Glossary；Deutsch et al., TigerGraph: A Native MPP Graph Database（arXiv:1901.08248，预印本，未经 peer review，只采架构描述）；Amazon Neptune User Guide Graph Data Model / Storage indexing / 与 Neo4j 架构差异页；Apache AGE Manual Overview / Graphs；Memgraph Docs Storage memory usage。本系列 Neo4j / JanusGraph 事实回指第 01–13 篇。

一、对照规则：五轴，不比「谁更快」

公开图基准常把工作负载、一致性级别、内存是否吃满、是否预热 page cache 搅在一起——第 01 篇已警告「基准误导选型」。本篇每个引擎只回答五轴上的机制位置：

读法：对照句回答「像不像、差在哪一层」；「该不该上」留给第 16 篇结合边语义与 GraphRAG。

二、TigerGraph：原生并行图（NPG）与 GSE / GPE

2.1 产品自称的架构位置

TigerGraph 文档用 Native Parallel Graph (NPG) 描述自己：本地存储与计算结合、支持实时更新、并按并行计算引擎方式工作。核心组件 GSE（Graph Storage Engine）与 GPE（Graph Processing Engine）以 C++ 实现；组件间消息传递，RESTPP 负责任务管理。交互面包括 GSQL 客户端、GraphStudio、REST。

Deutsch et al.（arXiv:1901.08248）把垂直栈写成三层：上层 GSQL 编译器 / GraphStudio / REST；中层标准与用户 UDF；底层 GSE + GPE。论文对二者职责的界定（采架构句，不采其附录基准数字）：

• GSE：ID 管理、元数据、拓扑在 cache / memory / disk 各层的存储管理；把图切成利于并行的压缩单元，并提供 CRUD 内核 API。
• GPE：以 BSP（Bulk Synchronous Parallel） 方式跑 UDF；管理 CPU / 内存 / 机器分区；调度任务时声明满足 ACID 事务语义并追求吞吐。

设计选择上的硬句（同文 §2）：

1. 原生图存储，明确拒绝「通用 NoSQL 上的虚拟图层」——理由是翻译开销 + 底层非为图操作优化（与第 13 篇 JanusGraph 路线形成直接分叉）。
2. 非强制全内存：可配置内存上限，放不下则溢写磁盘（企业版叙事）；编码压缩降低 footprint 与 cache miss。
3. 自动分区：出边与所属顶点落在同一 server（hash 定位置），便于局部遍历。
4. 分布式查询模式：大范围分析时可让多机协同；路径跨机时传递最小必要信息。
5. 编程抽象：顶点/边级并行存储+计算（think-like-a-vertex / edge 一脉）；语言层用 GSQL（SQL 风格 SELECT-FROM-WHERE + ACCUM / accumulator）表达迭代分析。

2.2 高可用对照句（相对第 12 篇）

Continuous Availability Overview：复制因子（RF）与分区因子（P）构成「\(P\) 分区 × \(R\) 副本」的二维布局；服务均匀分布；leaderless——副本平等，可服务读写；写同步后读可打任意副本；故障时调度绕开不可用节点。

与 Neo4j 第 12 篇对照：

2.3 对照句（收束）

TigerGraph ≈ 自研原生拓扑存储 + MPP/BSP 执行 + GSQL 分析语言；主叙事偏大规模并行遍历与迭代算法，而不是 Neo4j 那条「record/block 页缓存 + Cypher 计划器」说明书路径。厂商页上的加载/遍历吞吐数字是营销主张，本篇不转写为事实。

三、其它引擎：一条轴一句

3.1 Neo4j（本系列主线，回指）

原生指针/块存储 + page cache + Cypher 计划；Community aligned / Enterprise 推荐 block；默认 RC 与节点/关系锁（第 11 篇）；集群 primary/secondary + bookmark（第 12 篇）。选型时它是「拓扑一等公民且运维面收在图引擎内」的参照系，不是唯一答案。

3.2 JanusGraph + TinkerPop（第 13 篇）

可移植 Gremlin 接口 + Bigtable 宽行邻接表（边双写）；事务不必然 ACID；超节点靠 vertex-centric index。适合「已有 Cassandra/HBase 运维、要图层」而不是「只要一个更省事的图安装包」。

3.3 Amazon Neptune

User Guide：基本单元是 S/P/O/G 四元组（类 RDF quad）；属性图边/属性都编码进 statement；默认维护 SPOG / POGS / GPSO 三套语句索引覆盖常见访问模式（非六套全开，以降低资源）。存储为计算与存储分离的集群卷：段 10 GB 起跳、跨 AZ 六副本等（Storage 页）。相对 Neo4j，官方迁移文强调：Neo4j 偏「加载/查询/存储同机资源池」，Neptune 偏 OLTP + 共享分布式存储、读写实例解耦。

对照句：Neptune ≈ 托管四元组索引引擎 + 云共享存储；邻接局部性故事是「索引前缀命中」，不是 Neo4j x1 主块内联，也不是 TigerGraph 顶点共置出边分区。

3.4 Apache AGE（PostgreSQL 扩展）

Overview：目标是同一存储同时服务关系模型与图模型——ANSI SQL + openCypher。Graphs：每个图对应一个 Postgres namespace；顶点/边标签落成该 namespace 下的表（父表 _ag_label_vertex / _ag_label_edge，具体标签再派生子表）。

对照句：AGE ≈ 第 02 篇「边表 + 索引」路径的官方化扩展——hop 代价仍受 PG 缓冲池、索引与执行器支配，换得事务/备份/SQL 生态与站内 postgresql-kernel 同栈。多跳是否「够用」看扇出与递归/Cypher 计划，而不是换了一种磁盘魔术。

3.5 Memgraph

官方 Storage memory usage 三种模式：

对照句：Memgraph ≈ 内存优先的属性图引擎，用模式开关在「强事务 / 导入吞吐 / 落盘」之间切；ON_DISK 路径与站内 RocksDB 运维面相交，但产品叙事仍是图引擎而非通用 LSM 教程。

3.6 纯关系路径（无图引擎）

边表 + 二级索引，或递归 CTE / 物化路径——第 02 篇代价模型已覆盖。

对照句：当跳数浅、度数受控、团队 SQL 工具链沉没成本高时，先算清 \(\mathrm{Cost}_{\mathrm{edge}}\) 是否可接受，再决定是否引入图引擎运维面。

四、总表（机制位置，非评分）

flowchart TB
  Native["Native store<br/>Neo4j / TigerGraph / Memgraph-IM"]
  Layer["Graph layer on foreign store<br/>JanusGraph / AGE / Memgraph-on-disk"]
  Cloud["Managed graph service<br/>Neptune"]
  SQL["No graph engine<br/>edge table / recursive CTE"]
  Native --> Q["Pick by locality + language + ops"]
  Layer --> Q
  Cloud --> Q
  SQL --> Q

五、按工作负载形状选「先排除谁」（仍非最终选型）

下列是排除法提示，完整决策树在第 16 篇：

1. 深度多跳 + 要引擎内页局部性，且不想运维宽表集群 → 先看原生 store 族（Neo4j / TigerGraph / Memgraph-IM）；JanusGraph 的 \(C_{\mathrm{remote}}\) 要单独论证。
2. 已有 Cassandra/HBase，图是附加模型 → JanusGraph 图层句成立；不要假装得到 Neo4j block 共置。
3. 迭代全局算法（类 PageRank）且要 BSP/累加器语言 → TigerGraph / GSQL 叙事对口；用 Cypher 硬写全图迭代要另估计划与内存。
4. 必须留在 Postgres 进程与事务里 → AGE 或边表；接受邻接不是一等磁盘格式。
5. 云托管、少碰磁盘格式 → Neptune 一类；代价模型改成「索引模式 + 实例/存储扩展」，不是 Muninn page cache 调参。
6. 导入吞吐优先、可暂时放弃 ACID → Memgraph analytical 模式文档明确提供该权衡；不要与默认 transactional 混谈。

六、争论与开放问题

1. 原生 MPP vs 计划器+页缓存：TigerGraph / Pregel 谱系押「图即并行网格」；Neo4j 谱系押「持久化布局 + 声明式计划」。二者优化的瓶颈不同——全图多轮迭代 vs 选择性多跳 OLTP——用同一 LDBC 数字互刷没有信息量。
2. 「虚拟图层」是否永远吃亏：JanusGraph / AGE 证明运维复用有价；Deutsch et al. 指出的双层翻译惩罚在分布式宽表上往往表现为尾延迟，而不是大 O。
3. 开放问题：GQL 标准化是否收敛查询表面却仍留下存储分叉；四元组索引与 block 内联在幂律超节点上的可观测指标如何对齐；托管图服务把「store format」藏起来之后，排障是否退化为纯查询改写——第 15 篇从 Neo4j 主线给清单，其它引擎要做同构翻译而非照抄。

谱系：MPP 图计算接 Valiant BSP、Pregel/Giraph；原生并行图数据库把该计算模型与自研邻接存储绑死。四元组引擎接 RDF 语句索引传统。AGE 接「多模型共用 PG 存储」分支。本系列主线仍是 Neo4j 布局深度；本篇只把分叉画在地图上。

七、来源与实验台账（本篇）

八、小结

1. 对照只沿五轴写机制位置；延迟数字没有统一实验台账就不要进正文。
2. TigerGraph 是原生存储 + MPP/BSP + GSQL 分叉；JanusGraph 是外置宽行图层；Neptune 是四元组+托管共享存储；AGE 是 PG 表映射；Memgraph 用存储模式切换事务与内存权衡。
3. 排除法可以缩小集合；「何时必须原生图」的判决在第 16 篇，并接 GraphRAG 边语义。
4. 下一篇：回到 Neo4j 主线，把超节点、爆炸路径、内存与慢查询收成生产排障清单。

→ 系列目录 · 上一篇：TinkerPop / JanusGraph · 下一篇：生产排障