[[249633]]

【51CTO.com快譯】隨著企業采用云原生架構，話題自然轉向我們如何讓數據庫能夠橫向擴展。答案可能是更認真地打量TiDB。

TiDB是一款采用Apache 2.0許可證發布的開源NewSQL數據庫。因為它使用MySQL協議，現有的應用程序能夠使用任何MySQL連接件連接到它，大多數SQL功能保持一樣(連接、子查詢和事務等)。

然而底層還是存在差異。如果你的架構基于擁有讀取副本的MySQL，你會看到TiDB的工作方式略有不同。本文介紹了TiDB和MySQL的五大差異。

1.TiDB原生分發查詢執行和存儲

若是MySQL，通過復制進行橫向擴展很常見。通常一個擁有許多從數據庫的MySQL主數據庫，每個從數據庫有完整的數據副本。使用應用程序邏輯或ProxySQL等技術，查詢路由到相應的服務器(可以將查詢從主數據庫卸載到從數據庫，只要這么做很安全)。

橫向擴展復制非常適用于讀取密集的工作負載，因為查詢執行可以在復制從數據庫之間劃分。然而，這對寫入密集的工作負載來說成了瓶頸，因為每個副本要有完整的數據副本。換一個角度來看，MySQL復制機制橫向擴展SQL處理，但無法橫向擴展存儲。(順便說一下，對于傳統復制以及Galera Cluster和群組復制等較新的解決方案而言也是如此。)

TiDB的工作方式略有不同：

• 查詢執行通過一層TiDB服務器來處理。對SQL處理進行橫向擴展可通過添加新的TiDB服務器來實現，使用Kubernetes ReplicaSets很容易完成這個操作。這是因為TiDB服務器是無狀態的，其TiKV存儲層負責所有數據持久性。
• 表的數據自動分片成小塊，并在TiKV服務器之間分配。每個數據區域(分片在TiKV中的名稱)的三個副本保留在TiKV集群中，但沒有TiKV服務器需要完整的數據副本。使用MySQL術語：每個TiKV服務器同時既是主系統又是從系統，因為對于某些數據區域而言，它將包含主副本，對于其他數據區域而言，它將包含輔助副本。
• TiDB支持跨數據區域的查詢，用MySQL術語來說就是跨分片查詢。關于不同區域所在位置的元數據由Placement Driver(任何TiDB集群的管理服務器組件)來維護。所有操作都完全符合ACID，跨兩個區域改動數據的操作分兩個階段進行提交。

對于學習TiDB的MySQL用戶來說，更簡單的解釋是，TiDB服務器好比智能代理，將SQL轉換成發送給TiKV的批量鍵值請求。TiKV服務器使用基于范圍的分區(range-based partitioning)來存儲你的表。范圍自動平衡以使每個分區保持在96MB(默認值，但可配置)，每個范圍可以存儲在不同的TiKV服務器上。Placement Driver服務器跟蹤哪些范圍位于何處，一旦某個范圍變得太大或太熱，自動重新平衡。

這種設計有橫向擴展復制的幾個優點：

• 可獨立擴展SQL處理層和數據存儲層。對于許多工作負載來說，你會在遇到一個瓶頸之前遇到另一個瓶頸。
• 可通過添加節點(針對SQL和數據存儲都是如此)逐步擴展。
• 更好地利用硬件。要將MySQL擴展成一個主系統和四個副本，就得擁有數據的五個副本。TiDB只使用三個副本，熱點可通過Placement Driver自動重新平衡。

2. TiDB的存儲引擎是RocksDB

自2010年以來，MySQL的默認存儲引擎一直是InnoDB。在內部，InnoDB使用B +樹數據結構，這類似傳統商業數據庫使用的數據結構。

相比之下，TiDB使用RocksDB作為TiKV的存儲引擎。RocksDB對于大型數據集而言有優勢，因為它可以更有效地壓縮數據，而且索引在內存中再也裝不下時，插入性能并不會降低。

請注意，MySQL和TiDB都支持新的存儲引擎可供使用的API。比如說，Percona Server和MariaDB都支持RocksDB這個選項。

3. TiDB用Prometheus/Grafana收集指標

跟蹤關鍵指標是維護數據庫運行狀況的一個重要部分。 MySQL將這些快速變化的指標集中在Performance Schema中。Performance Schema是一組內存表，可通過常規SQL查詢來進行查詢。

如果是TiDB，做出將信息發送給***服務的戰略性選擇，而不是將指標保留在服務器內。Prometheus + Grafana是當今運維團隊中很常見的技術堆棧，附帶的圖表易于自行創建閾值或針對警報配置閾值。

[[249634]]

TiDB指標

4. TiDB處理DDL好得多

如果我們暫時忽略MySQL中并非所有的數據定義語言(DDL)變化都是聯機的，運行分布式MySQL系統時更大的挑戰是，同時針對所有節點外化模式變更。設想一下你有10個分片并添加一列，但每個分片要花不同的時間來完成改動。沒有分片，這個挑戰仍然存在，因為副本會在主系統之后處理DDL。

TiDB使用谷歌F1論文闡述的協議來實現聯機DDL。簡而言之，DDL變更分解成更小的過渡階段，那樣它們可以防止數據損壞情況，系統可以容忍單個節點每次最多支持一個DDL版本。

5. TiDB為HTAP工作負載而設計

MySQL團隊傳統上將注意力集中于為聯機事務處理(OLTP)查詢優化性能上。也就是說，MySQL團隊花更多的時間使較簡單的查詢更好地執行，而不是使所有或復雜的查詢更好地執行。這種方法沒有任何問題，因為許多應用程序只使用簡單的查詢。

TiDB旨在跨混合事務/分析處理(HTAP)查詢都能很好地執行。對于希望實時分析數據的那些人來說，這是一大賣點，因為那樣不需要MySQL數據庫和分析數據庫之間的批量加載。

結論

以上是我在MySQL界接觸15年、繼而關注TiDB的五大觀察結果。雖然其中許多涉及內部差異，但我建議看看關于MySQL兼容性的TiDB說明文檔。它描述了可能影響你應用程序的任何差異方面的一些細節。

原文標題：Meet TiDB: An open source NewSQL database，作者：Morgan Tocker

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】