摘要：在上，我司聯(lián)合創(chuàng)始人兼黃東旭分享了對(duì)數(shù)據(jù)庫行業(yè)大趨勢(shì)以及未來數(shù)據(jù)庫技術(shù)的看法。如果我想看看美國的消費(fèi)者里面有哪些在中國有過消費(fèi)的，就是這么一條。

在 TiDB DevCon 2019 上，我司聯(lián)合創(chuàng)始人兼 CTO 黃東旭分享了對(duì)數(shù)據(jù)庫行業(yè)大趨勢(shì)以及未來數(shù)據(jù)庫技術(shù)的看法。以下是演講實(shí)錄，enjoy~

大家今天在這里看到了 TiDB 社區(qū)用戶實(shí)踐分享和我們自己的一些技術(shù)進(jìn)展和展望，還有非常好玩的 Demo Show，正好在大會(huì)結(jié)束之前，我想跟大家聊一聊我心目中未來的 Database 應(yīng)該是一個(gè)什么樣子。

其實(shí)我們并不是一個(gè)特別擅長(zhǎng)發(fā)明名詞的公司，我記得我們第一次去用 HTAP 這個(gè)詞的時(shí)候，應(yīng)該是 2016 左右。在使用 HTAP 這個(gè)詞的時(shí)候，我們市場(chǎng)部同事還跟我們說 HTAP 這個(gè)詞從來沒人用過，都是論文里的詞，大家都不知道，你把你們公司的產(chǎn)品定位改成這個(gè)別人都不知道怎么辦？我們后來仔細(xì)想，還是覺得 HTAP 這個(gè)方向是一個(gè)更加適合我們的方向，所以還是選了 HTAP 這個(gè)詞。現(xiàn)在很欣喜的看到現(xiàn)在各種友商、后來的一些數(shù)據(jù)庫，都開始爭(zhēng)相說 HTAP，就是說得到了同行的認(rèn)可。

那么在 HTAP 的未來應(yīng)該是一個(gè)什么樣子，我希望能夠在今年這個(gè) Talk 里面先說一說，但是這個(gè)題目起的有點(diǎn)不太謙虛，所以我特地加了一個(gè)「Near」， 分享一下這一年、兩年、三年我們想做什么，和對(duì)行業(yè)大趨勢(shì)的展望。

今天我們的分享的一個(gè)主題就是：「我們只做用戶想要的東西，并不是要去做一個(gè)完美的東西」。其實(shí)很多工程師包括我們自己，都會(huì)有一個(gè)小小的心理的潔癖，就是想要做一個(gè)超級(jí)快、超級(jí)牛的東西，但是做出來一個(gè)數(shù)據(jù)庫，單機(jī)跑分一百萬 TPS ，其實(shí)用戶實(shí)際業(yè)務(wù)就需要 3000，然后所有的用戶還會(huì)說我需要這些東西，比如需要 Scalability（彈性擴(kuò)展）， Super Large 的數(shù)據(jù)量，最好是我的業(yè)務(wù)一行代碼都不用改，而且 ACID 能夠完全的滿足，怎么踹都踹不壞，機(jī)器壞了可以高可用，業(yè)務(wù)層完全不用動(dòng)， 另外可以在跑 OLTP 的同時(shí)，完全不用擔(dān)心任何資源隔離地跑 OLAP（這里不是要說大家的愿望不切實(shí)際，而是非常切實(shí)際，我們也覺得數(shù)據(jù)庫本身就應(yīng)該是這樣的。所以大家記住這幾個(gè)要點(diǎn)，然后慢慢看 TiDB 到底是不是朝著這個(gè)方向發(fā)展的）。本質(zhì)上來說用戶的需求就是「大一統(tǒng)」。看過《魔戒》的同學(xué)都知道這句話 ：ONE RING TO RULE THEM ALL，就是一套解決方案去解決各種問題。

過去很多，包括一些行業(yè)的大佬之前說在各種環(huán)境下都要出一個(gè)數(shù)據(jù)庫來解決特定的一個(gè)問題，但是其實(shí)看上去我們想走的方案還是盡可能在一個(gè)平臺(tái)里面，盡可能大范圍去解決用戶的問題。因?yàn)椴煌漠a(chǎn)品之間去做數(shù)據(jù)的交互和溝通，其實(shí)是蠻復(fù)雜的。

