技術選型是由技術方向和業務場景 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】。未經作者許可，禁止轉載。