Categories
程式開發

我们为什么放弃 MongoDB 和 MySQL,选择 TiDB


技术选型是由技术方向和业务场景 trade-off 决定的,脱离业务场景来说技术选型是没有任何意义的,所以本文只是阐述了伴鱼技术团队数据库选型的过程,这并不是 MySQL、MongoDB 和 TiDB 之间直接的比较,只能说明 TiDB 更适合伴鱼的业务场景和技术规划,另外由于 TiDB 是非常新的数据库技术,所以这也能体现出伴鱼技术团队对新技术的态度、技术后发优势的理解、成本与效率的衡权和技术生态与红利的思考。

我们为什么放弃 MongoDB 和 MySQL,选择 TiDB 1

为什么放弃 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】。未经作者许可,禁止转载。