太長不看

分布式數(shù)據(jù)庫的核心權(quán)衡是：“以質(zhì)換量”，犧牲功能、性能、復(fù)雜度、可靠性，換取更大的數(shù)據(jù)容量與請求吞吐量。但分久必合，硬件變革讓集中式數(shù)據(jù)庫的容量與吞吐達(dá)到一個(gè)全新高度，使分布式(TP)數(shù)據(jù)庫失去了存在意義。

以 NVMe SSD 為代表的硬件遵循摩爾定律以指數(shù)速度演進(jìn)，十年間性能翻了幾十倍，價(jià)格降了幾十倍，性價(jià)比提高了三個(gè)數(shù)量級。單卡 32TB+， 4K隨機(jī)讀寫 IOPS 可達(dá) 1600K/600K，延時(shí) 70μs/10μs，價(jià)格不到 200 ￥/TB·年。跑集中式數(shù)據(jù)庫單機(jī)能有一兩百萬的點(diǎn)寫/點(diǎn)查 QPS。

真正需要分布式數(shù)據(jù)庫的場景屈指可數(shù)，典型的中型互聯(lián)網(wǎng)公司/銀行請求數(shù)量級在幾萬到幾十萬QPS，不重復(fù)TP數(shù)據(jù)在百TB上下量級。真實(shí)世界中 99% 以上的場景用不上分布式數(shù)據(jù)庫，剩下1%也大概率可以通過經(jīng)典的水平/垂直拆分等工程手段解決。

頭部互聯(lián)網(wǎng)公司可能有極少數(shù)真正的適用場景，然而此類公司沒有任何付費(fèi)意愿。市場根本無法養(yǎng)活如此之多的分布式數(shù)據(jù)庫內(nèi)核，能夠成活的產(chǎn)品靠的也不見得是分布式這個(gè)賣點(diǎn)。HATP 、分布式單機(jī)一體化是迷茫分布式TP數(shù)據(jù)庫廠商尋求轉(zhuǎn)型的掙扎，但離 PMF 仍有不小距離。

互聯(lián)網(wǎng)的牽引

“分布式數(shù)據(jù)庫” 并不是一個(gè)嚴(yán)格定義的術(shù)語。狹義上它與 NewSQL：cockroachdb / yugabytesdb / tidb / oceanbase / TDSQL 等數(shù)據(jù)庫高度重合；廣義上 Oracle / PostgreSQL / MySQL / SQL Server / PolarDB / Aurora 這種跨多個(gè)物理節(jié)點(diǎn)，使用主從復(fù)制或者共享存儲的經(jīng)典數(shù)據(jù)庫也能歸入其中。在本文語境中，分布式數(shù)據(jù)庫指前者，且只涉及核心定位為事務(wù)處理型（OLTP）的分布式關(guān)系型數(shù)據(jù)庫。

分布式數(shù)據(jù)庫的興起源于互聯(lián)網(wǎng)應(yīng)用的快速發(fā)展和數(shù)據(jù)量的爆炸式增長。在那個(gè)時(shí)代，傳統(tǒng)的關(guān)系型數(shù)據(jù)庫在面對海量數(shù)據(jù)和高并發(fā)訪問時(shí)，往往會出現(xiàn)性能瓶頸和可伸縮性問題。即使用 Oracle 與 Exadata，在面對海量 CRUD 時(shí)也有些無力，更別提每年以百千萬計(jì)的高昂軟硬件費(fèi)用。

互聯(lián)網(wǎng)公司走上了另一條路，用諸如 MySQL 這樣免費(fèi)的開源數(shù)據(jù)庫自建。老研發(fā)/DBA可能還會記得那條 MySQL 經(jīng)驗(yàn)規(guī)約：單表記錄不要超過 2100萬，否則性能會迅速劣化；與之對應(yīng)的是，數(shù)據(jù)庫分庫分表開始成為大廠顯學(xué)。

這里的基本想法是“三個(gè)臭皮匠，頂個(gè)諸葛亮”，用一堆便宜的 x86 服務(wù)器 + 大量分庫分表開源數(shù)據(jù)庫實(shí)例弄出一個(gè)海量 CRUD 簡單數(shù)據(jù)存儲。故而，分布式數(shù)據(jù)庫往往誕生于互聯(lián)網(wǎng)公司的場景，并沿著手工分庫分表 → 分庫分表中間件 → 分布式數(shù)據(jù)庫這條路徑發(fā)展進(jìn)步。

