摘要：我們通常會(huì)說(shuō)我們要做一個(gè)分布式數(shù)據(jù)庫(kù)，自動(dòng)彈性伸縮，能解決分庫(kù)分表的問(wèn)題，你會(huì)用嗎用戶說(shuō)那肯定啊，現(xiàn)在的分庫(kù)分表太痛苦了。在軟件開(kāi)發(fā)領(lǐng)域有一條非常經(jīng)典的哲學(xué)。作為一個(gè)分布式數(shù)據(jù)庫(kù)，每一層的穩(wěn)定性都非常重要。

本文根據(jù)我司 CEO 劉奇在第 100 期 Infra Meetup 上的演講整理，預(yù)計(jì)閱讀時(shí)間為 30 分鐘。

大家可能知道我是 PingCAP CEO，但是不知道的是，我也是 PingCAP 的產(chǎn)品經(jīng)理，應(yīng)該也是最大的產(chǎn)品經(jīng)理，是對(duì)于產(chǎn)品重大特性具有一票否決權(quán)的人。中國(guó)有一類產(chǎn)品經(jīng)理是這樣的，別人有的功能我們統(tǒng)統(tǒng)都要有，別人沒(méi)有的功能，我們也統(tǒng)統(tǒng)都要有，所以大家看到傳統(tǒng)的國(guó)內(nèi)好多產(chǎn)品就是一個(gè)超級(jí)巨無(wú)霸，功能巨多、巨難用。所以我在 PingCAP 的一個(gè)重要職責(zé)是排除掉“看起來(lái)應(yīng)該需要但實(shí)際上不需要”的那些功能，保證我們的產(chǎn)品足夠的專注、足夠聚焦，同時(shí)又具有足夠的彈性。

本次分享題目是《TiDB 的架構(gòu)演進(jìn)哲學(xué)》，既然講哲學(xué)那肯定有故事和教訓(xùn)，否則哲學(xué)從哪兒來(lái)呢？但從另外的角度來(lái)說(shuō)，一般大家來(lái)講哲學(xué)就先得有信念。有一個(gè)內(nèi)容特別扯的美劇叫做《美國(guó)眾神》，里面核心的一條思路是“你相信什么你就是什么”。其實(shí)人類這么多年來(lái)，基本上也是朝這條線路在走的，人類對(duì)于未知的東西很難做一個(gè)很精確的推導(dǎo)，這時(shí)信念就變得非常重要了。

實(shí)際上，我們開(kāi)始做 TiDB 這個(gè)產(chǎn)品的時(shí)候，第一個(gè)信念就是相信云是未來(lái)。當(dāng)年 K8s 還沒(méi)火，我們就堅(jiān)定的擁抱了 K8s。第二是不依賴特定硬件、特定的云廠商，也就是說(shuō) TiDB 的設(shè)計(jì)方向是希望可以 Run 在所有環(huán)境上面，包括公有云私有云等等。第三是能支持多種硬件，大家都知道我們支持 X86、AMD64、ARM 等等，可能大家不清楚的是 MIPS，MIPS 典型代表是龍芯，除此之外，TiDB 未來(lái)還可以在 GPU 上跑（TiFlash 的后續(xù)工作會(huì)支持 GPU）。

有一句話大概是“眼睛里面寫(xiě)滿了故事，臉上沒(méi)有一點(diǎn)滄?！?，其實(shí)現(xiàn)實(shí)是殘酷的，歲月一定會(huì)給你滄桑的。我們?cè)缙诘臅r(shí)候，也有相對(duì)比較難的時(shí)候，這時(shí)候就有一些故事關(guān)于我們?cè)趺慈ソ?jīng)歷、怎么渡過(guò)的。 ?

首先大家做產(chǎn)品之前肯定先做用戶調(diào)研，這是通用的流程，我們當(dāng)初也做過(guò)這個(gè)事，跟用戶聊。我們通常會(huì)說(shuō)：“我們要做一個(gè)分布式數(shù)據(jù)庫(kù)，自動(dòng)彈性伸縮，能解決分庫(kù)分表的問(wèn)題，你會(huì)用嗎？”用戶說(shuō)“那肯定啊，現(xiàn)在的分庫(kù)分表太痛苦了。”這是最初我們獲取需求最普通的方式，也是我們最容易掉入陷阱的方式，就好像“我有一百萬(wàn)，你要不要？肯定要?！薄拔矣幸黄克攘酥缶徒】禑o(wú)比，延年益壽你要不要？肯定要。”很容易就得到類似的結(jié)論。

所以這個(gè)一句話結(jié)論的代價(jià)是我們進(jìn)行了長(zhǎng)達(dá)兩年的開(kāi)發(fā)。在這兩年的時(shí)間里，我們確定了很多的技術(shù)方向，比如最初 TiDB 就決定是分層的。很顯然一個(gè)復(fù)雜的系統(tǒng)如果沒(méi)有分層，基本上沒(méi)有辦法很好的控制規(guī)模和復(fù)雜度。TiDB 分兩層，一層是 SQL 層，一層是 key-value 層，那么到底先從哪一個(gè)層開(kāi)始寫(xiě)呢？其實(shí)從哪層開(kāi)始都可以，但是總要有一個(gè)先后，如何選擇？

這里就涉及到 TiDB 的第一條哲學(xué)。我們做一個(gè)產(chǎn)品的時(shí)候會(huì)不斷面臨選擇，那每次選擇的時(shí)候核心指導(dǎo)思想是什么？核心思想是能一直指導(dǎo)我們持續(xù)往前去迭代，所以我們第一條哲學(xué)就是：永遠(yuǎn)站在離用戶更近的地方去考慮問(wèn)題。

為什么我們會(huì)定義這樣一條哲學(xué)？因?yàn)殡x用戶越近越能更快的得到用戶的反饋，更快的驗(yàn)證你的想法是不是可行的。顯然 SQL 層離用戶更近，所以我們選擇從 SQL 層寫(xiě)起。其實(shí)一直到現(xiàn)在，絕大多數(shù)用戶用 TiDB 的時(shí)候根本感受不到 KV 層的存在，用戶寫(xiě)的都是 SQL，至于底層存儲(chǔ)引擎換成了別的，或者底層的 RocksDB 做了很多優(yōu)化和改進(jìn)，這些變化對(duì)于用戶關(guān)注的接口來(lái)說(shuō)是不可見(jiàn)的。

選擇從 SQL 層開(kāi)始寫(xiě)之后，接下來(lái)面臨的問(wèn)題就是怎么做測(cè)試，怎么去更好的做驗(yàn)證，怎么讓整個(gè)架構(gòu)，先能夠完整跑起來(lái)。

在軟件開(kāi)發(fā)領(lǐng)域有一條非常經(jīng)典的哲學(xué)：「Make it work, make it right, make it fast」。我想大家每一個(gè)學(xué)軟件開(kāi)發(fā)的人，或者每一個(gè)學(xué)計(jì)算機(jī)的人可能都聽(tīng)過(guò)這樣一句話。所以當(dāng)時(shí)我們就做另外一個(gè)決定，先在已有的 KV 上面構(gòu)建出一個(gè)原形，用最短的時(shí)間讓整個(gè)系統(tǒng)能夠先能 work。

