PingCAP創始人劉奇：TiDB設計理念進化與大規模實踐

本文是依據劉奇老師在“資料技術嘉年華”大會演講整理而來。

我今天介紹一下我們PingCAP的設計理念進化和一些實踐。

到現在為止TiDB已經開源有三年零兩個月，我是TiDB CEO，打雜比較多，偶爾寫寫程式碼。

為什麼做這個？我們被無數人問到這個問題。當初為什麼我們要做一個分散式資料庫？作為程式設計師我相信很多人很願意花些時間寫程式碼寫自己的東西，然而一直沒有非常理想的機會。

第二個不用關心容量規劃，程式設計師不知道這個東西最終能增長多少倍。

第三個任意時候都能擴充套件，彈性伸縮。大家都有這個經歷，凌晨三點做擴容經歷。

第四個，已有成本遷移，這是沒有辦法去避免的問題，現在有大量的產品在已有資料庫在跑著，我們希望得到更好的彈性。

在定這些目標之後我們開始做行動，作為資料庫廠商，大家通常擔心的第一件事情是產品的正確性，特別是演算法的正確性證明。如果演算法是錯的，我們算下來100%是錯的。所以我們對於每個演算法，每個改進都先寫證明，我們把所有證明過程也開源了。寫證明會發現整個系統裡有大量的併發問題。

另外幾點水平擴充套件、高可用。因為大家知道資料庫情況很複雜，整個系統的複雜性，我們有點類似於像微服務的思維，把整個系統分成幾層，儲存層、計算層、排程層，徹底分開，分別變成不同的。產品總體看起來是這樣的，大體上是MySQL協議支援，SQL  layer、tiKV，排程器會動態把一些資料移動、分裂，讓所有的資料在整個系統裡都是動態的，這也是不同其他的地方。近距離看大概是這樣的，時間關係不詳細展開。

從SQL角度來看，我們有邏輯計劃，邏輯計劃做最佳化最後會變成物理的plan。下面整個底層是儲存層。

從使用者角度來講，使用者通常不關心說我到底是OLTP還是HTAP。Oracle從一開始設計，考慮新產品上線的時候大家覺得緊張，覺得資料庫上去會不會是安全的。我線上已經做了庫分表，或者線上已經有多個業務在跑，我現在需要有一個平臺去查詢已有的所有資料，於是他們就幹了這樣的一件事情，搭了一個大的TiDB諮詢，把全公司所有業務全部導在這上面進行同步，這樣TiDB就變成了很有意思的資料中臺，全公司的資料都可以在毫秒級內去做查詢。

我們當時看這個案例都驚呆了，覺得我們不是用來幹這個事兒的，後來使用者把TiDB用成認證SAP的場景，比較早期它一上來解決這樣的痛苦，當時TiDB完全沒有想到。後來我們慢慢想明白了當你把所有資料放在一個平臺上的時候，你在這個平臺上做查詢你把原來分庫分表寫的很痛苦的問題，每天晚上做分析，這個已經不滿足現在社會需要，大家希望在毫秒級對資料進行決策，比如說分控。

這是我們儲存層整體的使用者感受，儲存層為SQL提供，一個是分散式事務，再也不用操心這個事務是分散式事務還是單機事務，我們只提供一種就是分散式事務，不管什麼操作都是滿足資料屬性的。剛才我也提到資料被拆分很多層，它已經拆分可以合併，這個好處在於什麼？

這時候分庫表就會非常痛苦，它會自動把這個塊切成多塊再分佈多個機器裡，它會做自動的負載均衡。當我們有很多這樣小塊出現，這些小塊平時可能有很少訪問的時候，我們會嘗試把它變成大塊，可以對它進行分裂、合併。這塊很明顯看到，TiDB和其他資料庫的理念差異，我們認為所有資料庫都應該是動態的，而不應該是靜態的。同時我們也會把SQL計算，把函式會推到儲存節點，這樣減少中間的環節。

這是一個大圖，TiDB怎麼做到高資料中心的強一致，單資料中怎麼掛節點，怎麼確保資料可用。通常部署是這樣的，通常有三個副本，用顏色標出來，然後是協議複製。這是通常的線上的部署的場景，對於金融環境，比如說像銀行，我們一般推薦5個副本。這個也是符合google當初提到的，他們推薦的是7個副本。取決於資料庫的重要性。

