摘要：申礫老師的演講實錄正在整理中，后續(xù)會分享給大家同時在里面，我們還做了大量的改進。

1 月 19 日 TiDB DevCon 2019 在北京圓滿落幕，超過 750 位熱情的社區(qū)伙伴參加了此次大會。會上我們首次全面展示了全新存儲引擎 Titan、新生態(tài)工具 TiFlash 以及 TiDB 在云上的進展，同時宣布 TiDB-Lightning Toolset & TiDB-DM 兩大生態(tài)工具開源，并分享了  TiDB 3.0 的特性與未來規(guī)劃，描述了我們眼中未來數(shù)據(jù)庫的模樣。
此外，更有 11 位來自一線的 TiDB 用戶為大家分享了實踐經驗與踩過的「坑」，獲得了現(xiàn)場觀眾的陣陣掌聲。同時，我們也為新晉 TiDB Committer 授予了證書，并為 2018 年最佳社區(qū)貢獻個人、最佳社區(qū)貢獻團隊頒發(fā)了榮譽獎杯。
錯過現(xiàn)場的小伙伴不要太「傷心」，我們將挑選部分精彩實錄分享給大家，敬請期待哦～

以下為我司 CEO 劉奇在 TiDB DevCon 2019 上的 Opening Keynote 實錄。

首先我想特別感謝每一位來參加 TiDB DevCon 2019 的 Contributor 和用戶，還有對 TiDB 保持好奇的人。今天我主要想跟大家分享一下我們過去一年的一些發(fā)展情況，以及我們對于未來的一些想法。

從圖 1 大家可以很清楚的看到 TiDB 在過去一年的增長。如果大家去對比一下 TiDB 增長曲線和其他同類產品、或者是上一代 NoSQL 產品的增長曲線會發(fā)現(xiàn)，TiDB 是遙遙領先的。看完我們的 Contributor 增長和我們在 GitHub 上面的各種狀態(tài)，在這里也特別感謝我們所有的那些正在使用 TiDB 的用戶。

圖 2 是過去一年，我們用戶自己去分享自己使用 TiDB 的一些經驗。我記得我們在籌辦這個會的時候，我說我有特別多想講的東西，掏心窩子的話特別多，能不能讓我多講講。我們市場的同學不太同意，說我們只有一天時間，我們應該把更多的時間交給我們用戶，讓他們來分享他們自己的經驗，交給在一線的同學。大家如果特別有興趣的話，可以去翻一翻我們用戶使用 TiDB 的一些經驗（https://pingcap.com/cases-cn/），里面有一些他們的踩坑經驗，也有一些他們比較欣慰的點，還有一些用戶吐槽的東西，所以我們在 2018 年年底的時候，搞了一次吐槽大會，請幾個用戶過去瘋狂吐槽一下我們的產品。我們定了幾個原則，比如，只允許說缺點，不允許說優(yōu)點。

這是海外的一些媒體對我們的報道（圖 3），大家可能也知道，我們去年拿了 InfoWorld 評選的 Bossie Awards 最佳開源軟件獎，接下來的分享 Morgan 會介紹我們在海外的一些發(fā)展情況和我們的海外團隊。

在過去一年，我們最喜歡聽用戶講的一句話是什么？我們最喜歡聽的一句話是：你們搞得定嗎？我覺得這句話太好了，很多時候，我們突然會去跟用戶去講，你這是 OLAP，你這是 OLTP。其實用戶關心的是，你能不能搞定我的問題，而不是說你過來派了一堆專家，告訴我該怎么干。

在過去一年里，用戶在用 TiDB 的過程中，也會遇到很多的問題。比如說，OLTP 和 OLAP 的隔離怎么去做。所以我們在今年啟用了一個全新的 Design，在這個 Design 里面是徹底地隔離 OLAP 和 OLTP 的 Workload。

我們曾經見到很多爭論，也見到很多論文，說到底是行存好，還是列存好。如果大家去看知乎的話，這個討論現(xiàn)在還沒有休止：到底數(shù)據(jù)庫是應該使用行存還是使用列存。而在我們現(xiàn)在的 Design 里面，我們會擱置這個爭議——為什么我們不能都有？

大家想一想，在多少年前，我們家里面還有固定電話，我們還在看紙質書，我們聽歌用 MP3，我們可能想看一下自己今天跑了多少步，還得用一個專門的硬件或者運動設備。但是到今天，一部手機就搞定這一切。

在之前，我們可能線上需要用 MySQL，或者用 PG，中間我們可能需要用消息隊列，去把 binlog 或者 change feeds 都給弄出來，然后再弄到一個 Data ware house 里面，在 Data ware house 里面去 Run。最終我們喪失了實時性，我們喪失了一致性。但是如果我們重新去想一下這個事情，這事兒就像當初的手機和 MP3、紙質書一樣的。到今天技術進步到一定程度的時候，為什么我不能 OLTP/OLAP All in one ，我只是一個普通的用戶，我不想接受那么一堆東西，同時我要實時性，我現(xiàn)在要的，馬上就要。