作為一個(gè)行業(yè)解決方案，分布式數(shù)據(jù)庫成功滿足了互聯(lián)網(wǎng)公司的場景需求。但是如果想把它抽象沉淀成一個(gè)產(chǎn)品對外輸出，還需要想清楚幾個(gè)問題：

十年前的利弊權(quán)衡，在今天是否依然成立？

互聯(lián)網(wǎng)公司的場景，對其他行業(yè)是否適用？

分布式事務(wù)數(shù)據(jù)庫，會不會是一個(gè)偽需求？

分布式的權(quán)衡

“分布式” 同 “HTAP”、 “存算分離”、“Serverless”、“湖倉一體” 這樣的Buzzword一樣，對企業(yè)用戶來說沒有意義。務(wù)實(shí)的甲方關(guān)注的是實(shí)打?qū)嵉膶傩耘c能力：功能性能、安全可靠、投入產(chǎn)出、成本效益。真正重要的是利弊權(quán)衡：分布式數(shù)據(jù)庫相比經(jīng)典集中式數(shù)據(jù)庫，犧牲了什么換取了什么？

數(shù)據(jù)庫需求層次金字塔[1]

分布式數(shù)據(jù)庫的核心Trade Off 可以概括為：“以質(zhì)換量”：犧牲功能、性能、復(fù)雜度、可靠性，換取更大的數(shù)據(jù)容量與請求吞吐量。

NewSQL 通常主打“分布式”的概念，通過“分布式”解決水平伸縮性問題。在架構(gòu)上通常擁有多個(gè)對等數(shù)據(jù)節(jié)點(diǎn)以及協(xié)調(diào)者，使用分布式共識協(xié)議 Paxos/Raft 進(jìn)行復(fù)制，可以通過添加數(shù)據(jù)節(jié)點(diǎn)的方式進(jìn)行水平伸縮。

首先，分布式數(shù)據(jù)庫因其內(nèi)在局限性，會犧牲許多功能，只能提供較為簡單有限的 CRUD 查詢支持。其次，分布式數(shù)據(jù)庫因?yàn)樾枰ㄟ^多次網(wǎng)絡(luò) RPC 完成請求，所以性能相比集中式數(shù)據(jù)庫通常有70%以上的折損。再者，分布式數(shù)據(jù)庫通常由DN/CN以及TSO等多個(gè)組件構(gòu)成，運(yùn)維管理復(fù)雜，引入大量非本質(zhì)復(fù)雜度。最后，分布式數(shù)據(jù)庫在高可用容災(zāi)方面相較于經(jīng)典集中式主從并沒有質(zhì)變，反而因?yàn)閺?fù)數(shù)組件引入大量額外失效點(diǎn)。

SYSBENCH吞吐對比[2]

在以前，分布式數(shù)據(jù)庫的利弊權(quán)衡是成立的：互聯(lián)網(wǎng)需要更大的數(shù)據(jù)存儲容量與更高的訪問吞吐量：這個(gè)問題是必須解決的，而這些缺點(diǎn)是可以克服的。但今日，硬件的發(fā)展廢問了 量 的問題，那么分布式數(shù)據(jù)庫的存在意義就連同著它想解決的問題本身被一并抹除了。

新硬件的沖擊

摩爾定律指出，每18～24個(gè)月，處理器性能翻倍，成本減半。這個(gè)規(guī)律也基本適用于存儲。從2013年開始到2023年是5～6個(gè)周期，性能和成本和10年前比應(yīng)該有幾十倍的差距，是不是這樣呢？

讓我們看一下 2013 年典型 SSD 的性能指標(biāo)，并與 2022 年 PCI-e Gen4 NVMe SSD 的典型產(chǎn)品進(jìn)行對比。不難發(fā)現(xiàn)：硬盤4K隨機(jī)讀寫 IOPS從 60K/40K 到了 1600K/600K，價(jià)格從 2220$/TB 40$/TB 。性能翻了15 ～ 26倍，價(jià)格便宜了56 倍[3,4,5]，作為經(jīng)驗(yàn)法則在數(shù)量級上肯定是成立了。