接下來說一下我們的實戰經驗，剛才我提到大中臺業務，實時把公司資料會聚在一起，因為它是很自然的需求，也是一個完美的替代方案。這是歷史上很有意思的使用邏輯，剛開始把資料同步，可靠性都能達到要求的時候，就把前面分庫表撤下去直接把它打到叢集裡，這時候整個系統就高度一致了。這是一個更加好理解的圖，中間所有的資料都可以透過Syncer，進行資料同步。目前我們資料量特別大的場景裡，這種場景用的比較多。

考慮到實時性和Spark生態，我們提供Spark  connector，它會繞過TiDB層直接跟Tikv層，期間減少轉換開銷。

這是非常典型的異地多活架構圖，也是目前我們在銀行裡實施的整體架構。目前一部分核心電子交易系統也使的這樣的架構，通常使用5個副本，大體上是這樣的，在整個系統裡代表資料塊，可以看到對於同樣的一塊資料，我們會讓它複製在多個資料中心，同時透過排程器會將相同的資料塊leader排程到離業務比較近的一塊地方，這樣一來業務去訪問的時候延遲就會比較低，這就是有一個很好的排程器帶來的好處，它可以控制資料，按照需要去做分佈。比如說如果這時候我們要維護一個資料中心，假設我們要維護這邊的IDC，這時可以把資料錄入到其他地方，等它恢復之後再挪過來。

這是轉轉前一陣分享的案例，轉轉All  in  TiDB，把以前的很多業務都遷到TiDB上面，當時微信支援轉轉，他們當時增長約五倍，有一篇非常詳細的文章，分享時間會比較長。我這邊稍微小結一下，他們目前的上線情況，上線11套OLTP系統，1套OLAP系統，完成90%的資料遷移，TiDB資料千億級表，萬級TPS。這個地方他們分享了一個截圖，在他們放量期間，整個TiDB響應時間非常的短。

美團昨天剛剛發了一篇文章講他們自己的使用經驗，目前上線了大概200臺物理機，上了10多個業務，以前的時候美團主要資料庫用的MySQL、NoSQL，同時他們有一個自己的研發。當然融合起來都非常的痛苦，同時美團用了很強的研發能力，也在參與TiDB的開發。當時他們選擇新一代資料庫的定義幾個重要目標，一個支撐未來幾十倍資料增長目標，資料庫其中是很重要的一個元件，所以在資料庫選型花了大量的時間，應該是以幾個月時間對資料庫做各種的測試，對於資料庫原理的理解，對於資料庫閱讀，最終對比之後他們選擇了TiDB。

這是目前在美團上線10套系統裡分佈的範圍，分到6個事業群和平臺。剛才我也提到，線上上層開啟Region，整個系統會自動把小的資料塊合成大的資料塊，永遠有排程源根據負載做排程，這是加快刪除資料後的空間回收速度。

美團推廣速度非常快，大概只用三個月時間就上線這麼多系統，後來我們也去找美團同學請教經驗，為什麼推廣這麼快？他們有專門的地推小組，第二有專門的研發同學和我們有直接的合作，直接是程式碼級別的合作，也會發布他們自己對於TiDB的改進經驗，還有一些從研發層面的原始碼改進。這是HTAP的案例，這是易果生鮮，他們非常符合剛才我們提到的大中臺的結構，就會資料同步。

講商業銀行之前，我想說一句，根據我們自己的統計，目前30億美金以上的網際網路公司已經有8成用了TiDB，我當時看了也覺得特別的震驚，我相信明年會更多，這是國內的一個商業銀行的多活的交易系統裡面的部署結構。這部署結構相對來說，看起來很順暢，按照一個TiDB的標準結構，同時為了資料的絕對安全，我們後來又加了叢集，它主要做備份，它有3個副本，所以我們搭建了備份系統。

前一段時間我們看到他們支撐雙十一的過程，非常讓人過程，雙十一是很神奇的節日，可以把一天的流量聚集到那麼兩分鐘。有一篇文章寫的很詳細，網上有發表，他們怎麼用，怎麼測試，怎麼選型以及怎麼上線和上線的經驗。

