隨著國內網際網路企業的快速發展，傳統的oracle資料庫架構在成本和擴充套件性上已不能滿足要求，更多的企業將目光轉向了開源的MySQL資料庫，由於MySQL本身是一個單機資料庫其本身並不具備橫向擴充套件能力，於是出現了應用側的分庫分表方案。進一步的又開發出分庫分表中介軟體，由中介軟體完成分庫分表的管理，避免了應用側的複雜性，分庫分表雖然一定程度解決了擴充套件性的問題，但也存在著其他比較嚴重的問題，比如：必須指定分庫鍵、分散式事務支援能力差、全表掃描效能影響、線上擴充套件能力不足等，實際上分庫分表更多的只是一個路由功能。
NoSQL資料庫的出現解決了分庫分表的複雜性和擴充套件性問題，透過將一些簡單場景執行在NoSQL資料庫(如HBase、MongoDB、Cassandra等)上獲得了應用透明和擴充套件能力的支援。由於NoSQL不支援SQL和事務或支援能力較差，導致很多基於SQL開發的應用無法直接遷移，需要重新開發，同時無法使用SQL的一些功能，也增加開發的複雜度和成本。
基於NoSQL資料庫的擴充套件能力優勢，又出現了支援SQL的NewSQL分散式資料庫，同時支援SQL和分散式事務，並且具有良好的擴充套件能力，該類資料庫更多參考谷歌spanner/ F1等，使用LSM的KV模型，典型的代表有TiDB、CockroachDB、oceanbase等。同時也出現了類似於AWS aurora、Polardb等基於分散式共享儲存的方案。
為滿足實時數倉、統計分析等需求又出現了一種新的資料庫形態HTAP(Hybrid Transaction and Analytical Process,混合事務和分析處理)，同時滿足OLTP和OLAP業務，典型的代表有TiDB，也有越來越多的國產資料庫公司加入HTAP陣營。
本文從實際使用和運維管理角度分析TiDB能解決的問題痛點。
（1）計算節點
TiDB Server：SQL 層，負責接受客戶端的連線，執行 SQL 解析和最佳化，最終生成分散式執行計劃。TiDB 層本身是無狀態的，實踐中可以啟動多個 TiDB 例項，透過負載均衡元件（如 LVS、HAProxy 或 F5）對外提供統一的接入地址，客戶端的連線可以均勻地分攤在多個 TiDB 例項上以達到負載均衡的效果。
（2）控制節點
PD (Placement Driver) Server：整個 TiDB 叢集的元資訊管理模組，負責儲存每個 TiKV 節點實時的資料分佈情況和叢集的整體拓撲結構，提供 TiDB Dashboard 管控介面，併為分散式事務分配事務 ID。PD 不僅儲存元資訊，同時還會根據 TiKV 節點實時上報的資料分佈狀態，下發資料排程命令給具體的 TiKV 節點，如熱點負載均衡、raft副本建立轉移等。此外，PD 本身也是由至少 3 個節點構成，擁有高可用的能力。
（3）儲存節點
TiDB作為HTAP混合負載資料庫，同時具有支援高併發OLTP事務的行存TiKV和支援實時數倉的MPP列存TiFlash。
(1) TiKV Server：負責儲存資料，從外部看 TiKV 是一個分散式的提供事務的 Key-Value 儲存引擎。儲存資料的基本單位是 Region，每個 Region 負責儲存一個 Key Range的資料，每個 TiKV 節點會負責多個 Region。另外，TiKV 中的資料都會自動維護多副本（預設為三副本，採用raft協議），天然支援高可用和自動故障轉移。
(2) TiFlash：透過raft協議實時的同步資料，資料是以列式的形式進行儲存，主要的功能是為分析型的場景加速，提供實時數倉能力。
3.1 分庫分表複雜性
分庫分表中介軟體解決了單節點效能問題，提供了一定的擴充套件性，但具有較大的業務侵入性，其主要問題有：
(1) 在設計時需要考慮表的分庫鍵，應用系統需要重新開發。SQL語句中必須帶有分庫鍵，否則中介軟體無法知道請求該發往哪個分庫從而對所有分庫發起全表掃描，對於支援禁用全表掃描特性的中介軟體不指定分庫鍵則會報錯。
(2) 當業務查詢時無法知道分庫鍵的情況下部分的解決方式是透過異構索引實現，首先透過異構索引等獲取分庫鍵然後再去中介軟體進行查詢，異構索引的維護需要資料同步或者雙寫方式，可能會帶來資料不一致而影響業務。
(3) 為減少跨庫join，部分小表會設定為廣播表或複製表，將join查詢下推到分庫執行，廣播表在分庫間的資料需要同步，增加了管理維護複雜性，且資料同步有可能延遲而影響業務。
(4) 分庫分表中介軟體對強一致性的分散式事務支援多數採用XA協議，比較依賴底層MySQL的XA支援和容錯能力，對底層資料庫版本有所要求，如阿里DRDS、MyCat等建議後端MySQL是5.7版本時才使用XA事務。
(5) 某個分庫存在熱點時，無法透過快速遷移方式均衡熱點訪問，需要重新將資料Hash到新分庫後可能才能打散熱點。
TiDB 作為分散式關係型資料庫，由計算節點tidb server提供訪問服務，透過負載均衡軟體保障對計算節點的均衡訪問，使用者使用時完全可以看做是一個單節點MySQL資料庫，不必關心是否有分庫鍵，還可以在資料庫內使用range 、hash、list等分割槽表。
TiDB採用raft多數派協議，強一致性事務模式，預設為3副本，以region(96M)為單位進行管理，一個region就是一段連續的key空間，tikv內每個region包含leader/follower兩種角色，預設情況下由leader提供讀寫請求，leader按照演算法均勻分佈到所有的儲存節點tikv例項上，系統根據region的負載訪問情況可以自動進行region的分裂和leader的轉移，使各節點負載儘量均衡。Follower節點作為leader的實時副本，可透過follower read、stale read等功能將非苛刻的實時讀分散到其他節點，進而降低leader節點的壓力提升整體系統處理能力。
3.2 線上擴容能力
分庫分表的模式底層一般使用MySQL主從方式，當需要進行底層分庫擴容時，對於已有的歷史資料大致需要經歷新增新分庫、遷移歷史資料、資料庫切換、歷史資料清理等步驟，步驟較為繁瑣，切換之前新擴容例項不能提供服務，且當主機上分庫達到下限後無法再擴容。
TiDB在對儲存節點tikv進行擴容時只需一條命令即可完成擴容操作，控制節點會自動的進行region排程以使每個例項的region和Leader均衡，當leader排程到新例項後即可開始服務,可以透過引數設定控制排程速度避免對叢集造成影響。
3.3 執行計劃管理
對於MySQL、分庫分表中介軟體當遇到慢SQL時存在以下幾個問題：(1) 不能儲存SQL執行時的實際執行計劃，只能在發現慢SQL後使用explain檢視，而檢視時的執行計劃和執行時可能會不一樣。
(2) 不能以實際執行的方式檢視執行計劃（MySQL8.0.18版本開始支援explain analyze方式）
(3) 不能對SQL執行計劃繫結。
TiDB的慢SQL日誌內會記錄執行計劃，透過select tidb_decode_plan()即可檢視，同時dashboard內也可以檢視慢SQL的執行計劃。TiDB4.0版本時推出SPM功能，實現執行計劃的繫結，提升了執行計劃穩定性。可參考文件tidb.io/blog/83b454f1。
從TiDB的執行計劃相關功能上看基本實現了類似oracle內的常用操作，執行計劃展示也類似於oracle的形式，同時執行計劃內還報含了每一步驟的資源消耗和時間統計資訊，比較利於判斷執行計劃的問題點。
3.4 DDL變更影響
MySQL、Oracle資料庫在執行DDL變更時如加列、新增索引等需要持有排他鎖，會阻塞其他操作，雖然有online ddl能力，執行期間允許DML操作 ，但在執行開始和結束時仍然要獲取排他鎖，防止有其他會話同時操作。而且在實際中發現當資料量較大時及時有oneline ddl仍會對其他會話產生鎖阻塞。
TiDB的表結構線上變更基於 Google F1 的非同步 Schema 變更演算法實現，變更是線上的、非同步的，並且 Schema 變更過程中所有資料保持可用 ，保持資料一致性，並最大限度減小對效能的影響。DDL變更操作僅更改資料字典，很快便可完成，僅有建立索引時需要回填資料，對於大表執行時間可能較長，可以透過設定併發執行緒加快速度，但是還是存在著序列執行問題。
3.5 混合負載支援
HTAP混合分析和事務處理是指一套資料庫上既能提供OLTP處理能力又能提供OLAP的分析能力，分庫分表方式一般透過資料同步方式將OLTP業務的資料同步到後端的分析型資料庫，該架構下除了維護生產庫，還需要維護資料同步通道和後端分析型資料庫，且在大資料量下存在著一定延遲，不能滿足實時數倉要求。
TiDB HTAP架構融合OLTP行存和OLAP列存兩種模式，透過tikv 提供oltp事務處理，透過tiflash提供OLAP處理，提供MPP能力。 TiDB內資料一致性透過raft實現，tikv中資料副本包含leader和follower角色，由leader實時接收計算節點的資料寫入。tiflash 中資料副本為learner角色，只從leader上同步資料，不參與raft投票，不影響tikv內leader選舉、遷移等，對OLTP事務處理無影響。
OLTP/OLAP訪問透過統一的計算節點入口實現，可以使用計算節點的智慧選擇方式，根據資料量自動選擇從tikv還是tiflash讀取資料，還可以設定引擎隔離，使計算節點僅訪問tiflash，而不影響tikv節點。
Oracle 12C版本開始也支援記憶體列存，，將行資料以列存形式存在記憶體中，同時具備行存、列存兩種模式。MySQL推出了一個列存引擎heatwave用於OLAP的分析場景，作為mysql的第二引擎，目前只能在oracle cloud服務上使用，。
3.6 冷熱儲存分離
歷史資料儲存是OLTP型資料庫經常面對的問題，從應用設計、資料庫功能、儲存層都在考慮資料分層儲存，實現冷熱資料的分離，將比較昂貴的高速儲存資源用於頻繁的業務，低速的儲存資源用於不常訪問的業務資料，從而實現既能降低成本又能最大化的提升效能。例如訂單類表：1年內的資料訪問較為頻繁且訪問效能要求較高，那麼可以把這些資料放到高效能裝置上，而歷史資料可以放到低效能裝置。在應用設計時提前規劃好生產表和歷史表(可能每年一個歷史年表)業務實現，對於oracle資料庫需要新分配表空間實現冷熱分層(12C版本開始支援生命週期管理，可以實現表和分割槽級的自動壓縮、儲存分層)，對於MySQL可能需要新建例項透過資料匯入匯出實現冷熱分層。
TiDB 5.3版本開始支援placementrules in SQL(參考tidb.io/blog/2dd85a80) ,可在DDL語句中設定庫、表、分割槽級的資料放置規則，透過放置規則可以實現不同表設定不同的副本數、不同表的Leader放到不同的中心、資料的冷熱儲存分層，放置規則的實現透過儲存層的lable引數識別儲存節點的資料中心、機房、機架、主機、磁碟型別等，從而實現一個叢集內的不同放置規則。比如在兩地三中心的場景下(頻寬滿足的情況下)，可以在同城的2中心放置生產表的leader ，以提供快速的訪問，歷史資料表可以放到異地的容災中心，提供實時性要求不苛刻的歷史資料訪問，從而能充分利用3箇中心的資源。
除此之外tidb有著較好的資料壓縮儲存能力，能夠節省磁碟空間的佔用，根據京東物流的測試使用情況，和MySQL相比壓縮比可達3:1。詳見連結：asktug.com/t/topic/123379
3.7 監控指標精細度
TiDB叢集在部署時會同時部署一套Prometheus和grafana,資料庫內包含有很多metrics介面用於監控數整個叢集(包含主機)的效能和狀態資訊，並將這些資訊寫入到Prometheus裡，細化指標達到1000多個，頻率基本為30秒/次。告警程式只需從TiDB叢集的Prometheus直接查詢即可獲得監控指標資料，極大的方便了告警程式接入。除了上述功能外TiDB在持續改進系統可觀測性，5.4版本開始推出實時展示TOP SQL、ContinuesProfiling功能，這裡有點類似oracle的ASH功能.
3.8 自主運維能力提升
國產資料庫官方文件普遍存在著內容簡短的問題，相關原理只是粗略介紹，對於使用者來說無法瞭解到內部原理，需要依靠廠商完成問題處理，不便於自主運維能力提升。
TiDB從2015年1.0版本開始開源(目前最新版5.4)，遵循apache2.0開源協議，與其他國產庫開源方式不同，tidb自開始便以開源方式在github上提交程式碼，目前已有很多大廠在使用，建立了良好的社群環境，有較多的經驗可供參考（目測有些大廠正是因為看到了tidb開源帶來的效應也開始開源自己的產品）。官方文件相較於國內其他資料庫寫的也相對比較詳盡，透過每個版本的release，就可以看出其用心和重視程度，並且部落格上也有很多豐富的技術文章，如原始碼分析系列。對於資料庫的瞭解程度有利於企業的資料庫選型、運維延續性和成本降低。
據墨天輪資料庫排行榜統計TiDB已連續多年成為最流行的國產資料庫。
在國產化的背景下，越來越多的企業放棄oracle而選擇國產資料庫，大多數最初的策略可能會選擇分庫分表方式，分庫分表後端的MySQL相對來說還是比較成熟穩定，但分庫分錶帶來的成本增加(開發成本、運維成本)、複雜性也逐漸成為企業痛點，TiDB作為新興的NewSQL分散式關係型資料庫，在面對高併發和海量資料場景下，提供了較好的OLTP處理能力和快速的擴縮容能力，很好的解決了分庫分錶帶來的痛點問題。當然確定一款資料庫是否適合自己的業務還需要大量測試和實踐檢驗。
本文作者：h5n1 發表於 2022-03-14
原文連結：國產化浪潮下TiDB解決的痛點問題 | TiDB 社群
本作品採用《CC 協議》，轉載必須註明作者和本文連結