點擊上面的鏈接文字，可以快速關注“東方雲洞察”公衆號
分佈式數據庫簡介
分佈式數據庫系統通常使用較小的計算機系統，每臺計算機可單獨放在一個地方，每臺計算機中都可能有DBMS的一份完整拷貝副本，或者部分拷貝副本，並具有自己局部的數據庫， 通過網絡互相連接共同組成一個完整的、全局的邏輯上集中、物理上分佈的大型數據庫。
分佈式並行數據庫通過並行使用多個CPU和磁盤來將諸如裝載數據、建立索引、執行查詢等操作並行化以提升性能的數據庫系統。其中最重要的關鍵詞是並行。
在組成大規模計算機集羣的時候，通常有兩種特性要考慮：並行和分佈式。並行強調多節點同時執行，共同解決一個大問題，通常在嚴格的高性能網絡環境中，有嚴格的執行要求和反饋時限。或者通過良好的分發極致，分佈式並行處理不同的任務，從而達到數據處理高性能的需求。
因爲並行數據庫的技術特點是爲了某類需求設計的，因此它有自己的適用環境。它採用關係理論非常適合結構化數據。非結構化或者某些半結構化數據，當然也可以在其中存和取，但是實際上有很多更好的解決方案可以選擇。
並行數據庫目前的主要問題來自於它的設計目的，因爲要實現完美的並行，因此它大多被設計爲計算和存儲緊密耦合，這樣計算可以控制每行數據的存儲位置和每個數據塊的存儲格式，這樣對大型的任務而言提供了很好的性能。
分佈式數據庫設計理念
分佈式數據庫核心的理念可以用下面一句話來概括：
“積少成多”讓多個“小”的能力協同、匯聚成“大”的能力來解決大問題，是引跑分佈式數據庫最核心的設計理念。分佈式數據庫的基本思想是將原來集中式數據庫中的數據以及處理能力，分散存儲到多個通過網絡連接的數據存儲節點上，以獲取更大的存儲容量和更高的併發訪問量。
並行數據庫主要由執行引擎、存儲引擎和管理功能模塊組成。在這裏我簡單介紹幾種常見的多節點數據庫架構，有些甚至可以看做是分佈式數據庫的變種，分佈式數據庫和我們平時經常提到的數據庫集羣有些相似的地方，但是不能把它們混淆。爲了讀者更清楚的理解，我做一些簡要說明：
第一類：主從結構數據庫
主從架構的數據庫目前應用比較廣放，其邏輯結構是一個主數據庫節點和一個從數據庫節點組成。從數據庫節點通常可以進行只讀訪問，通過支撐分析行任務來分擔主數據庫節點的壓力。常見的 DB2、Oracle、MySQL等都有主從架構的功能。
第二類：多計算節點、存儲共享架構
這種架構的數據庫在計算層面採用多節點的方式，但是存儲節點仍然是一個共享架構，所以這種架構的數據庫最大的問題在於可擴展性的限制，對於大數據量、高併發的場景很容易觸發這種架構的理論缺陷閥值。這種架構最傑出的代表是Oracle RAC以及 DB2 PureScale等數據庫。
第三類：單引擎節點、無數據共享的分佈式架構
這種架構的數據庫會把所有的數據分佈到不同的節點上，通過主引擎節點分發任務到所有計算節點，從屬引擎節點作爲備用和主引擎節點進行數據同步。代表性產品例如：IBM DB2 DPF、Netezza 等。這些分佈式數據庫通常應用於OLAP爲主的BI分析領域，因爲查詢性能很強，但是對於OLTP 這些數據庫的增、刪、改以及對事物的支持能力較弱。
第四類：完全集羣化的分佈式架構
在這種架構下引擎節點、計算節點以及存儲節點都是無中心的分佈式架構，這樣的中心Master架構在組成大規模集羣時優勢明顯，我認爲這是未來最先進的分佈式集羣架構，這樣在提供良好的系統擴展性和高可用的同時，也保持了引擎節點的對等性，整個系統完全沒有單點問題。
本文標題中所提到的分佈式並行數據庫架構，指的就是這裏所提到的第三類和第四類數據庫架構，它們在市場上都有很多實際的應用項目。
分佈式數據庫的優勢和應用場景
接下來我們簡單介紹一下分佈式數據庫架構的主要特點和主要應用場景，請允許我用引跑科技的分佈式數據庫產品架構來進行講解，但是，其原理和其他的率屬於第三和第四類分佈式數據庫原理和特點是一致的的，所以適合的應用場景也有很多重合的地方。
大家可以忽略引跑 DBOne 數據庫的名字，下面介紹的特點是很通用的。分佈式數據庫通常會有以下優勢：
· 數據表進行自動分片
· 數據的完整性通過多副本技術實現
· 高可用性通過分佈式結構來保證
· 自動的負載均衡
· 水平擴展和壓縮
自動數據分片
基於Share Nothing的分佈式數據庫架構，會對數據進行平均分配，通過數據分片（Sharding）的方式分佈在不同數據節點。這樣當處理應用對數據的請求時會分佈到不同的數據節點並行執行。
自動數據分片原理圖
智能水平擴展
設計良好的分佈式數據庫系統，會自動根據資源情況進行自動的擴展，把數據和業務負載自動擴展到新加入的物理服務器上。良好的可擴展性也是分佈式並行數據庫最大的優勢。
智能水平擴展原理圖
智能水平壓縮
數據水平壓縮是水平擴展的相反操作，用於需要自動或者手動收縮資源的場景。
智能水平壓縮原理圖
高可用性
分佈式數據庫通常會配置多個數據副本，例如Replica=2時，會把實際數據在不同的物理節點上存儲三份。下面的原理圖，展示了當某個服務器出現故障，其他服務器可以自動接管任務負載，並且重新分配數據分片。
高可用性原理圖二
自動節點發現和負載均衡
在分佈式數據庫架構中，動態添加硬件資源，從而避免在繁忙時段服務器的過載是非常重要的功能，這樣保證了整體的靈活性和可擴展性大大強於Oracle RAC爲代表的傳統交易型數據庫系統。
下圖展示了當服務器出現過載情況時，自動熱遷移數據到空閒物理服務器的情景，整個數據遷移粒度可以是：整個應用級、實例級、Shard級別或Shard內部更細粒度遷移。
綜合來看，分佈式並行數據庫在數據處理的高性能、高效的資源利用率、高可用性等方面都有很好的優勢。分佈式並行處理機制，對於OLAP領域的應用優勢非常明顯。在OLTP領域分佈式並行數據庫還剛剛開始顯現威力，對於分佈式事物的支持能力如何，成爲判斷分佈式並行數據庫是否完善的有效評判標準之一。
OLTP領域使用分佈式數據庫的考慮因素
企業的核心業務系統一般都是OLTP爲主的應用場景，在這個領域Oracle一直是市場的領導者，緊隨其後的IBMDB2、MS SQL Server等都在這個領域佔據重要市場地位。
近年來，隨着開源數據庫的發展，MySQL、PostgreSQL爲主的開源數據庫逐步佔據了OLTP領域較大一塊市場，在市場份額上對傳統的交易型數據庫廠商造成了衝擊。特別是在互聯網領域，開源數據庫應用非常廣泛。但是，在中大型企業及政府機構領域傳統交易型數據庫三強（Oracle、DB2、SQLServer）仍然佔有極大的比重。
隨着國產化戰略、自主可控需求的發展，以及去“Oracle”浪潮不斷的演化，在這些中大型企業中將會逐步使用國內的一些數據庫產品，在其中分佈式數據庫是一個非常重要的方向，只有基於好的分佈式架構的數據庫纔有可能與OracleRAC進行面對面的直接競爭。
對於企業而言，如果在OLTP應用場景要去Oracle數據庫，還是一個比較大的變革，源於Oracle和上層應用的緊密綁定，所以真正要做去“O”的決定，一般需要考慮以下因素：
1. 變革驅動因素
企業的核心交易系統要想去除掉Oracle，要由足夠的驅動力。這個驅動力或者是國產化、安全自主可控的國家戰略影響，或者是出於降低企業IT成本的需要，無論如何都需要有足夠動力讓企業決策者去推動替換Oracle數據庫的項目。
2. 穩定性因素
OLTP系統通常作爲企業核心業務的交易系統，穩定性是第一位的。沒有企業願意在OLTP應用場景中承受穩定性的損失。即使成本或其他因素再有吸引力，如果穩定性不達標，企業和組織機構頁不會願意冒這種風險去做變革。對於分佈式並行數據庫這種產品來說，把穩定性放在第一位是絕對正確的選擇。
3. 遷移複雜度
Oracle在去IOE運動中是最爲複雜和困難的，其原因就在於Oracle數據庫和上層應用綁定比較緊密，替換數據庫需要涉及到應用遷移，這個工作的工作量和時間週期通常較大。
對於上層業務應用來說，如果大量使用Oracle存儲過程、自定義函數、觸發器等來實現負責的業務邏輯，那麼替換Oracle數據庫時將會非常耗時，複雜度較高、風險也比較大。
相反，如果業務應用使用Hibernate等比較成熟的開發架構，業務邏輯都封裝在應用層，那麼這類應用的遷移難度和複雜度就會比較低，這類應用進行數據庫遷移會比較容易。
4. 高性能
很多大型的業務應用系統底層的數據庫基於OracleRAC，當數據量增大，SQL查詢的業務邏輯很複雜時，這種存儲共享的數據庫架構會受限於其擴展性的低效率和天花板問題，會出現性能瓶頸。對於併發壓力較大、數據量上TB的的業務系統來說，替換Oracle後，需要新的數據庫系統能夠提供很好的性能支撐。這種情況下，分佈式並行數據庫基本上成了不二之選。
5.可擴展性
企業核心業務系統通常對可擴展性要求較高，那麼作爲替換Oracle的新數據系統，在可擴展性方面要有一定的優勢。分佈式數據庫在可擴展性方面通常做的不錯，特別是第三類和第四類分佈式數據庫。
6. 高可用性
高可用性是指一個系統經過專門的設計，從而減少停工時間，而保持其服務的高度可用性。在這方面傳統的交易型數據庫會通過雙機熱備，多節點等方式來實現。OracleRAC、DataGuard等都是常見的方式。
而基於分佈式並行架構的數據庫系統，通常在高可用性方面做的不錯，通過多個並行計算、存儲節點以及多副本的實現方式，有效的保證了整體系統的高可用性。
7.運維複雜度
企業IT運維是保證IT能力正常支撐企業業務發展的重要流程，在OLTP應用場景中替換原有的數據庫，會對企業IT的運維能力造成衝擊和挑戰，因此，企業在整個去“O”過程中需要有效的評估運維複雜度的變化。新的基於分佈式架構的數據庫如果能夠在用戶界面、使用方式、命令、語法等方面和原有的Oracle數據庫保持儘可能多的兼容，會有效減少企業對新技術的學習成本，使得運維的複雜度可控。
分佈式數據庫取代Oracle的常見應用方案
引跑科技DBOne是基於分佈式並行數據庫架構的，如下圖展示的架構圖，可以很清楚的看到它是我前面提到的第三類或第四類分佈式數據庫架構。因爲，它的引擎節點可以部署成主備結構或者完全對等的集羣結構。
DBOne分佈式數據庫架構圖
DBOne主要包括分佈式數據庫引擎和分佈式數據存儲節點。分佈式數據庫引擎是系統核心，其負責SQL解析、優化、路由、分發、合併等操作，同時將底層的衆多存儲節點管理起來；分佈式存儲節點使用引跑自行設計和完全自主可控的單機iDB（IntpleDB）關係型數據庫產品。用戶可靈活構建不同規模的數據庫集羣，通過將業務數據分片到不同的數據庫存儲節點中，極大降低了普通數據庫面對海量數據時的壓力；通過將用戶的SQL請求分發到各節點上執行，充分利用各節點的計算資源，從而能夠使PC服務器集羣達到並超越小型機、中大型機的性能。
下面我以引跑的DBOne分佈式並行數據庫爲例，來介紹一下分佈式數據庫在取代Oracle的過程中的常見應用場景。
如上圖所示，這是一個典型OLTP應用場景中的Oracle架構，多RAC節點的共享存儲架構模式，本地一般通過帶庫進行定期備份。如果替換這樣的Oracle數據庫，可以採用以下的兩種應用方案。
方案一 Fusion混合模式
在這種架構下，原有Oracle數據庫和分佈式數據庫並行運行，通過同步工具進行異步或同步模式的數據同步。把上層應用對數據庫的請求進行劃分，把少量OLTP以及OLAP業務請求分流到分佈式數據庫執行。這樣對於某些應用遷移複雜度高、風險較大的情況可以靈活進行處理。如果原有的Oracle數據庫存在性能問題以及存儲擴容的需求，那麼可以只在Oracle數據庫中保留“熱”數據，全量數據放在分佈式數據庫中，這種模式可以很好的解決用戶的這些頭疼問題。
這種架構是一種在實際項目中經常用到的模式，對很多企業用戶來說，混和模式從各方面來說都更容易接受，儘管它只是一箇中間模式，卻能通過較小的代價快速解決客戶的問題。當然，應用負載的分流複雜性問題也是存在的。
方案二 完全分佈式模式
如上圖所示，在這種分佈式數據庫架構模式中，數據完全遷移到新的分佈式數據庫中，通過兩個相對獨立的分佈式集羣來實現本地或者異地的數據庫容災。對於很多新的應用項目這是比較好的實現方式，因爲無需考慮上層應用遷移的複雜度和風險問題。從實際市場情況來說，這種新交易型應用項目直接採用分佈式數據庫是比較常見的的，這種直接去Oracle的方式無論從風險和成本上來說都比較有優勢。
大數據應用促進“分佈式架構”的繁榮
從實際市場反饋來說，分佈式並行數據庫要想取代Oracle仍然任重而道遠，這其中有很多原因，就像我在第四節提到的那些因素，都制約着國產分佈式並行數據庫的發展。
好消息是大數據應用的繁榮會促進分佈式並行數據庫的進步，因爲整個大數據應用架構都是以分佈式以及並行爲核心的。越來越多的企業正在探索和實踐大數據項目，隨着大數據應用規模不斷髮展和影響力的擴大，對於分佈式並行數據庫的發展有極大的促進作用。
我期待有一天能夠在不改變任何原有業務邏輯和代碼的前提下，實現底層分佈式數據庫的自由伸縮和擴展。我們會以“高穩定性、可擴展，高性能”爲核心理念，改進引跑的分佈式並行數據庫，最終我們一定能夠讓它在去Oracle的征途上越走越遠。
掃描二維碼關注【東方雲洞察】公衆號
實時瞭解深度的公有云市場分析和洞察結果！點擊右上角，在彈出的菜單中發送給朋友、分享到朋友圈。請在公衆號搜索並關注：DongCloudInsight 或 東方雲洞察。需要點對點交流請加微信：jackyzhang523
幫助您瞭解公有云相關的深度洞察結果。帶來極具深度和最新鮮的：雲市場分析、雲機會洞察分析、雲重大事件快評、雲雜談、雲論壇資訊，以及公有云領域最高端的CEO面對面深度研討。
--- 最專注、專業的“公有云洞察”分享；關注全球，聚焦中國。