我們?cè)?2015 年的 9 月份開(kāi)源了第一個(gè)版本，當(dāng)時(shí)是沒(méi)有存儲(chǔ)層的，需要接在 HBase 上。當(dāng)這個(gè)系統(tǒng)能跑起來(lái)之后，我們的第一想法是趕緊找到當(dāng)初調(diào)研時(shí)說(shuō)要用的那些用戶，看看他們是什么想法，盡快的去驗(yàn)證我們的想法是不是可行的。因?yàn)楹芏嗳俗霎a(chǎn)品思維屬于自嗨型，“我做的東西最厲害，只要一推出去肯定一群人蜂擁而至?！北в羞@種想法的人太多了，實(shí)際上，只有盡快去驗(yàn)證才是唯一的解決之道，避免產(chǎn)品走入誤區(qū)。

然而當(dāng)我跟用戶講，你需要先裝一個(gè) Hadoop，可能還要裝一組 Zookeeper，但用戶說(shuō)：“我只想要一個(gè)更強(qiáng)大的 MySQL，但是讓我裝這一堆東西，你是解決問(wèn)題還是引入問(wèn)題？”

這個(gè)問(wèn)題有什么解決辦法呢？一個(gè)辦法是你去解決用戶，可以通過(guò)銷售或者通過(guò)某些關(guān)系跟用戶聊，顯然這是一個(gè)不靠譜的思路。作為一個(gè)產(chǎn)品型的公司，我們很快就否了這個(gè)想法。用戶的本質(zhì)要求是：你不要給我裝一堆的東西，要真正解決我的問(wèn)題。所以我們馬上開(kāi)始啟動(dòng)分布式 KV 的開(kāi)發(fā)工作，徹底解決掉這個(gè)問(wèn)題，滿足用戶的要求。

開(kāi)始開(kāi)發(fā) KV 層時(shí)候又會(huì)面臨很多技術(shù)選擇，我們有很多考量（如圖 3）。

第一點(diǎn)，我們認(rèn)為作為數(shù)據(jù)庫(kù)最重要的是正確性。 假設(shè)這個(gè)數(shù)據(jù)庫(kù)要用在金融行業(yè)，用在銀行、保險(xiǎn)、證券，和其他一些非常關(guān)鍵的場(chǎng)合的時(shí)候，正確性就是無(wú)比重要的東西。沒(méi)有人會(huì)用一個(gè)不正確的數(shù)據(jù)庫(kù)。

第二點(diǎn)是實(shí)現(xiàn)簡(jiǎn)潔、易用。 用戶對(duì)于一個(gè)不簡(jiǎn)潔、不易用的東西是無(wú)法接受的，所以我們當(dāng)時(shí)的一個(gè)想法是一定要做得比 HBase 更加易用，代碼量也要比 HBase 小，所以時(shí)至今天 TiDB 代碼量仍然是比 HBase 小得多，大約還不到 HBase 的十分之一。

第三點(diǎn)考慮是擴(kuò)展性。?TiDB 不僅在整體上是分層的，在存儲(chǔ)層 TiKV 內(nèi)部也是分層的，所以有非常好的擴(kuò)展性，也支持 Raw KV API、Transaction API，這個(gè)設(shè)計(jì)后來(lái)也收獲了很多用戶的支持，比如一點(diǎn)資訊的同學(xué)就是用的 Raw KV API。

第四點(diǎn)就是要求高性能低延遲。 大家對(duì)于數(shù)據(jù)庫(kù)的性能和延遲的追求是沒(méi)有止境的，但是我們當(dāng)時(shí)并沒(méi)有把太多精力花在高性能低延遲上。剛才說(shuō)到我們有一條哲學(xué)是「Make it work, make it right, make it fast」，大家可以看到這句話里面 「Fast」是放最后的，這一點(diǎn)也是 TiDB 和其他產(chǎn)品有非常大的差異的地方。作為一個(gè)技術(shù)人員，通常大家看一個(gè)產(chǎn)品好不好，就會(huì)想：“來(lái)，不服跑個(gè)分，產(chǎn)品架構(gòu)、易用性、技術(shù)文檔、Community 這些指標(biāo)都不看，先跑個(gè)分讓大家看看行不行”。這個(gè)思路真正往市場(chǎng)上去推時(shí)是不對(duì)的。很多事情的選擇是一個(gè)綜合的過(guò)程。你可以讓你的汽車跑的巨快無(wú)比，上面東西全拆了就留一個(gè)發(fā)動(dòng)機(jī)和四個(gè)輪子，那肯定也是跑得巨快，重量輕，而且還是敞篷車，但沒(méi)有一個(gè)人會(huì)在路上用的。同樣的，選擇 Rust 也是綜合考量的結(jié)果。我們看中了 Rust 這個(gè)非常具有潛力的語(yǔ)言。當(dāng)時(shí) Rust 沒(méi)有發(fā)布 1.0，還不是一個(gè) stable 版本，但我們相信它會(huì)有 1.0。大概過(guò)了幾個(gè)月，Rust 就發(fā)布了 1.0 版本，證明我們的選擇還是非常正確的。

最后一點(diǎn)就是穩(wěn)定性。 作為一個(gè)分布式數(shù)據(jù)庫(kù)，每一層的穩(wěn)定性都非常重要。最底下的一個(gè)存儲(chǔ)引擎，我們選擇了非常穩(wěn)定的 RocksDB。不過(guò)后來(lái)我們也查到幾個(gè) RocksDB 掉數(shù)據(jù)的 Bug。這也是做數(shù)據(jù)庫(kù)或者說(shuō)做基礎(chǔ)產(chǎn)品的殘酷性，我們?cè)谧霎a(chǎn)品的過(guò)程中找到了 Rust 編譯器的 Bug，XFS 掉數(shù)據(jù)的 Bug，RocksDB 掉數(shù)據(jù)的 Bug，好像幾大基礎(chǔ)組件的 Bug 都聚在這里開(kāi)會(huì)。

接著我們辛辛苦苦干了三個(gè)月，然后就開(kāi)源了 TiKV，所以這時(shí)候看起來(lái)沒(méi)有那么多的組件了。我們也不忘初心，又去找了我們當(dāng)初那個(gè)用戶，說(shuō)我們做了一些改進(jìn)，你要不要試一試。

但是用戶這時(shí)候給了一個(gè)讓我們非常傷心非常難受的回答：沒(méi)有，我們不敢上線，雖然你們的產(chǎn)品聽(tīng)起來(lái)挺好的，但是數(shù)據(jù)庫(kù)后面有很大的責(zé)任，心理上的擔(dān)心確實(shí)是過(guò)不去。于是我們回去開(kāi)始加班加點(diǎn)寫(xiě) TiDB Binlog，讓用戶可以把 binlog 同步給 MySQL。畢竟用戶需要一個(gè) Backup：萬(wàn)一 TiDB 掛了怎么辦，我需要切回 MySQL，這樣才放心，因?yàn)閿?shù)據(jù)是核心資產(chǎn)。