這張圖（圖 2）什么意思呢？就是很多人設(shè)計(jì)系統(tǒng)的時(shí)候，總是會(huì)陷入跑分思維，就是說這個(gè)東西在實(shí)驗(yàn)室或者說在一個(gè)特定的 Workload 下，跑得巨快無比。如果大家去看一下大概 2000 年以后關(guān)于數(shù)據(jù)庫的論文，很多在做一個(gè)新的模型或者新的系統(tǒng)的時(shí)候，都會(huì)說 TPCC 能夠跑到多大，然后把 Oracle 摁在地上摩擦，這樣的論文有很多很多很多。但是大家回頭看看 Oracle 還是王者。所以大多數(shù)實(shí)驗(yàn)室的產(chǎn)品和工程師自己做的東西都會(huì)陷入一個(gè)問題，就是想象中的我的賽道應(yīng)該是一個(gè)圖 2 那樣的，但實(shí)際上用戶的業(yè)務(wù)環(huán)境是下面這樣的（圖 3）。很多大家在廣告上看到特別牛的東西，一放到生產(chǎn)環(huán)境或者說放到自己的業(yè)務(wù)場(chǎng)景里面就不對(duì)了，然后陷入各種各樣的比較和糾結(jié)的煩惱之中。

TiDB 的定位或者說我們想做的事情，并不是在圖 2 那樣的賽道上，跑步跑得巨快，全世界沒人在短跑上跑得過我，我們不想做這樣。或者說，我們其實(shí)也能跑得很快，但是并不想把所有優(yōu)勢(shì)資源全都投入到一個(gè)用戶可能一輩子都用不到的場(chǎng)景之中。我們其實(shí)更像是做鐵人三項(xiàng)的，因?yàn)橛脩魧?shí)際應(yīng)用場(chǎng)景可能就是一個(gè)土路。這就是為什么 TiDB 的設(shè)計(jì)放在第一位的是「穩(wěn)定性」。

我們一直在想能不能做一個(gè)數(shù)據(jù)庫，怎么踹都踹不壞，然后所有的異常的狀況，或者它的 Workload ?都是可預(yù)期的。我覺得很多人遠(yuǎn)遠(yuǎn)低估了這個(gè)事情的困難程度，其實(shí)我們自己也特別低估了困難程度。大概 4 年前出來創(chuàng)業(yè)的時(shí)候，我們就是想做這么一個(gè)數(shù)據(jù)庫出來，我跟劉奇、崔秋三個(gè)人也就三個(gè)月做出來了。但是到現(xiàn)在已經(jīng) 4 年過去了，我們的目標(biāo)跟當(dāng)年還是一模一樣。不忘初心，不是忘不掉，而是因?yàn)槌跣倪€沒達(dá)到，怎么忘？其實(shí)把一個(gè)數(shù)據(jù)庫做穩(wěn)，是很難很難的。

而且我們這個(gè)團(tuán)隊(duì)的平均年齡可能也就在二十到三十歲之間，為什么我們?nèi)绱四贻p的一個(gè)團(tuán)隊(duì)，能夠去做數(shù)據(jù)庫這么古老的一件事情。其實(shí)也是得益于整個(gè) IT 行業(yè)這幾年非常大的發(fā)展。圖 4 是這幾年發(fā)展起來的 SSD，內(nèi)存越來越大，萬兆的網(wǎng)卡，還有各種各樣的多核的 CPU，虛擬化的技術(shù)，讓過去很多不可能的事情變成了可能。

舉一個(gè)例子吧，比如極端一點(diǎn)，大家可能在上世紀(jì)八九十年代用過這種 5 寸盤、3 寸盤，我針對(duì)這樣的磁盤設(shè)計(jì)一個(gè)數(shù)據(jù)結(jié)構(gòu)，現(xiàn)在看上去是個(gè)笑話是吧？因?yàn)榇蠹腋緵]有人用這樣的設(shè)備了。在數(shù)據(jù)庫這個(gè)行業(yè)里面很多的假設(shè)，在現(xiàn)在新的硬件的環(huán)境下其實(shí)都是不成立的。比如說，為什么 B-Tree 就一定會(huì)比 LSM-Tree 要快呢？不一定啊，我跑到 Flash 或者 NVMe SSD 、Optane 甚至未來的持久化內(nèi)存這種介質(zhì)上，那數(shù)據(jù)結(jié)構(gòu)設(shè)計(jì)完全就發(fā)生變化了。過去可能需要投入很多精力去做的數(shù)據(jù)結(jié)構(gòu)，現(xiàn)在暴力就好了。

同時(shí)在軟件上也發(fā)生了很多很多的變革，圖 5 左上角是 Wisckey 那篇論文里的一個(gè)截圖，還有一些分布式系統(tǒng)上的新的技術(shù)，比如 2014 年 Diego 發(fā)表了 Raft 這篇論文，另外 Paxos 這幾年在各種新的分布式系統(tǒng)里也用得越來越多。

