图数据库这四个字，这几年被提得太多，多到有点让人麻木。可真到项目里要选一款落地，多数人还是抓瞎：文档翻了一堆，每一家的官网都写着"高性能""分布式""易扩展"，看完照样不知道该选谁。我自己从最早用 Neo4j 做反欺诈关系圈，到后来带团队用 NebulaGraph 扛过十亿级边规模的图谱，中间还试过 JanusGraph、HugeGraph、Dgraph、ArangoDB、TigerGraph，踩的坑足够写一本小册子。这篇就把这七款图数据库放在一起做个比较，重点不在"谁最强"，而在"什么场景该选谁"。
如果你是刚接触图数据库的开发，看完能知道从哪下手；如果你正在做技术选型，看完至少能少开三次无意义的对比会；如果你是运维或数据工程，后半段的部署、导入、压测和排查经验可以直接抄。全文的部署命令和配置都经过实机验证，涉及的参数计算也会把过程写出来，方便你按自己的数据规模代入。
1. 先搞懂一件事：图数据库到底在解决什么问题
1.1 从多跳关联查询的痛说起
关系型数据库处理"一对多"很舒服，一旦要回答"我和我朋友的朋友的朋友之间有没有共同联系人"这种问题，就难受了。传统做法是写多层 JOIN，或者用递归 CTE。三层 JOIN 还能忍，五层以上执行计划就开始发散，中间结果集膨胀得离谱，十亿条边的图上跑一次深度查询，等几分钟是常事。
图数据库的思路完全不同。它把"关系"当成一等公民，物理存储上直接保存节点到节点的指针，遍历一条边接近 O(1)。这就是所谓的免索引邻接（index-free adjacency）。你从 A 点出发找它所有的邻居，不需要去扫任何索引，直接顺着指针跳过去就行。深度每增加一跳，代价只是多跳一次，而不是像 JOIN 那样重新做一遍集合运算。
这个差异带来的效果非常直观。同一个"六度人脉"查询，在 MySQL 上可能要几十秒，在 Neo4j 上通常是毫秒到几十毫秒级别。差距不是优化能弥补的，是模型层面的代差。
但也要说清楚，图数据库不是万能药。它的强项是关联关系密集、查询路径深度大、模式灵活多变这三类场景，典型代表是反欺诈团伙识别、推荐系统、知识图谱、权限关系、供应链溯源。如果你的业务就是每天跑固定的聚合报表，那 OLAP 列存数据库比图数据库合适得多，别硬上。
1.2 什么是数据库ER图，它和图模型差在哪
很多人搜"什么是数据库er图"，其实脑子里想的是"图数据库是不是就是画 ER 图那个东西"。这是两回事，得掰开讲。
ER 图（Entity-Relationship Diagram）是关系型数据库的设计图纸。它用矩形表示实体、椭圆表示属性、菱形表示关系，最后落到物理层就是一张张表和一堆外键。ER 图描述的是"结构"，本身不存数据。常用的画法就四步：先列出所有实体，再给每个实体定属性和主键，然后确定实体之间是一对一、一对多还是多对多，最后标注基数（1:1、1:N、M:N），多对多关系要拆成中间表。工具上，draw.io 免费够用，dbdiagram.io 写 DSL 出图很快，PowerDesigner 和 Navicat 适合老派团队。
图数据库里的"图"是数据本身。节点就是实体，边就是关系，属性和标签直接挂在节点和边上。你不需要先画好 ER 图再建表，因为图模型天然支持动态扩展——今天给用户节点加一个"风险等级"属性，不需要 ALTER TABLE，写进去就有了。
对比一下更清楚：ER 图里加一个新关系类型，你得改表结构、加外键、跑迁移脚本，DBA 还得评审；图模型里加一种新边，直接INSERT就行，schema 是可选的（Neo4j 允许无 schema，NebulaGraph 需要先建 Tag 和 Edge type，但改起来也简单）。所以做知识图谱这类"边类型会不断长出来"的场景，图数据库的迭代速度是关系库比不了的。
1.3 属性图与RDF：两条技术路线
选型前还有一个概念必须分清：图数据库分两大流派。
属性图（Property Graph）：节点和边都能带键值对属性，有标签做分类。Cypher、Gremlin、nGQL、GSQL、AQL 都属于这一派。工程上用得多，因为直观、好写、和业务代码贴合。
RDF 三元组：所有东西都是"主语-谓语-宾语"三元组，标准是 W3C 那套 SPARQL、OWL、RDFS。学术圈、语义网、部分医疗和生物信息项目爱用，好处是标准统一、推理能力强，坏处是表达复杂属性时比较绕，工程生态也弱一些。
本文比较的七款里，Neo4j、NebulaGraph、JanusGraph、HugeGraph、Dgraph、ArangoDB、TigerGraph 都是属性图路线。如果你的项目有强推理需求（比如要跑 OWL 本体推理），那可能得看 GraphDB、Virtuoso 这一类 RDF 库，不在今天讨论范围内。
2. 七种图数据库横向拆解
2.1 选型先定四个维度的硬指标
我评估图数据库只看四件事，顺序不能乱。
第一是数据规模上限。千万级节点，单机 Neo4j 完全够；上到十亿边，就得考虑分布式架构了。这里有个容易忽略的点：Neo4j 社区版不支持集群，企业版才有多集群（Causal Clustering），商务上要提前谈预算。
第二是查询语言与生态。Cypher 语法最舒服，学习曲线平缓；Gremlin 是图灵完备的，灵活但写起来啰嗦，团队上手慢；nGQL 和 Cypher 很像，迁移成本低；GSQL 是 TigerGraph 自有的，得重新学。语言选错，后面所有开发成本都会放大。
第三是一致性要求。金融风控场景要求强一致，就得看是不是支持 Raft/Paxos 这类共识协议；如果是离线分析为主，最终一致也能接受，那可选范围大很多。
第四是运维复杂度。JanusGraph 只提供计算层，你得自己搭 HBase 或 Cassandra 做存储、Elasticsearch 做索引，组件多、链路长、排查难。NebulaGraph 虽然是分布式，但组件边界清晰，相对好维护。这一点在人力紧张的团队里往往是决定性的。
2.2 七款产品逐个点评
Neo4j：属性图领域的标杆，原生图存储，Cypher 的发明者。单机性能极强，ACID 完整，生态和文档是最好的，出了问题基本能搜到答案。缺点也明显：社区版不能集群，水平扩展受限；企业版授权费不便宜。适合中小规模、强一致、快速验证的场景，比如 POC 阶段和中小型风控系统。
NebulaGraph：国产开源分布式图数据库，存算分离，graph、storage、meta 三类服务独立部署。nGQL 兼容 Cypher 的大部分习惯，学起来快。基于 RocksDB 做存储引擎，支持 Raft 一致性，实测在几十亿边的规模上横向扩展表现稳定。适合大规模图谱、需要自己掌控集群的场景。它的社区活跃度高，中文文档质量不错。
JanusGraph：Apache 顶级项目，典型特点是"只做计算，不碰存储"。存储后端可以接 HBase、Cassandra、BerkeleyDB，索引后端接 Elasticsearch 或 Solr。查询走 Gremlin，还能通过 Spark 做 OLAP。灵活是灵活，但整套链路组件太多，调优成本高，我见过不少团队卡在 HBase 的 Region 热点上。适合已有大数据基础设施（HBase 集群现成的）的团队复用资源。
HugeGraph：Apache 孵化项目，原百度内部产品开源。支持 Gremlin 查询，存储后端可选 RocksDB、HBase、MySQL，配套有可视化工具 HugeGraph-Studio 和 Hubble。优势是上手门槛低、和国内生态贴合好，单机版跑起来很快。适合中小团队做知识图谱、关系分析，规模特别大时会遇到一些扩展性瓶颈。
Dgraph：Go 语言写的，主打水平扩展和 GraphQL 风格的查询语言（DQL）。用 Raft 做一致性，Badger 做本地存储，天然支持分片和副本。它的卖点是"原生分布式、无单点"，部署简洁。缺点是生态相对小，中文资料少，一些复杂聚合查询的表达能力不如 Cypher 顺手。
ArangoDB：多模型数据库，文档、图、键值三种模型合一，查询语言是 AQL。如果你的场景是"一部分数据是文档、一部分是关系"，不想维护两套系统，它的价值就出来了。图遍历性能不错，但超大规模纯图场景不是它的主场。
TigerGraph：C++ 引擎，MPP 架构，主打深度链路分析和实时图计算，GSQL 支持类 SQL 的图查询和内置算法库。在金融反欺诈、电信网络分析这类需要跑 PageRank、社区发现、最短路径的场景里有优势。商业授权模式，社区版有功能和规模限制，选型时要仔细看条款。
2.3 一张表看清楚差异
| 产品 | 架构 | 查询语言 | 存储 | 扩展性 | 适合场景 |
|---|---|---|---|---|---|
| Neo4j | 原生图存储 | Cypher | 自研 | 单机强，企业版可集群 | 中小规模、强一致、POC |
| NebulaGraph | 分布式存算分离 | nGQL | RocksDB | 水平扩展好 | 十亿级图谱、自建集群 |
| JanusGraph | 计算层独立 | Gremlin | HBase/Cassandra | 依赖后端 | 已有大数据栈的团队 |
| HugeGraph | 单体/可扩展 | Gremlin | RocksDB/HBase/MySQL | 中等 | 知识图谱、关系分析 |
| Dgraph | 原生分布式 | DQL | Badger | 自动分片 | 高可用、GraphQL 生态 |
| ArangoDB | 多模型 | AQL | 自研 | 集群版支持 | 文档+图混合场景 |
| TigerGraph | MPP 并行 | GSQL | 自研 | 强 | 实时深度图计算 |
这张表建议收藏，选型会上照着念都能省半小时。但表只能给方向，真正决定成败的是细节，比如导入速度、并发能力、运维窗口，这些得靠实测。
3. 落地实操：从零把环境跑起来
3.1 Docker 起一个 Neo4j 并建第一张图
先用最快的方式把环境跑起来，验证概念。Neo4j 的 Docker 镜像开箱即用：
docker run -d \ --name neo4j-test \ -p 7474:7474 -p 7687:7687 \ -e NEO4J_AUTH=neo4j/test1234 \ -v $HOME/neo4j/data:/data \ -v $HOME/neo4j/logs:/logs \ neo4j:5这里有两个细节值得说。一是数据目录必须挂载出来，否则容器一删数据全没，我见过同事调试三天，重启一次前功尽弃。二是NEO4J_AUTH的密码至少八位，否则容器起不来，日志里会提示密码太短。
起来后打开http://localhost:7474，用 neo4j / test1234 登录。然后建第一张图：
CREATE (u1:User {name: '张三', age: 30}) CREATE (u2:User {name: '李四', age: 28}) CREATE (u3:User {name: '王五', age: 35}) CREATE (u1)-[:KNOWS {since: 2020}]->(u2) CREATE (u2)-[:KNOWS {since: 2021}]->(u3) CREATE (u1)-[:KNOWS {since: 2022}]->(u3); MATCH (a:User {name: '张三'})-[:KNOWS*1..3]->(b:User) RETURN a.name, b.name;最后那句*1..3就是变长路径查询，意思是沿着 KNOWS 边走 1 到 3 跳。这在 SQL 里要写递归 CTE，在图里就是一行。注意：变长路径不加范围限制（比如写成*）会在大图上炸内存，生产环境一定要写清楚上下界。
3.2 NebulaGraph 集群部署与关键配置
单机验证完，如果要上规模，NebulaGraph 是值得认真看的选项。官方提供了 nebula-docker-compose 仓库，三节点最小集群起法：
git clone -b release-3.8 https://github.com/vesoft-inc/nebula-docker-compose.git cd nebula-docker-compose docker compose up -d起来之后进 console 建图空间：
CREATE SPACE IF NOT EXISTS risk_graph ( partition_num = 100, replica_factor = 3, vid_type = FIXED_STRING(32) ); USE risk_graph; CREATE TAG IF NOT EXISTS user (name string, risk_score double); CREATE EDGE IF NOT EXISTS transfer (amount double, ts timestamp);参数计算是这一步的重点，很多人直接抄示例值，结果要么资源浪费要么性能不足。partition_num 决定数据分片数，经验公式是：单副本数据总量（GB）× 2 到 3，再对齐到集群磁盘数的整数倍。比如你的图数据单副本 30 GB，取 60 到 90 个分区，集群有 3 台机器各挂 2 块盘，就取 72 或 90。分片太少会导致单分片过大、热点严重；太多则元数据开销和跨分片查询成本上升。
replica_factor 是副本数，生产环境至少 3，能容忍一台机器宕机。测试环境设 1 就行，省资源。
vid_type也值得说一句。如果你的点 ID 是定长字符串（比如 32 位 MD5），用FIXED_STRING(32)比STRING省内存、检索更快；不定长的就用STRING。这个选择在建 space 时就定死了，后期改不了，必须提前想清楚。
3.3 数据导入的三种常用姿势
数据导入往往是整个项目里最耗时的一环，我按数据量给出三种做法。
小批量（百万级以内）：直接用 Cypher 或 nGQL 的 LOAD CSV。Neo4j 的写法：
LOAD CSV WITH HEADERS FROM 'file:///users.csv' AS row CREATE (:User {id: row.id, name: row.name});记得把dbms.security.allow_csv_import_from_file_urls打开，并且 CSV 文件要放在 import 目录下，路径是相对于该目录的。
中大批量（千万到十亿级）：用官方导入工具。Neo4j 用neo4j-admin database import，NebulaGraph 用 nebula-importer。后者是老牌的 CSV 导入方案，通过 YAML 配置定义映射关系，支持并发和失败重试：
version: v3 description: import user data clientSettings: concurrency: 10 batchSize: 256 retry: 3 source: csv: path: ./data/user.csv withHeader: true tags: - name: user type: vertex vertex: vid: index: 0 function: hash tags: - name: user props: - name: name type: string index: 1concurrency和batchSize是关键参数。batchSize 一般从 256 或 512 起调，太大反而因为单次请求体过大引发超时；concurrency 建议设为 storage 节点 CPU 核数的 1 到 2 倍，再多会因为 Raft 复制竞争反而变慢。这是我压了很多轮测出来的经验值，不是拍脑袋。
增量同步：生产系统不可能一次性导入完就完事。常见做法是 CDC 或双写，Neo4j 有 Kafka Connect 插件，NebulaGraph 社区有 exchange 工具。这一块复杂度高，建议先用 T+1 批量补数跑起来，再考虑实时。
4. Bloom 可视化安装与图探索
4.1 图数据库 Bloom 安装的两种路径
"图数据库 bloom 安装"这个问题被搜得不少，说明踩坑的人多。Bloom 是 Neo4j 生态里的可视化探索工具，最早是一个独立的桌面应用，后来逐步整合进 Neo4j Desktop 和企业版服务端。所以它的获取方式和你用的 Neo4j 版本强相关，我按两种主流路径说。
路径一：Neo4j Desktop。这是最省事的。打开 Desktop，进入你的 DBMS，左侧有个"Graph Apps"面板，在可用应用列表里找到 Bloom，点安装。装完后启动，它会自动连到当前 DBMS，不用配连接串。这种方式适合个人开发和学习，零成本。
路径二：Neo4j 服务端插件。企业版用户可以把 Bloom 部署成服务端插件，供多个用户通过浏览器访问。大致步骤是：从官方渠道下载与 Neo4j 版本匹配的 Bloom 包，解压后把 jar 放进 Neo4j 的plugins目录，在neo4j.conf里加上扩展类配置，然后重启服务。有几个坑必须提醒：
- 版本必须严格对应，Neo4j 5.x 的插件放到 4.x 上，启动直接报类加载错误，日志里能看到
UnsupportedClassVersionError之类。 - 需要有效的许可文件，Bloom 服务端版是商业功能，没有 license 会启动失败。
- 端口别冲突，Bloom 默认走 7473，如果你的 Neo4j 已经占了，要改配置。
具体配置项和下载地址以你所用版本的官方文档为准，我的建议是：如果你的场景只是内部几个人看图谱，Desktop 版本完全够用，别为了"看起来正式"去折腾服务端部署，投入产出比很差。
4.2 Bloom 的搜索语法与典型场景
Bloom 的核心价值在于不用写查询语句也能探索图。你在搜索框里输入关键词，它会基于你预先定义的搜索短语（Search Phrases）去找对应的节点，然后点开节点看它的邻居，一层层展开。
它支持几种搜索形式：按标签搜（比如User列出所有用户），按属性搜（输入名字直接命中），还有自然语言式的短语，比如配置好规则后可以直接输"张三的朋友"，它就返回一跳邻居。这个"短语"需要在 Bloom 的透视配置里预先定义，本质上是把一段 Cypher 模板参数化。
我实际用下来，Bloom 最适合三类场景。一是风控案件复盘，把涉案账号和转账关系展开成图，肉眼就能看出环形转账和资金归集点。二是数据质量排查，看有没有孤立节点、有没有异常的自环边。三是给业务方演示，比在 Browser 里敲 Cypher 有说服力得多。
要注意的是，Bloom 面向的是"探索"，不适合做固定报表。如果每天都要输出同一张图，用 Cypher 写死然后导出更靠谱。
4.3 不想花钱的替代可视化方案
不是所有团队都愿意为可视化掏钱。免费替代方案其实不少，效果也够用。
Neo4j Browser自带的图视图，写 Cypher 直接出图，缺点是节点超过 300 个就会卡，适合小规模验证。NebulaGraph Studio是 Nebula 官方配套，支持 nGQL 查询和图探索，浏览器直接开，功能完整。HugeGraph Hubble是 HugeGraph 生态里的可视化平台，支持图查询、图分析、Schema 管理。Gephi适合做离线分析和图算法可视化，导入 CSV 就能跑社区发现，但它不连数据库，属于导出后分析的路子。
如果这些都不满足，还有个终极方案：用 ECharts 的 graph 类型自己写前端。后端提供接口返回节点和边数组，前端渲染力导向图。我做过一个五百行代码的版本，支持点击展开、按类型着色，效果不比商用工具差，而且完全可控。缺点是布局算法要自己调，节点多了性能得做虚拟化。
5. 压测、调优与踩坑记录
5.1 压测方案怎么设计才不白测
我见过太多压测报告只写了一个 QPS 数字，没有任何上下文，这种报告毫无价值。一份能用的压测方案必须固定变量。
首先是数据集要真实。用随机生成的均匀分布数据压出来的结果，和真实业务里幂律分布（少数超级节点连接大量普通节点）的结果能差十倍以上。所以造数据时要有意识地注入热点，比如让 1% 的节点承担 40% 的边。
其次是查询要覆盖典型模式。至少包含四类：点查（按 ID 找节点）、一跳邻居、多跳路径（3 到 6 跳）、聚合统计。每类单独压，也要按真实业务比例混合压。
并发数的确定可以用利特尔法则估算：并发数 = 目标 QPS × 平均响应时间（秒）。假设你希望支撑 2000 QPS，实测平均响应时间是 20 毫秒，那么需要的并发是 2000 × 0.02 = 40。压测时从这个值的 50% 开始，逐步加压到 150%，找到拐点。
监控指标不能只看 QPS。P99 延迟比平均值重要得多，平均值好看但 P99 爆掉的情况太常见了。另外要看 CPU、内存、磁盘 IO、网络带宽、GC 停顿。图数据库对内存特别敏感，Neo4j 官方给过一个经验值，大约每 100 万节点或关系对应 1 GB 内存量级，实际要按你的属性大小和查询复杂度往上加冗余。如果你有 5000 万节点加 2 亿条边，粗算就是 25 GB 起步，再乘个 1.5 到 2 的安全系数，64 GB 内存的机器是比较稳的配置。
5.2 查询优化的几个硬手段
图查询优化，八成的问题出在三个地方。
第一，变长路径一定要限制范围。MATCH (a)-[*]->(b)这种写法在生产环境等于自杀。要写成[*1..4]，并且加上标签约束，让引擎能快速定位起点。
第二，索引要用对。Neo4j 建索引：CREATE INDEX FOR (u:User) ON (u.id)。但注意，索引只加速起点定位，一旦进入遍历阶段，走的是指针而不是索引。所以如果你的查询是"从某个已知 ID 出发找六跳内的所有人"，建好起点索引就够了；如果是"找出所有 risk_score 大于 0.8 的用户"，那需要索引辅助过滤，但过滤完之后还是靠遍历。
第三，控制返回结果集。大图上跑一个没有 LIMIT 的查询，可能瞬间把内存打满。养成习惯：探索阶段一律加LIMIT 1000，确认逻辑对了再放开。
对于 NebulaGraph，还有一条经验：尽量让查询在单分片内完成。跨分片查询需要协调节点聚合，延迟会明显上升。如果你的查询模式总是跨分片，可能说明分区键选错了。
5.3 我真实踩过的坑
说几个印象深刻的。
坑一：Bloom 版本不匹配。有次升级 Neo4j 到 5.x，忘了同步升级 Bloom 插件，结果服务起不来，日志报的是插件类版本不兼容。排查花了两个小时，最后发现只是版本号对不上。后来我在部署脚本里加了一条版本校验，两边版本号不一致直接拦住。
坑二：批量导入时把磁盘写爆。用 importer 导十亿条边，没估算临时文件大小，导到一半磁盘满了，整个任务失败还留下几 GB 的临时数据。教训是：导入前先用df -h看剩余空间，预留至少数据量 1.5 倍的空间，并且开启断点续传相关配置。
坑三：超级节点导致的倾斜。某个行业客户有个"平台账号"节点，连接了几百万条边。查询只要碰到这个节点，单分片的 CPU 立刻打满，其他分片闲着。解决办法是把超级节点单独打标，查询时用条件排除，或者对这类节点的边做额外拆分。这是大图项目里非常典型的问题，选型时就要考虑目标库对超级节点的处理能力。
坑四：把图数据库当关系库用。见过团队把用户表原样搬进图数据库，所有查询都是一跳，完全没有多跳需求，结果性能还不如原来的 MySQL。记住，图数据库的价值在"关系"，不在"存储"。
6. 常见问题速查表
6.1 高频故障对照表
| 现象 | 可能原因 | 排查方向 |
|---|---|---|
| 查询突然变慢 | 命中超级节点、索引失效 | 用 PROFILE 看执行计划，检查是否全表扫描 |
| 导入中途失败 | 磁盘满、内存不足、连接超时 | 查磁盘余量、调整 batchSize、看服务端日志 |
| 集群节点掉线 | 网络抖动、Raft 选主、时钟漂移 | 检查 NTP 同步、看心跳日志 |
| 内存持续增长不释放 | 缓存配置过大、查询结果集过大 | 调小缓存参数、检查是否有无 LIMIT 查询 |
| 写请求超时 | 分片热点、副本同步慢 | 看分片数据分布、检查磁盘 IO |
| Bloom 打不开 | 版本不匹配、端口冲突、许可过期 | 核对版本号、查端口占用、验证 license |
这张表建议贴在工位上。图数据库的问题八成逃不出这几类，先按表排查，能省大量时间。
6.2 运维阶段的几条经验
第一，监控要覆盖到分片级别。只看集群整体指标是不够的，分片之间的数据倾斜往往才是性能问题的根源。NebulaGraph 的SHOW STATS能看到各分片的点和边数量，定期看一眼，发现某个分片数据量远超其他，就该考虑重新分片了。
第二，备份策略要区分全量和增量。全量备份周期可以长一些（比如一周一次），增量要勤（每天甚至每小时）。图数据库的备份不像 MySQL 那么成熟，很多库需要停写或者快照，测试环境一定要先演练恢复流程，别等到真出事才发现备份是坏的。
第三，schema 变更要谨慎。Neo4j 无 schema 很自由，但自由带来的代价是数据质量失控，谁都能往里写奇怪的结构。我的建议是：即使是 Neo4j，也要在应用层定义好规范，什么类型的节点有哪些必填属性，用代码约束住。NebulaGraph 需要显式创建 Tag 和 Edge，反而倒逼了规范。
第四，版本升级不要跳大版本。图数据库的存储格式、RPC 协议在不同大版本之间经常不兼容。升级路径要按官方文档一步步来，先升中间版本再升目标版本。生产升级前，务必在同等规模的数据集上做完整回归。
第五，团队要有一个人懂存储层。图数据库的很多问题最终会落到 RocksDB 的 compaction、HBase 的 Region 分裂、磁盘 IO 这些底层机制上。如果团队里没人愿意往下钻，遇到复杂问题就只能等社区回复，那就很被动了。
这七款图数据库我都实际跑过，如果让我给一个最简单的选型建议：一亿边以内、团队人少、要快速出结果，选 Neo4j；数据量往上走、要自主可控、能接受运维投入，选 NebulaGraph；已经有 HBase 大数据栈、想复用的，看 JanusGraph 或 HugeGraph；需要实时跑图算法的，评估 TigerGraph。至于 Dgraph 和 ArangoDB，适合有特定技术偏好或者混合模型需求的团队，不是通用首选。
最后分享一个我自己的习惯：任何图数据库选型，我都会先用真实业务数据的十分之一做个 POC，跑三件事——全量导入、五类典型查询压测、模拟一次节点故障恢复。这三件事跑通，基本就能判断这套方案靠不靠谱。花两周做 POC，比开两个月选型会划算得多。
