分散式資料庫的需求與場景

在資料庫選型中，分散式資料庫與集中式資料庫之爭一直是爭論熱點。一個系統到底用集中式資料庫還是分散式資料庫，是資料庫使用者和DBA最為關注的問題。有些朋友直截了當的說“分散式資料庫是個偽需求”，也有人說“分散式資料庫太浪費，用集中式資料庫就夠用了”。我以前也在文章中說過，某些場景其實並不一定需要分散式資料庫。

偽需求是一種對於系統執行來說不是必需的需求，而是一種基於偏好的假設。確實在實際的資料庫應用中存在這種基於偏好的不必要的選擇，不過分散式資料庫是不是偽需求這個問題，其實還是十分複雜的。

隨著現代硬體的發展，大部分中小型的資料庫系統的負載是能夠用集中式資料庫承載的，並不需要橫向擴充套件。絕大多數獨立的系統中的資料庫並不存在強烈的橫向擴充套件需求，因此大多數分散式資料庫廠商宣揚的橫向擴充套件能力對這樣的場景確實不是強需求。

不過搞分散式並不總是為了解決單機處理能力不足的問題，從這個角度上來看，部分使用分散式資料庫並不是從單機無法承載負載的角度去考慮的。僅僅從單機能否承載整個負載來判斷分散式資料庫是不是偽需求有點過於武斷了。節約資源也不是集中式資料庫的專利，二十多年前和和一個銀行使用者談資料庫最佳化，談到了我們在運營商解決高負載系統，節約硬體投資的案例，不過他一直不為所動。他被我糾纏了多次後他對我實話實說了，他們為了確保銀行核心交易的可靠性，核心系統的Oracle資料庫負載被設定為不超過15%，也就是說CPU使用率等資源超過15%就必須擴容硬體，從而確保系統的可靠性。在這樣的需求場景下，因為他們的運維能力是不足以應對高負載系統的，因此他們選擇了多花點錢來換取更重要東西。對於這一點我當時還不大認可，認為他們在浪費資源，幾年後我參與了一家證券公司的一次故障分析。為了省錢他們在上海分部沒有捨得用小型機而是用了相對便宜的X86伺服器來跑一套Oracle 10.2.0.3的RAC，其中一個節點經常莫名其妙重啟。有一次節點重啟發生在尾盤交易期間，故障節點上的應用切換了7分鐘才恢復，導致尾盤交易受到影響，因此他們面臨了5000多萬元的交易賠償。如果讓他們重新選擇，無論此次故障是否和X86伺服器有關，他們可能都會毫不猶豫地選擇更加穩定不過投資金額有點大的IBM小型機。那次故障的原因最後被我找到了，是因為Linux作業系統的VM預設引數不合理導致的。

資料庫應用的場景是十分複雜的，不同的使用者，使用者不同的技術背景、研發能力、運維能力、投資需求、管理需求等都會影響到企業對資料庫產品與技術路線的選擇。而我們的認知往往是受到自己的背景的侷限的，因此有些時候，你並不一定就能簡單的否定別人的選擇，或者認定某個需求是偽需求。

前陣子和幾個金融行業的客戶交流，問他們為什麼要上分散式資料庫，他們說為了高可用，集中式資料庫主備切換的時間比較長，同時故障切換可能會丟失部分資料，影響他們的執行質量，因此他們不能接受。我說如果集中式資料庫能夠實現資料0丟失，同時也能實現自動切換，同時切換時間壓縮到5分鐘以內，他們能否接受這樣的資料庫。其中有幾個客戶認為，集中式資料庫能達到此類效果，他們是可以接受的。

接下來我又問剩下的幾個朋友，如果集中式資料庫有了類似Oracle RAC的功能，單節點故障可以快速切換，是不是就能夠滿足你們的需求了。其中有些客戶說可以了，他們現在就是用ORACLE RAC，國產資料庫能達到RAC FCF的切換效果，就能滿足他們的需求了。不過有些使用者還不滿足，他們說RAC雖然是高可用的，不過他們也遇到過RAC叢集故障，這時候雙節點都不可用，導致了全行核心交易中斷，雖然最後也在半個多小時後恢復了，但是也是業務全中斷。而分散式資料庫雖然節點故障部分資料要切換主副本，但是不會業務全中斷，只會影響部分使用者，這在業務考核上算是比較輕微的故障。因此，使用分散式資料庫對於他們的運營考核十分關鍵。

