图数据库与图计算引擎选型
讲到图技术选型，我第一个反应就是——别上来就挑个“最火”的，得先搞清楚你手里要解的问题是什么。团伙识别场景里，你既可能要做亿级节点上的实时关联查询，也可能要跑全量图谱的社区发现算法。这两类任务，底层引擎完全不一样。
图数据库 vs 图计算引擎：先分清楚
很多人把这两个概念混在一起，其实它们干的活差别很大。我刚开始做项目时也踩过坑，以为装个Neo4j就能搞定所有事情，结果跑个LPA算法等了半小时……嗯，后来明白了：
- 图数据库：核心是OLTP，侧重单点/小范围查询——比如“查张三的所有二度联系人”，响应要求在毫秒到秒级。数据存在本地，支持ACID。
- 图计算引擎：核心是OLAP，侧重全图/大规模迭代计算——比如跑PageRank、社区发现，数据量动辄百亿边，计算可能需要分钟甚至小时级。
个人习惯：在做选型前，先画一张“查询 vs 计算”比例图。如果线上查询占80%以上，优先选图数据库；如果每天都要跑离线全图迭代，图计算引擎才是正解。
| 维度 | 图数据库 | 图计算引擎 |
|---|---|---|
| 典型产品 | Neo4j, JanusGraph, NebulaGraph, HugeGraph | Spark GraphX, GraphScope, PowerGraph, Plato |
| 查询模式 | Cypher/Gremlin，点查、邻居遍历 | Pregel API，迭代消息传递 |
| 数据规模 | 单机千万级，分布式百亿 | 千亿边起步 |
| 响应时间 | 毫秒～秒 | 分钟～小时 |
| 典型场景 | 实时风控、社交推荐、身份关联 | 社区发现、影响传播、全量统计 |
选型决策的四个核心维度
我不会列一堆生硬的参数对比表，那样你看着也累。直接分享我在团伙识别项目里总结出的四个筛选项：
- 数据规模：节点数+边数决定存储和计算是否能落地。千万级以内单机Neo4j足够圆润；十亿级以上必须分布式方案（JanusGraph + HBase / NebulaGraph）。
- 查询模式：如果主要是“根据手机号查关联设备-查同设备注册人”这类多跳遍历，图数据库体验远好于用Spark写Map Join。反之，如果要跑连通分量、标签传播，图计算引擎效率高一个数量级。
- 实时性要求：在线风控要求亚秒级响应，必须上图数据库或者带索引的KV存储。离线批量分析可以容忍分钟延迟，选GraphX或者GraphScope就行。
- 运维成本：这一点容易被忽略。我见过团队选了JanusGraph + Cassandra + Elasticsearch，搞了三个月还没调通集群。如果你团队只有2个人，老实说Neo4j企业版或者NebulaGraph托管服务更省心。
我曾经在一个欺诈团伙识别项目里，数据量只有500万节点、3000万边，部门非要上JanusGraph分布式集群。结果上线半年，单机Neo4j照样能扛，分布式集群光ZK脑裂就修了三回。所以选型别盲目求大，够用就好。
主流引擎速览与对比
下面这张SVG图我把几款主流引擎按“在线/离线”“开源/商业”做了个分布，方便你快速定位。注意看配色——红色节点代表图数据库，绿色节点代表图计算引擎，紫色节点是混合型（比如GraphScope既能当数据库也能做计算）。
实战避坑清单
最后列几个我亲手填过的坑，希望你看到时能少走点弯路：
- 不要迷信“原生图存储”：JanusGraph底层依赖第三方存储，写入性能受限于HBase/Cassandra。我之前用JanusGraph做批量导入，数据量超过10亿边后HBase Region分裂导致写入抖动，后来换NebulaGraph才稳定。
- 图计算引擎的“内存假象”：Spark GraphX默认把所有数据放在内存，你以为内存够，但一旦做多轮迭代，shuffle开销直接爆炸。实际项目里建议先估算边数×属性的内存占用，留20%冗余。
- GraphScope的“全栈”陷阱：GraphScope确实很强大，但部署复杂度高，团队如果没有Kubernetes运维经验，建议先PoC。我有个同事就卡在集群网络配置上整整一周。
- 选型后一定要做数据同步设计：如果同时用图数据库和图计算引擎，两者之间的数据一致性是个大坑。最简单的做法是用消息队列，图库写时发事件，计算引擎定时拉全量快照。
特别提醒：团伙识别场景里，很多时候“关系”是动态变化的——今天A和B是交易对手，明天就变成代理人。如果你的图数据库不支持增量更新（比如某些压缩存储格式），那数据时效性就会出问题。选型前务必确认引擎的更新模式。
好了，选型这块的核心思路就在这里了。你可能会说“这么多选项，到底哪个适合我？”我的建议是——拿自己业务中最大的子图（比如100万节点、500万边），找两种不同类型的引擎各跑一轮，用数据说话。不要只看PPT参数。