當然大的氛圍下面，吹牛的很多，但如果我不知道他是怎么 Work 的，通常我是不太放心的，所以我們用一個簡單的圖（圖 5）說一下，到底 OLAP 和 OLTP 的 Workload 是怎么隔離的。 在我們全新的 Design 里面，TiDB 的 engine——TiKV ，但是我們通過 Raft 協(xié)議，通過 learner 把數(shù)據(jù)復制出來一份，這份協(xié)議是實時通過 Raft 做復制，但是用列式來存儲。如果我們的優(yōu)化器變得更加聰明，當一個查詢過來的時候，它不用再去糾結，而是會根據(jù)這個 Query 的特點、自動根據(jù)這個 SQL 去選擇到底是使用行存，還是使用列存，還是一部分使用行存，一部分使用列存，這樣就會帶來很多額外的好處。在這個圖上（圖 5）可以看到，Workload 是整個物理上是隔離的，是完全跑在不同的 Server 上面的。

這樣帶來的好處就非常明顯。我們就能夠同時去 Join 兩個不同格式的數(shù)據(jù)，同時能得到所有的 OLAP 和 OLTP 的系統(tǒng)的好處，能得到一個更神奇的結果，就是它可以比 OLTP 系統(tǒng)跑的快；你可以在一個 OLTP 的系統(tǒng)，在傳統(tǒng)上面不可想象的、在下面去跑一個報表。所以今天我們也非常高興的去向大家推出我們新的 Design 和對應的產品，這個產品叫 TiFlash。看過美劇 The Flash 的同學知道閃電俠，這個名稱是為了形容它的速度，因為它又是 TiDB 的 Ti 系列家族中的一員，所以我們給他取名叫 TiFlash，下午會有一個非常非常 Amazing 的環(huán)節(jié)會去展示整個 TiFlash。大家可以保持期待，這個一定不會讓大家失望。我昨天看了一下演示，非常震撼。

有關注我們微信公眾號的同學會發(fā)現(xiàn)，在今天早上（1 月 19 日）我們發(fā)布了?3.0 Bata 版本，在 3.0 里面，我們發(fā)布了大量的新特性，比如去年在 DevCon 上面，我承諾給大家的，我們會支持 Window Fuction、支持 View、支持 Partition，這些東西現(xiàn)在統(tǒng)統(tǒng)都有了。同時我們還有一些新的東西是之前沒有的，比如說?Plan binding，就是綁定執(zhí)行計劃，這里也是特別感謝美團同學的 Contribution，讓我們能夠支持到新的特性。這些特性，稍后申礫老師會給大家分享詳細的細節(jié)，這邊我就先跳過。（申礫老師的演講實錄正在整理中，后續(xù)會分享給大家～）

同時在 3.0 里面，我們還做了大量的改進。

大家知道，過去一年有那么多 TiDB 用戶，其實他們也有頭疼的地方。就是 TiDB 的執(zhí)行計劃跟 TiDB 的統(tǒng)計信息是高度相關的，有時候會遇到執(zhí)行計劃產生變化。所以 2019 年的 Q1，我們將會花大量的時間，去讓這個執(zhí)行計劃變的更加穩(wěn)定。 同時為了便于大家去查看這些慢查詢，我們做了一個非常漂亮的 Query Tracing 的界面，上午申礫的分享也會去介紹這個非常漂亮的界面，讓大家看到，一個復雜的 Query 下去，最終在每一步耗了多長時間，還有個非常漂亮的樹形圖。

然后我們也解決了過去一年，我們 Raft Store 是一個單線程的問題。我覺得這個需要消耗大量的時間和精力。我記得我們當初做 Region split 的時候好像沒花多久，分裂可能做一個月，然后 merge 做了一年，多線程這個也差不多做了一年。

前一陣大家可能也知道業(yè)內出現(xiàn)過刪庫跑路的事情。當時我們也非常震驚，我就想從我們的層面上能做哪些事情？所以，我們在 3.0 里面提供了一個新的功能，叫 Admin restore table，如果你一不小心把一個數(shù)據(jù)庫，或者把一個 table 給刪了，只要還沒有對數(shù)據(jù)做垃圾收集、沒有徹底喪失之前，你還可以一個命令，馬上恢復這個數(shù)據(jù)庫。