十年前，機(jī)械硬盤還是絕對主流。1TB 的硬盤價(jià)格大概七八百元，64GB 的SSD 還要再貴點(diǎn)。十年后，主流 3.2TB 的企業(yè)級 NVMe SSD 也不過三千塊錢。按五年質(zhì)保折算，1TB每月成本只要 16塊錢，每年成本不到 200塊。作為參考，云廠商號稱物美價(jià)廉的 S3對象存儲都要 1800￥/TB·年。

典型的第四代本地 NVMe 磁盤單卡最大容量可達(dá) 32TB～ 64TB，提供 70μs/10μs 4K隨機(jī)讀/寫延遲，1600K/600K 的讀寫IOPS，第五代更是有著單卡十幾GB/s 的驚人帶寬。

這樣的卡配上一臺經(jīng)典 Dell 64C / 512G 服務(wù)器，IDC代維5年折舊，總共十萬塊不到。而這樣一臺服務(wù)器跑 PostgreSQL 或者 MySQL ，sysbench 單機(jī)點(diǎn)寫入可以接近百萬QPS，點(diǎn)查詢干到兩百萬 QPS 不成問題。

這是什么概念呢？對于一個(gè)典型的中型互聯(lián)網(wǎng)公司/銀行，數(shù)據(jù)庫請求數(shù)量級通常在幾萬/幾十萬 QPS這個(gè)范圍；不重復(fù)的TP數(shù)據(jù)量級在百TB上下浮動?？紤]到使用硬件存儲壓縮卡還能有個(gè)幾倍壓縮比，這類場景在現(xiàn)代硬件條件下，有可能集中式數(shù)據(jù)庫單機(jī)單卡就直接搞定了[6]。

在以前，用戶可能需要先砸個(gè)幾百萬搞 exadata 高端存儲，再花天價(jià)購買 Oracle 商業(yè)數(shù)據(jù)庫授權(quán)與原廠服務(wù)。而現(xiàn)在做到這些，硬件上只需一塊幾千塊的企業(yè)級 SSD 卡即可起步；像 PostgreSQL 這樣的開源 Oracle 替代，最大單表32TB照樣跑得飛快，不再有當(dāng)年MySQL非要分表不可的桎梏。原本高性能的數(shù)據(jù)庫服務(wù)從情報(bào)/銀行領(lǐng)域的奢侈品，變成各行各業(yè)都能輕松負(fù)擔(dān)得起的平價(jià)服務(wù)[7]。

性價(jià)比是第一產(chǎn)品力，高性能大容量的存儲在十年間性價(jià)比提高了三個(gè)數(shù)量級，分布式數(shù)據(jù)庫曾經(jīng)的價(jià)值亮點(diǎn)，在這種大力出奇跡的硬件變革下顯得軟弱無力。

偽需求的困境

在當(dāng)下，犧牲功能性能復(fù)雜度換取伸縮性有極大概率是偽需求。

在現(xiàn)代硬件的加持下，真實(shí)世界中  99%+ 的場景超不出單機(jī)集中式數(shù)據(jù)庫的支持范圍，剩下1%也大概率可以通過經(jīng)典的水平/垂直拆分等工程手段解決。這一點(diǎn)對于互聯(lián)網(wǎng)公司也能成立：即使是全球頭部大廠，不可拆分的TP單表超過幾十TB的場景依然罕見。

NewSQL的祖師爺 Google Spanner 是為了解決海量數(shù)據(jù)伸縮性的問題，但又有多少企業(yè)能有Google的業(yè)務(wù)數(shù)據(jù)量？從數(shù)據(jù)量上來講，絕大多數(shù)企業(yè)終其生命周期的TP數(shù)據(jù)量，都超不過集中式數(shù)據(jù)庫的單機(jī)瓶頸，而且這個(gè)瓶頸仍然在以摩爾定律的速度指數(shù)增長中。從請求吞吐量上來講，很多企業(yè)的數(shù)據(jù)庫性能余量足夠讓他們把業(yè)務(wù)邏輯全部用存儲過程實(shí)現(xiàn)并絲滑地跑在數(shù)據(jù)庫中。