我重點說一下，當一個資料庫產品從開始的到使用者去用到場景越來越多的時候，需要產品有更好的適應性。在這種情況下產品需要不斷的進化，在進化裡有很有意思的過程，就像我們人一樣，我們一步步往外的。通常情況下，一個MySQL大家覺得合理，大家覺得一行在50列以內是合理的舉手？200列以內合理的舉下手？400列以內合理的舉下手？在很多行業幾百列是常態。我們們網際網路一般在這些場景見的不多，現在覺得500列已經不夠用了，大家需要更多的怎麼辦？

那好，我就什麼都能存，這時就面臨一個問題。SQL有一個問題，當我們把實際減少欄位挪出去只處理它的源資料在哪一個位置，它長度多少，我們只需要幾十個位元組就搞定了。所以我們就把value從LSM tree中分離出來。

Serverless是去年和今年都比較火的話題，TiDB目前已經在上面提供了服務，目前在google  GKE和AWS  EKS都已經上線，大家可以在這兩個平臺一鍵搭建TiDB，目前這兩個平臺API和  K8S上線非常舒適，我們很好的線上上給大家提供服務。同時正在做的事情，根據負載自動新增計算節點，讓大家無感，讓大家不用計算，我到底要部署多少個儲存節點，這些東西不需要關心，後臺自動會幫你做，它會根據負載自動新增或伸縮。

TiDB對於儲存要求，我們要求使用SSAD。這時候就會帶來大家擔心的成本問題，我知道雖然現在MME（音）已經是新的採購標配，不是所有資料都需要在資料庫裡，需要在記憶體裡有索引，但是對於資料變冷之後，系統應該自動識別冷資料，並且把冷資料自動搬出去，同時保持相對可以接受的延遲，需要時按需做載入做計算，當一個叢集到幾百T時需要算幾百T的成本，這時就需要有一套方式能夠把資料的冷熱進行分離出來。分離的過程，完全不需要人操作，因為系統可以根據訪問資料熱度上線時間來決定。簡化資料管理最重要，當然儲存成本現在已經很便宜，這個也會進一步降低儲存的成本。

剛才我也提到使用者根本不關心所謂的OLTP、OSTP，能不能搞定，和很好的做隔離。所以在TiDB下一代迭代裡會出現全新的結構，在TiDB的三個副本里有三個副本使用列存，它會根據查詢特點，這時候根本不進到行存會直接在列存出現結果。同時在掃大範圍表裡會自動到列存，會把行存列存資料統一出來，這時會有非常震撼的效果，它會像列存行存跑得快，最重要一點不用關心它是列存還是行存，同時訪問的時間沒有延遲。

如果大家先用現在的版本，會發現現在的版本沒有很好的做到在CPU，在記憶體上的隔離。現在按照佇列優先順序來的，接下來的版本會看到完全不一樣的，同時對最佳化器產生非常高的要求，以前大家見到所有的最佳化器都考慮我是行存或者列存最佳化器，現在

它是智慧最佳化器，它會根據你的特點到底選擇行存還是列存去存，還是一部分到列存裡，比如ID會印什麼，印的這裡會在行存裡存，其他在列存裡，最後摺合在一起，這將讓我們非常興奮，我們預期1月份放出第一個可以體驗的版本。

很多人知道TiDB，知道TiDB很多事情，也有很多事情可能大家不知道。我說一下大家可能不知道TiDB的一些事情，我們知道TiDB今年拿了最佳的開源軟體獎，我印象中歷史上好像是第一個國內廠商拿到這個獎，歡迎大家糾正我。

TiDB也是進了CNCF  database  landscape，如果沒記錯，國內廠商第一個進到這裡。我非常欣慰，這麼多年終於可以為國爭光了。同時我們也做了一些事情，我們把TiKV給了CNCF，在前兩天大會上也是被大家認出來了。作為一個低調廠商，可能這些東西都不知道，我們從來沒有做過融資釋出會，從來沒有做過產品釋出會，和大家印象中的很多公司都不一樣，我們一直低調做事情，最終還是能看到大家以前看不到的那些東西。我們也進了Big  data  landscape，好像也是唯一的國內廠商，大家可以看一下這個圖，非常的欣慰。

大家可能不知道TiDB的使用者早就分佈了全球，大家通常只能看到身邊，美團好在用，Oracle在用。大家可能不知道新加坡的也在用，可能也不知道印度在用，臺灣也用上了。

謝謝大家！