聊聊數據庫的將來，寫在 PingCAP 成立五週年前夕

數據是架構的中心

做爲一個互聯網行業的架構師，幾乎是每天都在和各類類型的數據打交道，這麼多年的經驗，不一樣行業不一樣系統，從技術層面來講，抽象到最高，總結成一句話就是：

數據是架構的中心。

仔細想一想，咱們其實作的一切工做，都是圍繞着數據。數據的產生，數據的存儲，數據的消費，數據的流動……只不過是根據不一樣的需求，變化數據的形態和服務方式。計算機系的同窗可能還記得老師說過的一句話：程序 = 算法 + 數據結構，我這裏斗膽模仿一下這個句式：系統 = 業務邏輯 x 數據。能夠說不少架構問題都是出在數據層，例如常見的「煙囪式系統」帶來的種種問題，特別是數據孤島問題，其實本質上的緣由就出在沒有將數據層打通，若是不從數據架構去思考，就可能「頭疼醫頭、腳疼醫腳」，費了半天勁仍是很彆扭，反過來若是將數據層治理好，就像打通「任督二脈」同樣，起到四兩撥千斤的效果。

可是理想一般很豐滿，現實卻很骨感。至少在咱們五年前出來創業那會兒，咱們以爲並無一個系統可以很好的解決數據的問題。可能好奇的讀者就要問了：不是有 Hadoop？還有 NoSQL？再不濟關係型數據庫也能分庫分表啊？其實列出的這幾個幾乎就是當年處理存儲問題的所有候選，這幾個方案的共同特色就是：不完美。

具體一點來講，這幾個解決方案對於數據應用的場景覆蓋其實都不大，對於複雜一點的業務，可能須要同時使用 n 多個方案才能覆蓋完整。這就是爲何隨着近幾年互聯網業務愈來愈複雜，相似 Kafka 這樣的數據 Pipeline 愈來愈流行，從數據治理的角度其實很好理解：各類數據平臺各負責各的，爲了作到場景的全覆蓋，必然須要在各個「島」之間修路呀。

咱們當年就在想，能不能有一個系統以一個統一的接口儘量大的覆蓋到更多場景。

咱們須要一個 Single Source of Truth。數據應該是貫穿在應用邏輯各個角落，我理想中的系統中對於任意數據的存取都應該是能夠不加限制的（先不考慮權限和安全，這是另外一個問題），這裏的「不加限制」是更廣義的，例如：沒有容量上限，只要有足夠的物理資源，系統能夠無限的擴展；沒有訪問模型限制，咱們能夠自由的關聯、聚合數據；沒有一致性上的限制；運維幾乎不須要人工干預……

以分佈式數據庫爲統一中心的架構

我當年特別着迷於一個美劇：Person of Interest （疑犯追蹤），這個電視劇裏面有一個神同樣的人工智能 The Machine，收集一切數據加以分析，從而預測或是干預將來人們的行動。雖然這部美劇仍是比較正統的行俠仗義之類的主題，可是更讓我着迷的是，是否咱們能設計一個 The Machine？雖然直到目前我還不是一個 AI 專家，可是給 The Machine 設計一個數據庫彷佛是可行的。這幾年創業過程當中，咱們發現更使人興奮的點在於：

以分佈式數據庫爲統一中心的架構是可能的。

這個怎麼理解呢？舉個例子，就像在上面提到的分裂帶來的問題，數據層的割裂必然意味着業務層須要更高的複雜度去彌補，其實不少工程師其實偏向於用線性的思惟去思考維護系統的成本。可是實際的經驗告訴咱們，事情並非這樣的。一個系統只有一個數據庫和有十個數據庫的複雜程度其實並非的簡單的 10x，考慮到數據的流動，維護成本只多是更多，這裏尚未考慮到異構帶來的其餘問題。

以分佈式數據庫爲中心的架構是什麼樣子的呢？很好理解，整個架構的中心是一個場景覆蓋度足夠廣，且具備無限的水平伸縮能力的存儲系統。大部分數據的流動被限制在這個數據庫內部，這樣應用層就能夠幾乎作到無狀態，由於這個中心的數據庫負責了絕大部分狀態，每一個應用能夠經過本身的緩存來進行加速。 這裏我想提醒的是，爲何我在上面強調水平擴展能力，是由於受限的擴展能力也是致使分裂的一個重要的緣由。咱們歷來都沒有辦法準確的預測將來，咱們很難想象甚至是一年後業務的變化（想一想此次疫情），有句老話說的很好：惟一不變的就是變化。

另一個常常被問到的問題，爲何要強調緩存層須要離業務層更近，或者說，爲何位於中心的這個巨型數據庫不該該承擔緩存的責任？個人理解是，只有業務更懂業務，知道應該以什麼樣的策略緩存什麼樣的數據，並且出於性能（低延遲）考慮，緩存離業務更近也是有道理的。

對應上面那句話「惟一不變的就是變化」，這個架構帶來最大的好處正是「以不變應萬變」，或者更簡單的一個詞：簡潔。Google 其實在很早就想清楚了這個問題，由於他們很早就明白什麼是真正的複雜。

另外一個例子是 HTAP，若是關注的數據庫的發展的話，最近必定對 HTAP 這個詞很熟悉，其實在我看來的 HTAP 的本質在於上面提到的覆蓋度，下面是一個典型的架構：

