表太多分成多個數據庫有什麼影響

近年來，分散式資料庫已經成為了行業中預設的主流技術方向，彷彿只要一款資料庫不是分散式架構，即喪失了其技術先進性，無法承載未來業務的發展。這種觀點對於“大資料”時代的海量資料需求完全正確，但是，在“賬務類”的業務場景下，是否就必須使用分散式架構呢？對於這個問題，業界充斥著截然相反的聲音。

一方的觀點認為，在大資料時代，“賬務類”和其他系統一樣，其所需要處理的資料量都有可能會被無限制地放大，因此需要透過一個通用的分散式資料庫，滿足未來“可能”存在的海量資料強交易場景是非常有必要的。就算是分散式架構下效能與集中式資料庫相比存在短板，我們也可以使用分散式的彈性擴張特性，將整體效能無上限地進行提升。

而另一方的觀點則認為，在商業化的環境中單純探討理論是無意義的，實際上在“賬務類”場景中針對海量資料的強交易需求幾乎是不存在的。同時，由於硬體條件所限，分散式架構是否能夠真正避免網路效能瓶頸也是個問題。一般來說，在目前行業中的大部分“賬務類”場景中，Oracle等傳統集中式資料庫處理能力綽綽有餘，因此分散式資料庫技術在“賬務類”場景中並不存在剛需。

分散式資料庫處理“賬務類”場景在技術上是否合適？

可以看到，正反方的觀點包含討論技術實現及業務需求的不同方向。從產品發展的角度看，實際上，Google Spanner並不是第一個實現分散式交易資料庫的架構。早在上世紀九十年代，IBM DB2 DPF即基於二段提交機制實現了跨節點事務的一致性，將分散式資料庫的交易能力進行了商業化實現；2003年Greenplum也提供了可以保證分散式事務下的資料一致性能力（包括：增、刪、改、查）。但這兩個資料庫都沒有進一步在強交易的“賬務類”場景上發力，迄今為止他們主要業務場景依然圍繞著資料倉庫展開，並沒有過多涉足“賬務類”交易場景。

從技術角度來看，分散式交易資料庫的處理效能與集中式資料庫Oracle相比存在較大差距。這個效能差距存在的前提是：資料量。在幾十億資料量的級別下，集中式資料庫透過伺服器記憶體與資料壓縮機制，完全能夠將這些資料存在一臺伺服器的記憶體中。這種情況下，分散式交易所需要執行的程式碼指令數量以及網路開銷，與在單臺伺服器內部透過記憶體匯流排進行資料交換的開銷是完全無法相比的。

譬如說，僅僅在事務號分配這個領域，集中式架構只需要簡單使用一個原子變數即可生成程序唯一的事務號；而分散式架構要麼透過網路從一個集中式GTM生成事務號，要麼透過Google Spanner類似的機制使用原子鐘生成一個時間範圍作為事務順序號，之後提交時還必須等待一個毫秒級的誤差延時才能完成事務提交。

除此以外，無論是二段提交還是最佳化後的Percolator機制，都會對事務提交造成極大的延時。而由分散式技術所帶來的並行執行效率的提升，在“賬務類”場景下的點狀記錄修改需要的是瞬時的交易處理效能，分散式演算法所帶來的併發頻寬擴充套件能力引入了更多的開銷，因此並無用武之地。

因此，

從技術以及演算法的角度來看，在資料量完全能夠使用一臺伺服器存放的場景中，集中式交易效能一定高於分散式交易效能。

一般來說，在DB2、Oracle等成熟的傳統交易型資料庫中，這個數字可以達到億級記錄的資料量。如同Google這樣的網際網路巨頭，確實會由於更大的海量資料，對分散式交易能力有著較大的需求。因此在Google內部Spanner發揮了重要的作用。但我們從Google Trends的資料中可以發現，在海外，實際的Spanner應用並不活躍，這到底又是什麼原因呢？

到這裡，我們就必須要討論在“賬務類”場景下，分散式資料庫產品的市場契合度的問題。到底哪些行業及客戶的“賬務類”低延遲強交易場景，有著海量的資料，必須透過分散式資料庫來解決？我們知道大部分會產生海量資料的業務系統，例如網際網路、物聯網等，幾乎不存在如同“銀行分戶賬”一樣，需要多資料之間資訊大量強事務交換的要求。而在其他對資料一致性要求最為明顯的金融、電信、政企、交通等領域往往為純交易場景。企業可以透過微服務及各類架構，控制資料量在十億行以下，因此集中式資料庫在容量上足以支撐，實時處理效能方面也遠高於分散式架構。這也許就是如同Spanner、CockroachDB這樣的資料庫，在海外的實際應用都並不活躍的原因。

分散式資料庫與“賬務類”場景的市場契合度如何？

可以看到，

分散式資料庫在“賬務類”場景是否具有商用價值，這並非一個純技術問題，而是一個產品市場契合度（Product Market Fit）的綜合問題。

在一個開發人員的眼中，交易系統可以說是包羅永珍。以銀行金融業務為例，從銀行的分戶賬核心，到支付平臺，到渠道系統，都可以歸納為交易系統。而實際上，真正涉及到轉賬的“賬務類”業務系統往往十分聚焦，在金融體系中除了分戶賬這類真正儲存著每個賬戶金額的資料表，在交易的那一剎那需要強交易能力以外，大部分產生海量資料的業務系統都可以歸納為“非賬務類”業務（如各類：報文、業務流水、歷史記錄等）。

