近期跟多家用戶交流，發現用戶在選型數據庫時正有了一些新的變化，這也是近些年通過不斷實踐，用戶總結的最佳實踐方法。例如，有的用戶不盲目追求分布式，而是通過業務單元化后，底層通過集中式數據庫解決；有的用戶選擇分布式數據庫，但在應用上通常是按照“單機”模式去使用，即不做數據分片；有的用戶利用分布式數據庫提供的租戶特性，做單機數據庫的整合；也有的用戶回歸“傳統”的集中式共享存儲架構來解決問題。上面談到的租戶及單機模式的使用方法，可以說是一種“偽分布式”。那么在面臨這些“新架構、新用法”，用戶又該如何選擇呢？本文選擇了分布式和集中式的多種主流用法，嘗試從多種角度來對比分析下。

1. 多角度對比數據庫主流用法

1)談談“偽分布式”

在正式對比之前，這里先談下偽分布式的兩種用法。第一種“單機”模式，其實是一種對分布式的妥協，放棄了分布式能力，選擇單機式的使用方法。這種通常發生在用戶已經選擇使用分布式數據庫，但其更多業務是不需要采用分布式使用方式，但選擇另一款集中式數據庫又需要引入新的技術棧，因而采用這種方式。這種方式優點在于一方面簡化統一技術棧、第二則利用平臺能力（如高可用、易管理等）做到比直接使用單機庫更好的效果。這種方式多見于分庫分表類型的分布式數據庫，因其底層是依托于獨立的單機數據庫引擎構建，因而相對容易。另一種方式“租戶”模式，則多見于資源整合類需求，用戶將原來直接使用大量單機數據庫，轉而通過分布式數據庫提供的租戶來承載。其業務可采用分片、也可采用單機。這種方式優點在于同樣一方面可以簡化統一技術棧，第二則更多是為了更好的利用資源，通過租戶的形式來整合底層資源。當然上述兩種能力，也存在一定的弊端，主要表現在資源有效利用率（分布式架構多少存在一些冗余）、管理靈活性（統一方式管理所帶來的）、可靠性（集群內的單點故障蔓延）、可用性（受限于平臺整體可用性）、擴展性（是否能做到真正的一體化）等等。

2).多角度架構對比

下文將從多角度對比各種數據庫主流架構。這其中選擇原生分布式、分庫分表類型的分布式，默認這兩者都采用數據分片的通常用法；另外選擇分布式的兩種新用法，租戶模式和單機模式。集中式方面，選擇了典型的三種架構，共享存儲模式（類似Oracle RAC）、主備模式（類似Oracle DG）和單機模式。

1.png

架構層面

在架構層面，分布式在擴展性天然具備一定優勢，當然針對絕大多數企業及場景來看，集中式共享模式提供的Scale Up能力，已經是可以滿足的了。之前國內這種方案較少，大多還是主備，近兩年部分廠商開始發力。在可用性、可靠性、容災等方面，分布式具備的計算層無狀態、存儲層多副本架構等技術特點，成為可靠的保障。從我的觀察來看，很多國內用戶選擇分布式數據庫，很多往往不是因為計算、存儲的規模問題，而是考慮了可用性問題。出于對國產數據庫的各種不放心，天然會考慮通過分布式能解決一定問題。這有一定道理，但是這其實也是一柄雙刃劍，分布式架構的復雜度也帶來對可用性的挑戰。其實經典的 IOE 架構，是之前企業的普遍選擇，大部分核心業務系統是構建于此，只不過國產數據庫此類架構發展較晚，大家還處于觀望狀態。

性能層面

在性能層面，分布式同樣具備一定的優勢，可通過水平擴展計算節點來解決高并發、高吞吐的問題。這一點集中式之前方案不多，雖然單節點的處理能力已經達到上百萬的TPMC，但是在極端場景下還是有所欠缺。共享存儲的架構是另一種思路，可在一定程度上解決傳統集中式架構的性能短板。之前有一點容易被忽略的是關于時延問題，分布式架構在這點上往往表現不佳，這主要是因為其層次多、路徑長所導致的，這一點集中式架構是有一定優勢的。

一致性層面

在一致性方面分兩點，一是數據一致性，即多個數據副本是否保障的實時一致性；一是讀寫一致性，可理解為讀取的是否為最新版本的數據。這方面主要是數據副本的復制機制、復制粒度有關，強一致會帶來不錯的一致性表現，但對性能的影響也是巨大的。其實最好的一致性是數據不復制，對單一副本進行讀寫，集中式的共享存儲模式就是這種，嚴格意義來講也不是數據不復制，只不過數據副本的構建是在更低層次（存儲）上解決了。

應用適配性

在應用適配難度上，分布式的劣勢就很明顯了，其在架構設計、語句開發等方面不可避免地需要考慮分布式的特點。當然很多分布式廠商也都在解決這一問題，希望通過類似“透明分布式”的做法來屏蔽這一難點。但目前看來只能說在一定程度上可以解決，尚無法達到同集中式同等的設計、開發適配能力，畢竟過去幾十年來研發人員已經習慣在集中式數據庫上的設計開發了。此外，針對庫內計算的問題則差異更大，這也是大家這些年都紛紛采用降低數據庫計算要求，這其實也是無奈之舉，但同時其背后的壓力與成本付出則是更多人看不到的。

資源利用

在資源利用方面，分布式所需組件多、資源消耗大，是很多人所詬病的，這是其架構決定的。約一體化的架構對資源的使用效率越高，這一點集中式有一定優勢。在隔離性方面，同樣如此，較為清晰的資源調用路徑有利于提升隔離性，避免因資源消耗過大導致的異常蔓延問題。

綜合成本

最后的成本問題則來自多個方面，這包括了硬件、軟件采購及與之相配套的開發測試與運營維護成本。這一點分布式具有的新架構、節點組件多、資源需求多、開發適配投入大、管理維護復雜等問題是存在的，這也在一定程度造成分布式推廣難點，因而可見近年來很多分布式企業提供的單機一體化能力，就是為了在一定程度上減低部分成本。很多用戶可能會有感覺，上了分布式后，比之前集中式的 IOE 架構還要貴，這點也為國產集中式架構產品帶來一定啟發，做出更具性價比的產品。

2. 典型業務場景分析

上面談到了數據庫主流用法，那么用戶又該如何去選呢？一方面可以參考表格內容做好自有業務分析，一方面也可以參考行業一些通用做法。這里引用來自白鱔老師近期發表的一篇文章，其中對主流業務場景做了抽象。這里將下面場景逐一分析，看用什么架構適配會更為合適。

1).典型業務場景回顧

2.png

2).可適配的最佳架構

下面從不同架構特點及場景需求出發，做兩兩匹配，看何種架構會更為合適些。

3.png