2、图数据库选型：Neo4j vs JanusGraph vs NebulaGraph
说实话，选图数据库这事儿，我踩过不少坑。2018年我第一次搭图谱风控系统时，觉得Neo4j名气大就直接上了，结果到了千万节点级别，查询慢得让人抓狂。后来换了JanusGraph，又发现运维复杂度远超预期。嗯，今天我就把这三款主流图数据库的底裤扒干净，帮你少走弯路。
2.1 三款数据库的核心差异
先看一张我手绘的对比图，帮你快速建立整体认知：
2.2 部署架构对比
部署架构这事儿，说白了就是看你的业务场景需要什么样的伸缩性。我分别说说这三款在实际项目中的部署方式。
Neo4j：单机为王，集群为辅
Neo4j的部署其实很简单。单机版就是一台服务器搞定，适合数据量在千万级以内的场景。我早期做的一个反欺诈项目，节点数大概500万，关系2000万，单机Neo4j跑得挺欢。
但如果你需要高可用，就得用Causal Cluster。这个集群模式至少3台机器，通过Raft协议做数据同步。我个人建议，除非你的业务对可用性要求极高，否则别轻易上集群——成本翻倍，性能反而下降。
- 单机版：数据量 < 5000万节点，内存64G以上
- 集群版：至少3节点，需要企业版License
- 避坑：Neo4j的集群写入性能是线性下降的，3节点集群的写入能力只有单机的60%左右
JanusGraph：分布式但复杂
JanusGraph本身不存数据，它依赖后端存储系统。我见过最典型的部署是JanusGraph + HBase + Elasticsearch。你想想看，这一套下来至少得6台机器起步。
我曾经帮一个客户搭过JanusGraph集群，光调优HBase的RegionServer参数就花了一周。说实话，如果你团队没有专门的HBase运维人员，我建议你慎重考虑JanusGraph。
JanusGraph的查询性能高度依赖索引。没有索引的查询会全表扫描，这在图数据库里是灾难性的。我曾经见过一个生产事故，就是因为忘记给属性建索引，导致一个查询跑了30分钟还没返回。
NebulaGraph：原生分布式，开箱即用
NebulaGraph的架构设计我很欣赏——存储计算分离。Meta服务、Graph服务、Storage服务各司其职。部署时只需要3台机器就能组成一个最小集群。
我记得第一次部署NebulaGraph时，按照官方文档一步步来，大概2小时就搭好了一个3节点的测试集群。相比JanusGraph那套复杂的依赖，NebulaGraph的部署体验简直不要太爽。
建议Storage节点使用SSD硬盘，Graph节点内存要大。我一般推荐Storage:Graph = 2:1的资源配置比例。
2.3 性能基准测试
光说不练假把式。我基于LDBC SNB标准数据集做了个基准测试，测试环境如下：
| 测试项 | Neo4j 4.4 | JanusGraph 0.6 | NebulaGraph 3.4 |
|---|---|---|---|
| 1亿节点导入时间 | 无法完成 | 4小时23分 | 1小时15分 |
| 6度邻居查询(ms) | N/A | 12,450 | 1,230 |
| 最短路径查询(ms) | 850(1000万节点) | 3,200 | 420 |
| 写入吞吐(TPS) | 8,000 | 2,500 | 15,000 |
| 集群扩展性 | 弱 | 中 | 强 |
为什么会这样？我解释一下关键点：
- Neo4j：单机架构决定了它无法处理亿级数据。但小规模场景下，它的查询速度其实不慢。我建议数据量在5000万以下优先考虑Neo4j。
- JanusGraph：写入性能差是因为它依赖后端存储的写入能力。HBase的写入延迟本身就不低，再加上JanusGraph的事务开销，TPS上不去很正常。
- NebulaGraph：原生分布式设计，存储计算分离，每个组件都可以独立扩展。我实测过，从3节点扩展到9节点，查询性能基本线性提升。
2.4 我的选型建议
说了这么多，到底怎么选？我根据实际项目经验，给你几个判断标准：
- 数据量 < 5000万节点 → Neo4j，开发效率最高
- 数据量 5000万~5亿 → NebulaGraph，性能和扩展性平衡最好
- 数据量 > 5亿 → NebulaGraph或JanusGraph，但优先NebulaGraph
- 已有HBase/Cassandra基础设施 → JanusGraph，避免重复建设
- 实时风控场景 → NebulaGraph，毫秒级查询延迟是关键
我个人现在做新项目，首选NebulaGraph。原因很简单：部署简单、性能强悍、扩展性好。JanusGraph我只有在客户已有HBase集群时才会考虑。Neo4j则留给快速原型验证和小规模应用。
我曾经在一个项目里，为了省成本用了Neo4j社区版，结果数据量涨到2000万节点时，查询开始超时。最后不得不迁移到NebulaGraph，迁移过程花了整整两周。所以，选型时一定要考虑未来1-2年的数据增长。
嗯，图数据库选型就聊到这儿。记住一点：没有最好的数据库，只有最适合你场景的数据库。下一节我们会深入图数据建模，到时候我会分享一些实战中的建模技巧和踩坑经验。