在筆者看來，大部分人對“大資料”存在一個理解的誤區，即分散式及大資料可以解決一切問題。宏觀條件下，企業數字化轉型的過程中會以“非賬務類”為主要場景產生海量資料，單臺數據庫無法處理，分散式資料庫是這類需求的絕佳選擇。這類業務，往往資料量以數億甚至達到萬億級別，同時服務的終端業務眾多，需要更強的彈性併發能力，且同樣需要保障ACID，只是在交易延遲上可以有一定放寬。

而細分到如同分戶賬核心這類“賬務類”場景時，其需求是極限的交易延遲，這一點並不是分散式資料庫的優勢所在。尤其是在微服務應用架構大行其道的今天，大部分這類交易的場景都會被拆分到多個微服務中，透過各種冪等性原則及補償策略，完成應用整體的端到端交易能力，降低對底層資料庫強交易能力的依賴。

對比項

賬務類

非賬務類

常見資料量

千萬~億級

億~萬億級

資料庫安全性

專庫專用

資料庫可共享

可以交叉服務多個業務

資料型別

結構化

結構化、半結構化、非結構化

併發能力

基於低延遲的

實時高併發

可接受一定延遲的

海量彈性併發

事務處理效率

極高，需要系統匯流排級的低延遲

甚至需要序列處理保障

可容忍一定網路延遲

但需要保障ACID

事務處理複雜度

多表多記錄關聯

甚至需要儲存過程

少量關聯

因此，我們可以看到，“非賬務類”場景產生了海量資料，分散式資料庫十分契合這一場景的業務需求。同時，“非賬務類”場景雖然同樣需要聯機處理的事務一致性能力，但相對於“賬務類”強交易能力的需求，相對可以容忍更長的網路延遲。

而對強交易存在剛需的“賬務類”場景，其核心需求則是匯流排級別的交易延遲，同時透過微服務架構細分控制單體資料量，可以更切實地滿足業務對各個子系統效能的訴求。在信創的背景下，基於長期成本及供應鏈的考慮，傳統商業化集中式資料庫有較強的遷移訴求。對於這類遷移的需求，雖然說95%的“賬務類”系統透過集中式MySQL或PostgreSQL架構已經可以承載，但剩下5%資料量較大的系統又應該如何處理呢？綜合現實條件的約束，筆者認為透過類似MyCat分庫分表中介軟體方案承載“賬務類”系統，依然值得我們探討。當然，我們也期待未來我國自研的企業級產品，可以給我們提供MyCat這類分庫分表中介軟體方案以外的更多選項。

總體來說，

從市場契合度的方面來看，無論從資料量以及應用開發架構趨勢，集中式資料庫更契合“賬務類”場景，對分散式資料庫並不存在強烈的市場剛需；而分散式資料庫更契合於海量資料需求下的“非賬務類”場景。

新一代集中式資料庫特性

除了Oracle、MySQL、SQL Server等上一代傳統交易型資料庫以外，當前業界新一代集中式交易型資料庫包括AWS Aurora、以及阿里雲PolarDB等。這類新一代交易型資料庫透過一寫多讀的能力，構建基於雲平臺提供的分散式儲存之上。因此，其事務處理依然集中在單臺服務的匯流排之上，並不涉及分散式事務處理架構。

一般來說，這類基於雲計算的集中式資料庫往往在部署當中採用讀寫分離的主從架構，用於加速其資料的讀取效能，也能夠儘可能提升讀多寫少場景下的效能擴充套件性。其核心思路參考了十多年前就在Oracle DataGuard以及IBM DB2 HADR等產品中的讀寫分離架構，同時在資料庫快取及儲存方面進行了最佳化，使得同一份資料可以被多個節點同時讀取，減少資料冗餘。

因此，類似AWS Aurora或阿里雲PolarDB等產品，在資料庫引擎的快取機制上甚至會使用如同Intel Optane“持久記憶體（Persistent Memory）”等特殊硬體，加以深度最佳化，使得其執行在分散式的雲端儲存時，還能夠保證資料庫例項足夠低的讀寫延遲。

這類新一代的集中式資料庫，有效基於雲平臺簡化管理模型，同時基於讀寫分離擴充套件了查詢的能力，減輕寫入節點的處理壓力，或許可以成為“賬務類”場景下有力的資料庫競爭者。

架構的選型應該遵循業務的實際需求

透過以上的分析我們不難看出，任何技術的選型都離不開業務需求，產品市場契合度（Product Market Fit）是所有新型產品是否能夠在正確的場景獲得廣泛應用的核心基礎。

“賬務類”場景在資料量可控的情況下，集中式資料庫可以帶來更低的延遲，從而獲得更高的業務處理效能。而部分超大型企業的系統中，即使是“賬務類”系統也可能超出集中式資料庫的處理能力，因此引入基於分庫分表資料庫方案，結合業務處理改造可以更合理地解決現實的業務需求。“非賬務類”場景主要面向海量資料，及彈性的高併發聯機業務，透過分散式資料庫基於多伺服器橫向擴充套件能力，可以獲得更有效的資料底座支撐能力。但無論是哪一類的系統，對於資料庫的ACID一致性能力都同樣有著明確的要求。

因此，企業IT架構決策團隊在進行技術產品選型時，應該充分論證目標業務的真實述求，以企業的長期發展需求為導向，為不同的業務選型不同的基礎技術架構。