本文是依據(jù)劉奇老師在“數(shù)據(jù)技術(shù)嘉年華”大會演講整理而來。

（本文 PPT下載，關(guān)注公眾號回復(fù)：2018DTC ，劉奇老師的PPT位于主會場模塊下。

點(diǎn)擊“閱讀原文”查看主會場直播回放。

我今天介紹一下我們PingCAP的設(shè)計理念進(jìn)化和一些實(shí)踐。

到現(xiàn)在為止TiDB已經(jīng)開源有三年零兩個月，我是TiDB CEO，打雜比較多，偶爾寫寫代碼。

為什么做這個？我們被無數(shù)人問到這個問題。當(dāng)初為什么我們要做一個分布式數(shù)據(jù)庫？作為程序員我相信很多人很愿意花些時間寫代碼寫自己的東西，然而一直沒有非常理想的機(jī)會。

第二個不用關(guān)心容量規(guī)劃，程序員不知道這個東西最終能增長多少倍。

第三個任意時候都能擴(kuò)展，彈性伸縮。大家都有這個經(jīng)歷，凌晨三點(diǎn)做擴(kuò)容經(jīng)歷。

第四個，已有成本遷移，這是沒有辦法去避免的問題，現(xiàn)在有大量的產(chǎn)品在已有數(shù)據(jù)庫在跑著，我們希望得到更好的彈性。

在定這些目標(biāo)之后我們開始做行動，作為數(shù)據(jù)庫廠商，大家通常擔(dān)心的第一件事情是產(chǎn)品的正確性，特別是算法的正確性證明。如果算法是錯的，我們算下來100%是錯的。所以我們對于每個算法，每個改進(jìn)都先寫證明，我們把所有證明過程也開源了。寫證明會發(fā)現(xiàn)整個系統(tǒng)里有大量的并發(fā)問題。

另外幾點(diǎn)水平擴(kuò)展、高可用。因為大家知道數(shù)據(jù)庫情況很復(fù)雜，整個系統(tǒng)的復(fù)雜性，我們有點(diǎn)類似于像微服務(wù)的思維，把整個系統(tǒng)分成幾層，存儲層、計算層、調(diào)度層，徹底分開，分別變成不同的。產(chǎn)品總體看起來是這樣的，大體上是MySQL協(xié)議支持，SQL  layer、tiKV，調(diào)度器會動態(tài)把一些數(shù)據(jù)移動、分裂，讓所有的數(shù)據(jù)在整個系統(tǒng)里都是動態(tài)的，這也是不同其他的地方。近距離看大概是這樣的，時間關(guān)系不詳細(xì)展開。

從SQL角度來看，我們有邏輯計劃，邏輯計劃做優(yōu)化最后會變成物理的plan。下面整個底層是存儲層。

從用戶角度來講，用戶通常不關(guān)心說我到底是OLTP還是HTAP。Oracle從一開始設(shè)計，考慮新產(chǎn)品上線的時候大家覺得緊張，覺得數(shù)據(jù)庫上去會不會是安全的。我線上已經(jīng)做了庫分表，或者線上已經(jīng)有多個業(yè)務(wù)在跑，我現(xiàn)在需要有一個平臺去查詢已有的所有數(shù)據(jù)，于是他們就干了這樣的一件事情，搭了一個大的TiDB咨詢，把全公司所有業(yè)務(wù)全部導(dǎo)在這上面進(jìn)行同步，這樣TiDB就變成了很有意思的數(shù)據(jù)中臺，全公司的數(shù)據(jù)都可以在毫秒級內(nèi)去做查詢。

