2、图数据库选型：Neo4j、JanusGraph、ArangoDB、TigerGraph 对比与适用场景

做图数据库选型，我承认，刚开始接触药物知识图谱那会儿，我也挺懵的。市面上叫得上名字的图数据库少说也有十几种，光流行的那几个就够你纠结一阵子。今天咱们就掰开揉碎，把 Neo4j、JanusGraph、ArangoDB、TigerGraph 这四个主流选手的核心差异讲清楚。

先看一张总览图，了解它们各自在技术栈中的位置和架构特点：

这张图基本把四个库的骨骼画出来了。下面我们挨个拆解，结合我实际踩过的坑和见到的案例来聊。

2.1 Neo4j：国内图数据库圈子里的"正统"派

我最早用的就是 Neo4j。说白了，很多人学图数据库就是被 Neo4j 带入门的。它的社区版免费、单机部署简单，一个 java -jar 就能跑起来，非常接地气。

适合谁？ 团队规模不大、图数据量在十亿以下、且团队熟悉 Cypher 查询语言。Cypher 的语法非常直观，你看着查询语句就能想象出图中路径的样子。

举个药物知识图谱里的例子：

MATCH (d:Drug {name: '阿司匹林'})-[:靶向]->(p:Protein {name: 'COX-1'})
OPTIONAL MATCH (p)-[:参与通路]->(pw:Pathway)
RETURN d, p, pw

这段代码你几乎不用动脑就知道在干什么：找阿司匹林靶向的蛋白，再找这个蛋白参与的通路。

但要注意，Neo4j 原生存储强依赖图模型的局部性。我遇到过有人在单机上堆了 20 亿节点，结果写入速度和查询都开始打折扣。嗯，别误会，Neo4j 本身没毛病，但它更适合"图数据不可分割地挂在一台机器上"的场景。

它的企业版虽然支持集群（Causal Cluster），但从我自己和同行交流的经验看，要把它跑成大规模分布式生产集群，运维成本并不低。

2.2 JanusGraph：Hadoop 生态圈的"老黄牛"

JanusGraph 是开源的分布式图数据库，本身不存储数据，底层依赖 HBase、Cassandra、Elasticsearch 等。你想想看，这就意味着你可以把图数据跟公司现有的 Hadoop 大数据栈放在一起。

我在做一个千人规模的药物关系计算平台时，用 JanusGraph 对接过已有的 HBase 集群。那时候团队已经有成熟的 HBase 运维经验，所以 JanusGraph 的接入成本几乎为零——后端存储早就有人在维护了。

JanusGraph 的优点是什么？ 底层存储的可替换性、索引的可扩展性、以及与 Spark/MapReduce 的天然整合。你可以在 JanusGraph 上用 Gremlin 做实时查询，同时用 Spark 做批量图算法。

// JanusGraph 的配置示例（后端用 HBase）
// conf/janusgraph-hbase.properties

storage.backend=hbase
storage.hostname=zk1,zk2,zk3
storage.hbase.table=my_drug_graph

index.search.backend=elasticsearch
index.search.hostname=es1,es2
index.search.elasticsearch.client-only=true

不过，JanusGraph 也是一把双刃剑。它的性能瓶颈通常不在图引擎本身，而在底层存储。我有个朋友在金融风控场景里踩过坑：HBase 某台 RegionServer 挂了，整张图查询被打到熔断。这种场景下，你需要额外投入运维精力。

所以 JanusGraph 适合谁？ 你们公司已经是 HBase/Cassandra 大户，有专门的 Hadoop 运维团队，图数据量百亿级起步，需要跟大数据生态深度绑定

2.3 ArangoDB：多模型的"变形金刚"

我接触 ArangoDB 比较晚，但一上手就被它的多模型设计吸引了。说白了，它一个引擎里同时支持文档、KV 和图，而且三种模型的数据可以混查。这非常契合药物知识图谱里的一个现实：很多实体属性本身就是复杂的文档结构。

