分布式數(shù)據(jù)庫(kù)是偽需求
當(dāng)前位置：點(diǎn)晴教程→知識(shí)管理交流
→『 技術(shù)文檔交流 』
隨著硬件技術(shù)的進(jìn)步，單機(jī)數(shù)據(jù)庫(kù)的容量和性能已達(dá)到了前所未有的高度。而分布式(TP)數(shù)據(jù)庫(kù)在這種變革面前極為無(wú)力，和“數(shù)據(jù)中臺(tái)”一樣穿著皇帝的新衣，處于自欺欺人的狀態(tài)里。太長(zhǎng)不看分布式數(shù)據(jù)庫(kù)的核心權(quán)衡是：“以質(zhì)換量”，犧牲功能、性能、復(fù)雜度、可靠性，換取更大的數(shù)據(jù)容量與請(qǐng)求吞吐量。但分久必合，硬件變革讓集中式數(shù)據(jù)庫(kù)的容量與吞吐達(dá)到一個(gè)全新高度，使分布式(TP)數(shù)據(jù)庫(kù)失去了存在意義。 以 NVMe SSD 為代表的硬件遵循摩爾定律以指數(shù)速度演進(jìn)，十年間性能翻了幾十倍，價(jià)格降了幾十倍，性?xún)r(jià)比提高了三個(gè)數(shù)量級(jí)。單卡 115 TB+， 4K隨機(jī)讀寫(xiě) IOPS 可達(dá) 3M IOPS，延時(shí) 50μs/9μs，價(jià)格不到 200 ￥/TB·年。跑 PostgreSQL 單機(jī)能有一兩百萬(wàn)的點(diǎn)寫(xiě)/點(diǎn)查 QPS。 真正需要分布式數(shù)據(jù)庫(kù)的場(chǎng)景屈指可數(shù)，典型的中型互聯(lián)網(wǎng)公司/銀行請(qǐng)求數(shù)量級(jí)在幾萬(wàn)到幾十萬(wàn)QPS，不重復(fù)TP數(shù)據(jù)在百TB上下量級(jí)。真實(shí)世界中 99.99 % 以上的場(chǎng)景用不上分布式數(shù)據(jù)庫(kù)，剩下1%也大概率可以通過(guò)經(jīng)典的水平/垂直拆分等工程手段解決。 頭部互聯(lián)網(wǎng)公司可能有極少數(shù)真正的適用場(chǎng)景，然而此類(lèi)公司沒(méi)有任何付費(fèi)意愿。市場(chǎng)根本無(wú)法養(yǎng)活如此之多的分布式數(shù)據(jù)庫(kù)內(nèi)核，能夠成活的產(chǎn)品靠的也不見(jiàn)得是分布式這個(gè)賣(mài)點(diǎn)。HATP 、分布式單機(jī)一體化是迷茫分布式TP數(shù)據(jù)庫(kù)廠商尋求轉(zhuǎn)型的掙扎，但離 PMF 仍有不小距離。 互聯(lián)網(wǎng)的牽引“分布式數(shù)據(jù)庫(kù)” 并不是一個(gè)嚴(yán)格定義的術(shù)語(yǔ)。狹義上它與 NewSQL：cockroachdb / yugabytesdb / tidb / oceanbase / TDSQL 等數(shù)據(jù)庫(kù)高度重合；廣義上 Oracle / PostgreSQL / MySQL / SQL Server / PolarDB / Aurora 這種跨多個(gè)物理節(jié)點(diǎn)，使用主從復(fù)制或者共享存儲(chǔ)的經(jīng)典數(shù)據(jù)庫(kù)也能歸入其中。在本文語(yǔ)境中，分布式數(shù)據(jù)庫(kù)指前者，且只涉及核心定位為事務(wù)處理型（OLTP）的分布式關(guān)系型數(shù)據(jù)庫(kù)。 分布式數(shù)據(jù)庫(kù)的興起源于互聯(lián)網(wǎng)應(yīng)用的快速發(fā)展和數(shù)據(jù)量的爆炸式增長(zhǎng)。在那個(gè)時(shí)代，傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)在面對(duì)海量數(shù)據(jù)和高并發(fā)訪問(wèn)時(shí)，往往會(huì)出現(xiàn)性能瓶頸和可伸縮性問(wèn)題。即使用 Oracle 與 Exadata，在面對(duì)海量 CRUD 時(shí)也有些無(wú)力，更別提每年以百千萬(wàn)計(jì)的高昂軟硬件費(fèi)用。 互聯(lián)網(wǎng)公司走上了另一條路，用諸如 MySQL 這樣免費(fèi)的開(kāi)源數(shù)據(jù)庫(kù)自建。老研發(fā)/DBA可能還會(huì)記得那條 MySQL 經(jīng)驗(yàn)規(guī)約：?jiǎn)伪碛涗洸灰^(guò) 2100萬(wàn)，否則性能會(huì)迅速劣化；與之對(duì)應(yīng)的是，數(shù)據(jù)庫(kù)分庫(kù)分表開(kāi)始成為大廠顯學(xué)。 這里的基本想法是“三個(gè)臭皮匠，頂個(gè)諸葛亮”，用一堆便宜的 x86 服務(wù)器 + 大量分庫(kù)分表開(kāi)源數(shù)據(jù)庫(kù)實(shí)例弄出一個(gè)海量 CRUD 簡(jiǎn)單數(shù)據(jù)存儲(chǔ)。故而，分布式數(shù)據(jù)庫(kù)往往誕生于互聯(lián)網(wǎng)公司的場(chǎng)景，并沿著手工分庫(kù)分表 → 分庫(kù)分表中間件 → 分布式數(shù)據(jù)庫(kù)這條路徑發(fā)展進(jìn)步。 作為一個(gè)行業(yè)解決方案，分布式數(shù)據(jù)庫(kù)成功滿(mǎn)足了互聯(lián)網(wǎng)公司的場(chǎng)景需求。但是如果想把它抽象沉淀成一個(gè)產(chǎn)品對(duì)外輸出，還需要想清楚幾個(gè)問(wèn)題： 十年前的利弊權(quán)衡，在今天是否依然成立？ 互聯(lián)網(wǎng)公司的場(chǎng)景，對(duì)其他行業(yè)是否適用？ 分布式事務(wù)數(shù)據(jù)庫(kù)，會(huì)不會(huì)是一個(gè)偽需求？ 分布式的權(quán)衡“分布式” 同 “HTAP”、 “存算分離”、“Serverless”、“湖倉(cāng)一體” 這樣的Buzzword一樣，對(duì)企業(yè)用戶(hù)來(lái)說(shuō)沒(méi)有意義。務(wù)實(shí)的甲方關(guān)注的是實(shí)打?qū)嵉膶傩耘c能力：功能性能、安全可靠、投入產(chǎn)出、成本效益。真正重要的是利弊權(quán)衡：分布式數(shù)據(jù)庫(kù)相比經(jīng)典集中式數(shù)據(jù)庫(kù)，犧牲了什么換取了什么？  分布式數(shù)據(jù)庫(kù)的核心Trade Off 可以概括為：“以質(zhì)換量”：犧牲功能、性能、復(fù)雜度、可靠性，換取更大的數(shù)據(jù)容量與請(qǐng)求吞吐量。 NewSQL 通常主打“分布式”的概念，通過(guò)“分布式”解決水平伸縮性問(wèn)題。在架構(gòu)上通常擁有多個(gè)對(duì)等數(shù)據(jù)節(jié)點(diǎn)以及協(xié)調(diào)者，使用分布式共識(shí)協(xié)議 Paxos/Raft 進(jìn)行復(fù)制，可以通過(guò)添加數(shù)據(jù)節(jié)點(diǎn)的方式進(jìn)行水平伸縮。 首先，分布式數(shù)據(jù)庫(kù)因其內(nèi)在局限性，會(huì)犧牲許多功能，只能提供較為簡(jiǎn)單有限的 CRUD 查詢(xún)支持。其次，分布式數(shù)據(jù)庫(kù)因?yàn)樾枰ㄟ^(guò)多次網(wǎng)絡(luò) RPC 完成請(qǐng)求，所以性能相比集中式數(shù)據(jù)庫(kù)通常有70%以上的折損。再者，分布式數(shù)據(jù)庫(kù)通常由DN/CN以及TSO等多個(gè)組件構(gòu)成，運(yùn)維管理復(fù)雜，引入大量非本質(zhì)復(fù)雜度。最后，分布式數(shù)據(jù)庫(kù)在高可用容災(zāi)方面相較于經(jīng)典集中式主從并沒(méi)有質(zhì)變，反而因?yàn)閺?fù)數(shù)組件引入大量額外失效點(diǎn)。  SYSBENCH吞吐對(duì)比[2] 在以前，分布式數(shù)據(jù)庫(kù)的利弊權(quán)衡是成立的：互聯(lián)網(wǎng)需要更大的數(shù)據(jù)存儲(chǔ)容量與更高的訪問(wèn)吞吐量：這個(gè)問(wèn)題是必須解決的，而這些缺點(diǎn)是可以克服的。但今日，硬件的發(fā)展廢問(wèn)了 量 的問(wèn)題，那么分布式數(shù)據(jù)庫(kù)的存在意義就連同著它想解決的問(wèn)題本身被一并抹除了。
 新硬件的沖擊摩爾定律指出，每18～24個(gè)月，處理器性能翻倍，成本減半。這個(gè)規(guī)律也基本適用于存儲(chǔ)。從2013年開(kāi)始到2023年是5～6個(gè)周期，性能和成本和10年前比應(yīng)該有幾十倍的差距，是不是這樣呢？ 讓我們看一下 2013 年典型 SSD 的性能指標(biāo)，并與 2023 當(dāng)下主流 PCI-e Gen4 NVMe SSD 的典型產(chǎn)品進(jìn)行對(duì)比。不難發(fā)現(xiàn)：硬盤(pán)4K隨機(jī)讀寫(xiě) IOPS從 60K/40K 到了 1600K/600K，價(jià)格從 2220$/TB 到 40$/TB 。性能翻了 15 ～ 26 倍，價(jià)格便宜了 56 倍。
 十年前，機(jī)械硬盤(pán)還是絕對(duì)主流。1TB 的硬盤(pán)價(jià)格大概七八百元，64GB 的SSD 還要再貴點(diǎn)。十年后，主流 3.2TB 的企業(yè)級(jí) NVMe SSD 也不過(guò)三千塊錢(qián)。按五年質(zhì)保折算，1TB每月成本只要 16塊錢(qián)，每年成本不到 200塊。作為參考，云廠商號(hào)稱(chēng)物美價(jià)廉的 S3對(duì)象存儲(chǔ)都要 1800￥/TB·年。  典型的第五代本地 NVMe 磁盤(pán)單卡最大容量可達(dá) 32TB～ 64TB，提供 70μs/10μs 4K隨機(jī)讀/寫(xiě)延遲，2500K/600K 的讀寫(xiě)IOPS，第五代更是有著單卡十幾GB/s 的驚人帶寬。 這樣的卡配上一臺(tái)經(jīng)典 Dell 64C / 512G 服務(wù)器，IDC代維5年折舊，總共十萬(wàn)塊不到。而這樣一臺(tái)服務(wù)器跑 PostgreSQL 或者 MySQL ，sysbench 單機(jī)點(diǎn)寫(xiě)入可以接近百萬(wàn)QPS，點(diǎn)查詢(xún)干到兩百萬(wàn) QPS 不成問(wèn)題。