我們當(dāng)時看這個案例都驚呆了，覺得我們不是用來干這個事兒的，后來用戶把TiDB用成認(rèn)證SAP的場景，比較早期它一上來解決這樣的痛苦，當(dāng)時TiDB完全沒有想到。后來我們慢慢想明白了當(dāng)你把所有數(shù)據(jù)放在一個平臺上的時候，你在這個平臺上做查詢你把原來分庫分表寫的很痛苦的問題，每天晚上做分析，這個已經(jīng)不滿足現(xiàn)在社會需要，大家希望在毫秒級對數(shù)據(jù)進(jìn)行決策，比如說分控。

這是我們存儲層整體的用戶感受，存儲層為SQL提供，一個是分布式事務(wù)，再也不用操心這個事務(wù)是分布式事務(wù)還是單機(jī)事務(wù)，我們只提供一種就是分布式事務(wù)，不管什么操作都是滿足數(shù)據(jù)屬性的。剛才我也提到數(shù)據(jù)被拆分很多層，它已經(jīng)拆分可以合并，這個好處在于什么？

這時候分庫表就會非常痛苦，它會自動把這個塊切成多塊再分布多個機(jī)器里，它會做自動的負(fù)載均衡。當(dāng)我們有很多這樣小塊出現(xiàn)，這些小塊平時可能有很少訪問的時候，我們會嘗試把它變成大塊，可以對它進(jìn)行分裂、合并。這塊很明顯看到，TiDB和其他數(shù)據(jù)庫的理念差異，我們認(rèn)為所有數(shù)據(jù)庫都應(yīng)該是動態(tài)的，而不應(yīng)該是靜態(tài)的。同時我們也會把SQL計算，把函數(shù)會推到存儲節(jié)點(diǎn)，這樣減少中間的環(huán)節(jié)。

這是一個大圖，TiDB怎么做到高數(shù)據(jù)中心的強(qiáng)一致，單數(shù)據(jù)中怎么掛節(jié)點(diǎn)，怎么確保數(shù)據(jù)可用。通常部署是這樣的，通常有三個副本，用顏色標(biāo)出來，然后是協(xié)議復(fù)制。這是通常的線上的部署的場景，對于金融環(huán)境，比如說像銀行，我們一般推薦5個副本。這個也是符合google當(dāng)初提到的，他們推薦的是7個副本。取決于數(shù)據(jù)庫的重要性。

接下來說一下我們的實(shí)戰(zhàn)經(jīng)驗，剛才我提到大中臺業(yè)務(wù)，實(shí)時把公司數(shù)據(jù)會聚在一起，因為它是很自然的需求，也是一個完美的替代方案。這是歷史上很有意思的使用邏輯，剛開始把數(shù)據(jù)同步，可靠性都能達(dá)到要求的時候，就把前面分庫表撤下去直接把它打到集群里，這時候整個系統(tǒng)就高度一致了。這是一個更加好理解的圖，中間所有的數(shù)據(jù)都可以通過Syncer，進(jìn)行數(shù)據(jù)同步。目前我們數(shù)據(jù)量特別大的場景里，這種場景用的比較多。

考慮到實(shí)時性和Spark生態(tài)，我們提供Spark  connector，它會繞過TiDB層直接跟Tikv層，期間減少轉(zhuǎn)換開銷。

這是非常典型的異地多活架構(gòu)圖，也是目前我們在銀行里實(shí)施的整體架構(gòu)。目前一部分核心電子交易系統(tǒng)也使的這樣的架構(gòu)，通常使用5個副本，大體上是這樣的，在整個系統(tǒng)里代表數(shù)據(jù)塊，可以看到對于同樣的一塊數(shù)據(jù)，我們會讓它復(fù)制在多個數(shù)據(jù)中心，同時通過調(diào)度器會將相同的數(shù)據(jù)塊leader調(diào)度到離業(yè)務(wù)比較近的一塊地方，這樣一來業(yè)務(wù)去訪問的時候延遲就會比較低，這就是有一個很好的調(diào)度器帶來的好處，它可以控制數(shù)據(jù)，按照需要去做分布。比如說如果這時候我們要維護(hù)一個數(shù)據(jù)中心，假設(shè)我們要維護(hù)這邊的IDC，這時可以把數(shù)據(jù)錄入到其他地方，等它恢復(fù)之后再挪過來。