举个例子，一个药物的"分子结构"、"临床实验指标"这些信息，如果用纯图模型硬存，要么变成一堆属性值导致图爆炸，要么变成一堆小节点拖慢遍历。但在 ArangoDB 里，你可以把临床实验指标存为文档集合，药物节点指向文档 ID，查询时通过 AQL 把图和文档 JOIN 起来。

// ArangoDB AQL 示例：查靶向某蛋白的药物，同时返回药物的临床实验文档

FOR p IN Proteins
  FILTER p.name == 'COX-1'
  FOR d, e IN 1..1 INBOUND p GRAPH 'drug_target_graph'
    LET trials = (
      FOR t IN ClinicalTrials
        FILTER t.drug_id == d._id
        RETURN t
    )
    RETURN { drug: d.name, trials: trials }

我个人很喜欢 ArangoDB 的 SmartGraph 功能。在分布式环境下，它会自动把频繁关联的节点放在同一台机器上，减少跨分片查询。我帮一个做药物重定位的创业公司做过测试，SmartGraph 确实能把批量路径查询的延迟降低 40% 以上。

不过，ArangoDB 的图算法丰富度不如 Neo4j 和 JanusGraph 的 Gremlin 生态，更适合你对图的需求是路径查询、模式匹配，而不是大量的全局图算法（比如 PageRank 迭代几百轮）的场景。

2.4 TigerGraph：为"深度链路分析"而生的"野兽"

TigerGraph，嗯，这个名字本身就透着一股性能至上的味道。它不是开源产品，但提供了一个免费的基础版本，也够你做中型图谱了。

TigerGraph 最让我印象深刻的是它的 MPP（大规模并行处理）架构。你想想，在药物知识图谱里最头疼的查询是什么？多层、多跳的关联路径。比如"从某个症状出发，关联到药物，再到靶点，再到通路，再到适应症"这种 5-6 跳的查询，很多图数据库会卡住。

TigerGraph 用了一套自有的分布式分区存储 + 编译型查询语言 GSQL，把图遍历过程编译成并行任务在集群上跑。我去年帮一个金融客户评估过，10 亿节点的图，跑 6 跳的路径查询，TigerGraph 比同配置的 Neo4j 快了一个数量级。

// TigerGraph GSQL 示例：查找与某个蛋白有关联的所有药物及通路标签
CREATE QUERY drug_pathway_analysis(STRING protein_name) FOR GRAPH drug_graph {
  SetAccum<STRING> @pathway_labels;
  Start = {Proteins.*};
  L1 = SELECT p FROM Start:p WHERE p.name == protein_name;
  L2 = SELECT t FROM L1:l -(targeted_by:e)- Drug:d
        ACCUM d.@pathway_labels += l.pathway;
  PRINT L2[L2.name, L2.@pathway_labels];
}

TigerGraph 的短板在于它的生态封闭、价格不菲。如果你们团队想用开源方案 + 社区支持，TigerGraph 可能不是首选。但在"查询响应时间比天还大"的超大规模场景里，它的性能优势无法替代。

2.5 综合对比一览

我习惯用一张表来终结选择困难症：

2.6 到底怎么选？

我个人的决策思路是这样的，你听听看有没有参考价值：

1. 先看数据规模：低于 10 亿节点，优先 Neo4j 或 ArangoDB。超过 50 亿，看你们团队是大数据出身还是纯后端出身，大数据出身倾向 JanusGraph，性能派倾向 TigerGraph。
2. 再看查询类型：如果 80% 的查询是 1-3 跳的路径查询、模式匹配，Neo4j 和 ArangoDB 都够用。如果动不动就是 5 跳以上大规模深度链路分析，TigerGraph 是唯一能把延迟压在秒级的选择。
3. 看周边生态：你们已有的数据平台是 Hadoop/Spark 还是存了一堆 JSON 文档？前者选 JanusGraph，后者选 ArangoDB。

嗯，选图数据库就像选工具，没有万能的锤子。我的经验是：从最小可行图谱开始，先用单机 Neo4j 跑通业务逻辑，性能扛不住了再往分布式迁移。千万别一开始就想搞一套百亿节点的千亿图谱——那步子跨太大了。