伴鱼技术团队
技术选型是由技术方向和业务场景trade-off决定的，脱离业务场景来说技术选型是没有任何意义的，所以本文只是阐述了伴鱼技术团队数据库选型的过程，这并不是MySQL、MongoDB和TiDB之间直接的比较，只能说明TiDB更适合伴鱼的业务场景和技术规划，另外由于TiDB是非常新的数据库技术，所以这也能体现出伴鱼技术团队对新技术的态度、技术后发优势的理解、成本与效率的衡权和技术生态与红利的思考。
为什么放弃MongoDB？伴鱼是年成立的，那个时候NoSQL还如日中天，关系型数据库为了应付海量的数据只能业务侵入式的分库分表，虽然Google在年发布了NewSQL数据库Spanner的论文，但是工业界还没有一款可以使用的NewSQL数据库，综合当时的各种情况，伴鱼选择的是MongoDB。
不过，在年到年之间，对于伴鱼来说MongoDB确实是一个上佳之选，主要有以下几个方面的原因：
开发更高效：公司初期处于探索期，产品迭代非常快，MongoDB是NoSQL数据库，不需要做建库建表等DDL操作，特别在产品快速迭代，需要频繁增减字段的时候就更高效，当然这个也是有代价的，从本质上来说，MongoDB是读模式，它几乎不检查写入的内容是否合法，对数据Schema的解释是在应用程序的代码中，导致写入数据的约束性是没有保证的。
运维更高效：当时公司研发非常少，这段时间整个后端只有两个工程师，没有专职的运维和DBA，但是MongoDB的单机性能比MySQL要高不少，不但对数据库的运维成本要低不少，并且当时除了几个热点库外，其他的库MongoDB可以直接扛住流量压力，省去了中间的Cache层，让开发和运维都更高效。
有事务需求的场景不多：当时使用的是MongoDB2.x和3.x，只提供了数据一致性的选择（强一致性、单调一致性和最终一致性）和原子操作，在少数的几个场景，比如交易相关的场景，通过选择强一致性和原子操作，再在应用层实现MVCC的机制，可以满足简单的事务需求。
总体来说，在伴鱼产品的探索期，为了效率牺牲一点数据约束性和事务能力是值得的，但是年底伴鱼产品方向比较明确后，业务场景从探索期转变到快速发展期，对数据库的需求从效率优先转变为效率、事务能力与生态并重：
有事务需求的场景急增：事务场景从最初与钱相关的交易扩展到一些虚拟货币，并且由于并发量的增加，之前没有事务保障的场景出现竞争的情况越来越多，还在应用层通过MVCC机制实现简单的事务是非常低效的，并且在应用层实现事务的正确性也是很难保证的。（一个有趣的故事：JeffDean曾经说过自己对Bigtable最后悔的事情是没有提供跨行事务支持，导致业务就会在上层企图自己搞事务，并且业务实现的分布式事务大部分都是错的，所以在后来的Spanner数据库中JeffDean直接提供了官方分布式事务支持。）
对大数据生态的需求急增：在产品探索期的时候，也有很强的数据分析需求，不过当时数据总量小，在MongoDB的隐藏从库中直接分析就足够了，但是产品快速发展期，数据量急剧增加，在OLTP数据库中进行OLAP操作已经力不从心了。但是通过大数据生态来进行数据分析，对于MongoDB来说有一个非常残酷的现实，基本所有的大数据生态都是围绕MySQL生态打造的，如果想接入MongoDB的数据，意味着需要重新大量造轮子。
对数据约束性的要求更高：由于业务快速的发展，服务可能会出现多人维护和移交的情况，如果存储的数据没有约束，意味着存储的数据Schema是不可控的，这很容易让后面参与的工程师崩溃和掉进坑里，这个时候数据的约束性变成是一个更高优秀级的需求，关系数据库的写模式变成更好的选择。
到产品快速发展期，由于业务场景对数据库的需求已经发生了很大的改变，所以在这个时候，伴鱼技术团队开始谨慎思考数据库重新选型的问题，我们理想型的数据库是这样的：
高可用；
高吞吐；
支持ACID事务；
大数据生态友好；
有水平扩张能力，并且尽量做到不侵入业务；
基于上面这些需求，我们开始了数据库的重新选型之路。
初识TiDB早在年的时候我就非常