這是轉(zhuǎn)轉(zhuǎn)前一陣分享的案例，轉(zhuǎn)轉(zhuǎn)All  in  TiDB，把以前的很多業(yè)務(wù)都遷到TiDB上面，當(dāng)時微信支持轉(zhuǎn)轉(zhuǎn)，他們當(dāng)時增長約五倍，有一篇非常詳細(xì)的文章，分享時間會比較長。我這邊稍微小結(jié)一下，他們目前的上線情況，上線11套OLTP系統(tǒng)，1套OLAP系統(tǒng)，完成90%的數(shù)據(jù)遷移，TiDB數(shù)據(jù)千億級表，萬級TPS。這個地方他們分享了一個截圖，在他們放量期間，整個TiDB響應(yīng)時間非常的短。

美團(tuán)昨天剛剛發(fā)了一篇文章講他們自己的使用經(jīng)驗，目前上線了大概200臺物理機(jī)，上了10多個業(yè)務(wù)，以前的時候美團(tuán)主要數(shù)據(jù)庫用的MySQL、NoSQL，同時他們有一個自己的研發(fā)。當(dāng)然融合起來都非常的痛苦，同時美團(tuán)用了很強(qiáng)的研發(fā)能力，也在參與TiDB的開發(fā)。當(dāng)時他們選擇新一代數(shù)據(jù)庫的定義幾個重要目標(biāo)，一個支撐未來幾十倍數(shù)據(jù)增長目標(biāo)，數(shù)據(jù)庫其中是很重要的一個組件，所以在數(shù)據(jù)庫選型花了大量的時間，應(yīng)該是以幾個月時間對數(shù)據(jù)庫做各種的測試，對于數(shù)據(jù)庫原理的理解，對于數(shù)據(jù)庫閱讀，最終對比之后他們選擇了TiDB。

這是目前在美團(tuán)上線10套系統(tǒng)里分布的范圍，分到6個事業(yè)群和平臺。剛才我也提到，在線上層開啟Region，整個系統(tǒng)會自動把小的數(shù)據(jù)塊合成大的數(shù)據(jù)塊，永遠(yuǎn)有調(diào)度源根據(jù)負(fù)載做調(diào)度，這是加快刪除數(shù)據(jù)后的空間回收速度。

美團(tuán)推廣速度非?？?，大概只用三個月時間就上線這么多系統(tǒng)，后來我們也去找美團(tuán)同學(xué)請教經(jīng)驗，為什么推廣這么快？他們有專門的地推小組，第二有專門的研發(fā)同學(xué)和我們有直接的合作，直接是代碼級別的合作，也會發(fā)布他們自己對于TiDB的改進(jìn)經(jīng)驗，還有一些從研發(fā)層面的源碼改進(jìn)。這是HTAP的案例，這是易果生鮮，他們非常符合剛才我們提到的大中臺的結(jié)構(gòu)，就會數(shù)據(jù)同步。

講商業(yè)銀行之前，我想說一句，根據(jù)我們自己的統(tǒng)計，目前30億美金以上的互聯(lián)網(wǎng)公司已經(jīng)有8成用了TiDB，我當(dāng)時看了也覺得特別的震驚，我相信明年會更多，這是國內(nèi)的一個商業(yè)銀行的多活的交易系統(tǒng)里面的部署結(jié)構(gòu)。這部署結(jié)構(gòu)相對來說，看起來很順暢，按照一個TiDB的標(biāo)準(zhǔn)結(jié)構(gòu)，同時為了數(shù)據(jù)的絕對安全，我們后來又加了集群，它主要做備份，它有3個副本，所以我們搭建了備份系統(tǒng)。

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

