TiDB和MongoDB分片集羣架構比較

此文已由做者溫正湖受權網易雲社區發佈。

歡迎訪問網易雲社區，瞭解更多網易技術產品運營經驗。

 

最近閱讀了TiDB源碼的說明文檔，跟MongoDB的分片集羣作了下簡單對比。

首先展現TiDB的總體架構

MongoDB分片集羣架構以下：

更加具體點以下：

下面從介紹TiDB組件的角度切入，將其跟MongoDB分片集羣作對比。

TiDB 集羣主要分爲三個組件：

 

TiDB Server

TiDB Server 負責接收 SQL 請求，處理 SQL 相關的邏輯，並經過 PD 找到存儲計算所需數據的 TiKV 地址，與 TiKV 交互獲取數據，最終返回結果。 TiDB Server 是無狀態的，其自己並不存儲數據，只負責計算，能夠無限水平擴展，能夠經過負載均衡組件（如LVS、HAProxy 或 F5）對外提供統一的接入地址。

// 類比MongoDB分片集羣中的mongos或者叫router server

 

PD Server

Placement Driver (簡稱 PD) 是整個集羣的管理模塊，其主要工做有三個： 一是存儲集羣的元信息（某個 Key 存儲在哪一個 TiKV 節點）；二是對 TiKV 集羣進行調度和負載均衡（如數據的遷移、Raft group leader 的遷移等）；三是分配全局惟一且遞增的事務 ID。

PD 是一個集羣，須要部署奇數個節點，通常線上推薦至少部署 3 個節點。

//類比MongoDB分片集羣中的config server

 

TiKV Server

TiKV Server 負責存儲數據，從外部看 TiKV 是一個分佈式的提供事務的 Key-Value 存儲引擎。存儲數據的基本單位是 Region，每一個 Region 負責存儲一個 Key Range （從 StartKey 到 EndKey 的左閉右開區間）的數據，每一個 TiKV 節點會負責多個 Region 。TiKV 使用 Raft 協議作複製，保持數據的一致性和容災。副本以 Region 爲單位進行管理，不一樣節點上的多個 Region 構成一個 Raft Group，互爲副本。數據在多個 TiKV 之間的負載均衡由 PD 調度，這裏也是以 Region 爲單位進行調度。

//類比MongoDB分片集羣中的replica set

// Region概念相似MongoDB分片中的chunk，但又有些不同。chunk是個邏輯概念，數據存儲並非以chunk爲單位。而Region是正式在TIKV上的數據單位。兩種都是數據遷移的最小單位。默認也是64MB

 

核心特性

水平擴展

無限水平擴展是 TiDB 的一大特色，這裏說的水平擴展包括兩方面：計算能力和存儲能力。TiDB Server 負責處理 SQL 請求，隨着業務的增加，能夠簡單的添加 TiDB Server 節點，提升總體的處理能力，提供更高的吞吐。TiKV 負責存儲數據，隨着數據量的增加，能夠部署更多的 TiKV Server 節點解決數據 Scale 的問題。PD 會在 TiKV 節點之間以 Region 爲單位作調度，將部分數據遷移到新加的節點上。因此在業務的早期，能夠只部署少許的服務實例（推薦至少部署 3 個 TiKV， 3 個 PD，2 個 TiDB），隨着業務量的增加，按照需求添加 TiKV 或者 TiDB 實例。

// TIDB相比MongoDB分片，優點在於其具備更強的業務負載均衡的能力，TIDB是每一個region做爲一個raft group，會根據raft group leader所在TIKV節點的負載來調整leader節點，從而實現業務負載均衡。

 

高可用

高可用是 TiDB 的另外一大特色，TiDB/TiKV/PD 這三個組件都能容忍部分實例失效，不影響整個集羣的可用性。下面分別說明這三個組件的可用性、單個實例失效後的後果以及如何恢復。

• TiDB

TiDB 是無狀態的，推薦至少部署兩個實例，前端經過負載均衡組件對外提供服務。當單個實例失效時，會影響正在這個實例上進行的 Session，從應用的角度看，會出現單次請求失敗的狀況，從新鏈接後便可繼續得到服務。單個實例失效後，能夠重啓這個實例或者部署一個新的實例。

// MongoDB分片集羣經過Driver就能夠實現負載均衡，不須要單獨部署負載均衡組件。 Driver同時鏈接多個mongos實現負載均衡。

• PD

PD 是一個集羣，經過 Raft 協議保持數據的一致性，單個實例失效時，若是這個實例不是 Raft 的 leader，那麼服務徹底不受影響；若是這個實例是 Raft 的 leader，會從新選出新的 Raft leader，自動恢復服務。PD 在選舉的過程當中沒法對外提供服務，這個時間大約是3秒鐘。推薦至少部署三個 PD 實例，單個實例失效後，重啓這個實例或者添加新的實例。

// 跟config server的高可用同樣，但config server心跳超時須要10s，選出主通常須要30s時間。因爲mongos緩存了cs上的元數據，因此cs選主期間，業務正常的讀寫均不受影響。很好奇，選主如何在3s以內搞定。

• TiKV

TiKV 是一個集羣，經過 Raft 協議保持數據的一致性（副本數量可配置，默認保存三副本），並經過 PD 作負載均衡調度。單個節點失效時，會影響這個節點上存儲的全部 Region。對於 Region 中的 Leader 結點，會中斷服務，等待從新選舉；對於 Region 中的 Follower 節點，不會影響服務。當某個 TiKV 節點失效，而且在一段時間內（默認 10 分鐘）沒法恢復，PD 會將其上的數據遷移到其餘的 TiKV 節點上。

// 這是TiDB相比MongoDB分片的不一樣的地方，PD在某個TiKV節點失效超時後，將其上原有的數據副本遷移到其餘存活的TiKV節點實現數據副本完整性。而MongoDB分片集羣的數據高可用依賴shard的配置，若是shard是單一的mongod進程，那麼該shard故障後，其上的數據都不可用或丟失，若是shard是複製集，則數據是安全的，但副本數會減小，須要人工處理故障節點。因此，分片集羣中shard必定要配置爲複製集的形式

 

網易雲免費體驗館，0成本體驗20+款雲產品！ 

更多網易技術、產品、運營經驗分享請點擊。

 

 

 

 

相關文章：
【推薦】 BigData – Join中居然也有謂詞下推!?