傳統的數據架構一般將 OLTP、OLAP、離線數倉分離，各個系統各司其職，中間經過獨立的 Pipeline 進行同步（有時候還會加上 ETL）。 下面是一個 HTAP 的系統的樣子：

雖然從表面上看，只是簡單的將接口層進行整合，可是這個意義實際上是深遠的，首先數據同步的細節被隱藏了一塊兒來，這意味着數據庫層面能夠本身決定經過何種方式同步數據，另外因爲 OLTP 引擎和 OLAP 引擎在同一個系統內部，使得不少細節信息不會在同步的過程當中丟失，好比：事務信息，這就意味着在內部的分析引擎可以作到傳統的 OLAP 沒辦法作的事情。另外對於業務層的使用來講，少一個系統意味着更統一的體驗和更小的學習和改形成本，不要低估統一帶來的力量。

將來在哪裏？

上面這些是過去五年發生的事情，也幾乎按照咱們創業時候的設想一步步的變爲現實，那麼接下來的五年會發什麼？隨着對於行業和技術的理解的加深，至少有一點我深信不疑的是：

彈性調度會是將來的數據庫的核心能力

誰都不會否定，最近十年在 IT 技術上，最大的變革是由雲帶來的，這場革命還在進行時。雲的核心能力是什麼？我認爲是彈性。計算資源分配的粒度變得愈來愈細，就像從只能買房變成能夠租房，甚至能夠像住酒店同樣靈活。這意味着什麼？本質在於咱們能夠不用爲「想象中」的業務峯值提早支付成本。

過去咱們的採購服務器也好，租賃機櫃也好，都是須要設定一個提早量的，當業務峯值沒有到來以前，其實這些成本是已經提早支付的了。雲的出現將彈性變成了基礎設施的一個基礎能力，我預計數據庫也會發生一樣的事情。鄭州婦科醫院那個好：http://www.xbhnzzyy.com/

可能有不少朋友會有疑問，如今難道不是幾乎全部數據庫都號稱可以支持透明水平擴展嘛？其實這裏但願你們不要將「彈性調度」狹隘的理解爲擴展性，並且這個詞的重點在「調度」上，我舉幾個例子以方便你們理解：

1. 數據庫能不可以自動識別 workload，根據 workload 進行自動伸縮？例如：預感到峯值即未來臨，自動的採購機器，對熱數據建立更多副本並重分佈數據，提早擴容。在業務高峯過去後，自動回收機器進行縮容。

2. 數據庫能不能感知業務特色，根據訪問特色決定分佈？例如：若是數據帶有明顯的地理特徵（好比，中國的用戶大機率在中國訪問，美國用戶在美國），系統將自動的將數據的地理特徵在不一樣的數據中心放置。

3. 數據庫能不能感知查詢的類型和訪問頻度，從而自動決定不一樣類型數據的存儲介質？例如：冷數據自動轉移到 S3 之類比較便宜的存儲，熱數據放在高配的閃存上，並且冷熱數據的交換徹底是對業務方透明的。

這裏提到的一切背後都依賴的是「彈性調度」能力。將來我相信物理資源的成本會持續的下降，計算資源的單價持續降低帶來的結果是：當存儲成本和計算資源變得不是問題的時候，問題就變成「如何高效的分配資源」。若是將高效分配做爲目標的話，「能調度」就是顯而易見的基礎。 固然就像一切事物發展的客觀規律同樣，學會跑步以前，先要學會走路，我相信在接下來的一段時間內，咱們會看到第一批初步擁有這樣能力的新型數據庫，讓咱們拭目以待。

下一個階段是智能

對於更遠的將來是怎麼樣子的？我不知道，可是就像 The Machine 同樣，只有足夠數據才能誕生出智能，我相信就像咱們不瞭解宇宙和海洋同樣，咱們如今對於數據的認識必定是膚淺的，甚至大量的數據咱們都還沒記錄下來，必定有更大奧祕隱藏在這海量的數據中，從數據中能獲取什麼樣的洞察，可以怎麼樣更好的改變咱們的生活，我並不知道，可是作這件事情的主角我猜不會是人類。雖然在這個小節咱們討論的東西可能就有點像科幻小說了，不過我願意相信這樣的將來，從數據的海洋中誕生出新的智能體。鄭州試管嬰兒費用：http://jbk.39.net/yiyuanfengcai/tsyl_zztjyy/3100/

尾聲

創業這五年的時間，回頭看看那個最樸素的出發點：寫一個更好的數據庫完全解決煩人的 MySQL 分庫分表問題。彷佛也算沒有偏離初心，可是在這個旅途中一步步看到了更大的世界，也愈來愈有能力和信心將咱們相信的東西變爲現實：

我有一個夢想，將來的軟件工程師不用再爲維護數據庫加班熬夜，各類數據相關的問題都將被數據庫自動且妥善的處理；

我有一個夢想，將來咱們對數據的處理將再也不碎片化，任何業務系統都可以方便的存儲和獲取數據；

我有一個夢想，將來的咱們在面臨數據的洪流時候，能從容地以不變應萬變。

最近我聽到一句話，我我的很喜歡：雄心的一半是耐心。構建一個完美的數據庫並非一朝一夕的工做，可是我相信咱們正走在正確的道路上。

凡所過往，皆爲序章。