所以最終我們第一個(gè)用戶上線的時(shí)候，整個(gè) TiDB 的架構(gòu)是這樣的（如圖 5）。用戶通過(guò) Client 連上 TiDB，然后 TiDB 后面就通過(guò) Binlog 同步到 MySQL。后來(lái)過(guò)了一段時(shí)間，用戶就把后面的 MySQL 撤了。我們當(dāng)時(shí)挺好奇為什么撤了，用戶說(shuō)，第一個(gè)原因是后面 MySQL 撐不起一個(gè)集群給它回吐 Binlog，第二就是用了一段時(shí)間覺(jué)得 TiDB 挺穩(wěn)定的，然后就不需要 Binlog 備份了。

其實(shí)第一個(gè)用戶上線的時(shí)候，數(shù)據(jù)量并不算大，大概 800G 的數(shù)據(jù)，使用場(chǎng)景是 OLTP 為主，有少量的復(fù)雜分析和運(yùn)算，但這少量的復(fù)雜分析運(yùn)算是當(dāng)時(shí)他們選擇 TiDB 最重要的原因。因?yàn)楫?dāng)時(shí)他們需要每隔幾分鐘算一個(gè)圖出來(lái)，如果是在 MySQL 上面跑，大約需要十幾分鐘，但他們需要每隔幾分鐘打一個(gè)點(diǎn)，后來(lái)突然發(fā)現(xiàn)第二天才能把前一天的點(diǎn)都打出來(lái)，這對(duì)于一個(gè)實(shí)時(shí)的系統(tǒng)來(lái)說(shuō)就很不現(xiàn)實(shí)了。雖然這個(gè)應(yīng)用實(shí)踐只有少部分運(yùn)算，但也是偏 OLAP，我記得 TiDB 也不算特別快，大概是十幾秒鐘，因?yàn)橹С至艘粋€(gè)并行的 Hash Join。

不管怎樣，這個(gè)時(shí)候終于有第一個(gè)用戶能證明我們做到了「Make it work」。

接下來(lái)就是「Make it right」。大家可能想象不到做一個(gè)保證正確性的數(shù)據(jù)庫(kù)這件事情有多么難，這是一個(gè)巨大的挑戰(zhàn)，也有巨大的工作量，是從理論到實(shí)踐的距離。

大家可能會(huì)想寫(xiě)程序跟理論有什么關(guān)系？其實(shí)在分布式數(shù)據(jù)庫(kù)領(lǐng)域是有一套方法論的。這個(gè)方法論要求先實(shí)現(xiàn)正確性，而實(shí)現(xiàn)正確的前提是有一個(gè)形式化的證明。為了保證整個(gè)系統(tǒng)的理論正確，我們把所有的核心算法都用 TLA+ 寫(xiě)了一遍證明，并且把這個(gè)證明開(kāi)源出去了，如果大家感興趣可以翻看一下（https://github.com/pingcap/tla-plus）。以前寫(xiě)程序的時(shí)候，大家很少想到先證明一下算法是對(duì)的，然后再把算法變成一個(gè)程序，其實(shí)今天還有很多數(shù)據(jù)庫(kù)廠商沒(méi)有做這件事。

在理論上保證正確性之后，下一步是在現(xiàn)實(shí)中測(cè)試驗(yàn)證。這時(shí)只有一個(gè)辦法就是用非常龐大的測(cè)試用例做測(cè)試。大家通常自己做測(cè)試的時(shí)候，測(cè)試用例應(yīng)該很少能達(dá)到十萬(wàn)級(jí)的規(guī)模，而我們現(xiàn)在測(cè)試用例的規(guī)模是以千萬(wàn)為單位的。當(dāng)然如果以千萬(wàn)為單位的測(cè)試用例靠純手寫(xiě)不太現(xiàn)實(shí)，好在我們兼容了 MySQL 協(xié)議，可以直接從 MySQL 的測(cè)試用例里收集一些。這樣就能很快驗(yàn)證整個(gè)系統(tǒng)是否具備正確性。

這些測(cè)試用例包括應(yīng)用、框架、管理工具等等。比如有很多應(yīng)用程序是依賴 MySQL，那直接拿這個(gè)應(yīng)用程序在 TiDB 上跑一下，就知道 TiDB 跟 MySQL 的兼容沒(méi)問(wèn)題，如 Wordpress、無(wú)數(shù)的 ORM 等等。還有一些 MySQL 的管理工具可以拿來(lái)測(cè)試，比如 Navicat、PHP admin 等。另外我們把公司內(nèi)部在用的 Confluence、Jira 后面接的 MySQL 都換成了 TiDB，雖然說(shuō)規(guī)模不大，但是我們是希望在應(yīng)用這塊有足夠的測(cè)試，同時(shí)自己「Eat dog food」。

這些工作看起來(lái)已經(jīng)挺多的了，但實(shí)際上還有一塊工作比較消耗精力，叫 7*24 的錯(cuò)誤注入測(cè)試。最早我們也不知道這個(gè)測(cè)試這么花錢(qián)，我們現(xiàn)在測(cè)試的集群已經(jīng)是幾百臺(tái)服務(wù)器了。如果創(chuàng)業(yè)的時(shí)候就知道需要這么多服務(wù)器測(cè)試，我們可能就不創(chuàng)業(yè)了，好像天使輪的融資都不夠買(mǎi)服務(wù)器的。不過(guò)好在這個(gè)事是一步一步買(mǎi)起來(lái)，剛開(kāi)始我們也沒(méi)有買(mǎi)這么多測(cè)試服務(wù)器，后來(lái)隨著規(guī)模的擴(kuò)大，不斷的在增加這塊的投入。

大家可能到這兒的時(shí)候還是沒(méi)有一個(gè)直觀的感受，說(shuō)這么多測(cè)試用例，到底是一個(gè)什么樣的感受。我們可以對(duì)比看一下行業(yè)巨頭 Oracle 是怎么干的。

這是一篇在 HackNews上面的討論，討論的問(wèn)題是：你覺(jué)得這個(gè)最壞的、規(guī)模最大的代碼是什么樣子的？下面就有一個(gè) Oracle 的前員工就介紹了 Oracle Database 12.2 這個(gè)版本的情況。他說(shuō)這個(gè)整體的源代碼接近 2500 萬(wàn)行 C 代碼，可能大家維護(hù) 25 萬(wàn)行 C 代碼的時(shí)候就會(huì)痛不欲生了，可以想想維護(hù)這么多代碼的是一種什么樣的感受。到現(xiàn)在為止，TiDB 的代碼應(yīng)該還不到 25 萬(wàn)行。當(dāng)然 TiDB 的功能遠(yuǎn)遠(yuǎn)沒(méi)有 Oracle 那么多，Oracle 的功能其實(shí)是很多的，歷史積累一直往上加，加的很兇。