“過早優(yōu)化是萬惡之源”，為了不需要的規(guī)模去設(shè)計(jì)是白費(fèi)功夫。如果量不再成為問題，那么為了不需要的量去犧牲其他屬性就成了一件毫無意義的事情。

在數(shù)據(jù)庫的許多細(xì)分領(lǐng)域中，分布式并不是偽需求：如果你需要一個(gè)高度可靠容災(zāi)的簡單低頻 KV 存儲元數(shù)據(jù)，那么分布式的 etcd 就是合適的選擇；如果你需要一張全球地理分布的表可以在各地任意讀寫，并愿意承受巨大的性能衰減作為代價(jià)，那么分布式的 YugabyteDB 也許是一個(gè)不錯(cuò)的選擇。如果你需要進(jìn)行信息公示并防止篡改與抵賴，區(qū)塊鏈在本質(zhì)上也是一種 Leaderless 的分布式賬本數(shù)據(jù)庫；

對于大規(guī)模數(shù)據(jù)分析OLAP來說，分布式可以說是必不可少（不過這種一般稱為數(shù)據(jù)倉庫，MPP）；但是在事務(wù)處理OLTP領(lǐng)域，分布式可以說是大可不必：OTLP數(shù)據(jù)庫屬于工作性記憶，而工作記憶的特點(diǎn)就是小、快、功能豐富。即使是非常龐大的業(yè)務(wù)系統(tǒng)，同一時(shí)刻活躍的工作集也不會特別大。OLTP 系統(tǒng)設(shè)計(jì)的一個(gè)基本經(jīng)驗(yàn)法則就是：如果你的問題規(guī)模可以在單機(jī)內(nèi)解決，就不要去折騰分布式數(shù)據(jù)庫。

OLTP 數(shù)據(jù)庫已經(jīng)有幾十年的歷史，現(xiàn)有內(nèi)核已經(jīng)發(fā)展到了相當(dāng)成熟的地步。TP 領(lǐng)域標(biāo)準(zhǔn)正在逐漸收斂至 PostgreSQL，MySQL，Oracle 三種 Wire Protocol 。如果只是折騰數(shù)據(jù)庫自動分庫分表再加個(gè)全局事務(wù)這種“分布式”，那一定是沒有出路的。如果真能有“分布式”數(shù)據(jù)庫殺出一條血路，那大概率也不是因?yàn)椤胺植际健边@個(gè)“偽需求”，而應(yīng)當(dāng)歸功于新功能、開源生態(tài)、兼容性、易用性、國產(chǎn)信創(chuàng)、自主可控這些因素。

迷茫下的掙扎

分布式數(shù)據(jù)庫最大的挑戰(zhàn)來自于市場結(jié)構(gòu)：最有可能會使用分布式TP數(shù)據(jù)庫的互聯(lián)網(wǎng)公司，反而是最不可能為此付費(fèi)的一個(gè)群體。互聯(lián)網(wǎng)公司可以作為很好的高質(zhì)量用戶甚至貢獻(xiàn)者，提供案例、反饋與PR，但唯獨(dú)在為軟件掏錢買單這件事上與其模因本能相抵觸。即使頭部分布式數(shù)據(jù)庫廠商，也面臨著叫好不叫座的難題。

近日與某分布式數(shù)據(jù)庫廠工程師閑聊時(shí)獲悉，在客戶那兒做 POC 時(shí)，Oracle 10秒跑完的查詢，他們的分布式數(shù)據(jù)庫用上各種資源和 Dirty Hack 都有一個(gè)數(shù)量級上的差距。即使是從10年前 PostgreSQL 9.2 分叉出來的 openGauss，都能在一些場景下干翻不少分布式數(shù)據(jù)庫，更別提10年后的 PostgreSQL 15 與 Oracle 23c 了。這種差距甚至?xí)屧瓘S都感到迷茫，分布式數(shù)據(jù)庫的出路在哪里？