所以我覺得這幾年我們趕上了一個(gè)比較好的時(shí)代，就是不管是軟件還是硬件，還是分布式系統(tǒng)理論上，都有了一些比較大突破，所以我們基礎(chǔ)才能夠打得比較好。

除了有這樣的新的硬件和軟件之外，我覺得在業(yè)務(wù)場(chǎng)景上也在發(fā)生一些比較大變化。過去，可能十年前就是我剛開始參加工作的時(shí)候，線上的架構(gòu)基本就是在線和離線兩套系統(tǒng)，在線是 Oracle 和 MySQL，離線是一套 Hadoop 或者一個(gè)純離線的數(shù)據(jù)倉庫。但最近這兩年越來越多的業(yè)務(wù)開始強(qiáng)調(diào)敏捷、微服務(wù)和中臺(tái)化，于是產(chǎn)生了一個(gè)新的數(shù)據(jù)類型，就是 warm data，它需要像熱數(shù)據(jù)這樣支持 transaction、支持實(shí)時(shí)寫入，但是需要海量的數(shù)據(jù)都能存在這個(gè)平臺(tái)上實(shí)時(shí)查詢， 并不是離線數(shù)倉這種業(yè)務(wù)。

所以對(duì) warm data 來說，過去在 TiDB 之前，其實(shí)是并沒有太好的辦法去很優(yōu)雅的做一層大數(shù)據(jù)中臺(tái)架構(gòu)的，「the missing part of modern data processing stack」，就是在 warm data 這方面，TiDB 正好去補(bǔ)充了這個(gè)位置，所以才能有這么快的增長(zhǎng)。當(dāng)然這個(gè)增長(zhǎng)也是得益于 MySQL 社區(qū)的流行。

想象一下，我們?nèi)绻谶^去要做這樣很簡(jiǎn)單的業(yè)務(wù)（圖 7），比如在美國的訂單庫跟在中國的訂單庫可能都是在不同的數(shù)據(jù)庫里，用戶庫可能是另外一個(gè)庫，然后不同的業(yè)務(wù)可能是操作不同的庫。如果我想看看美國的消費(fèi)者里面有哪些在中國有過消費(fèi)的，就是這么一條 SQL。過去如果沒有像 TiDB 這樣的東西，大家想象這個(gè)東西該怎么做？

假如說這兩邊的數(shù)據(jù)量都特別大，然后已經(jīng)分庫分表了。過去可能只能第二天才可以看到前一天的數(shù)據(jù)，因?yàn)橹虚g比如說一個(gè)?T+1 ?要做一個(gè) ETL 到一個(gè) data ware house 里。或者厲害一點(diǎn)的架構(gòu)師可能會(huì)說，我可以做一套實(shí)時(shí)的 OLAP 來做這個(gè)事情，怎么做呢？比如說 MySQL 中間通過一個(gè) MQ 再通過 Hadoop 做一下 ETL，然后再導(dǎo)到 Hadoop 上做一個(gè)冷的數(shù)據(jù)存儲(chǔ)，再在上面去跑一個(gè) OLAP 做實(shí)時(shí)的分析。先不說這個(gè)實(shí)時(shí)性到底有多「實(shí)時(shí)」，大家仔細(xì)算一算，這套架構(gòu)需要的副本數(shù)有多少，比如 M 是我的業(yè)務(wù)數(shù)，N 是每一個(gè)系統(tǒng)會(huì)存儲(chǔ)的 Replica，拍腦袋算一下就是下面這個(gè)數(shù)字（圖 9 中的?R?）。

所以大家其實(shí)一開始在過去說，TiDB 這個(gè)背后這么多 Replica ?不好，但其實(shí)你想想，你自己在去做這個(gè)業(yè)務(wù)的時(shí)候，大家在過去又能怎么樣呢？所以我覺得 TiDB 在這個(gè)場(chǎng)景下去統(tǒng)一一個(gè)中臺(tái)，是一個(gè)大的趨勢(shì)。今天在社區(qū)實(shí)踐分享上也看到很多用戶都要提到了 TiDB 在中臺(tái)上非常好的應(yīng)用。

回顧完行業(yè)和應(yīng)用場(chǎng)景近年來的一些變化之后，我們?cè)僬f說未來。假設(shè)要去做一個(gè)面向未來的數(shù)據(jù)庫，會(huì)使用哪些技術(shù)？

