作者：查士加
原文：http://bigdata.51cto.com/art/201806/576992.htm
如今硬件的性價比越來越高，網絡傳輸速度越來越快，數據庫分層的趨勢逐漸顯現，人們已經不再強求用一個解決方案來解決所有的存儲問題，而是通過分層，讓緩存與數據庫負責各自擅長的業務場景。
黃東旭提到，當前數據庫領域面臨各種問題，如在縮放、一致性、大數據分析、與雲基礎架構集成等方面均存在諸多問題，現有的數據庫解決方案和大數據分析引擎解決方案基本處於割裂的狀態，由於 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 場景。