這位 Oracle 前員工介紹了自己在 Oracle 的開(kāi)發(fā)工作的流程，如下圖：

比如用戶報(bào)了一個(gè) Bug，然后他開(kāi)始 fix。第一件事是花兩周左右的時(shí)間去理解 20 個(gè)不同的 flag，看看有沒(méi)有可能因?yàn)閮?nèi)部亂七八糟的原因來(lái)造成這個(gè) Bug。大家可能不知道 MySQL 有多少變量，我剛做 TiDB 的時(shí)候也不知道，當(dāng)時(shí)我覺(jué)得自己是懂?dāng)?shù)據(jù)庫(kù)的，后來(lái)去看了一下 MySQL 的 flag 的變量數(shù)就驚呆了，但看到 Oracle 的 flag 變量數(shù)，那不是驚呆了，是絕望了。大家可能知道開(kāi)啟 1 個(gè) flag 的時(shí)候會(huì)對(duì)什么東西有影響，但是要去理解 20 個(gè) flag 開(kāi)啟時(shí)和另外幾個(gè) flag 組合的時(shí)候都有什么影響，可能會(huì)崩潰。所以其實(shí)精通 Oracle 這件事情，實(shí)際上可能比精通 C++ 這件事情更困難的。一個(gè) Oracle 開(kāi)發(fā)者在內(nèi)部處理這件事情都這么復(fù)雜，更何況是外面的用戶。但 Oracle 確實(shí)是功能很強(qiáng)大。

說(shuō)回這位前 Oracle 員工的描述，他接著添加了更多的 flag 處理一個(gè)新的用戶場(chǎng)景的問(wèn)題，然后加強(qiáng)代碼，最后改完以后會(huì)提交一個(gè)測(cè)試。先在 100 到 200 臺(tái)機(jī)器上面把這個(gè) Oracle 給 build 出來(lái)，然后再對(duì)這個(gè) Oracle 去做新的測(cè)試。他應(yīng)該對(duì) Oracle 的測(cè)試用例的實(shí)際數(shù)量了解不深刻，我猜他可能不知道 Oracle 有多少個(gè)測(cè)試，所以寫(xiě)的是 “millions of tests”，這顯然太低估了 Oracle 的測(cè)試數(shù)量。通常情況下，只會(huì)看到掛了的測(cè)試，看不到全部的測(cè)試數(shù)量。

下面的步驟更有意思了：Go home，因?yàn)檎麄€(gè)測(cè)試需要 20-30 個(gè)小時(shí)，跑完之后測(cè)試系統(tǒng)反饋了一個(gè)報(bào)告：掛了 200 多個(gè) test，更茫然的是這 200 tests 他以前都沒(méi)見(jiàn)過(guò)，這也是 Oracle 非常強(qiáng)大的一個(gè)地方，如果一個(gè)開(kāi)發(fā)者的代碼提交過(guò)去掛掉一兩百個(gè)測(cè)試，是很正常的事情，因?yàn)?Oracle 的測(cè)試能 Cover 東西非常多，是這么多年來(lái)非常強(qiáng)大的積累，不停的堆功能的同時(shí)就不停的堆測(cè)試，當(dāng)然也不停的堆 flag。所以從另一個(gè)角度來(lái)看，限制一個(gè)系統(tǒng)的功能數(shù)量，對(duì)于維護(hù)來(lái)說(shuō)是非常重要的。

總之，看完這個(gè)回復(fù)之后，我對(duì)行業(yè)前輩們充滿了敬畏之情。

隨著 TiDB 有用戶開(kāi)始上線，用戶的數(shù)量和規(guī)模越來(lái)越大，這時(shí)候就出現(xiàn)了一個(gè)很有意思的事情，一部分用戶把 TiDB 當(dāng)成了可以支持事務(wù)、擁有良好實(shí)時(shí)性的數(shù)據(jù)倉(cāng)庫(kù)在用，和我們說(shuō)：我們把公司 Hadoop 換了，數(shù)據(jù)量十幾 T。

我們就一下開(kāi)始陷入了深深的思考，因?yàn)?TiDB 本來(lái)設(shè)計(jì)的目的不是這個(gè)方向，我們想做一個(gè)分布式 OLTP 數(shù)據(jù)庫(kù)，并沒(méi)有想說(shuō)我們要做一個(gè) Data Warehouse。但是用戶的理由讓我們覺(jué)得也很有道理，無(wú)法反駁——TiDB 兼容 MySQL，會(huì) MySQL 的人很多，更好招人，最重要的是 Hadoop 跑得還不夠快。

雖然我們自己也很吃驚，但這體現(xiàn)了 TiDB 另一方面的價(jià)值，所以我們繼續(xù)問(wèn)用戶還有什么痛點(diǎn)。用戶表示還有一部分查詢不夠快，數(shù)據(jù)沒(méi)辦法做到 shuffle，而且以前用 Spark，TiDB 好像沒(méi)有 Spark 的支持。

我們想了想，TiDB 直接連 Spark 也是可以的，但這樣 Spark 對(duì)底下沒(méi)有感知，事務(wù)跑得巨慢，就跟 Spark 接 MySQL 沒(méi)什么差別。我們研究了一下，做出了一個(gè)新的東西——TiSpark。TiSpark 就開(kāi)始能夠同時(shí)在 TiDB 上去跑 OLAP 和 OLTP。

就在我們準(zhǔn)備改進(jìn) TiDB 的數(shù)據(jù)分析能力的時(shí)候，突然又有一大批 TP 用戶上線了，給我們報(bào)了一堆問(wèn)題，比如執(zhí)行計(jì)劃不準(zhǔn)確，選不到最優(yōu)執(zhí)行計(jì)劃，數(shù)據(jù)熱點(diǎn)分布不均勻，Raft store 單線程寫(xiě)入瓶頸，報(bào)表跑的慢等等……于是我們制定了 1.0 到 2.X 的計(jì)劃，先把用戶提的這些問(wèn)題一一解決。

這里有另外一條哲學(xué)：將用戶遇到的問(wèn)題放在第一優(yōu)先級(jí)。我們從產(chǎn)品最初設(shè)計(jì)和之后 Roadmap 計(jì)劃永遠(yuǎn)是按照這個(gè)原則去做的。

首先，執(zhí)行計(jì)劃不準(zhǔn)確的問(wèn)題。 最簡(jiǎn)單有效的解決辦法是加一個(gè) Index Hint，就像是“你告訴我怎么執(zhí)行，我就怎么執(zhí)行，我自己不會(huì)自作聰明的選擇”。但這不是長(zhǎng)久之計(jì)，因?yàn)橛脩艨赡苁窃谝粋€(gè)界面上選擇各種條件、參數(shù)等等，最后拼成一個(gè) SQL，他們自己沒(méi)辦法在里面加 Index Hint。我們不能決定用戶的使用習(xí)慣，所以從這時(shí)開(kāi)始，我們決定從 RBO（Rule Based Optimizer）演進(jìn)到 CBO（Cost Based Optimizer），這條路也走了非常久，而且還在持續(xù)進(jìn)行。