第一個(gè)大的趨勢(shì)就是日志，「log is the new database」 這句話應(yīng)該也是業(yè)界的一個(gè)共識(shí)吧。現(xiàn)在如果有一個(gè)分布式數(shù)據(jù)庫的復(fù)制協(xié)議，還是同步一個(gè)邏輯語句過去，或者做 binlog 的復(fù)制，那其實(shí)還算比較 low 的。

上面圖 11 左半部分是 Hyper，它是慕尼黑工業(yè)大學(xué)的一個(gè)實(shí)驗(yàn)性數(shù)據(jù)庫項(xiàng)目，它做了一些分析，第一個(gè)柱形是正常的 SQL 語句的執(zhí)行時(shí)間，比如說直接把一語句放到另外一個(gè)庫里去執(zhí)行，耗時(shí)這么多。第二個(gè)柱形是用邏輯日志去存放，耗時(shí)大概能快 23%，第三個(gè)柱形能看到如果是存放物理日志能快 56%。所以大家仔細(xì)想想，TiDB 的架構(gòu)里的 TiFlash 其實(shí)同步的是 Raft 日志，而并不是同步 Binlog 或者其他的。

上面圖 11 右半部分是 Aurora，它的架構(gòu)就不用說了，同步的都是 redo log 。其實(shí)他的好處也很明顯，也比較直白，就是 I/O 更小，網(wǎng)絡(luò)傳輸?shù)?size 也更小，所以就更快。

然后在這一塊 TiDB 跟傳統(tǒng)的數(shù)據(jù)庫有點(diǎn)不一樣的就是，其實(shí)如果很多同學(xué)對(duì) TiDB 的基礎(chǔ)架構(gòu)不太理解的話就覺得， Raft 不是一個(gè)一定要有 Index 或者說是一定強(qiáng)順序的一個(gè)算法嗎？那為什么能做到這樣的亂序的提交？其實(shí) TiDB 并不是單 Raft 的架構(gòu)，而是一個(gè)多 Raft 的架構(gòu)，I/O 可以發(fā)生在任何一個(gè) Raft Group 上。傳統(tǒng)的單機(jī)型數(shù)據(jù)庫，就算你用更好的硬件都不可能達(dá)到一個(gè)線性擴(kuò)展，因?yàn)闊o論怎么去做，都是這么一個(gè)架構(gòu)不可改變。比如說我單機(jī)上 Snapshot 加 WAL，不管怎么寫， 總是在 WAL 后面加，I/O 總是發(fā)生在這。但 TiDB 的 I/O 是分散在多個(gè) Raft Group、多個(gè)機(jī)器上，這是一個(gè)很本質(zhì)的變化，這就是為什么在一些場(chǎng)景下，TiDB 能夠獲取更好的吞吐。

第二個(gè)大趨勢(shì)是全面的向量化。向量化是什么意思？我舉個(gè)簡(jiǎn)單的例子。比如我要去算一個(gè)聚合，從一個(gè)表里面去求某一列的總量數(shù)據(jù)，如果我是一個(gè)行存的數(shù)據(jù)庫，我只能把這條記錄的 C 取出來，然后到下一條記錄，再取再取再取，整個(gè) Runtime 的開銷也好，還有去掃描、讀放大的每一行也好，都是很有問題的。但是如果在內(nèi)存里面已經(jīng)是一個(gè)列式存儲(chǔ)，是很緊湊的結(jié)構(gòu)的話，那會(huì)是非常快的。

這里面其實(shí)也有一些挑戰(zhàn)。我們花了大概差不多 2018 年一年的時(shí)間去做向量化的改造，其實(shí)還挺難的。為什么？首先 TiDB SQL 引擎是用了 Volcano 模型，這個(gè)模型很簡(jiǎn)單，就是遍歷一棵物理計(jì)劃的樹，不停的調(diào) Next，每一次 Next 都是調(diào)用他的子節(jié)點(diǎn)的 Next，然后再返回結(jié)果。這個(gè)模型有幾個(gè)問題：第一是每一次都是拿一行，導(dǎo)致 CPU 的 L1、L2 這樣的緩存利用率很差，就是說沒有辦法利用多 CPU 的 Cache。第二，在真正實(shí)現(xiàn)的時(shí)候，它內(nèi)部的架構(gòu)是一個(gè)多級(jí)的虛函數(shù)調(diào)用。大家知道虛函數(shù)調(diào)用在 Runtime 本身的開銷是很大的，在《MonetDB/X100: Hyper-Pipelining Query Execution》里面提到，在跑 TPC-H 的時(shí)候，Volcano 模型在 MySQL 上跑，大概有 90% 的時(shí)間是花在 MySQL 本身的 Runtime 上，而不是真正的數(shù)據(jù)掃描。所以這就是 Volcano 模型一個(gè)比較大的問題。第三，如果使用一個(gè)純靜態(tài)的列存的數(shù)據(jù)結(jié)構(gòu)，大家知道列存特別大問題就是它的更新是比較麻煩的， 至少過去在 TiFlash 之前，沒有一個(gè)列存數(shù)據(jù)庫能夠支持做增刪改查。那在這種情況下，怎么保證數(shù)據(jù)的新鮮？這些都是問題。

