上个月给一个做供应链风控的团队做选型评审他们原本的方案是把关系全塞进 MySQL用七八层自连接去查某个供应商的上游三级原材料有没有落在制裁名单里一条 SQL 跑四十多秒业务方点一次查询要等一杯咖啡。这不是 SQL 写得不好是关系型数据库在处理变长路径这类查询时天生吃亏——每多一跳就多一次连接运算跳数一上去代价是指数级的。图数据库就是冲着这类问题来的。但它不是银弹市面上一堆名字听着都差不多的产品底层路线差得非常远有的把图结构直接做进存储引擎有的只是把图查询语言套在宽表存储上有的干脆是拼装出来的。这篇就把 Neo4j、NebulaGraph、Apache HugeGraph、JanusGraph、ArangoDB、TigerGraph、Amazon Neptune 这七款摆在一起按我自己踩过坑的标准做一次横向比较。适合正在做技术选型的后端和架构同学也适合想搞清楚图数据库到底和关系库差在哪的新手。1. 为什么选图数据库比选关系库更容易翻车1.1 图数据库真正擅长的是变长路径而不是存关系很多人第一次接触这类产品脑子里想的还是关系型建模那一套先画数据库 ER 图实体一张表关系一张中间表主外键连起来。这套思路搬到图数据库里会走偏。关系型里关系是二等公民只能靠外键和中间表表达图模型里顶点和边都是一等公民边本身可以带属性可以直接被索引可以有自己的类型。差别在哪里体现假设你要查A 认识的人认识的人里哪些同时关注了 B在关系型里是两次 self join勉强能撑如果要查最短路径在 6 跳以内或者某个资金账户的上游来源连接次数不可预期优化器基本没法给出好的执行计划。图数据库的核心能力就在这里给定起点沿着边往外扩展扩展的代价和图的整体规模关系不大只和你实际走过的边数量相关。这也是为什么反欺诈、知识图谱、推荐召回、IT 资产拓扑、权限血缘这些场景特别喜欢它。反过来说如果你的查询 90% 都是按 ID 查一行按时间范围聚合统计多表 join 出报表那上图数据库大概率是给自己找麻烦。图数据库的聚合分析能力普遍弱于成熟的关系库和数据仓库很多产品连标准的窗口函数都不支持。先把查询模式摸清楚再谈选型。1.2 七款候选的入选理由以及被我淘汰的那几个选这七款不是凑数是覆盖了当前主流的几条技术路线产品路线定位查询语言开源情况典型使用场景Neo4j原生图存储单机性能标杆Cypher社区版开源企业版收费知识图谱、中小规模高并发关联查询NebulaGraph分布式存算分离nGQL / openCypher 兼容开源千亿级点边、超大规模图谱Apache HugeGraph分布式后端可插拔Gremlin开源国内团队做关系网络、反作弊JanusGraph拼装式存储与索引解耦Gremlin开源已有 HBase/Cassandra 存量的大数据团队ArangoDB多模型图文档KVAQL社区版开源图与文档混合、内容关系推荐TigerGraph并行图计算引擎GSQL社区版有功能限制深度链路分析、金融风控Amazon Neptune云托管多语言支持Gremlin / openCypher / SPARQL闭源托管已经在云上、不想自己运维被我在这次评审里淘汰的还有几个RedisGraph 这条线已经不再积极演进新项目我不建议压上去Dgraph 的部署和运维门槛对中小团队偏重OrientDB 社区活跃度这几年掉得厉害。不是说它们不行是选型要看三年后的维护成本而不是今天跑 Demo 爽不爽。1.3 我用来对比的六项硬指标每次选型我都会固定拿这几个维度去卡避免被厂商的宣传材料带着跑存储模型原生图存储还是图查询层 通用 KV/宽表这决定了深链查询的下限。查询语言与生态语言的学习成本、客户端驱动是否齐全、有没有可视化工具。横向扩展能力是只能纵向升级还是能加机器线性提升。事务与一致性有没有 ACID、跨分区事务支持到什么程度、隔离级别是什么。导入与运维批量导入工具、备份恢复、监控指标是否开箱可用。成本结构开源协议、企业版授权模式、云上按小时计费的隐性溢价。下面逐个说。我会尽量把为什么这样设计讲清楚而不是只列参数。2. Neo4j把图结构做进存储引擎的老牌选手2.1 免索引邻接省下来的到底是什么Neo4j 最核心的设计叫免索引邻接index-free adjacency。翻译成人话每个顶点在磁盘上都直接记着它的第一条边在哪儿每条边记着它的起点、终点和上下一条边的位置。你要从一个顶点往外走一跳就是顺着指针读一次磁盘不需要再去查任何全局索引。这一点在关系型数据库里是做不到的。关系库查 join 必须先通过索引找到匹配行索引本身是 B 树数据量大了以后索引层级变高查找代价随数据量对数增长。Neo4j 的邻接遍历代价基本是常数级所以你会看到一个很有意思的现象在千万级点、上亿级边的数据集上Neo4j 做 3 到 5 跳的路径查询依然能压在百毫秒量级而同样数据的 MySQL 可能已经跑不出来了。代价也明显这种存储结构是为顺着边走优化的不适合全表扫描和聚合统计。你想算所有顶点的平均度数Neo4j 会比关系库慢。它天生就是点查和路径查的引擎。实际配置上最关键的一个参数是页缓存page cache。我的经验值是给它物理内存的 50% 到 70%剩余留给操作系统和查询执行。如果热数据能全部装进页缓存路径查询的尾延迟会明显收敛。容量估算不用太精确把顶点数、边数乘以各自的平均属性字节数再打个 1.5 倍的膨胀系数就够你做机器规划了。2.2 Cypher 的写法红利与执行计划陷阱Cypher 是我用过最舒服的图查询语言它用 ASCII 艺术画图MATCH (a:Company {name:甲方公司})-[:SUPPLIES*1..3]-(b:Company) WHERE b.riskLevel HIGH RETURN a.name, b.name, length(shortestPath((a)-[*]-(b))) AS hops LIMIT 50这段的意思是从甲方公司出发沿着 SUPPLIES 边往外走 1 到 3 跳找出风险等级为高的下游公司。可读性比 SQL 的层层嵌套好太多。但 Cypher 有个大坑变长路径和笛卡尔积。MATCH (a)-[*]-(b)这种不限制方向、不限制类型的写法会在稠密图上爆炸。我见过一个查询在测试环境跑了 200 毫秒上线后遇上几个超级节点度数上万的顶点直接跑到内存溢出。规避办法有三条变长路径一定要带类型和方向[:SUPPLIES*1..3]-比[*1..3]安全得多。用PROFILE或EXPLAIN看执行计划重点看有没有出现CartesianProduct和VarLengthExpand的大行数估算。对超级节点做预处理比如限制它的边采样或者把它的邻居预先聚合出来。提示开发阶段养成习惯任何带变长路径的查询上线前都跑一遍 PROFILE看 db hits 的绝对值。db hits 上千万的查询别指望在并发场景下表现良好。可视化这块补一句Neo4j Bloom 是配套的交互式探索工具装的时候注意三点Bloom 的版本必须和 Neo4j Server 的主版本对齐放错版本会在浏览器控制台报错而服务端日志一片安静独立部署 Bloom 需要企业版授权用 Desktop 的话是内置的插件方式是丢进plugins/目录后重启服务。Bloom 的价值在于让业务方自己拖拽着看关系不用每次找开发写查询做知识图谱类项目时省下的沟通成本比授权费值。2.3 从单机到因果集群能力边界与授权成本Neo4j 社区版只能单机跑企业版才有因果集群Causal Clustering。集群的形态是一个写主节点Leader 多个读从节点Follower 若干只投票不存数据的仲裁节点。写请求全走主节点读请求可以打到任意从节点主从之间用 Raft 协议同步。这个架构决定了它的写扩展性是有天花板的——只有单点写。如果你的场景是读多写少比如知识图谱查询、权限校验集群扩几个读副本就能撑住如果场景是高并发写入比如每秒几万条边的事件流实时入库Neo4j 集群会让你很难受。这一点和 NebulaGraph 这种原生分片的架构有本质区别。还有一个实际工程里经常被忽略的点索引和约束也要建。很多人从关系库转过来以为图数据库不需要索引结果发现按属性查顶点慢得离谱。给高频查询的属性建索引是必须的CREATE INDEX company_name_idx FOR (c:Company) ON (c.name); CREATE CONSTRAINT company_id_unique FOR (c:Company) REQUIRE c.id IS UNIQUE;唯一约束除了保证数据质量还能让MERGE语句在并发写入时不会写出重复顶点这在实时导入场景里是刚需。3. 分布式阵营的两种活法NebulaGraph 与 Apache HugeGraph3.1 NebulaGraph 的存算分离与 nGQL 的取舍NebulaGraph 的架构是三件套graphd负责查询解析和执行metad管元数据和集群调度storaged管实际数据存储底层用 RocksDB 做单机引擎。三个角色可以独立部署和扩容这就是所谓的存算分离。数据按分片partition打散到各个 storaged 上每个分片用 Raft 做多副本默认三副本。这种设计的好处很直接数据量涨了加 storaged查询压力涨了加 graphd互不干扰。千亿级点边的规模在它的设计目标里实际部署时我一个客户用了十几台机器跑几百亿边路径查询3 跳以内稳定在几十毫秒。它对超级节点的处理也比 Neo4j 友好因为数据是分片的热点不会全砸在一台机器上。nGQL 是个折中产物。早期版本它搞了一套类 SQL 的语法后来为了降低迁移成本在新版本里做了 openCypher 兼容层。我的建议是新项目直接用 nGQL 原生的GO语法它的语义更贴近数据分布写法也更明确GO 3 STEPS FROM company_1001 OVER SUPPLIES WHERE $$.company.riskLevel HIGH YIELD src(edge) AS from_id, dst(edge) AS to_id, edge.riskScoreGO N STEPS明确告诉引擎走几跳不像 Cypher 的变长路径那样容易写出不可控的计划。它的短板也要说清楚跨分片事务支持有限强一致的多点写入场景要谨慎设计通常得靠业务层补偿或者引入外部事务协调另外生态工具相比 Neo4j 要薄一些Cypher 的存量代码迁移过来需要改语法。还有一个坑是顶点 ID 的类型——默认是 64 位整型用字符串 ID 的话要在建图空间时显式声明VID_TYPE FIXED_STRING(N)N 要一次定够后面改不了很多人在导入数据时才发现 ID 被截断。3.2 HugeGraph 的后端矩阵与 Gremlin 兼容路线Apache HugeGraph 走的是另一条路兼容 TinkerPop Gremlin然后让你自己挑存储后端。它的可选后端包括内存、RocksDB、Cassandra、HBase、ScyllaDB索引后端可以选 Lucene 或者 Elasticsearch。这意味着如果你的团队已经有一整套 HBase 运维体系可以直接把图数据落在熟悉的存储上运维压力小很多。Gremlin 的写法是这样的g.V().has(company,name,甲方公司) .repeat(out(supplies)).times(3).emit() .has(riskLevel,HIGH) .path().limit(50)Gremlin 的表达能力比 Cypher 更强因为它是图灵完备的可以嵌逻辑、做分支、循环。代价是可读性差写复杂查询像在写 Lisp团队里没有一两个熟悉函数式写法的人会比较痛苦。而且 Gremlin 的执行计划更难调优一个repeat().until()写不好性能可能差两个数量级。HugeGraph 在国内的实践比较多配套工具链还算齐HugeGraph-Loader 做批量导入HugeGraph-Studio 做可视化HugeGraph-Tools 做备份和迁移。它的问题在于组件耦合较重一个完整的生产部署要拉起 server、loader、studio、hubble 好几个东西版本对齐是个体力活。3.3 导入、扩容、运维三件事的实测差异选型到最后真正决定成败的往往不是查询性能而是这三件事做起来顺不顺。批量导入NebulaGraph 有nebula-importer和 Spark 版的导入工具大数据量下走 Spark 是正解实测几十亿边级别的导入要以小时计但可以横向扩 executor 加速。HugeGraph-Loader 是基于 Spark 的配置项多但文档清楚。两者都要注意一件事导入前先建好索引和 Schema边类型、属性类型都要预先定义图数据库普遍是 Schema 相对严格的没有关系库那种先插数据再改表的自由。扩容NebulaGraph 加 storaged 后需要做数据均衡balance data / balance leader这一步会消耗 IO建议在业务低峰做而且要监控均衡进度。HugeGraph 换后端基本等于重新导入数据扩容依赖底层存储比如 HBase 自身的 Region 分裂所以它的扩容体验本质上取决于你选的存储后端选对了后端就白送选错了就得自建。运维监控NebulaGraph 暴露的指标比较全和 Prometheus 集成顺滑HugeGraph 靠 HTTP 接口取状态得自己补一些采集脚本。这块的实际工作量经常被低估等出问题了才发现连个 QPS 曲线都没有。4. 拼装派与多模型派JanusGraph 与 ArangoDB4.1 JanusGraph 的存储后端加索引后端组合矩阵JanusGraph 是我见过最乐高的图数据库。它自己不管存储只做图语义层把数据存到 Cassandra / HBase / ScyllaDB / BerkeleyDB把索引存到 Elasticsearch / Solr / Lucene。你可以自由组合存储后端索引后端适合场景要注意的坑CassandraElasticsearch写多读多、已有 Cassandra 集群ES 索引延迟导致写入后立刻查不到HBaseSolr已有 Hadoop 生态组件多JVM 调优复杂ScyllaDBElasticsearch追求低延迟写入ScyllaDB 运维经验要求高BerkeleyDBLucene单机开发、测试生产不可用无法横向扩展这个设计的最大优势是复用存量基础设施。团队已经有成熟的 Cassandra 集群和 ES 集群JanusGraph 几乎是零新增运维负担。劣势也很清楚跨两个系统的最终一致性。JanusGraph 的索引更新是异步的你写完一个顶点立刻按属性去查可能查不到得等 ES 的刷新间隔通常配置成 1 秒左右。这在高并发写入 立即读取的场景里会出问题常见的规避办法是关键路径用顶点 ID 直查走存储后端的精确读不经过 ES只有属性查询才依赖索引。4.2 Gremlin 在 JanusGraph 上最容易踩的性能坑JanusGraph 的性能调优八成问题出在三个地方。第一没用索引。Gremlin 的g.V().has(name,x)如果 name 没建索引会退化成全图扫描几百万顶点就是灾难。必须显式建mgmt graph.openManagement() name mgmt.getPropertyKey(name) mgmt.buildIndex(byNameComposite, Vertex.class).addKey(name).buildCompositeIndex() mgmt.commit()复合索引composite只支持等值查询混合索引mixed支持范围查询和全文检索但必须挂索引后端。这个区分很多人搞混建了复合索引然后写has(age, gt(30))结果索引不生效。第二事务没提交。JanusGraph 的写入在一个事务里不 commit 就不落盘。有人在循环里写了几万条边上一次 commit内存直接打满。第三OLAP 和 OLTP 混用。JanusGraph 支持通过 Spark 做全图分析OLAP但那个路径的资源消耗和在线查询完全不是一个量级千万别在同一个集群上跑。4.3 ArangoDB 用 AQL 把图、文档、键值装进一个引擎ArangoDB 的定位是多模型数据库同一个引擎里能存文档、键值和图。它的核心创新是边就是特殊的文档存在边集合edge collection里带_from和_to两个字段。这样一来图遍历和文档查询可以写在同一条语句里用 AQLFOR v, e, p IN 1..3 OUTBOUND company/1001 supplies FILTER v.riskLevel HIGH RETURN { company: v.name, hops: LENGTH(p.edges), path: p.vertices[*].name }AQL 的可读性介于 SQL 和 Cypher 之间学过 SQL 的人上手很快。它的优势场景是**图 文档混合**比如一个商品推荐系统商品详情是文档、用户行为是边、标签是键值用 ArangoDB 可以一个库全搞定不用维护两套系统做数据同步。代价是它在单一维度上都不是最强的。纯深链遍历性能打不过 Neo4j超大规模分布式能力不如 NebulaGraph。它赢在少一个组件就少一类故障。集群模式下 ArangoDB 用分片 副本RocksDB 引擎跨分片遍历的性能会明显下降做选型时一定要用自己的数据实测跨分片场景。4.4 两条路线各自的适用面我把这两个的判断标准简化成两句话如果团队已经有 Cassandra 或 HBase 且运维成熟图数据量在十亿级以内JanusGraph 是性价比很高的选择因为新增的运维成本接近于零。反过来如果团队没有大数据组件经验JanusGraph 会让你陷入排查问题不知道是图的问题还是存储的问题的泥潭。如果业务里图查询只占一部分另外一部分是文档检索和键值读写ArangoDB 值得认真评估。它的短板是超大规模但中小规模下开发效率的提升非常明显。我见过一个内容社区用它同时扛文章存储、标签关系和相关推荐省掉了一整套数据同步链路。5. 闭源与托管TigerGraph、Amazon Neptune 的取舍点5.1 TigerGraph 的 GSQL 与并行遍历引擎TigerGraph 的技术亮点是并行图计算。它的存储和计算都做了分片遍历的时候多个分片同时展开用一套叫累加器accumulator的机制做中间结果聚合。这让它在超深链分析比如 5 跳以上的路径枚举上有明显优势风控和反洗钱领域用得比较多。GSQL 的写法是查询 存储过程混合的CREATE QUERY findRiskPath(STRING startId, INT maxHops) { SumAccumINT pathCount; Start {Company.*}; Result SELECT t FROM Start:s -(:e)- Company:t WHERE s.id startId ACCUM pathCount 1; PRINT Result, pathCount; }这种写法的好处是可以把复杂逻辑预编译成过程调用时只传参省去了解析开销坏处是学习曲线陡跟 Cypher、Gremlin 都不兼容迁移等于重写。另外要注意社区版在集群规模和数据量上是有限制的生产用基本要走商业授权报价不算便宜做预算时要提前跟采购对齐。5.2 Amazon Neptune 的三套查询语言与管理边界Neptune 最大的特点不是技术是三种查询语言同时支持Gremlin属性图、openCypher属性图、SPARQLRDF 三元组。这意味着你做技术选型的时候不用先被迫决定用属性图还是 RDF可以先跑起来再收敛模型。RDF 这条路在需要遵循 W3C 标准、做数据互操作的场景里很有价值比如医药、科研、出版领域的数据集。底层存储是三可用区六副本写入自动同步故障切换对应用基本透明。你不用管分片、不用管副本、不用管备份脚本这些都是托管的。代价是看不见的边界慢查询的诊断手段比自运维少遇到性能问题很多时候只能提工单。成本随数据量线性上升按实例小时 存储 IO 计费冷数据放在那也在烧钱长期看比自建贵。迁移成本极高一旦数据进了托管服务想搬走要经历导出、转换、重新导入中间还有停机窗口。我的建议是短期项目、团队没有专职 DBA、数据量可控的情况下托管是理性的选择如果这个图谱会成为公司核心资产跑五年以上自建或者至少保留一套可迁移的方案更稳妥。5.3 云托管的真实账单与锁定风险算账的时候别只看实例单价。托管图数据库的成本至少包含四块实例费、存储费、IO/请求费、跨可用区流量费。其中 IO 费是最容易失控的图查询的随机读特别多一次深链遍历可能产生几千次 IO如果你的查询模式本身不优化账单会给你上课。我会在选型阶段做一个单位查询成本的测算挑十条典型查询各跑一万次记录总 IO 和耗时换算成钱。这个数字比任何性能报告都实在。同时把迁移出去需要多少人天也写进选型文档这不是要立刻迁移而是给未来的自己留条路。6. 七款横向总表与场景化选型路径6.1 关键能力对照表维度Neo4jNebulaGraphHugeGraphJanusGraphArangoDBTigerGraphNeptune存储模型原生图原生分布式图依赖后端依赖后端多模型原生分布式图托管原生查询语言CyphernGQL / openCypherGremlinGremlinAQLGSQLGremlin / openCypher / SPARQL横向写扩展弱单写主强取决于后端取决于后端中强强托管跨分区事务单机 ACID集群弱有限支持依赖后端弱支持支持支持深链性能强内存内强分片并行中中中强强可视化Bloom 成熟StudioStudio / Hubble第三方自带 Web UIGraphStudio需第三方运维成本低中高中高高低低商业版极低成本结构企业版按核授权开源免费开源免费开源免费社区版免费商业授权为主按用量付费6.2 按数据规模、查询深度、一致性要求走决策路径我在实际选型里会把决策简化成三步走。第一步看规模。点边总量在一亿以内单机 Neo4j 或 ArangoDB 完全够用别过度设计。上了十亿级就必须考虑分布式NebulaGraph、HugeGraph、Neptune、TigerGraph 进入候选JanusGraph 配合 Cassandra 也能撑。到了百亿千亿基本只剩原生分布式的几款而且要做分片键设计。第二步看查询深度和模式。大量 1 到 3 跳的点查任何一款都能应付选生态好的。需要 5 跳以上深度遍历或者全图算法优先考虑 TigerGraph、NebulaGraph 这类并行遍历引擎。第三步看一致性和写入模式。如果业务要求写进去立刻能按属性查到JanusGraph 配合 ES 的异步索引会让你很难受Neo4j 或者带强一致索引的方案更合适。如果是海量事件流持续写入、对延迟不敏感选支持高吞吐写入的分布式方案。6.3 三个典型场景的推荐组合场景一企业知识图谱几千万到几亿点边读多写少业务人员要自己探索关系。推荐 Neo4j 企业版配 Bloom。理由Cypher 生态成熟招人和培训成本最低Bloom 让业务方自助查询减少开发排期压力。预算紧张就用社区版单机加分片或者把冷数据归档。场景二超大规模关系网络百亿级点边需要在线 3 跳查询加离线全图分析。推荐 NebulaGraph 做在线查询配合 Spark 做离线图计算。理由是存算分离让查询和存储独立扩容成本可控而且 nGQL 的GO N STEPS语义明确不容易写出失控计划。场景三已有 Hadoop 生态想快速把图能力接进现有数据链路。推荐 JanusGraph 配 HBase 加 Solr。理由是几乎不新增运维对象数据可以和离线任务共享存储。前提是团队能接受异步索引带来的延迟。7. 别信评测报告用七天跑一遍自己的数据7.1 前 48 小时建模与数据导入任何第三方测评对你都没有参考价值因为图数据库的性能和数据分布关系极大。有没有超级节点、平均度数是多少、属性是宽是窄这些才是决定性能的关键。所以第一件事是把自己的数据抽一份样本出来规模控制在生产数据的 5% 到 10%但拓扑结构必须是真实的尤其是要包含那些度数异常高的顶点。导入阶段要记录三个数字导入总耗时、失败记录数、导入过程中的峰值内存。失败记录往往能暴露出建模问题比如顶点 ID 格式不统一、时间字段格式不一致、边的两端有悬空引用。这些问题在 Demo 数据里永远不会出现在真实数据里一抓一大把。# 以 Neo4j 为例用 UNWIND 批量导入比逐条 CREATE 快一个数量级 from neo4j import GraphDatabase driver GraphDatabase.driver(bolt://localhost:7687, auth(neo4j, password)) def batch_import(tx, rows): tx.run( UNWIND $rows AS row MERGE (a:Company {id: row.from_id}) MERGE (b:Company {id: row.to_id}) MERGE (a)-[r:SUPPLIES {year: row.year}]-(b) SET r.amount row.amount , rowsrows) with driver.session() as session: for chunk in chunks(all_rows, 5000): session.execute_write(batch_import, chunk)一个实操心得批量导入时批次大小不是越大越好。我的经验区间是 2000 到 10000 条之间具体取决于单条记录的大小。批次太大事务日志压力大反而变慢太小则网络往返开销占比过高。这个数字要在自己的环境上试出来别照抄别人的。7.2 中间三天查询模式覆盖与压力测试第二天开始跑查询。做法是把业务方提的需求整理成 10 到 20 条典型查询覆盖点查、1 跳、3 跳、5 跳、聚合统计、写操作每条都记录平均延迟、P99 延迟、返回行数。P99 比平均值重要得多图数据库的尾延迟经常因为碰上超级节点而抖动得厉害。压测要用真实并发模型。我见过太多团队用 100 并发去压一个实际只有 5 并发的场景然后在生产上发现瓶颈完全在别的地方。压测的目标不是刷出一个漂亮数字是找到性能开始劣化的拐点从多少并发开始P99 突然翘起来。这个拐点就是你未来的容量红线。同时要做破坏性测试故意在压测中注入写请求看读写混合场景下性能怎么变化故意让查询命中超级节点看会不会拖垮整个实例故意跑一条没有索引的查询观察它对其他查询的影响。这些信息在你上线后救命的时刻会体现价值。7.3 最后两天备份恢复、扩容与故障演练这一步最容易被跳过但恰恰是决定长期成本的地方。备份恢复做一次完整备份记录备份耗时和备份文件大小然后真的恢复一次。很多方案备份没问题恢复的时候发现版本不兼容、索引要重建、权限要重配恢复时间比预期长好几倍。恢复时间RTO和可接受的数据丢失量RPO必须在这两天里明确不能写待定。扩容演练加一台机器进去观察数据重分布耗时、对在线查询的影响、扩容后性能是否有提升。如果扩容后性能没变化甚至下降说明瓶颈在别的地方通常是查询本身或者客户端那就别急着买机器。故障演练手动杀掉一个节点记录服务中断时长、有没有数据丢失、客户端能不能自动重连。用托管的服务就模拟可用区切换看监控指标和实际业务表现是否一致。7.4 必须记下来的那几个数字测评结束我会把这些数字填进一页纸的表格里作为最终决策依据指标含义为什么重要导入吞吐边/秒数据装载能力决定上线窗口和后续增量导入方案3 跳查询 P99毫秒核心场景体验直接影响业务可用性判断性能劣化拐点并发数容量红线决定机器数量和扩容时机备份恢复耗时灾难恢复能力决定你能承诺的 RTO单万次查询成本经济性托管的隐性成本最容易在这里暴露迁移工作量人天退出成本保护自己不被锁定这六个数字填完选哪款基本就没悬念了。真正让我吃亏的从来不是性能不够而是当初没把备份恢复要多久换掉它要多少人力算进去。选型这件事性能只是入场券可维护性和可退出性才决定你三年后是不是还在骂自己。