第二個(gè)是熱點(diǎn)數(shù)據(jù)處理問(wèn)題。 我們推出了一個(gè)熱點(diǎn)調(diào)度器，這個(gè)可能大家在分布式數(shù)據(jù)庫(kù)領(lǐng)域第一次聽(tīng)說(shuō)，數(shù)據(jù)庫(kù)領(lǐng)域應(yīng)該是 PingCAP 首創(chuàng)。 熱點(diǎn)調(diào)度器會(huì)統(tǒng)計(jì)、監(jiān)控整個(gè)系統(tǒng)熱點(diǎn)情況，再把這些熱點(diǎn)做一個(gè)快速遷移和平衡，比如整個(gè)系統(tǒng)有 10 個(gè)熱點(diǎn)，某一個(gè)機(jī)器上有 6 個(gè)熱點(diǎn)，這臺(tái)機(jī)器就會(huì)很卡，這時(shí)熱點(diǎn)調(diào)度器會(huì)開(kāi)始將熱點(diǎn)打散，快速分散到集群的其他機(jī)器上去，從而讓整個(gè)集群的機(jī)器都處于比較正常的負(fù)載狀態(tài)。

第三個(gè)就是解決 Raft store 單線程瓶頸的問(wèn)題。為了改變 Raft store 單線程，我們大概花了一年多的時(shí)間，目前已經(jīng)在 TiDB 3.0 里實(shí)現(xiàn)了。我們將 Raft store 線程更多耗時(shí)的計(jì)算變成異步操作，offload 到其它線程。不知道有沒(méi)有人會(huì)好奇為什么這個(gè)改進(jìn)會(huì)花這么長(zhǎng)時(shí)間？我們一直認(rèn)為數(shù)據(jù)庫(kù)的穩(wěn)定性第一位的。分布式系統(tǒng)里面一致性協(xié)議本身也復(fù)雜，雖然說(shuō) Raft 是比 Paxos 要簡(jiǎn)單，但它實(shí)際做起來(lái)也很復(fù)雜，要在一個(gè)復(fù)雜系統(tǒng)里支持多線程，并且還要做優(yōu)化，盡可能讓這個(gè) I/O 能 group 到一起，其實(shí)非常耗精力。

第四個(gè)就是解決報(bào)表跑得慢的問(wèn)題，這個(gè)骨頭特別硬，我們也是啃到今天還在繼續(xù)。首先要大幅提升 TiDB 在分析場(chǎng)景下的能力。大家都可以看到我們?cè)诎l(fā)布每一個(gè)版本的時(shí)候，都會(huì)給出與上一個(gè)版本的 TPC-H 性能對(duì)比（TPC-H 是一個(gè)有非常多的復(fù)雜查詢、大量運(yùn)算的場(chǎng)景）。其次就是高度并行化，充分利用多核，并提供參數(shù)控制，這個(gè)特性可能很多用戶不知道，我們可以配一下參數(shù)，就讓 TiDB 有多個(gè)并發(fā)在底層做 Scan（https://github.com/pingcap/docs-cn/blob/master/v2.1/sql/tidb-specific.md）。

解決完這些問(wèn)題，我們終于覺(jué)得可以喘口氣了，但喘氣的時(shí)間就不到一個(gè)星期，很快又有很多用戶的反饋開(kāi)始把我們淹沒(méi)了。因?yàn)殡S著用戶規(guī)模的擴(kuò)大，用戶反饋問(wèn)題的速度也變得越來(lái)越快，我們處理的速度不一定跟的上用戶的增速。

這時(shí)候我們也聽(tīng)到了用戶的一些「新呼聲」。

有用戶說(shuō)他們?cè)谂軓?fù)雜查詢時(shí) OLTP 的查詢延遲變高了，跑一個(gè)報(bào)表的時(shí)候發(fā)現(xiàn) ?OLTP 開(kāi)始卡了。這個(gè)問(wèn)題的原因是在跑復(fù)雜查詢的時(shí)候，SQL 資源被搶占。我們又想有沒(méi)有可能將 OLAP 和 OLTP 的 Workload 分開(kāi)？于是我們搞了第一個(gè)實(shí)驗(yàn)版本，在 TiKV 里把請(qǐng)求分優(yōu)先級(jí)，放到不同隊(duì)列里面去，復(fù)雜 Query 放在第一優(yōu)先級(jí)的隊(duì)列， OLTP 放在高優(yōu)先級(jí)。然后我們發(fā)現(xiàn)自己是對(duì)報(bào)表理解不夠深刻，這個(gè)方案只能解決一部分用戶的問(wèn)題，因?yàn)橛械膱?bào)表跑起來(lái)需要幾個(gè)小時(shí)，導(dǎo)致隊(duì)列永遠(yuǎn)是滿的，永遠(yuǎn)搶占著系統(tǒng)的資源。還有一部分用戶的報(bào)表沒(méi)有那么復(fù)雜，只是希望報(bào)表跑得更快、更加實(shí)時(shí)，比如一個(gè)做餐飲 SaaS 的用戶，每天晚上需要看一下餐館營(yíng)收情況，統(tǒng)計(jì)一家餐館時(shí)速度還行，如果統(tǒng)計(jì)所有餐館的情況，那就另說(shuō)了。

另外，報(bào)表有一些必需品，比如 View 和 Window Function，沒(méi)有這些的話 SQL 寫(xiě)起來(lái)很痛苦，缺乏靈活度。

與此同時(shí)，用戶關(guān)于兼容性和新特性的要求也開(kāi)始變多，比如希望支持 MySQL 類似的 table partition，還有銀行用戶習(xí)慣用悲觀鎖，而 TiDB 是樂(lè)觀鎖，遷移過(guò)來(lái)會(huì)造成額外的改造成本（TiDB 3.0 已經(jīng)支持了悲觀鎖）。

還有用戶有 400T 的數(shù)據(jù)，沒(méi)有一個(gè)快速導(dǎo)入的工具非常耗時(shí)（當(dāng)然現(xiàn)在我們有快速導(dǎo)入工具TiDB Lightning），這個(gè)問(wèn)題有一部分原因在于用戶的硬件條件限制，比如說(shuō)千兆網(wǎng)導(dǎo)入數(shù)據(jù)。

還有些用戶的數(shù)據(jù)規(guī)模越來(lái)越大，到 100T 以上就開(kāi)始發(fā)現(xiàn)十分鐘已經(jīng)跑不完 GC 了（TiDB 的 GC 是每十分鐘一次），一個(gè)月下來(lái) GC 已經(jīng)整體落后了非常多。

我們當(dāng)時(shí)非常頭痛，收到了一堆意見(jiàn)和需求，壓力特別大，然后趕緊匯總了一下，如圖 10 所示。

面對(duì)這么多的需求，我們考慮了兩個(gè)點(diǎn)：