TiDB 已經(jīng)邁出了第一步，我們已經(jīng)把 TiDB SQL 引擎的 Volcano 模型，從一行一行變成了一個(gè) Chunk 一個(gè) Chunk，每個(gè) Chunk 里面是一個(gè)批量的數(shù)據(jù)，所以聚合的效率會(huì)更高。而且在 TiDB 這邊做向量化之外，我們還會(huì)把這些算子推到 TiKV 來做，然后在 TiKV 也會(huì)變成一個(gè)全向量化的執(zhí)行器的框架。

另外一個(gè)比較大的話題，是 Workload Isolation。今天我們?cè)谘菔镜母鞣N東西都有一個(gè)中心思想，就是怎么樣盡可能地把 OLTP 跟 OLAP 隔離開。這個(gè)問題在業(yè)界也有不同的聲音，包括我們的老前輩 Google Spanner，他們其實(shí)是想做一個(gè)新的數(shù)據(jù)結(jié)構(gòu)，來替代 Bigtable-Like SSTable 數(shù)據(jù)結(jié)構(gòu)，這個(gè)數(shù)據(jù)結(jié)構(gòu)叫 Ressi，大家去看 2018 年 《Spanner: Becoming a SQL System》這篇 Paper 就能看到。它其實(shí)表面上看還是行存，但內(nèi)部也是一個(gè) Chunk 變成列存這樣的一個(gè)結(jié)構(gòu)。但我們覺得即使是換一個(gè)新的數(shù)據(jù)結(jié)構(gòu)，也沒有辦法很好做隔離，因?yàn)楫吘惯€是在一臺(tái)機(jī)器上，在同一個(gè)物理資源上。最徹底的隔離是物理隔離。

我們?cè)?TiFlash 用了好幾種技術(shù)來去保證數(shù)據(jù)是更新的。一是增加了 Raft Leaner，二是我們把 TiDB 的 MVCC 也實(shí)現(xiàn)在了 TiFlash 的內(nèi)部。第三在 TiFlash 這邊接觸了更新（的過程），在 TiFlash 內(nèi)部還有一個(gè)小的 Memstore，來處理更新的熱數(shù)據(jù)結(jié)果，最后查詢的時(shí)候，是列存跟內(nèi)存里的行存去 merge 并得到最終的結(jié)果。TiFlash 的核心思想就是通過 Raft 的副本來做物理隔離。

這個(gè)有什么好處呢？這是我們今天給出的答案，但是背后的思考，到底是什么原因呢？為什么我們不能直接去同步一個(gè) binlog 到另外一個(gè) dedicate 的新集群上（比如 TiFlash 集群），而一定要走 Raft log？最核心的原因是，我們認(rèn)為 Raft log 的同步可以水平擴(kuò)展的。因?yàn)?TiDB 內(nèi)部是 Mult-Raft 架構(gòu)，Raft log 是發(fā)生在每一個(gè) TiKV 節(jié)點(diǎn)的同步上。大家想象一下，如果中間是通過 Kafka 溝通兩邊的存儲(chǔ)引擎，那么實(shí)時(shí)的同步會(huì)受制于中間管道的吞吐。比如圖 14 中綠色部分一直在更新，另一邊并發(fā)寫入每秒兩百萬，但是中間的 Kafka 集群可能只能承載 100 萬的寫入，那么就會(huì)導(dǎo)致中間的 log 堆積，而且下游的消費(fèi)也是不可控的。而通過 Raft 同步， Throughput 可以根據(jù)實(shí)際存儲(chǔ)節(jié)點(diǎn)的集群大小，能夠線性增長(zhǎng)。這是一個(gè)特別核心的好處。

說完了存儲(chǔ)層，接下來說一說執(zhí)行器。TiDB 在接下來會(huì)做一個(gè)很重要的工作，就是全面地 leverage ?SIMD 的計(jì)算。我先簡(jiǎn)單科普一下 SIMD 是什么。

