數據庫

聊聊數據庫的未來,寫在 PingCAP 成立五周年之際

我還清楚記得,五年前的這個時候,當時還在豌豆莢,午后與劉奇和崔秋的閑聊關于未來數據庫的想象,就像一粒種子一樣,到了今天看起來也竟枝繁葉茂郁郁蔥蔥,有點感慨。按照慣例,五年是一個重要的節點,沒有十年那么冗長,也沒有一兩年的短暫,是一個很好的回顧節點,就在此認真的回顧一下過去,展望一下未來。

五年前創業的出發點其實很樸素:做一個更好的分布式數據庫。從學術的角度上看起來,并不是提出了什么驚天地泣鬼神的神奇算法,我們選擇的 Shared-nothing 的架構其實在當時的業界也不是什么新鮮的事情了,但真正令我激動的是:我們要造的是一個真正能作為整個系統的 Single Source of Truth 的基礎軟件。這句話怎么理解呢?我在后邊會好好聊聊。

數據是架構的中心

作為一個互聯網行業的架構師,幾乎是天天都在和各種類型的數據打交道,這么多年的經驗,不同行業不同系統,從技術層面來說,抽象到最高,總結成一句話就是:數據是架構的中心。仔細想想,我們其實做的一切工作,都是圍繞著數據。數據的產生,數據的存儲,數據的消費,數據的流動……只不過是根據不同的需求,變化數據的形態和服務方式。計算機系的同學可能還記得老師說過的一句話:程序 = 算法 + 數據結構,我這里斗膽模仿一下這個句式:系統 = 業務邏輯 x 數據。可以說很多架構問題都是出在數據層,例如常見的「煙囪式系統」帶來的種種問題,特別是數據孤島問題,其實本質上的原因就出在沒有將數據層打通,如果不從數據架構去思考,就可能「頭疼醫頭、腳疼醫腳」,費了半天勁還是很別扭,反過來如果將數據層治理好,就像打通「任督二脈」一樣,起到四兩撥千斤的效果。但是理想通常很豐滿,現實卻很骨感。至少在我們五年前出來創業那會兒,我們覺得并沒有一個系統能夠很好的解決數據的問題??赡芎闷娴淖x者就要問了:不是有 Hadoop?還有 NoSQL?再不濟關系型數據庫也能分庫分表???其實列出的這幾個幾乎就是當年處理存儲問題的全部候選,這幾個方案的共同特點就是:不完美。具體一點來說,這幾個解決方案對于數據應用的場景覆蓋其實都不大,對于復雜一點的業務,可能需要同時使用 n 多個方案才能覆蓋完整。這就是為什么隨著近幾年互聯網業務越來越復雜,類似 Kafka 這樣的數據 Pipeline 越來越流行,從數據治理的角度其實很好理解:各種數據平臺各負責各的,為了做到場景的全覆蓋,必然需要在各個「島」之間修路呀。我們當年就在想,能不能有一個系統以一個統一的接口盡可能大的覆蓋到更多場景。我們需要一個 Single Source of Truth。數據應該是貫穿在應用邏輯各個角落,我理想中的系統中對于任意數據的存取都應該是可以不加限制的(先不考慮權限和安全,這是另一個問題),這里的“不加限制”是更廣義的,例如:沒有容量上限,只要有足夠的物理資源,系統可以無限的擴展;沒有訪問模型限制,我們可以自由的關聯、聚合數據;沒有一致性上的限制;運維幾乎不需要人工干預……

以分布式數據庫為統一中心的架構

我當年特別著迷于一個美?。篜erson of Interest (疑犯追蹤),這個電視劇里面有一個神一樣的人工智能 The Machine,收集一切數據加以分析,從而預測或是干預未來人們的行動。雖然這部美劇還是比較正統的行俠仗義之類的主題,但是更讓我著迷的是,是否我們能設計一個 The Machine?雖然直到目前我還不是一個 AI 專家,但是給 The Machine 設計一個數據庫似乎是可行的。這幾年創業過程中,我們發現更令人興奮的點在于:以分布式數據庫為統一中心的架構是可能的。這個怎么理解呢?舉個例子,就像在上面提到的分裂帶來的問題,數據層的割裂必然意味著業務層需要更高的復雜度去彌補,其實很多工程師其實偏向于用線性的思維去思考維護系統的成本。但是實際的經驗告訴我們,事情并不是這樣的。一個系統只有一個數據庫和有十個數據庫的復雜程度其實并不是的簡單的 10x,考慮到數據的流動,維護成本只可能是更多,這里還沒有考慮到異構帶來的其他問題。

以分布式數據庫為中心的架構是什么樣子的呢?很好理解,整個架構的中心是一個場景覆蓋度足夠廣,且具有無限的水平伸縮能力的存儲系統。大部分數據的流動被限制在這個數據庫內部,這樣應用層就可以幾乎做到無狀態,因為這個中心的數據庫負責了絕大部分狀態,每個應用可以通過自己的緩存來進行加速。

這里我想提醒的是,為什么我在上面強調水平擴展能力,是因為受限的擴展能力也是導致分裂的一個重要的原因。我們從來都沒有辦法準確的預測未來,我們很難想象甚至是一年后業務的變化(想想這次疫情),有句老話說的很好:唯一不變的就是變化。

另外一個經常被問到的問題,為什么要強調緩存層需要離業務層更近,或者說,為什么位于中心的這個巨型數據庫不應該承擔緩存的責任?我的理解是,只有業務更懂業務,知道應該以什么樣的策略緩存什么樣的數據,而且出于性能(低延遲)考慮,緩存離業務更近也是有道理的。

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

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

傳統的數據架構通常將 OLTP、OLAP、離線數倉分離,各個系統各司其職,中間通過獨立的 Pipeline 進行同步(有時候還會加上 ETL)。