哪些是共性需求？

什么是徹底解決之道？

把共性的需求都列在一塊，提供一個(gè)在產(chǎn)品層面和技術(shù)層面真正的徹底的解決辦法。

比如圖 10 列舉的那么多問(wèn)題，其實(shí)真正要解決三個(gè)方面：性能、隔離和功能。性能和隔離兼得好像很困難，但是這個(gè)架構(gòu)有非常獨(dú)特的優(yōu)勢(shì)，也是可以做得到的。那可以進(jìn)一步「三者兼得」，同時(shí)解決功能的問(wèn)題嗎？我們思考了一下，也是有辦法的。TiDB 使用的 Raft 協(xié)議里有一個(gè) Raft Learner 的角色，可以不斷的從 Leader 那邊復(fù)制數(shù)據(jù)，我們把數(shù)據(jù)同步存成了一個(gè)列存，剛才這三方面的問(wèn)題都可以用一個(gè)方案去徹底解決了。

首先復(fù)雜查詢的速度變快了，眾所周知分析型的數(shù)據(jù)引擎基本上全部使用的是列存。第二就是強(qiáng)一致性，整個(gè) Raft 協(xié)議可以保證從 Learner 讀數(shù)據(jù)的時(shí)候可以選擇一致性的讀，可以從 Leader 那邊拿到 Learner 當(dāng)前的進(jìn)度，判斷是否可以對(duì)外提供請(qǐng)求。第三個(gè)是實(shí)時(shí)性可以保證，因?yàn)槭峭ㄟ^(guò) streaming 的方式復(fù)制的。

所以這些看上去非常復(fù)雜的問(wèn)題用一個(gè)方案就可以解決，并且強(qiáng)化了原來(lái)的系統(tǒng)。這個(gè)「強(qiáng)化」怎么講？從用戶的角度看，他們不會(huì)考慮 Query 是 OLAP 還是 OLTP，只是想跑這條 Query，這很合理。用一套東西解決用戶的所有問(wèn)題，對(duì)用戶來(lái)說(shuō)就是「強(qiáng)化」的系統(tǒng)。

很多用戶都跟我們反饋了成本問(wèn)題，用戶覺(jué)得全部部署到 ?SSD 成本有點(diǎn)高。一開(kāi)始聽(tīng)到這個(gè)反饋，我們還不能理解，SSD 已經(jīng)很便宜了呀，而且在整個(gè)系統(tǒng)來(lái)看，存儲(chǔ)機(jī)器只是成本的一小部分。后來(lái)我們深刻思考了一下，其實(shí)用戶說(shuō)得對(duì)，很多系統(tǒng)都是有早晚高峰的，如果在幾百 T 數(shù)據(jù)里跑報(bào)表，只在每天晚上收工時(shí)統(tǒng)計(jì)今天營(yíng)業(yè)的狀況，那為什么要求用戶付出最高峰值的配置呢？這個(gè)要求是不合理的，合不合理是一回事，至于做不做得到、怎么做到是另外一回事。

于是我們開(kāi)始面臨全新的思考，這個(gè)問(wèn)題本質(zhì)上是用戶的數(shù)據(jù)只有一部分是熱的，但是付出的代價(jià)是要讓機(jī)器 Handle 所有的數(shù)據(jù)，所以可以把問(wèn)題轉(zhuǎn)化成：我們能不能在系統(tǒng)里面做到冷熱數(shù)據(jù)分離？能不能支持系統(tǒng)動(dòng)態(tài)彈性的伸縮，伸展熱點(diǎn)數(shù)據(jù)，用完就釋放？

如果對(duì)一個(gè)系統(tǒng)來(lái)說(shuō)，峰值時(shí)段和非峰值時(shí)段的差別在于峰值時(shí)段多了 5% 的熱點(diǎn)。我們有必要去 Handle 所有的數(shù)據(jù)嗎？所以徹底的解決辦法是對(duì)系統(tǒng)進(jìn)行合理的監(jiān)控，檢測(cè)出熱點(diǎn)后，馬上創(chuàng)建一個(gè)新的節(jié)點(diǎn)，這個(gè)新的節(jié)點(diǎn)只負(fù)責(zé)處理熱點(diǎn)數(shù)據(jù)，而不是把所有的數(shù)據(jù)做動(dòng)態(tài)的 rebalance，重新搬遷。在峰值時(shí)間過(guò)去之后就可以把復(fù)制出來(lái)的熱點(diǎn)數(shù)據(jù)撤掉，占的這個(gè)機(jī)器可以直接停掉了，不需要長(zhǎng)時(shí)間配備非常高配置的資源，而是動(dòng)態(tài)彈性伸縮的。

TiDB 作為一個(gè)高度動(dòng)態(tài)的系統(tǒng)，本身的架構(gòu)就具有非常強(qiáng)的張力，像海綿一樣，能夠滿足這個(gè)要求，而且能根據(jù)系統(tǒng)負(fù)載動(dòng)態(tài)的做這件事。這跟傳統(tǒng)數(shù)據(jù)庫(kù)的架構(gòu)有很大的區(qū)別。比如有一個(gè) 4T 的 MySQL 數(shù)據(jù)庫(kù)，一主一從，如果主庫(kù)很熱，只能馬上搞一個(gè)等配的機(jī)器重掛上去，然后復(fù)制全部數(shù)據(jù)，但實(shí)際上用戶需要的只是 5% 的熱數(shù)據(jù)。而在 TiDB 里，數(shù)據(jù)被切成 64MB 一個(gè)塊，可以很精確的檢測(cè)熱數(shù)據(jù)，很方便的為熱數(shù)據(jù)做伸展。這個(gè)特性預(yù)計(jì)在 TiDB 4.0 提供。

這也是一個(gè)良好的架構(gòu)本身帶來(lái)的強(qiáng)大的價(jià)值，再加上基于 K8s 和云的彈性架構(gòu)，就可以得到非常多的不一樣的東西。同樣的思路，如果我要做數(shù)據(jù)分析，一定是掃全部數(shù)據(jù)嗎？對(duì)于一個(gè)多租戶的系統(tǒng)，我想統(tǒng)計(jì)某個(gè)餐館今天的收入，數(shù)據(jù)庫(kù)里有成千上萬(wàn)個(gè)餐館，我需要運(yùn)算的數(shù)據(jù)只是其中一小塊。如果我要快速做列存計(jì)算時(shí)，需要把數(shù)據(jù)全部復(fù)制一份嗎？也不需要，只復(fù)制我需要的這部分?jǐn)?shù)據(jù)就行。這些事情只有一個(gè)具有彈性、高度張力的系統(tǒng)才能做到。這是 TiDB 相對(duì)于傳統(tǒng)架構(gòu)有非常不一樣的地方。時(shí)至今天，我們才算是把整個(gè)系統(tǒng)的架構(gòu)基本上穩(wěn)定了，基于這個(gè)穩(wěn)定的架構(gòu)，我們還可以做更多非常具有張力的事情。