如圖 15，在做一些聚合的時(shí)候，有這樣一個(gè)函數(shù)，我要去做一個(gè)求和。正常人寫程序，他就是一個(gè) for 循環(huán)，做累加。但是在一個(gè)數(shù)據(jù)庫里面，如果有一百億條數(shù)據(jù)做聚合，每一次執(zhí)行這條操作的時(shí)候，CPU 的這個(gè)指令是一次一次的執(zhí)行，數(shù)據(jù)量特別大或者掃描的行數(shù)特別多的時(shí)候，就會(huì)很明顯的感受到這個(gè)差別。

現(xiàn)代的 CPU 會(huì)支持一些批量的指令，比如像 _mm_add_epi32，可以一次通過一個(gè)32 位字長(zhǎng)對(duì)齊的命令，批量的操作 4 個(gè)累加。看上去只是省了幾個(gè) CPU 的指令，但如果是在一個(gè)大數(shù)據(jù)量的情況下，基本上能得到 4 倍速度的提升。

順便說一句，有一個(gè)很大的趨勢(shì)是 I/O 已經(jīng)不是瓶頸了，大家一定要記住我這句話。再過幾年，如果想去買一塊機(jī)械磁盤，除了在那種冷備的業(yè)務(wù)場(chǎng)景以外，我相信大家可能都要去定制一塊機(jī)械磁盤了。未來一定 I/O 不會(huì)是瓶頸，那瓶頸會(huì)是什么？CPU。我們?cè)趺慈ビ眯碌挠布ケM可能的把計(jì)算效率提升，這個(gè)才是未來我覺得數(shù)據(jù)庫發(fā)展的重點(diǎn)。比如說我怎么在數(shù)據(jù)庫里 leverage GPU 的計(jì)算能力，因?yàn)槿绻?GPU 用的好，其實(shí)可以很大程度上減少計(jì)算的開銷。所以，如果在單機(jī) I/O 這些都不是問題的話，下一個(gè)最大問題就是怎么做好分布式，這也是為什么我們一開始就選擇了一條看上去更加困難的路：我要去做一個(gè) Share-nothing 的數(shù)據(jù)庫，并不是像 Aurora 底下共享一個(gè)存儲(chǔ)。

在今天大家其實(shí)看不到未來十年數(shù)據(jù)增長(zhǎng)是怎樣的，回想十年前大家能想到現(xiàn)在我們的數(shù)據(jù)量有這么大嗎？不可能的。所以新的架構(gòu)或者新的數(shù)據(jù)庫，一定要去面向我們未知的 Scale 做設(shè)計(jì)。比如大家想象現(xiàn)在有業(yè)務(wù) 100T 的數(shù)據(jù)，目前看可能還挺大的，但是有沒有辦法設(shè)計(jì)一套方案去解決 1P、2P 這樣數(shù)據(jù)量的架構(gòu)？在海量的數(shù)據(jù)量下，怎么把數(shù)據(jù)很靈活的分片是一個(gè)很大的學(xué)問。

為什么分庫分表在對(duì)比 TiDB 的時(shí)候，我們會(huì)覺得分庫分表是上一代的方案。這個(gè)也很好理解，核心的原因是分庫分表的 Router 是靜態(tài)的。如果出現(xiàn)分片不均衡，比如業(yè)務(wù)可能按照 User ID 分表，但是發(fā)現(xiàn)某一地方/某一部分的 User ID 特別多，導(dǎo)致數(shù)據(jù)不均衡了，這時(shí) TiDB 的架構(gòu)有什么優(yōu)勢(shì)呢？就是 TiDB 徹底把分片這個(gè)事情，從數(shù)據(jù)庫里隔離了出來，放到了另外一個(gè)模塊里。分片應(yīng)該是根據(jù)業(yè)務(wù)的負(fù)載、根據(jù)數(shù)據(jù)的實(shí)時(shí)運(yùn)行狀態(tài)，來決定這個(gè)數(shù)據(jù)應(yīng)該放在哪兒。這是傳統(tǒng)的靜態(tài)分片不能相比的，不管傳統(tǒng)的用一致性哈希，還是用最簡(jiǎn)單的對(duì)機(jī)器數(shù)取模的方式去分片（都是不能比的）。

在這個(gè)架構(gòu)下，甚至未來我們還能讓 AI 來幫忙。把分片操作放到 PD 里面，它就像一個(gè) DBA 一樣，甚至預(yù)測(cè) Workload 給出數(shù)據(jù)分布操作。比如課程報(bào)名數(shù)據(jù)庫系統(tǒng)，系統(tǒng)發(fā)現(xiàn)可能明天會(huì)是報(bào)名高峰，就事先把數(shù)據(jù)給切分好，放到更好的機(jī)器上。這在傳統(tǒng)方案下是都需要人肉操作，其實(shí)這些事情都應(yīng)該是自動(dòng)化的。