從這個簡單的例子可以看出，相類似的業務場景，因為自身需求的不同、考核標準不同、技術能力不同，就會做出不同的選擇，在這些 場景中，選擇分散式資料庫也並不是偽需求。實際上，從業務的角度出發，選擇分散式資料庫是因為集中式資料庫存在某些對他們業務場景不利的因素，而選擇集中式資料庫則是因為分散式資料庫有他們無法忍受的缺陷。

就上面那個怕業務全中斷影響考核的使用者場景來說，實際上選擇集中式資料庫也是可以解決他的問題的。比如他們的系統能夠採用分庫分表的方式來進行改造，也可以做到某個資料庫出故障隻影響一部分使用者，不會導致業務全中斷，郵儲銀行的核心繫統改造就是這麼做的。郵儲銀行的成功也並不能說明選擇分散式資料庫的使用者的選擇是不合理的，因為不同的使用者，其對應用改造與分庫分表系統的運維能力是不同的，不能用一種統一的標準來衡量不同的使用者。在我交流過的大多數使用者那裡，集中式資料庫與分散式資料庫的選擇沒有一個是基於單機能否承載業務負載的，他們大多數是基於業務連續性與運營的考核體系的。可能也有朋友對此不服氣，認為採用分庫分表完全可以解決使用者所關心的問題。分庫分表的應用之複雜，也不是所有使用者都能夠承受的，很多使用者玩不轉，也就 不敢選擇這個技術路線了。

在與使用者需求的碰撞中，我們還發現了一些分散式資料庫的強需求場景。比如上個月我在北京與一個開發商就係統最佳化的問題進行分析的時候發現，他們目前的應用採用的是微服務架構，整個系統拆得很碎。資料庫是四十多個rds mysql例項承載的。不過他們還是有不少準實時的聚合計算需求。目前的微服務限制了他們這方面的需求，因此他們需要搞一個集中庫來聚合這些資料。這個場景就很適合與MySQL相容性較高的分散式資料庫了。我給他們推薦了TiDB和OceanBase。

還有一個使用者，正在把幾百套小系統從Oracle、MySQL資料庫遷移到國產資料庫上。他們希望選取一個支援多租戶的分散式資料庫來完成這項工作。當他們完成遷移後，不需要面對數百個運維起來十分複雜的小型國產資料庫，希望只是面對一兩個大型的分散式資料庫叢集。這也是分散式資料庫應用的十分典型的場景。

我也遇到過一些使用者他們現在優先選擇集中式資料庫，和他們深入溝通後發現，並不是他們不希望使用分散式資料庫，而是目前的很多分散式資料庫在功能上與他們的需求還有差距。他們需要具有強資源隔離的多租戶，需要HTAP能力，需要多機房雙活能力，需要比較簡單的運維和強大的可觀測性。

從對使用者的需求上看，分散式資料庫的核心挑戰是如何在保證資料的一致性和完整性的同時，實現資料的分散式儲存和計算。這需要在功能、效能、複雜度、可靠性等方面做出合理的權衡和設計。目前，市場上的分散式資料庫產品還不夠成熟和完善，往往存在一些缺陷和侷限，比如：功能不完善，只能支援簡單的CRUD操作，不支援複雜的SQL語法和分析功能，分散式執行計劃的質量不高;效能不穩定，由於需要進行多次網路通訊和分散式協調，效能相比單機資料庫有較大的損失;複雜度高，分散式資料庫涉及多個元件和節點，運維管理難度大，故障排查困難;可靠性低，分散式資料庫由於引入了更多的失效點，容易出現資料丟失、不一致、腦裂等問題。因此，分散式資料庫的發展還有很大的空間和潛力，需要不斷地創新和最佳化，以滿足使用者的真實需求。

分散式資料庫與集中式資料庫的選擇其實是使用者對自身應用場景、技術能力、技術偏好的綜合考慮後的結果，沒有完美的資料庫和資料庫架構，因此集中式資料庫與分散式資料庫都可以找到適合的應用場景與使用者。實際上現在集中式資料庫也在彌補與分散式資料庫在高可用性方面的差距，分散式資料庫也希望自己做得像集中式資料庫一樣普遍適用各種場景並且可以比較簡單的運維，這種相互學習是二者發展的重要動力。多練好內功，在使用者真實的需求中找到自己產品的發展方向，把使用者所需要的功能做出來並且做好，就會獲得市場的認可。