據我所知，目前不少公司都在生產環境使用TiDB了，例如:小米，小紅書，餓了嗎，美團等。數據庫
現在硬件的性價比愈來愈高，網絡傳輸速度愈來愈快，數據庫分層的趨勢逐漸顯現，人們已經再也不強求用一個解決方案來解決全部的存儲問題，而是經過分層，讓緩存與數據庫負責各自擅長的業務場景。當前數據庫領域面臨各類問題，如在縮放、一致性、大數據分析、與雲基礎架構集成等方面均存在諸多問題，現有的數據庫解決方案和大數據分析引擎解決方案基本處於割裂的狀態，因爲 Oracle、MySQL 數據庫並非面向分佈式環境而設計，所以即便勉強經過分庫、分表或中間件的方式，在數據庫層面作了分片，從本質上看也只是複製了相同的堆棧，而非針對分佈式系統進行存儲和計算優化，這正是進行跨業務查詢或跨物理機查詢和寫入十分繁瑣的本質緣由。NoSQL 雖然解決了數據庫彈性擴展的難題，可是卻放棄了數據的強一致性以及對 ACID 事務的支持，帶來了新的問題。後端
爲了解決這一問題，TiDB 在架構上將計算和存儲層進行高度的抽象和分離，對混合負載的場景經過 IO 優先級隊列，智能副本調度，行列混合存儲等技術使其變爲可能。TiDB 做爲開源的分佈式關係數據庫，其特色是幾乎能夠 100% 兼容 MySQL 接口，也兼容 MySQL 的語法和協議，在保證不喪失 ACID 事務的前提下，可以彈性伸縮，高可用，能夠同時處理 OLTP 和 OLAP 工做負載，再也不須要 ETL。緩存
TiDB總體架構圖微信
TiDB 產品的總體架構是高度分層的，由分佈式 SQL 層（TiDB）、分佈式 KV 存儲引擎（TiKV）以及管理整個集羣的 PD 模塊組成。無限水平擴展是 TiDB 的一大特色，這裏所說的水平擴展包括兩方面：計算能力和存儲能力。網絡
HTAP 給開發者提供了一個實時數據分析方面的新思路，不須要再去維護另外一個離線的數據倉庫，既減輕了 ETL 的工做，又能節省很大一部分創建數據倉庫所用到的存儲和計算成本，HTAP 將是將來的重要趨勢。黃東旭介紹了 TiDB 的四個主要應用場景，一是 MySQL 分片與合併；二是直接替換 MySQL；三是用作數據倉庫；四是做爲其餘系統的一個模塊。架構
用例1：MySQL分片與合併併發
Syncer分佈式
TiDB 應用的第一類場景是 MySQL 的分片與合併。對於已經在用 MySQL 的業務，分庫、分表、分片、中間件是經常使用手段，隨着分片的增多，跨分片查詢是一大難題。TiDB 在業務層兼容 MySQL 的訪問協議，PingCAP 作了一個數據同步的工具——Syncer，它能夠把 TiDB 做爲一個 MySQL Slave，將 TiDB 做爲現有數據庫的從庫接在主 MySQL 庫的後方，在這一層將數據打通，能夠直接進行復雜的跨庫、跨表、跨業務的實時 SQL 查詢。黃東旭提到，「過去的數據庫都是一主多從，有了 TiDB 之後，能夠反過來作到多主一從。」高併發
用例2：直接替換MySQL工具
第二類場景是用 TiDB 直接去替換 MySQL。若是你的IT架構在搭建之初並未考慮分庫分表的問題，所有用了 MySQL，隨着業務的快速增加，海量高併發的 OLTP 場景愈來愈多，如何解決架構上的弊端呢?
在一個 TiDB 的數據庫上，全部業務場景不須要作分庫分表，全部的分佈式工做都由數據庫層完成。TiDB 兼容 MySQL 協議，因此能夠直接替換 MySQL，並且基本作到了開箱即用，徹底不用擔憂傳統分庫分表方案帶來繁重的工做負擔和複雜的維護成本，友好的用戶界面讓常規的技術人員能夠高效地進行維護和管理。另外，TiDB 具備 NoSQL 相似的擴容能力，在數據量和訪問流量持續增加的狀況下可以經過水平擴容提升系統的業務支撐能力，而且響應延遲穩定。
黃東旭在演講中提到了摩拜單車的案例，摩拜早期的數據庫所有用 MySQL，隨着業務的快速增加，MySQL 的弊端逐漸顯現，摩拜單車於 2017 年初開始使用 TiDB 替換 MySQL。現在，摩拜的 IT 系統中已部署了數套 TiDB 集羣，近百個節點，承載着數十 TB 的各種數據。
用例3：數據倉庫
TiDB 自己是一個分佈式系統，第三種使用場景是將 TiDB 看成數據倉庫使用。TPC-H 是數據分析領域的一個測試集，TiDB 2.0 在 OLAP 場景下的性能有了大幅提高，原來只能在數據倉庫裏面跑的一些複雜的 Query，在 TiDB 2.0 裏面跑，時間基本都能控制在 10 秒之內。固然，由於 OLAP 的範疇很是大，TiDB 的 SQL 也有搞不定的狀況，爲此 PingCAP 開源了 TiSpark，TiSpark 是一個 Spark 插件，用戶能夠直接用 Spark SQL 實時地在 TiKV 上作大數據分析。
用例4：做爲其餘系統的模塊
TiDB 是一個傳統的存儲跟計算分離的項目，其底層的 Key-Value 層，能夠單獨做爲一個 HBase 的 Replacement 來用，它同時支持跨行事務。TiDB 對外提供兩個 API 接口，一個是 ACID Transaction 的 API，用於支持跨行事務；另外一個是 Raw API，它能夠作單行的事務，換來的是整個性能的提高，但不提供跨行事務的 ACID 支持。用戶能夠根據自身的需求在兩個 API 之間自行選擇。例若有一些用戶直接在 TiKV 之上實現了 Redis 協議，將 TiKV 替換一些大容量，對延遲要求不高的 Redis 場景。
本文分享自微信公衆號 - 互聯網後端架構（fullstack888）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。