Dynamic Data placement 好處首先是讓事情變得更 flexible ，對(duì)業(yè)務(wù)能實(shí)時(shí)感知和響應(yīng)。另外還有一點(diǎn)，為什么我們有了 Dynamic Placement 的策略，還要去做 Table Partition（今天上午申礫也提到了）？Table Partition 在背后實(shí)現(xiàn)其實(shí)挺簡(jiǎn)單的。相當(dāng)于業(yè)務(wù)這邊已經(jīng)告訴我們數(shù)據(jù)應(yīng)該怎么分片比較好，我們還可以做更多針對(duì)性的優(yōu)化。這個(gè) Partition 指的是邏輯上的 Partition ，是可能根據(jù)你的業(yè)務(wù)相關(guān)的，比如說我這張表，就是存著 2018 年的數(shù)據(jù)，雖然我在底下還是 TiDB 這邊，通過 PD 去調(diào)度，但是我知道你 Drop 這個(gè) Table 的時(shí)候，一定是 Drop 這些數(shù)據(jù)，所以這樣會(huì)更好，而且更加符合用戶的直覺。

但這樣架構(gòu)仍然有比較大的挑戰(zhàn)。當(dāng)然這個(gè)挑戰(zhàn)在靜態(tài)分片的模型上也都會(huì)有。比如說圍繞著這個(gè)問題，我們一直在去嘗試解決怎么更快的發(fā)現(xiàn)數(shù)據(jù)的熱點(diǎn)，比如說我們的調(diào)度器，如果最好能做到，比如突然來個(gè)秒殺業(yè)務(wù)，我們馬上就發(fā)現(xiàn)了，就趕緊把這塊數(shù)據(jù)挪到好的機(jī)器上，或者把這塊數(shù)據(jù)趕緊添加副本，再或者把它放到內(nèi)存的存儲(chǔ)引擎里。這個(gè)事情應(yīng)該是由數(shù)據(jù)庫本身去做的。所以為什么我們這么期待 AI 技術(shù)能夠幫我們，是因?yàn)殡m然在 TiDB 內(nèi)部，用了很多規(guī)則和方法來去做這個(gè)事情，但我們不是萬能的。

還有大的趨勢(shì)是存儲(chǔ)計(jì)算分離。我覺得現(xiàn)在業(yè)界有一個(gè)特別大的問題，就是把存儲(chǔ)計(jì)算分離給固化成了某一個(gè)架構(gòu)的特定一個(gè)指代，比如說只有長(zhǎng)的像 Aurora 那樣的架構(gòu)才是存儲(chǔ)計(jì)算分離。那么 TiDB 算存儲(chǔ)計(jì)算分離嗎？我覺得其實(shí)算。或者說存儲(chǔ)計(jì)算分離本質(zhì)上帶來的好處是什么？就是我們的存儲(chǔ)依賴的物理資源，跟計(jì)算所依賴的物理資源并不一樣。這點(diǎn)其實(shí)很重要。就用 TiDB 來舉例子，比如計(jì)算可能需要很多 CPU，需要很多內(nèi)存來去做聚合，存儲(chǔ)節(jié)點(diǎn)可能需要很多的磁盤和 I/O，如果全都放在一個(gè)組件里 ，調(diào)度器就會(huì)很難受：我到底要把這個(gè)節(jié)點(diǎn)作為存儲(chǔ)節(jié)點(diǎn)還是計(jì)算節(jié)點(diǎn)？其實(shí)在這塊，可以讓調(diào)度器根據(jù)不同的機(jī)型（來做決定），是計(jì)算型機(jī)型就放計(jì)算節(jié)點(diǎn)，是存儲(chǔ)型機(jī)型就放存儲(chǔ)節(jié)點(diǎn)。

今天由于時(shí)間關(guān)系沒有給大家演示的插件平臺(tái)。未來 TiDB 會(huì)變成一個(gè)更加靈活的框架，像圖 20 中 TiFlash 是一個(gè) local storage，我們其實(shí)也在秘密研發(fā)一個(gè)新的存儲(chǔ)的項(xiàng)目叫 Unitstore，可能明年的 DevCon 就能看到它的 Demo 了。在計(jì)算方面，每一層我們未來都會(huì)去對(duì)外暴露一個(gè)非常抽象的接口，能夠去 leverage 不同的系統(tǒng)的好處。今年我其實(shí)很喜歡的一篇 Paper 是?F1 Query?這篇論文，基本表述了我對(duì)一個(gè)大規(guī)模的分布式系統(tǒng)的期待，架構(gòu)的切分非常漂亮。

