隨著企業(yè)采用云原生架構(gòu)，話題自然轉(zhuǎn)向我們?nèi)绾巫寯?shù)據(jù)庫能夠橫向擴展。答案可能是更認真地打量TiDB。

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

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

1.TiDB原生分發(fā)查詢執(zhí)行和存儲

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

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

TiDB的工作方式略有不同：

• 查詢執(zhí)行通過一層TiDB服務(wù)器來處理。對SQL處理進行橫向擴展可通過添加新的TiDB服務(wù)器來實現(xiàn)，使用Kubernetes ReplicaSets很容易完成這個操作。這是因為TiDB服務(wù)器是無狀態(tài)的，其TiKV存儲層負責所有數(shù)據(jù)持久性。

• 表的數(shù)據(jù)自動分片成小塊，并在TiKV服務(wù)器之間分配。每個數(shù)據(jù)區(qū)域(分片在TiKV中的名稱)的三個副本保留在TiKV集群中，但沒有TiKV服務(wù)器需要完整的數(shù)據(jù)副本。使用MySQL術(shù)語：每個TiKV服務(wù)器同時既是主系統(tǒng)又是從系統(tǒng)，因為對于某些數(shù)據(jù)區(qū)域而言，它將包含主副本，對于其他數(shù)據(jù)區(qū)域而言，它將包含輔助副本。

• TiDB支持跨數(shù)據(jù)區(qū)域的查詢，用MySQL術(shù)語來說就是跨分片查詢。關(guān)于不同區(qū)域所在位置的元數(shù)據(jù)由Placement Driver(任何TiDB集群的管理服務(wù)器組件)來維護。所有操作都完全符合ACID，跨兩個區(qū)域改動數(shù)據(jù)的操作分兩個階段進行提交。

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

這種設(shè)計有橫向擴展復(fù)制的幾個優(yōu)點：

• 可獨立擴展SQL處理層和數(shù)據(jù)存儲層。對于許多工作負載來說，你會在遇到一個瓶頸之前遇到另一個瓶頸。

• 可通過添加節(jié)點(針對SQL和數(shù)據(jù)存儲都是如此)逐步擴展。

• 更好地利用硬件。要將MySQL擴展成一個主系統(tǒng)和四個副本，就得擁有數(shù)據(jù)的五個副本。TiDB只使用三個副本，熱點可通過Placement Driver自動重新平衡。

2. TiDB的存儲引擎是RocksDB

自2010年以來，MySQL的默認存儲引擎一直是InnoDB。在內(nèi)部，InnoDB使用B 樹數(shù)據(jù)結(jié)構(gòu)，這類似傳統(tǒng)商業(yè)數(shù)據(jù)庫使用的數(shù)據(jù)結(jié)構(gòu)。

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

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

3. TiDB用Prometheus/Grafana收集指標

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

如果是TiDB，做出將信息發(fā)送給最佳服務(wù)的戰(zhàn)略性選擇，而不是將指標保留在服務(wù)器內(nèi)。Prometheus Grafana是當今運維團隊中很常見的技術(shù)堆棧，附帶的圖表易于自行創(chuàng)建閾值或針對警報配置閾值。

TiDB指標

4. TiDB處理DDL好得多

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

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

5. TiDB為HTAP工作負載而設(shè)計

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

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

結(jié)論

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

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