不过，在 2015 年到 2017 年之间，对于伴鱼来说 MongoDB 确实是一个上佳之选，主要有以下几个方面的原因：

总体来说，在伴鱼产品的探索期，为了效率牺牲一点数据约束性和事务能力是值得的，但是 2017 年底伴鱼产品方向比较明确后，业务场景从探索期转变到快速发展期，对数据库的需求从效率优先转变为效率、事务能力与生态并重：

到产品快速发展期，由于业务场景对数据库的需求已经发生了很大的改变，所以在这个时候，伴鱼技术团队开始谨慎思考数据库重新选型的问题，我们理想型的数据库是这样的：

基于上面这些需求，我们开始了数据库的重新选型之路。

后来同事推荐说有个叫TiDB的数据库，目前有些公司也在用了，反馈也不错，所以我们决定调研一下。TiDB 官网的文档做的非常友好，不论是理论还是架构的文章都非常齐全，几乎一口气就把所有的文章都看了一遍（当时文章比现在要少），完备的理论支持、优雅的架构设计、与 Google Spanner 一脉相承的设计思路让我们对 TiDB 的前景非常看好，并且功能上完全满足我们的要求，所以当时就决定长期关注 TiDB，并且准备进行初步验证。

当时伴鱼所有的业务都部署在阿里云上（现在有自建机房），就直接在阿里云上面按 TiDB 的配置要求购买了机器，当时安装的是 TiDB 1.x 的版本。因为 TiDB 官网已经有 Sysbench 的压力测试数据，这个性能数据是符合我们需求的，所以决定对我们的业务场景进行一次完全模拟的长期测试： 伴鱼 IM 的并发比较高，并且采用写扩散的设计，对数据库的要求会比较高，所以适合进行验证。通过对 IM 业务的 inbox 表进行双写，业务同步写 MongoDB 和异步写 TiDB，业务读只读 MongoDB，这样如果 TiDB 有问题也不会影响线上业务。

在低峰期对 IM 业务开启双写后，TiDB 监控的 999 线和 99 线还满足要求，但是所有 TiKV 节点的 io 使用率一直在 90% 附近波动，这个如果到高峰期是绝对会有问题的，通过重读 TiKV 的配置，在修改配置项 sync-log = false 后，TiKV 的 io 使用率维持在 5% 以下，当天的高峰期也一切正常，没有出现问题。

在这之后，我们对 IM 的双写观察 2-3 个月的时间，在确认一切正常后，再将同步读写都修改为 TiDB 并且异步写 MongoDB，一切正常并且持续观察。

sync－log 配置是控制 TiKV 数据多副本进行 raft 协议同步的时候，如果 sync－log＝false，则内存中处理完成就返回 ack，对于 3 副本来说，单节点故障是不会丢失数据的，同一个 raft 集的 2 个副本同时故障可能会出现丢数据的情况，这个问题除了金融等对数据安全性要求非常高的场景外，其他的业务场景是可以接受的，并且 MySQL 等其他数据库的集群方案在 master 节点故障的时候问题更大。

我们当时非常关心的问题列表为：

收集了大概 20 多个问题，得益于伴鱼和 TiDB 都在北京，离得还非常近，在线上联系上并且约好时间后，和 TiDB 进行了第一次深度的交流。

大概是2018年上半年的一天，我和 TiDB 的 3-4 个同事聊了一整个上午，基本都是我将收集到的问题一个个抛出来，大家一起讨论。整个交流过程解答了很多我们关心的问题，也了解到当前业界对TiDB的使用情况，大大增强了我们对 TiDB 的信心，对于数据库的选型来说，这是非常关键的事情。

特别感谢当时一起交流的 TiDB 同事：房晓乐以及另外 2-3 位我不知道名字的同学（非常抱歉）。

初创公司在技术沉淀和积累上是远远不及一些成熟公司的，这些沉淀和积累就是成熟公司在技术上的先发优势，当技术没有出现变革的时候我们没有选择，但是当技术正出现重大变革的时候，如果我们还做同样的技术选型，那么也需要花同样的时间和成本才能达到成熟公司的水平，然后等大家都开始迁移到新的技术上的时候，这些技术沉淀和积累就可能会变成技术债务。

所以初创公司应该去预判技术趋势，选择面向未来的技术，在技术上弯道超车，避免自己的技术债务，这个是伴鱼技术团队对技术后发优势的理解。

Unix 哲学是经过时间和实践的锤炼设计原则，很多时候也是伴鱼技术团队的实践原则，比如 Rule of Economy ：「宁花机器一分，不花程序员一秒」。在技术选型上，我们是总是期望基础软件做更多的事情，业务研发做更少的事情，如果业务研发需要在业务层去做原本基础软件应该做好的事情，那其实就是基础软件的抽象泄漏了。如果基础软件抽象泄漏，必然会导致业务层重复去解决这个问题，这个其实是非常大的隐性成本。

MySQL 相比较 TiDB 而言，集群的高可用和大表需要分库分表其实就是 MySQL 在面对当前需求的抽象泄漏，MySQL 的集群高可用需要 DBA 和基础架构团队花成本去解决，MySQL 的大表分库分表方案需要 DBA、基础架构团队和业务研发团队花成本去解决，只不过这些都是隐性成本，不像在搭建数据库集群的时候，TiDB 比 MySQL 可能需要更多的机器来的简单直接，所以很容易被忽略了。

所以，对于成本与效率的衡权，伴鱼技术团队更关注工程师的效率，更关注工程师的心情（在业务上层重复解决一些底层软件抽象泄漏的问题是很影响心情的），更关注隐性成本，而不仅仅是账面明显可以比较的资源数字，特别是在机器越来越便宜，人才越来越值钱的趋势下。

另一方面，在选择面向未来、优雅高效的解决方案，还是选择成熟的但不够优雅和高效的解决方案，如果选择成熟的解决方案，对技术的掌控会比较高，但是会在效率方面持续的进行付出；如果选择面向未来的解决方案，需要花时间和精力来掌握新技术，但是新技术会优雅和高效的解决问题，我们认为这个就是技术的红利。比如对于大表的解决方案，MySQL 提供的解决方案是分库分表，业务研发和 DBA 一起配合非常低效地解决这个问题，但是对于 NewSQL 的 TiDB，单表几乎可以理解为无限大的（业界已经存在 100 亿以上的表），从根本上解决了这个问题。现在伴鱼的大表都从 MongoDB 迁移到 TiDB 上面，业务研发和 DBA 不再为数据的增加而不停地进行分库分表，这个就是巨大的技术红利。

所以，基于上面的一些讨论与思考，伴鱼决定 All in TiDB，MongoDB 不再增加新的库和表，正在使用 MongoDB 的业务继续使用，并且对 MongoDB 上的大表进行有计划的迁移，避免进行分库分表操作。