所以，用一句話總結(jié)我們解決成本問(wèn)題的思路是：一定要解決真正的核心的問(wèn)題，解決最本質(zhì)的問(wèn)題。

TiDB 還有一條哲學(xué)是關(guān)于橫向和縱向發(fā)展的選擇。

通常業(yè)內(nèi)會(huì)給創(chuàng)業(yè)公司的最佳建議是優(yōu)先打“透”一個(gè)行業(yè)，因?yàn)樾袠I(yè)內(nèi)復(fù)制成本是最低的，可復(fù)制性也是最好的。但 TiDB 從第一天開(kāi)始就選擇了相反的一條路——「先往通用性發(fā)展」，這是一條非常艱難的路，意味著放棄了短時(shí)間的復(fù)制性，但其實(shí)我們換取的是更長(zhǎng)時(shí)間的復(fù)制性，也就是通用性。

因?yàn)楫a(chǎn)品的整體價(jià)值取決于總的市場(chǎng)空間，產(chǎn)品的廣泛程度會(huì)決定產(chǎn)品最終的價(jià)值。早期堅(jiān)定不移的往通用性上面走，有利于盡早感知整個(gè)系統(tǒng)是否有結(jié)構(gòu)性缺陷，驗(yàn)證自己對(duì)用戶需求的理解是否具有足夠的廣度。如果只往一個(gè)行業(yè)去走，就無(wú)法知道這個(gè)產(chǎn)品在其他行業(yè)的適應(yīng)性和通用性。如果我們變成了某個(gè)行業(yè)專用數(shù)據(jù)庫(kù)，那么再往其他行業(yè)去發(fā)展時(shí)，面臨的第一個(gè)問(wèn)題是自己的恐懼。這恐懼怎么講呢？Database 應(yīng)該是一個(gè)通用型的東西，如果在一個(gè)行業(yè)里固定了，那么你要如何確定它在其他場(chǎng)景和行業(yè)是否具有適應(yīng)性？

這個(gè)選擇也意味著我們會(huì)面臨非常大的挑戰(zhàn)，一上來(lái)先做最厲害的、最有挑戰(zhàn)的用戶。 如果大家去關(guān)注整個(gè) TiDB 發(fā)展的用戶案例的情況，你會(huì)注意到 TiDB 有這樣一個(gè)特點(diǎn)，TiDB 是先做百億美金以上的互聯(lián)網(wǎng)公司，這是一個(gè)非常難的選擇。但大家應(yīng)該知道，百億美金以上的互聯(lián)網(wǎng)公司，在選擇一個(gè)數(shù)據(jù)庫(kù)等技術(shù)產(chǎn)品的時(shí)候，是沒(méi)有任何商業(yè)上的考量的，對(duì)這些公司來(lái)說(shuō)，你的實(shí)力是第一位的，一定要能解決他們問(wèn)題，才會(huì)認(rèn)可你整個(gè)系統(tǒng)。但這個(gè)也不好做，因?yàn)檫@些公司的應(yīng)用場(chǎng)景通常都?jí)毫薮?。?shù)據(jù)量巨大，QPS 特別高，對(duì)穩(wěn)定性的要求也非常高。我們先做了百億美金的公司之后，去年我們有 80% 百億美金以上的公司用 TiDB，除了把我們當(dāng)成競(jìng)爭(zhēng)對(duì)手的公司沒(méi)有用，其他全部在用。然后再做 30 億美金以上的公司，今年是 10 億美金以上的用戶，實(shí)際上現(xiàn)在是什么樣規(guī)模的用戶都有，甭管多少億美金的，“反正這東西挺好用的，我就用了?！彼晕覀儸F(xiàn)在也有人專門(mén)負(fù)責(zé)在用戶群里面回答大家的提問(wèn)。

其實(shí)當(dāng)初這么定那個(gè)目標(biāo)主要是考慮數(shù)據(jù)量，因?yàn)?TiDB 作為一個(gè)分布式系統(tǒng)一定是要處理具有足夠數(shù)據(jù)量的用戶場(chǎng)景， 百億美金以上的公司肯定有足夠的數(shù)據(jù)，30 億美金的公司也會(huì)有，因?yàn)樗麄兊臄?shù)據(jù)在高速增長(zhǎng)，當(dāng)我們完成了這些，然后再開(kāi)始切入到傳統(tǒng)行業(yè)，因?yàn)樵谶@之前我們經(jīng)過(guò)了穩(wěn)定性的驗(yàn)證，經(jīng)過(guò)了規(guī)模的驗(yàn)證，經(jīng)過(guò)了場(chǎng)景的驗(yàn)證。

堅(jiān)持全球化的技術(shù)視野也是一個(gè)以橫向優(yōu)先的發(fā)展哲學(xué)。 最厲害的產(chǎn)品一定是全球在用的。這個(gè)事情的最大差異在于視野和格局，而格局最終會(huì)反映到人才上，最終競(jìng)爭(zhēng)不是在 PingCAP 這兩百個(gè)員工，也不是現(xiàn)在 400 多個(gè) Contributors，未來(lái)可能會(huì)有上千人參與整個(gè)系統(tǒng)的進(jìn)化迭代，在不同的場(chǎng)景下對(duì)系統(tǒng)進(jìn)行打磨，所以競(jìng)爭(zhēng)本質(zhì)上是人才和場(chǎng)景的競(jìng)爭(zhēng)。基于這一條哲學(xué)，所以才有了現(xiàn)在 TiDB 在新一代分布式數(shù)據(jù)庫(kù)領(lǐng)域的全面領(lǐng)先，無(wú)論是從 GitHub Star 數(shù)、 Contributor 數(shù)量來(lái)看，還是從用戶數(shù)據(jù)的規(guī)模、用戶分布的行業(yè)來(lái)看，都是領(lǐng)先的。同樣是在做一個(gè)數(shù)據(jù)庫(kù)，大家的指導(dǎo)哲學(xué)不一樣會(huì)導(dǎo)致產(chǎn)品最終的表現(xiàn)和收獲不一樣，迭代過(guò)程也會(huì)完全不一樣。我們?cè)谧龅姆较蚴恰笖y全球的人才和全球的場(chǎng)景去競(jìng)爭(zhēng)」。

關(guān)于橫向和縱向發(fā)展，并不是我們只取了橫向。

2019 年 TiDB 演進(jìn)的指導(dǎo)思想是：穩(wěn)定性排第一，易用性排第二，性能第三，新功能第四。 這是我在 2018 年經(jīng)過(guò)思考后，把我們發(fā)展的優(yōu)先級(jí)做了排序。上半年我們重點(diǎn)關(guān)注的是前兩個(gè)，穩(wěn)定性和易用性。下半年會(huì)關(guān)注縱向發(fā)展，「Make it fast」其實(shí)是縱向上精耕細(xì)作、釋放潛力的事情。這個(gè)指導(dǎo)思想看起來(lái)好像又跟其他廠商想法不太一樣。

