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

1. 多角度對比數(shù)據(jù)庫主流用法

1)談?wù)劇皞畏植际健?/h3>

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

2).多角度架構(gòu)對比

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

1.png

架構(gòu)層面

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

性能層面

在性能層面，分布式同樣具備一定的優(yōu)勢，可通過水平擴(kuò)展計算節(jié)點(diǎn)來解決高并發(fā)、高吞吐的問題。這一點(diǎn)集中式之前方案不多，雖然單節(jié)點(diǎn)的處理能力已經(jīng)達(dá)到上百萬的TPMC，但是在極端場景下還是有所欠缺。共享存儲的架構(gòu)是另一種思路，可在一定程度上解決傳統(tǒng)集中式架構(gòu)的性能短板。之前有一點(diǎn)容易被忽略的是關(guān)于時延問題，分布式架構(gòu)在這點(diǎn)上往往表現(xiàn)不佳，這主要是因?yàn)槠鋵哟味唷⒙窂介L所導(dǎo)致的，這一點(diǎn)集中式架構(gòu)是有一定優(yōu)勢的。

一致性層面

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

應(yīng)用適配性

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

資源利用

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

綜合成本

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

2. 典型業(yè)務(wù)場景分析

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

1).典型業(yè)務(wù)場景回顧

2.png

2).可適配的最佳架構(gòu)

下面從不同架構(gòu)特點(diǎn)及場景需求出發(fā)，做兩兩匹配，看何種架構(gòu)會更為合適些。

3.png