這是什么概念呢？對(duì)于一個(gè)典型的中型互聯(lián)網(wǎng)公司/銀行，數(shù)據(jù)庫(kù)請(qǐng)求數(shù)量級(jí)通常在幾萬(wàn)/幾十萬(wàn) QPS這個(gè)范圍；不重復(fù)的TP數(shù)據(jù)量級(jí)在百TB上下浮動(dòng)。考慮到使用硬件存儲(chǔ)壓縮卡還能有個(gè)幾倍壓縮比，這類(lèi)場(chǎng)景在現(xiàn)代硬件條件下，有可能集中式數(shù)據(jù)庫(kù)單機(jī)單卡就直接搞定了[6]。Cursor從分布式 Yugabyte換到單機(jī)PG RDS，就是一個(gè)非常有代表性的例子。 在以前，用戶(hù)可能需要先砸個(gè)幾百萬(wàn)搞 exadata 高端存儲(chǔ)，再花天價(jià)購(gòu)買(mǎi) Oracle 商業(yè)數(shù)據(jù)庫(kù)授權(quán)與原廠服務(wù)。而現(xiàn)在做到這些，硬件上只需一塊幾千塊的企業(yè)級(jí) SSD 卡即可起步；像 PostgreSQL 這樣的開(kāi)源 Oracle 替代，最大單表32TB照樣跑得飛快，不再有當(dāng)年MySQL非要分表不可的桎梏。原本高性能的數(shù)據(jù)庫(kù)服務(wù)從情報(bào)/銀行領(lǐng)域的奢侈品，變成各行各業(yè)都能輕松負(fù)擔(dān)得起的平價(jià)服務(wù)[7]。 性?xún)r(jià)比是第一產(chǎn)品力，高性能大容量的存儲(chǔ)在十年間性?xún)r(jià)比提高了三個(gè)數(shù)量級(jí)，分布式數(shù)據(jù)庫(kù)曾經(jīng)的價(jià)值亮點(diǎn)，在這種大力出奇跡的硬件變革下顯得軟弱無(wú)力。 偽需求的困境在當(dāng)下，犧牲功能性能復(fù)雜度換取伸縮性有極大概率是偽需求。 在現(xiàn)代硬件的加持下，真實(shí)世界中 99%+ 的場(chǎng)景超不出單機(jī)集中式數(shù)據(jù)庫(kù)的支持范圍，剩下1%也大概率可以通過(guò)經(jīng)典的水平/垂直拆分等工程手段解決。這一點(diǎn)對(duì)于互聯(lián)網(wǎng)公司也能成立：即使是全球頭部大廠，不可拆分的TP單表超過(guò)幾十TB的場(chǎng)景依然罕見(jiàn)。 NewSQL的祖師爺 Google Spanner 是為了解決海量數(shù)據(jù)伸縮性的問(wèn)題，但又有多少企業(yè)能有Google的業(yè)務(wù)數(shù)據(jù)量？從數(shù)據(jù)量上來(lái)講，絕大多數(shù)企業(yè)終其生命周期的TP數(shù)據(jù)量，都超不過(guò)集中式數(shù)據(jù)庫(kù)的單機(jī)瓶頸，而且這個(gè)瓶頸仍然在以摩爾定律的速度指數(shù)增長(zhǎng)中。從請(qǐng)求吞吐量上來(lái)講，很多企業(yè)的數(shù)據(jù)庫(kù)性能余量足夠讓他們把業(yè)務(wù)邏輯全部用存儲(chǔ)過(guò)程實(shí)現(xiàn)并絲滑地跑在數(shù)據(jù)庫(kù)中。 “過(guò)早優(yōu)化是萬(wàn)惡之源”，為了不需要的規(guī)模去設(shè)計(jì)是白費(fèi)功夫。如果量不再成為問(wèn)題，那么為了不需要的量去犧牲其他屬性就成了一件毫無(wú)意義的事情。  在數(shù)據(jù)庫(kù)的許多細(xì)分領(lǐng)域中，分布式并不是偽需求：如果你需要一個(gè)高度可靠容災(zāi)的簡(jiǎn)單低頻 KV 存儲(chǔ)元數(shù)據(jù)，那么分布式的 etcd 就是合適的選擇；如果你需要一張全球地理分布的表可以在各地任意讀寫(xiě)，并愿意承受巨大的性能衰減作為代價(jià)，那么分布式的 YugabyteDB 也許是一個(gè)不錯(cuò)的選擇。如果你需要進(jìn)行信息公示并防止篡改與抵賴(lài)，區(qū)塊鏈在本質(zhì)上也是一種 Leaderless 的分布式賬本數(shù)據(jù)庫(kù)； 對(duì)于大規(guī)模數(shù)據(jù)分析OLAP來(lái)說(shuō)，分布式可以說(shuō)是必不可少（不過(guò)這種一般稱(chēng)為數(shù)據(jù)倉(cāng)庫(kù)，MPP）；但是在事務(wù)處理OLTP領(lǐng)域，分布式可以說(shuō)是大可不必：OTLP數(shù)據(jù)庫(kù)屬于工作性記憶，而工作記憶的特點(diǎn)就是小、快、功能豐富。即使是非常龐大的業(yè)務(wù)系統(tǒng)，同一時(shí)刻活躍的工作集也不會(huì)特別大。OLTP 系統(tǒng)設(shè)計(jì)的一個(gè)基本經(jīng)驗(yàn)法則就是：如果你的問(wèn)題規(guī)?？梢栽趩螜C(jī)內(nèi)解決，就不要去折騰分布式數(shù)據(jù)庫(kù)。
OLTP 數(shù)據(jù)庫(kù)已經(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ù)庫(kù)自動(dòng)分庫(kù)分表再加個(gè)全局事務(wù)這種“分布式”，那一定是沒(méi)有出路的。如果真能有“分布式”數(shù)據(jù)庫(kù)殺出一條血路，那大概率也不是因?yàn)椤胺植际健边@個(gè)“偽需求”，而應(yīng)當(dāng)歸功于新功能、開(kāi)源生態(tài)、兼容性、易用性、國(guó)產(chǎn)信創(chuàng)、自主可控這些因素。 迷茫下的掙扎分布式數(shù)據(jù)庫(kù)最大的挑戰(zhàn)來(lái)自于市場(chǎng)結(jié)構(gòu)：最有可能會(huì)使用分布式TP數(shù)據(jù)庫(kù)的互聯(lián)網(wǎng)公司，反而是最不可能為此付費(fèi)的一個(gè)群體。互聯(lián)網(wǎng)公司可以作為很好的高質(zhì)量用戶(hù)甚至貢獻(xiàn)者，提供案例、反饋與PR，但唯獨(dú)在為軟件掏錢(qián)買(mǎi)單這件事上與其模因本能相抵觸。即使頭部分布式數(shù)據(jù)庫(kù)廠商，也面臨著叫好不叫座的難題。 近日與某分布式數(shù)據(jù)庫(kù)廠工程師閑聊時(shí)獲悉，在客戶(hù)那兒做 POC 時(shí)，Oracle 10秒跑完的查詢(xún)，他們的分布式數(shù)據(jù)庫(kù)用上各種資源和 Dirty Hack 都有一個(gè)數(shù)量級(jí)上的差距。即使是從10年前 PostgreSQL 9.2 分叉出來(lái)的 openGauss，都能在一些場(chǎng)景下干翻不少分布式數(shù)據(jù)庫(kù)，更別提 12 年后的 PostgreSQL 17 與 Oracle 23c 了。這種差距甚至?xí)屧瓘S都感到迷茫，分布式數(shù)據(jù)庫(kù)的出路在哪里？
所以一些分布式數(shù)據(jù)庫(kù)開(kāi)始自救轉(zhuǎn)型， HTAP 是一個(gè)典型例子：分布式搞事務(wù)雞肋，但是做分析很好呀。那么為什么不能捏在一起湊一湊？一套系統(tǒng)，同時(shí)可以做事務(wù)處理與分析喲！但真實(shí)世界的工程師都明白：AP系統(tǒng)和TP系統(tǒng)各有各的模式，強(qiáng)行把兩個(gè)需求南轅北轍的系統(tǒng)硬捏合在一塊，只會(huì)讓兩件事都難以成功。 不論是使用經(jīng)典 ETL/CDC 推拉到專(zhuān)用 ClickHouse/Greenplum/Doris 去處理，還是邏輯復(fù)制到In-Mem列存的專(zhuān)用從庫(kù)，哪一種都要比用一個(gè)奇美拉雜交HTAP數(shù)據(jù)庫(kù)要更靠譜。甚至現(xiàn)在連分析都不一定非要分布式不可：一個(gè)最典的例子莫過(guò)于： TiDB 官網(wǎng)的 92C 478G 服務(wù)器跑 TPC-H 50 倉(cāng)結(jié)果，跟DuckDB 單機(jī)用一臺(tái) Mac 8C 64G 跑 300 倉(cāng)結(jié)果的耗時(shí)基本相同。?  另一種思路是單機(jī)分布式一體化：打不過(guò)就加入：添加一個(gè)單機(jī)模式以規(guī)避代價(jià)高昂的網(wǎng)絡(luò)RPC開(kāi)銷(xiāo)，起碼在那些用不上分布式的99%場(chǎng)景中，不至于在硬指標(biāo)上被集中式數(shù)據(jù)庫(kù)碾壓得一塌糊涂 —— 用不上分布式?jīng)]關(guān)系，先拽上車(chē)別被其他人截胡！ 目前 Oceanbase 是這樣做的。但這里的問(wèn)題本質(zhì)與 HTAP 是一樣的：強(qiáng)行整合異質(zhì)數(shù)據(jù)系統(tǒng)沒(méi)有意義，如果這樣做有價(jià)值，那么為什么沒(méi)人去把所有異構(gòu)數(shù)據(jù)庫(kù)整合一個(gè)什么都能做的巨無(wú)霸二進(jìn)制 —— 數(shù)據(jù)庫(kù)全能王？因?yàn)檫@樣違背了KISS原則：Keep It Simple, Stupid！  分布式數(shù)據(jù)庫(kù)和數(shù)據(jù)中臺(tái)的處境類(lèi)似[8]：起源于互聯(lián)網(wǎng)大廠內(nèi)部的場(chǎng)景，也解決過(guò)領(lǐng)域特定的問(wèn)題。曾幾何時(shí)乘著互聯(lián)網(wǎng)行業(yè)的東風(fēng)，數(shù)據(jù)庫(kù)言必談分布式，火熱風(fēng)光好不得意。卻因?yàn)檫^(guò)度的包裝吹捧，承諾了太多不切實(shí)際的東西，又無(wú)法達(dá)到用戶(hù)預(yù)期 —— 最終一地雞毛，成為皇帝的新衣。 TP數(shù)據(jù)庫(kù)領(lǐng)域還有很多地方值得投入精力：Leveraging new hardwares，積極擁抱 CXL，RDMA，NVMe 等底層體系結(jié)構(gòu)變革；或者提供簡(jiǎn)單易用的聲明式接口，讓數(shù)據(jù)庫(kù)的使用與管理更加便利；提供更為智能的自動(dòng)駕駛監(jiān)控管控，盡可能消除運(yùn)維性的雜活兒；使用擴(kuò)展加強(qiáng)現(xiàn)有數(shù)據(jù)庫(kù)內(nèi)核的能力，或者開(kāi)發(fā)類(lèi)似 Babelfish 的 MySQL / Oracle 兼容插件，實(shí)現(xiàn)關(guān)系數(shù)據(jù)庫(kù) WireProtocol 統(tǒng)一。哪怕砸錢(qián)堆人提供更好的支持服務(wù)，都比一個(gè) “分布式” 的偽需求噱頭要更有意義。 因時(shí)而動(dòng)，君子不器。愿分布式數(shù)據(jù)庫(kù)廠商們找到自己的 PMF，做一些用戶(hù)真正需要的東西。 References
閱讀原文：https://mp.weixin.qq.com/s/FNhTCZk-SBVQkYhQ3zi_-g 該文章在 2025/4/22 18:17:23 編輯過(guò) |
關(guān)鍵字查詢(xún)
相關(guān)文章
正在查詢(xún)... 
|
400 186 1886
?