我們前面講的三條哲學(xué)里面，最后一條就是「Make it fast」，如果要修建五百層的摩天大樓，要做的不是搭完一層、裝修一層，馬上給第一層做營(yíng)業(yè)，再去搭第二層。而一定要先把五百層的架構(gòu)搭好，然后想裝修哪一層都可以。TiDB 就是「摩天大樓先搭架構(gòu)后裝修」的思路，所以在 TiDB 3.0 發(fā)布之后，我們開(kāi)始有足夠的時(shí)間去做「裝修」的事情。

說(shuō)了這么多故事，如果要我總結(jié)一下 2015 - 2019 年外面的朋友對(duì) TiDB 的感受，是下圖這樣的：

2015 年，當(dāng)我們開(kāi)始做 TiDB 的時(shí)候，大家說(shuō)：??？這事兒你們也敢干？因?yàn)閷?xiě)一個(gè)數(shù)據(jù)庫(kù)本身非常難，寫(xiě)一個(gè)分布式數(shù)據(jù)庫(kù)就是無(wú)比的難，然后還是國(guó)人自主研發(fā)。到 2016 年的時(shí)候，大家覺(jué)得你好像折騰了點(diǎn)東西，聽(tīng)到點(diǎn)聲音，但也沒(méi)啥。到 2017、2018 年，大家看到有越來(lái)越多用戶在用。2019 年，能看到更多使用后點(diǎn)贊的朋友了。

我昨天翻了一下 2015 年 4 月 19 日發(fā)的一條微博。

當(dāng)時(shí)我們正準(zhǔn)備創(chuàng)業(yè)，意氣風(fēng)發(fā)發(fā)了一條這樣微博。這一堆話其實(shí)不重要，大家看一下閱讀量 47.3 萬(wàn)，有 101 條轉(zhuǎn)發(fā)，44 條評(píng)論，然而我一封簡(jiǎn)歷都沒(méi)收到。當(dāng)時(shí)大家看到我們都覺(jué)得，這事兒外國(guó)人都沒(méi)搞，你行嗎？折騰到今天，我想應(yīng)該沒(méi)有人再對(duì)這個(gè)問(wèn)題有任何的懷疑。很多國(guó)人其實(shí)能力很強(qiáng)了，自信也可以同步跟上來(lái)，畢竟我們擁有全球最快的數(shù)據(jù)增速，很多廠家擁有最大的數(shù)據(jù)量，對(duì)產(chǎn)品有最佳的打磨場(chǎng)景。

想想當(dāng)時(shí)我也挺絕望的，想著應(yīng)該還有不少人血?dú)夥絼?，還有很多技術(shù)人員是有非常強(qiáng)大的理想的，但是前面我也說(shuō)了，總有一個(gè)從理想到現(xiàn)實(shí)的距離，這個(gè)距離很長(zhǎng)，好在現(xiàn)在我們能收到很多簡(jiǎn)歷。所以很多時(shí)候大家也很難想象我們剛開(kāi)始做這件事情的時(shí)候有多么的困難，以及中間的每一個(gè)堅(jiān)持。只要稍微有一丁點(diǎn)的松懈，就可能走了另外一條更容易走的路，但是那條更容易走的路，從長(zhǎng)遠(yuǎn)上看是一條更加困難的路，甚至是一條沒(méi)有出路的路。

最后再說(shuō)一下 2020 年。在擁有行業(yè)復(fù)制能力的之后，在產(chǎn)品層面我們要開(kāi)始向著更高的性能、更低的延遲、更多 Cloud 支持（不管是公有云還是私有云都可以很好的使用 TiDB）等方向縱向發(fā)展。同時(shí)也會(huì)支持我剛剛說(shuō)的，熱點(diǎn)根據(jù) Workload 自動(dòng)伸縮，用極小的成本去扛，僅僅需要處理部分熱點(diǎn)的數(shù)據(jù)，而不是復(fù)制整個(gè)數(shù)據(jù)的傳統(tǒng)主-從思路。

大家去想一想，如果整個(gè)系統(tǒng)會(huì)根據(jù) Workload 自動(dòng)伸縮，本質(zhì)上是一個(gè) self-driving 的事情。現(xiàn)在有越來(lái)越多的用戶把 TiDB 當(dāng)成一個(gè)數(shù)據(jù)中臺(tái)來(lái)用，有了 TiDB 行列混存，并且 TiDB 對(duì)用戶有足夠透明度，就相當(dāng)于是握有了 database 加上 ETL，加上 data warehouse，并且是保證了一致性、實(shí)時(shí)性的。

昨天我寫(xiě)完 slides 之后想起了以前看的一個(gè)電視劇《大秦帝國(guó)》。第一部第九集里有一段關(guān)于圍棋的對(duì)話。商鞅執(zhí)黑子先行，先下在了一個(gè)應(yīng)該是叫天元位置，大約在棋盤(pán)的中間。大家知道一般下圍棋的時(shí)候都是先從角落開(kāi)始落子居多。商鞅的對(duì)手就說(shuō)，我許你重下，意思就是你不要開(kāi)玩笑，誰(shuí)下這兒啊？于是商鞅說(shuō)這樣一句話，“中樞之地，輻射四極，雄視八荒”，這也是一個(gè)視野和格局的事情。然后對(duì)手說(shuō)：“先生招招高位，步步懸空，全無(wú)根基實(shí)地”，就是看起來(lái)好像是都還挺厲害的，一點(diǎn)實(shí)際的基礎(chǔ)都沒(méi)有，商鞅說(shuō)：“旦有高位，豈無(wú)實(shí)地？”，后來(lái)商鞅贏了這盤(pán)棋，他解釋道：“棋道以圍地為歸宿，但必以取勢(shì)為根本。勢(shì)高，則圍廣”。

這跟我們做 TiDB 其實(shí)很像，我們一上來(lái)就是先做最難最有挑戰(zhàn)的具有最高 QPS 和 TPS、最大數(shù)據(jù)量的場(chǎng)景，這就是一個(gè)「取勢(shì)」的思路，因?yàn)椤竸?shì)高，則圍廣」。 所以我們更多時(shí)候是像我前面說(shuō)的那樣，站在哲學(xué)層面思考整個(gè)公司的運(yùn)轉(zhuǎn)和 TiDB 這個(gè)產(chǎn)品的演進(jìn)的思路。這些思路很多時(shí)候是大家看不見(jiàn)的，因?yàn)椴皇且粋€(gè)純粹的技術(shù)層面或者算法層面的事情。

我也聽(tīng)說(shuō)有很多同學(xué)對(duì) TiDB 3.0 特別感興趣，不過(guò)今天沒(méi)有足夠的時(shí)間介紹，我們會(huì)在后續(xù)的 TechDay 上介紹 3.0 GA 的重大特性，因?yàn)閺?2.0 到 3.0 產(chǎn)生了一個(gè)巨大的變化和提升，性能大幅提升，硬件成本也下降了一倍的樣子，需要一天的時(shí)間為大家詳細(xì)的拆解。