所以一些分布式數(shù)據(jù)庫開始自救轉(zhuǎn)型， HTAP 是一個(gè)典型例子：分布式搞事務(wù)雞肋，但是做分析很好呀。那么為什么不能捏在一起湊一湊？一套系統(tǒng)，同時(shí)可以做事務(wù)處理與分析喲！但真實(shí)世界的工程師都明白：AP系統(tǒng)和TP系統(tǒng)各有各的模式，強(qiáng)行把兩個(gè)需求南轅北轍的系統(tǒng)硬捏合在一塊，只會讓兩件事都難以成功。不論是使用經(jīng)典 ETL/CDC 推拉到專用 ClickHouse/Greenplum/Doris 去處理，還是邏輯復(fù)制到In-Mem列存的專用從庫，哪一種都要比用一個(gè)奇美拉雜交HTAP數(shù)據(jù)庫要更靠譜。

另一種思路是單機(jī)分布式一體化：打不過就加入：添加一個(gè)單機(jī)模式以規(guī)避代價(jià)高昂的網(wǎng)絡(luò)RPC開銷，起碼在那些用不上分布式的99%場景中，不至于在硬指標(biāo)上被集中式數(shù)據(jù)庫碾壓得一塌糊涂 —— 用不上分布式?jīng)]關(guān)系，先拽上車別被其他人截胡！但這里的問題本質(zhì)與 HTAP 是一樣的：強(qiáng)行整合異質(zhì)數(shù)據(jù)系統(tǒng)沒有意義，如果這樣做有價(jià)值，那么為什么沒人去把所有異構(gòu)數(shù)據(jù)庫整合一個(gè)什么都能做的巨無霸二進(jìn)制 —— 數(shù)據(jù)庫全能王？因?yàn)檫@樣違背了KISS原則：Keep It Simple, Stupid！

分布式數(shù)據(jù)庫和數(shù)據(jù)中臺的處境類似[8]：起源于互聯(lián)網(wǎng)大廠內(nèi)部的場景，也解決過領(lǐng)域特定的問題。曾幾何時(shí)乘著互聯(lián)網(wǎng)行業(yè)的東風(fēng)，數(shù)據(jù)庫言必談分布式，火熱風(fēng)光好不得意。卻因?yàn)檫^度的包裝吹捧，承諾了太多不切實(shí)際的東西，又無法達(dá)到用戶預(yù)期 —— 最終一地雞毛，成為皇帝的新衣。

TP數(shù)據(jù)庫領(lǐng)域還有很多地方值得投入精力：Leveraging new hardwares，積極擁抱 CXL，RDMA，NVMe 等底層體系結(jié)構(gòu)變革；或者提供簡單易用的聲明式接口，讓數(shù)據(jù)庫的使用與管理更加便利；提供更為智能的自動駕駛監(jiān)控管控，盡可能消除運(yùn)維性的雜活兒；開發(fā)類似 Babelfish 的 MySQL / Oracle 兼容插件，實(shí)現(xiàn)關(guān)系數(shù)據(jù)庫 WireProtocol 統(tǒng)一。哪怕砸錢堆人提供更好的支持服務(wù)，都比一個(gè) “分布式” 的偽需求噱頭要更有意義。

因時(shí)而動，君子不器。愿分布式數(shù)據(jù)庫廠商們找到自己的 PMF，做一些用戶真正需要的東西。

References

[1] 數(shù)據(jù)庫需求層次金字塔 : https://mp.weixin.qq.com/s/1xR92Z67kvvj2_NpUMie1Q

[2] PostgreSQL到底有多強(qiáng)？ : https://mp.weixin.qq.com/s/651zXDKGwFy8i0Owrmm-Xg

[3] 2013年SSD性能 : https://www.snia.org/sites/default/files/SNIASSSI.SSDPerformance-APrimer2013.pdf

[4] 2022年鎂光9400 NVMe SSD 規(guī)格說明 : https://media-www.micron.com/-/media/client/global/documents/products/product-flyer/9400_nvme_ssd_product_brief.pdf

[5] 2013-2030 SSD價(jià)格走勢與預(yù)測 : https://blocksandfiles.com/2021/01/25/wikibon-ssds-vs-hard-drives-wrights-law/

[6] 單實(shí)例100TB使用壓縮卡到20TB: https://mp.weixin.qq.com/s/JSQPzep09rDYbM-x5ptsZA

[7] 公有云是不是殺豬盤？: https://mp.weixin.qq.com/s/UxjiUBTpb1pRUfGtR9V3ag

[8] 中臺：一場徹頭徹尾的自欺欺人: https://mp.weixin.qq.com/s/VgTU7NcOwmrX-nbrBBeH_w