當然通常聊到一個新版本的時候，大家最關心的就是，不服跑個分。所以呢，我們也在最簡單最基礎的環(huán)境下跑了個分，圖 7 是 3.0 版本與 2.1 版本的對比。大家知道我們在前不久發(fā)布了 2.1，大家可以看到，整體的 Performance 的提升非常的明顯，基本上直接 Double 了。大家在實測的過程中，應該會測出比 Double 更高的性能。

當然這個 Performance 的提升，里面有很大一部分是我們一個新的 Storage 的貢獻。新的 Storage 叫 Titan。我們也是非常有意思的和美圖基于 TiKV 開發(fā)的一個 Redis 的實現(xiàn)，使用了一樣的名字。大家對于這個希臘神話的熱愛，其實是一樣的。程序員在選名字的時候，也都有自己的特點，所以大家就重名了，重名之后，我們還討論了一下，覺得這個名字要不要考慮改一下，后來大家覺得既然都挺喜歡，要不然都用這個吧，我們覺得這也挺好。

然后整個新的存儲引擎的 Design 是這樣（圖 9），我們把 Key 和 Value 做了分離。大家知道，去年我們在做論文分享的時候，有一次專門分享了 《WiscKey: Separating Keys from Values in SSD-conscious Storage》 這篇論文，也是非常感謝這篇論文。Titan 整體上是基于 RocksDB 去做的一個修改或者是一個優(yōu)化，更多的是在 RocksDB 的外圍實現(xiàn)了 Key Value 分離，主要是適應于更大的 Value。

下面是 Titan 的 Performance 跑分。大家看到整體的提升都會非常的明顯，從兩倍到 N 倍吧，這個 N 的多少，取決于 Value 最終有多大，Value 越大的話，N 會越大（延伸閱讀：《Titan 的設計與實現(xiàn)》）。

說了這么多，那么在一個云的時代我們到底是怎樣去擁抱云的。
大家知道 TiDB 在最初 Design 的時候，就是為 Cloud 做了大量的優(yōu)化，同時在三年前我們就相信 Kubernetes 是未來，然后 TiDB 整個就 All-in Kubernetes 了。所以我們一直在等著 Cloud 出一個功能，就是 Cloud 能不能夠支持 Native Kubernetes Engine，后來我們看到了 Google 發(fā)布了他們的 Kubernetes Engine。所以我們第一時間和 Google 的 K8s 做了一個集成，同時大家現(xiàn)在也可以去訪問 Google 云平臺（Google Cloud Platform），去試用我們的產品（https://pingcap.com/tidb-cloud/），在那上面真的是一鍵就可以跑起一個集群，然后都可以由我們來 maintain 整個 TiDB，相當于我們現(xiàn)在有一個 TiDB On Cloud。接下來也會支持 AWS 和 Azure。

其實之前有部分同學都提過，TiDB 做得挺好的為什么不做一套漂亮的界面，然后它的易用性會更佳，更重要的是支持多租戶。美團今天也會分享他們在使用 TiDB 的經驗，當我們一個集群，兩個集群，十個集群，二十個集群，一百個集群的時候怎么辦，那么多集群，我怎么用一個簡單的方式去維護，那這個時候就需要一套 Database as Service 的東西，能夠去幫我管理整個公司的所有 TiDB 集群。所以對于多租戶的支持就變得非常有用。同時也會做自動的 Backup 和 Recover。

那我們下一步會有什么不一樣的地方？我們剛才提到 3.0 版本有這么多讓人非常興奮的功能，有這么多的巨大改進，什么時候能夠把他用到產品里面，是大家接下來關心的一個問題。

首先我們會在今年的 6 月份發(fā)布第一個 3.0 的 GA。目前正在不同的用戶場景下做大量的測試，通過不同的 Workload ?做測試。

另外，大家知道，我們去年寫了一個 24 章經——就是 TiDB 源碼閱讀系列文章，我們寫了 24 篇，如果熟悉金庸先生的話應該知道 42 章經，今年我們開始為 TiKV 準備 24 章經，會去詳細解讀 TiKV 源碼的實現(xiàn)。著名 IT 作家、譯者侯捷大師說：「源碼面前，了無秘密」。我希望大家對于 TiDB 的理解能夠深入骨髓。能夠自己隨意去 Hack 我們的東西，能為整個 TiDB Community 貢獻更多東西。

同時我們也會提供更加智能的、基于機器學習的功能。如果大家之前有關注我們的黑客馬拉松，會發(fā)現(xiàn)我們實現(xiàn)第一個 prototype，是用貝葉斯模型做智能的熱點的調度。大家以后應該會跟“人工看熱點調度，再人工 split ”這事兒 say goodbye 了。

最后，當我們有大量的用戶，有大量的使用場景，有大量的經驗的時候，我們需要一個更加強大的 Community 和一個更加強大的 Ecosystem。今天崔秋老師也會去講我們整個 Community 的運轉并為新晉 Committer 授予證書。