上周和一个做数据架构的朋友吃饭，他吐槽说最近被 Neo4j 迁移折腾得够呛。本来图数据库用得挺顺手，结果业务一扩张，数据量从几百万节点飙到上亿，单机版扛不住了，只能往集群迁移。他说这事看着简单，真上手就发现坑一个接一个。我听完想起自己几年前第一次搞 Neo4j 迁移，那会儿也是摸着石头过河，踩过的雷现在想想都肉疼。
说白了，Neo4j 迁移最让人头疼的不是技术本身，而是数据一致性。图数据库和关系型数据库不同，节点和关系像蜘蛛网一样缠在一起，稍有偏差，整个图就会断裂。比如一个用户节点关联了十几个订单，迁移时漏掉一条关系，用户和订单之间的路径就少了一条，查询结果直接变样。我见过最夸张的案例，有人用 CSV 导出再导入，结果因为 ID 映射没处理好，节点和关系完全对不上，花了三天手动修复。
那怎么解决一致性的问题？业内常用的方案有几种。最简单粗暴的是停机迁移：先把源库停掉，然后全量导出数据，再全量导入新库。好处是简单，迁移过程中数据不会变化；坏处是业务会中断，互联网产品停机几小时可能损失几百万。我有个客户做电商推荐系统，迁移时停了 4 小时，结果当天转化率下降了 15%，老板差点掀桌子。
稍微高级一点的是在线迁移，使用 Neo4j 自带的备份和恢复工具。比如用 把数据库导出成 dump 文件，然后在目标库上 。这种方式比 CSV 更靠谱，因为它保持了图的结构和索引，而且速度很快，几亿节点的数据也就几个小时。但有个大问题：dump 文件是二进制格式，跨版本迁移时容易翻车。比如从 4.x 迁移到 5.x，内部数据结构会变，直接 load 可能报错，需要提前在测试环境跑一遍，确认兼容性。
再往上走一步，就是 CDC（变更数据捕获）加双写。这种方案适合对零停机要求极高的场景。先在目标库建好同样的图结构，开启源库的 CDC，把增量数据实时同步到目标库，同时保持源库写入。等数据追平后，再把流量切到新库。听起来完美，但实操起来复杂得让人抓狂。比如同步时，源库删了某个节点，目标库还没同步，业务侧可能查到孤立的关系。还有并发写入冲突，两边同时更新同一个节点属性，究竟以谁为准，需要设计好冲突解决策略。
说到冲突解决，我见过最蠢的做法是直接用时间戳覆盖——时间戳新就采纳。但图数据库里有些操作不是简单覆盖就能解决的。比如一个节点被删了，但它的关系还在目标库里，光改时间戳没用，必须把关系也一起处理掉。更合理的做法是使用版本向量或 CRDT（无冲突复制数据类型），不过这对团队的技术要求很高，小公司往往玩不转。
除了数据一致性，性能也是大坑。很多人以为迁移就是把数据复制过去就完事了，结果新库跑得慢得像蜗牛。原因通常是索引没有重建，或者查询模式变了。比如在源库里给某个属性建了索引，迁移后新库的分布式架构可能不支持相同的索引策略。我的一个朋友把 Neo4j 从单机迁移到集群，结果之前的索引全是基于本地存储的，集群里数据分散到多台机器，索引必须改成全局的，否则查询会走全表扫描。他花了整整一周重新设计索引，才把查询性能拉回来。
还有个容易被忽视的点：数据量估算。很多人以为只要迁移当前数据就行，但图数据库的存储膨胀很厉害。每个节点和关系除了数据本身，还要存标签、属性、元数据，甚至内部指针。举个例子，一个只有 ID 和姓名两个属性的用户节点，存下来可能占几百字节。Neo4j 为了快速遍历，会保存很多辅助信息。我曾帮一个客户估算迁移空间，他们的源库用了 500 GB，我建议目标库准备 2 TB，他们觉得我在忽悠，结果迁移到一半磁盘满了，紧急扩容才救回来。这还没算上索引和日志的空间，建议至少按源库的三倍预分配。
说点走心的。Neo4j 迁移的技术方案大同小异，真正拉开差距的是对业务的理解。要清楚哪些数据是核心，哪些可以容忍短暂不一致；哪些查询必须实时，哪些可以异步补偿。比如金融风控场景，关系一致性必须严格，哪怕慢一点也不能出错；但社交推荐场景，偶尔丢几条关系影响不大。我见过最成功的迁移案例，是团队提前一个月做压力测试，把生产环境的流量镜像到测试集群跑一遍，摸透所有边界情况后才动手。这种准备工作，比任何花哨的工具都管用。所以下次遇到 Neo4j 迁移，别急着选工具，先和业务方聊清楚，再动键盘。
