帶你走近TiDB：一款開源NewSQL資料庫

隨著企業採用雲原生架構，話題自然轉向我們如何讓資料庫能夠橫向擴展。答案可能是更認真地打量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是當今運維團隊中很常見的技術堆棧，附帶的圖表易於自行創建閾值或針對警報配置閾值。

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說明文檔。它描述了可能影響你應用程序的任何差異方面的一些細節。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！