技术选型是由技术方向和业务场景 trade-off 决定的，脱离业务场景来说技术选型是没有任何意义的，所以本文只是阐述了伴鱼技术团队数据库选型的过程，这并不是 MySQL、MongoDB 和 TiDB 之间直接的比较，只能说明 TiDB 更适合伴鱼的业务场景和技术规划，另外由于 TiDB 是非常新的数据库技术，所以这也能体现出伴鱼技术团队对新技术的态度、技术后发优势的理解、成本与效率的衡权和技术生态与红利的思考。
为什么放弃 MongoDB？
伴鱼是 2015 年成立的，那个时候 NoSQL 还如日中天，关系型数据库为了应付海量的数据只能业务侵入式的分库分表，虽然 Google 在 2012 年发布了 NewSQL 数据库 Spanner 的论文，但是工业界还没有一款可以使用的 NewSQL 数据库，综合当时的各种情况，伴鱼选择的是 MongoDB。
不过，在 2015 年到 2017 年之间，对于伴鱼来说 MongoDB 确实是一个上佳之选，主要有以下几个方面的原因：
- 开发更高效：公司初期处于探索期，产品迭代非常快，MongoDB 是 NoSQL 数据库，不需要做建库建表等DDL操作，特别在产品快速迭代，需要频繁增减字段的时候就更高效，当然这个也是有代价的，从本质上来说，MongoDB 是读模式，它几乎不检查写入的内容是否合法，对数据 Schema 的解释是在应用程序的代码中，导致写入数据的约束性是没有保证的。
- 运维更高效：当时公司研发非常少，这段时间整个后端只有两个工程师，没有专职的运维和 DBA ，但是 MongoDB 的单机性能比 MySQL 要高不少，不但对数据库的运维成本要低不少，并且当时除了几个热点库外，其他的库 MongoDB 可以直接扛住流量压力，省去了中间的 Cache 层，让开发和运维都更高效。
- 有事务需求的场景不多：当时使用的是 MongoDB 2.x 和 3.x，只提供了数据一致性的选择（强一致性、单调一致性和最终一致性）和原子操作，在少数的几个场景，比如交易相关的场景，通过选择强一致性和原子操作，再在应用层实现 MVCC 的机制，可以满足简单的事务需求。
原文链接:【https://www.infoq.cn/article/mFTtecC4y3Qc1egNNFym】。未经作者许可，禁止转载。