[[249633]]

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

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

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

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

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

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

TiDB的工作方式略有不同：

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

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

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

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

2. TiDB的存儲引擎是RocksDB

自2010年以來，MySQL的默認(rèn)存儲引擎一直是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)勢，因?yàn)樗梢愿行У貕嚎s數(shù)據(jù)，而且索引在內(nèi)存中再也裝不下時，插入性能并不會降低。

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

3. TiDB用Prometheus/Grafana收集指標(biāo)

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

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

[[249634]]

TiDB指標(biāo)

4. TiDB處理DDL好得多

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

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

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

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

TiDB旨在跨混合事務(wù)/分析處理(HTAP)查詢都能很好地執(zhí)行。對于希望實(shí)時分析數(shù)據(jù)的那些人來說，這是一大賣點(diǎn)，因?yàn)槟菢硬恍枰狹ySQL數(shù)據(jù)庫和分析數(shù)據(jù)庫之間的批量加載。

結(jié)論

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

原文標(biāo)題：Meet TiDB: An open source NewSQL database，作者：Morgan Tocker

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