我重點(diǎn)說一下，當(dāng)一個數(shù)據(jù)庫產(chǎn)品從開始的到用戶去用到場景越來越多的時候，需要產(chǎn)品有更好的適應(yīng)性。在這種情況下產(chǎn)品需要不斷的進(jìn)化，在進(jìn)化里有很有意思的過程，就像我們?nèi)艘粯?，我們一步步往外的。通常情況下，一個MySQL大家覺得合理，大家覺得一行在50列以內(nèi)是合理的舉手？200列以內(nèi)合理的舉下手？400列以內(nèi)合理的舉下手？在很多行業(yè)幾百列是常態(tài)。咱們互聯(lián)網(wǎng)一般在這些場景見的不多，現(xiàn)在覺得500列已經(jīng)不夠用了，大家需要更多的怎么辦？

那好，我就什么都能存，這時就面臨一個問題。SQL有一個問題，當(dāng)我們把實(shí)際減少字段挪出去只處理它的源數(shù)據(jù)在哪一個位置，它長度多少，我們只需要幾十個字節(jié)就搞定了。所以我們就把value從LSM tree中分離出來。

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

TiDB對于存儲要求，我們要求使用SSAD。這時候就會帶來大家擔(dān)心的成本問題，我知道雖然現(xiàn)在MME（音）已經(jīng)是新的采購標(biāo)配，不是所有數(shù)據(jù)都需要在數(shù)據(jù)庫里，需要在內(nèi)存里有索引，但是對于數(shù)據(jù)變冷之后，系統(tǒng)應(yīng)該自動識別冷數(shù)據(jù)，并且把冷數(shù)據(jù)自動搬出去，同時保持相對可以接受的延遲，需要時按需做加載做計算，當(dāng)一個集群到幾百T時需要算幾百T的成本，這時就需要有一套方式能夠把數(shù)據(jù)的冷熱進(jìn)行分離出來。分離的過程，完全不需要人操作，因為系統(tǒng)可以根據(jù)訪問數(shù)據(jù)熱度上線時間來決定。簡化數(shù)據(jù)管理最重要，當(dāng)然存儲成本現(xiàn)在已經(jīng)很便宜，這個也會進(jìn)一步降低存儲的成本。

剛才我也提到用戶根本不關(guān)心所謂的OLTP、OSTP，能不能搞定，和很好的做隔離。所以在TiDB下一代迭代里會出現(xiàn)全新的結(jié)構(gòu)，在TiDB的三個副本里有三個副本使用列存，它會根據(jù)查詢特點(diǎn)，這時候根本不進(jìn)到行存會直接在列存出現(xiàn)結(jié)果。同時在掃大范圍表里會自動到列存，會把行存列存數(shù)據(jù)統(tǒng)一出來，這時會有非常震撼的效果，它會像列存行存跑得快，最重要一點(diǎn)不用關(guān)心它是列存還是行存，同時訪問的時間沒有延遲。

如果大家先用現(xiàn)在的版本，會發(fā)現(xiàn)現(xiàn)在的版本沒有很好的做到在CPU，在內(nèi)存上的隔離?，F(xiàn)在按照隊列優(yōu)先級來的，接下來的版本會看到完全不一樣的，同時對優(yōu)化器產(chǎn)生非常高的要求，以前大家見到所有的優(yōu)化器都考慮我是行存或者列存優(yōu)化器，現(xiàn)在

它是智能優(yōu)化器，它會根據(jù)你的特點(diǎn)到底選擇行存還是列存去存，還是一部分到列存里，比如ID會印什么，印的這里會在行存里存，其他在列存里，最后折合在一起，這將讓我們非常興奮，我們預(yù)期1月份放出第一個可以體驗的版本。

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

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

大家可能不知道TiDB的用戶早就分布了全球，大家通常只能看到身邊，美團(tuán)好在用，Oracle在用。大家可能不知道新加坡的也在用，可能也不知道印度在用，臺灣也用上了。

謝謝大家！