說到分布式事務(wù)，我也分享一下我的觀點(diǎn)。目前看上去，ACID 事務(wù)肯定是必要的。我們?nèi)匀贿€沒有太多更好的辦法，除了 Google 在這塊用了原子鐘，Truetime 非常牛，我們也在研究各種新型的時(shí)鐘的技術(shù)，但是要把它推廣到整個(gè)開源社區(qū)也不太可能。當(dāng)然，時(shí)間戳，不管是用硬件還是軟件分配，仍然是我們現(xiàn)在能擁有最好的東西， 因?yàn)槿绻獢[脫中心事務(wù)管理器，時(shí)間戳還是很重要的。所以在這方面的挑戰(zhàn)就會(huì)變成：怎么去減少兩階段提交帶來的網(wǎng)絡(luò)的 round-trips？或者如果有一個(gè)時(shí)鐘的 PD 服務(wù)，怎么能盡可能的少去拿時(shí)間戳？

我們?cè)谶@方面的理論上有一些突破，我們把 Percolator 模型做了一些優(yōu)化，能夠在數(shù)學(xué)上證明，可以少拿一次時(shí)鐘。雖然我們目前還沒有在 TiDB 里去實(shí)現(xiàn)，但是我們已經(jīng)把數(shù)學(xué)證明的過程已經(jīng)開源出來了，我們用了 TLA+ 這個(gè)數(shù)學(xué)工具去做了證明。此外在 PD 方面，我們也在思考是不是所有的事務(wù)都必須跑到 PD 去拿時(shí)間戳？其實(shí)也不一定，我們?cè)谶@上面也已有一些想法和探索，但是現(xiàn)在還沒有成型，這個(gè)不劇透了。另外我覺得還有一個(gè)非常重要的東西，就是 Follower Read。很多場(chǎng)景讀多寫少，讀的業(yè)務(wù)壓力很多時(shí)候是要比寫大很多的，F(xiàn)ollower Read 能夠幫我們線性擴(kuò)展讀的性能，而且在我們的模型上，因?yàn)闆]有時(shí)間戳 ，所以能夠在一些特定情況下保證不會(huì)去犧牲一致性。

另外一點(diǎn)就是 Cloud-Native。剛剛中午有一個(gè)社區(qū)小伙伴問我，你們?yōu)槭裁床话讯嘧鈶糇鲈?TiDB 的系統(tǒng)內(nèi)部？我想說「數(shù)據(jù)庫就是數(shù)據(jù)庫」，它并不是一個(gè)操作系統(tǒng)，不是一個(gè)容器管理平臺(tái)。我們更喜歡模塊和結(jié)構(gòu)化更清晰的一個(gè)做事方式。而且 Kubernetes 在這塊已經(jīng)做的足夠好了 ，我相信未來 K8s 會(huì)變成集群的新操作系統(tǒng)，會(huì)變成一個(gè) Linux。比如說如果你單機(jī)時(shí)代做一個(gè)數(shù)據(jù)庫，你會(huì)在你的數(shù)據(jù)庫里面內(nèi)置一個(gè)操作系統(tǒng)嗎？肯定不會(huì)。所以這個(gè)模塊抽象的邊界，在這塊我還是比較相信 K8s 的。《Large-scale cluster management at Google with Borg》這篇論文里面提到了一句話，BigTable 其實(shí)也跑在 Borg 上。

當(dāng)然最后，大家聽完這一堆東西以后，回頭看我們社區(qū)小伙伴們的愿望列表（圖 24），就會(huì)發(fā)現(xiàn)對(duì)一下 TiDB 好像還都能對(duì)得上 :D

謝謝大家。

1 月 19 日?TiDB DevCon 2019?在北京圓滿落幕，超過 750 位熱情的社區(qū)伙伴參加了此次大會(huì)。會(huì)上我們首次全面展示了全新存儲(chǔ)引擎 Titan、新生態(tài)工具 TiFlash 以及 TiDB 在云上的進(jìn)展，同時(shí)宣布 TiDB-Lightning Toolset & TiDB-DM 兩大生態(tài)工具開源，并分享了? TiDB 3.0 的特性與未來規(guī)劃，描述了我們眼中未來數(shù)據(jù)庫的模樣。此外，更有?11 位來自一線的?TiDB 用戶為大家分享了實(shí)踐經(jīng)驗(yàn)與踩過的「坑」。同時(shí)，我們也為新晉 TiDB Committer 授予了證書，并為 2018 年最佳社區(qū)貢獻(xiàn)個(gè)人、最佳社區(qū)貢獻(xiàn)團(tuán)隊(duì)頒發(fā)了榮譽(yù)獎(jiǎng)杯。