$P(X_2│X_1=0.75)
卷首語：五年之後，數據庫會變成什麼樣子？
作者：黃東旭
我還清楚記得，五年前的這個時候，當時還在豌豆莢，午後與劉奇和崔秋的閒聊關於未來數據庫的想象，就像一粒種子一樣，到了今天看起來也竟枝繁葉茂鬱鬱蔥蔥，有點感慨。按照慣例，五年是一個重要的節點，沒有十年那麼冗長，也沒有一兩年的短暫，是一個很好的回顧與展望節點。
五年前創業的出發點其實很樸素：做一個更好的分佈式數據庫。從學術的角度上看起來，並不是提出了什麼驚天地泣鬼神的神奇算法，我們選擇的 Shared-nothing 的架構其實在當時的業界也不是什麼新鮮的事情了，但真正令我激動的是：我們要造的是一個真正能作爲整個系統的 Single Source of Truth 的基礎軟件。
創業五年，TiDB按照我們當初的設想一步步變成了現實 ，在這個旅途中，我們一步步看到了更大的世界。那麼接下來的五年會發什麼？隨着對於行業和技術的理解的加深，至少有一點我深信不疑的是：彈性調度會是未來的數據庫的核心能力。
誰都不會否認，最近十年在 IT 技術上，最大的變革是由雲帶來的，這場革命還在進行時。雲的核心能力是什麼？我認爲是彈性。計算資源分配的粒度變得越來越細，就像從只能買房變成可以租房，甚至可以像住酒店一樣靈活。這意味着什麼？本質在於我們可以不用爲「想象中」的業務峯值提前支付成本。
過去我們的採購服務器也好，租賃機櫃也好，都是需要設定一個提前量的，當業務峯值沒有到來之前，其實這些成本是已經提前支付的了。雲的出現將彈性變成了基礎設施的一個基礎能力，我預計數據庫也會發生同樣的事情。
可能有很多朋友會有疑問，現在難道不是幾乎所有數據庫都號稱能夠支持透明水平擴展嘛？其實這裏希望大家不要將「彈性調度」狹隘的理解爲擴展性，而且這個詞的重點在「調度」上，我舉幾個例子以方便大家理解：
1. 數據庫能不能夠自動識別 workload，根據 workload 進行自動伸縮？例如：預感到峯值即將來臨，自動的採購機器，對熱數據創建更多副本並重分佈數據，提前擴容。在業務高峯過去後，自動回收機器進行縮容。
2. 數據庫能不能感知業務特點，根據訪問特點決定分佈？例如：如果數據帶有明顯的地理特徵（比如，中國的用戶大概率在中國訪問，美國用戶在美國），系統將自動的將數據的地理特徵在不同的數據中心放置。
3. 數據庫能不能感知查詢的類型和訪問頻度，從而自動決定不同類型數據的存儲介質？例如：冷數據自動轉移到 S3 之類比較便宜的存儲，熱數據放在高配的閃存上，而且冷熱數據的交換完全是對業務方透明的。
這裏提到的一切背後都依賴的是「彈性調度」能力。未來我相信物理資源的成本會持續的降低，計算資源的單價持續下降帶來的結果是：當存儲成本和計算資源變得不是問題的時候，問題就變成「如何高效的分配資源」。如果將高效分配作爲目標的話，「能調度」就是顯而易見的基礎。
當然就像一切事物發展的客觀規律一樣，學會跑步之前，先要學會走路，我相信在接下來的一段時間內，我們會看到第一批初步擁有這樣能力的新型數據庫，讓我們拭目以待。
對於更遠的未來是怎麼樣子的？我不知道，但是就像 The Machine 一樣，只有足夠數據才能誕生出智能，我相信就像我們不瞭解宇宙和海洋一樣，我們現在對於數據的認識一定是膚淺的，甚至大量的數據我們都還沒記錄下來，一定有更大奧祕隱藏在這海量的數據中，從數據中能獲取什麼樣的洞察，能夠怎麼樣更好的改變我們的生活，我並不知道，但是做這件事情的主角我猜不會是人類。雖然在這個小節我們討論的東西可能就有點像科幻小說了，不過我願意相信這樣的未來，從數據的海洋中誕生出新的智能體。
我有一個夢想，未來的軟件工程師不用再爲維護數據庫加班熬夜，各種數據相關的問題都將被數據庫自動且妥善的處理；
我有一個夢想，未來我們對數據的處理將不再碎片化，任何業務系統都能夠方便的存儲和獲取數據；
我有一個夢想，未來的我們在面臨數據的洪流時候，能從容地以不變應萬變。
最近我聽到一句話，我個人很喜歡：雄心的一半是耐心。構建一個完美的數據庫並不是一朝一夕的工作，但是我相信我們正走在正確的道路上。
凡所過往，皆爲序章。
目錄
熱點 | Hot
尤雨溪 B 站直播，Vue 3.0 Beta 是一個值得體驗的全新版本
唯一維護者鋃鐺入獄，周下載量超 2600 萬的 JS 庫該何去何從？
觀點 | Opinion
中臺翻車紀實：一年叫停，員工轉崗被裁，資源全浪費
放棄微服務，改用宏服務，Uber 這波什麼操作？
Uber 的 Kafka 實踐：踩坑 5 年，隨時像替換汽車引擎一樣替換 Kafka
推薦文章 | Article
做獨立開發者兩年了，我是這樣賺錢的
落地三年，兩次架構升級，網易 Service Mesh 實踐之路