下面是一個 HTAP 的系統的樣子:

雖然從表面上看,只是簡單的將接口層進行整合,但是這個意義其實是深遠的,首先數據同步的細節被隱藏了一起來,這意味著數據庫層面可以自己決定通過何種方式同步數據,另外由于 OLTP 引擎和 OLAP 引擎在同一個系統內部,使得很多細節信息不會在同步的過程中丟失,比如:事務信息,這就意味著在內部的分析引擎能夠做到傳統的 OLAP 沒辦法做的事情。另外對于業務層的使用來說,少一個系統意味著更統一的體驗和更小的學習和改造成本,不要低估統一帶來的力量。

未來在哪里?

上面這些是過去五年發生的事情,也幾乎按照我們創業時候的設想一步步的變為現實,那么接下來的五年會發什么?隨著對于行業和技術的理解的加深,至少有一點我深信不疑的是:

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

誰都不會否認,最近十年在 IT 技術上,最大的變革是由云帶來的,這場革命還在進行時。云的核心能力是什么?我認為是彈性。計算資源分配的粒度變得越來越細,就像從只能買房變成可以租房,甚至可以像住酒店一樣靈活。這意味著什么?本質在于我們可以不用為「想象中」的業務峰值提前支付成本。

過去我們的采購服務器也好,租賃機柜也好,都是需要設定一個提前量的,當業務峰值沒有到來之前,其實這些成本是已經提前支付的了。云的出現將彈性變成了基礎設施的一個基礎能力,我預計數據庫也會發生同樣的事情。

可能有很多朋友會有疑問,現在難道不是幾乎所有數據庫都號稱能夠支持透明水平擴展嘛?其實這里希望大家不要將「彈性調度」狹隘的理解為擴展性,而且這個詞的重點在「調度」上,我舉幾個例子以方便大家理解:

1. 數據庫能不能夠自動識別 workload,根據 workload 進行自動伸縮?例如:預感到峰值即將來臨,自動的采購機器,對熱數據創建更多副本并重分布數據,提前擴容。在業務高峰過去后,自動回收機器進行縮容。

2. 數據庫能不能感知業務特點,根據訪問特點決定分布?例如:如果數據帶有明顯的地理特征(比如,中國的用戶大概率在中國訪問,美國用戶在美國),系統將自動的將數據的地理特征在不同的數據中心放置。

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

這里提到的一切背后都依賴的是「彈性調度」能力。未來我相信物理資源的成本會持續的降低,計算資源的單價持續下降帶來的結果是:當存儲成本和計算資源變得不是問題的時候,問題就變成「如何高效的分配資源」。如果將高效分配作為目標的話,「能調度」就是顯而易見的基礎。

當然就像一切事物發展的客觀規律一樣,學會跑步之前,先要學會走路,我相信在接下來的一段時間內,我們會看到第一批初步擁有這樣能力的新型數據庫,讓我們拭目以待。

下一個階段是智能

對于更遠的未來是怎么樣子的?我不知道,但是就像 The Machine 一樣,只有足夠數據才能誕生出智能,我相信就像我們不了解宇宙和海洋一樣,我們現在對于數據的認識一定是膚淺的,甚至大量的數據我們都還沒記錄下來,一定有更大奧秘隱藏在這海量的數據中,從數據中能獲取什么樣的洞察,能夠怎么樣更好的改變我們的生活,我并不知道,但是做這件事情的主角我猜不會是人類。雖然在這個小節我們討論的東西可能就有點像科幻小說了,不過我愿意相信這樣的未來,從數據的海洋中誕生出新的智能體。

尾聲

創業這五年的時間,回頭看看那個最樸素的出發點:寫一個更好的數據庫徹底解決煩人的 MySQL 分庫分表問題。似乎也算沒有偏離初心,但是在這個旅途中一步步看到了更大的世界,也越來越有能力和信心將我們相信的東西變為現實:

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

我有一個夢想,未來我們對數據的處理將不再碎片化,任何業務系統都能夠方便的存儲和獲取數據;

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

最近我聽到一句話,我個人很喜歡:雄心的一半是耐心。構建一個完美的數據庫并不是一朝一夕的工作,但是我相信我們正走在正確的道路上。

凡所過往,皆為序章。

作者簡介:黃東旭,PingCAP 聯合創始人兼 CTO,資深基礎軟件工程師,架構師,曾就職于微軟亞洲研究院,網易有道及豌豆莢,擅長分布式系統以及數據庫開發,在分布式存儲領域有豐富的經驗和獨到的見解??駸岬拈_源愛好者以及開源軟件作者,代表作品分布式 Redis 緩存方案 Codis,以及分布式關系型數據庫 TiDB。2015 年創業,成立 PingCAP,在 PingCAP 的主要工作是從零開始設計并研發開源 NewSQL 數據庫 TiDB,目前 GitHub 上該項目累積 star 數超過 23000+,成為本領域全球頂級的開源項目。

老魚,企業級老編一枚,你若有故事,歡迎聯系!

位置數據:隱私和流行病

上一篇

我們熟知的NAND閃存,還有個“雙胞胎兄弟”

下一篇

你也可能喜歡

聊聊數據庫的未來,寫在 PingCAP 成立五周年之際

長按儲存圖像,分享給朋友

ITPUB 每周精要將以郵件的形式發放至您的郵箱


微信掃一掃

微信掃一掃
天津11选五开奖结果手 佳永配资 湖北快三开奖结果查询一定牛 体彩内部员工揭秘11选5 广东快乐10分彩票 上海时时乐开奖综合走势图 河南11选5开奖走势图 新群英会20选5任4技巧 山西快乐十分直播开奖 金龙策略配资 福建十一选五开奖号码