分佈式並行數據庫將在OLTP 領域促進去「Oracle」

原文連接：http://www.csdn.net/article/2015-09-11/2825678

摘要：本文全面介紹了分佈式數據庫和它的設計理念，以及分佈式數據庫的優點和應用場景，從而引出OLTP領域使用分佈式數據庫的考慮因素和分佈式數據庫取代Oracle的常見應用方案，最終大數據應用促進了「分佈式架構」的繁榮。

分佈式數據庫簡介

分佈式數據庫系統一般使用較小的計算機系統，每臺計算機可單獨放在一個地方，每臺計算機中均可能有DBMS的一份完整拷貝副本，或者部分拷貝副本，並具備本身局部的數據庫， 經過網絡互相鏈接共同組成一個完整的、全局的邏輯上集中、物理上分佈的大型數據庫。

分佈式並行數據庫經過並行使用多個CPU和磁盤來將諸如裝載數據、創建索引、執行查詢等操做並行化以提高性能的數據庫系統。其中最重要的關鍵詞是並行。

在組成大規模計算機集羣的時候，一般有兩種特性要考慮：並行和分佈式。並行強調多節點同時執行，共同解決一個大問題，一般在嚴格的高性能網絡環境中，有嚴格的執行要求和反饋時限。或者經過良好的分發極致，分佈式並行處理不一樣的任務，從而達到數據處理高性能的需求。

由於並行數據庫的技術特色是爲了某類需求設計的，所以它有本身的適用環境。它採用關係理論很是適合結構化數據。非結構化或者某些半結構化數據，固然也能夠在其中存和取，可是實際上有不少更好的解決方案能夠選擇。

並行數據庫目前的主要問題來自於它的設計目的，由於要實現完美的並行，所以它大多被設計爲計算和存儲緊密耦合，這樣計算能夠控制每行數據的存儲位置和每一個數據塊的存儲格式，這樣對大型的任務而言提供了很好的性能。

分佈式數據庫設計理念

分佈式數據庫核心的理念能夠用下面一句話來歸納：

「聚沙成塔」讓多個「小」的能力協同、匯聚成「大」的能力來解決大問題，是引跑分佈式數據庫最核心的設計理念。分佈式數據庫的基本思想是將原來集中式數據庫中的數據以及處理能力，分散存儲到多個經過網絡鏈接的數據存儲節點上，以獲取更大的存儲容量和更高的併發訪問量。

並行數據庫主要由執行引擎、存儲引擎和管理功能模塊組成。 在這裏我簡單介紹幾種常見的多節點數據庫架構，有些甚至能夠看作是分佈式數據庫的變種，分佈式數據庫和咱們平時常常提到的數據庫集羣有些類似的地方，可是不能把它們混淆。爲了讀者更清楚的理解，我作一些簡要說明：

第一類：主從結構數據庫

主從架構的數據庫目前應用比較廣放，其邏輯結構是一個主數據庫節點和一個從數據庫節點組成。從數據庫節點一般能夠進行只讀訪問，經過支撐分析行任務來分擔主數據庫節點的壓力。常見的 DB二、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一直是市場的領導者，緊隨其後的IBM DB二、MS SQL Server等都在這個領域佔據重要市場地位。

近年來，隨着開源數據庫的發展，MySQL、PostgreSQL爲主的開源數據庫逐步佔據了OLTP領域較大一塊市場，在市場份額上對傳統的交易型數據庫廠商形成了衝擊。特別是在互聯網領域，開源數據庫應用很是普遍。可是，在中大型企業及政府機構領域傳統交易型數據庫三強（Oracle、DB二、SQL Server）仍然佔有極大的比重。

隨着國產化戰略、自主可控需求的發展，以及去「Oracle」浪潮不斷的演化，在這些中大型企業中將會逐步使用國內的一些數據庫產品，在其中分佈式數據庫是一個很是重要的方向，只有基於好的分佈式架構的數據庫纔有可能與Oracle RAC進行面對面的直接競爭。

對於企業而言，若是在OLTP應用場景要去Oracle數據庫，仍是一個比較大的變革，源於Oracle和上層應用的緊密綁定，因此真正要作去「O」的決定，通常須要考慮如下因素：

1. 變革驅動因素

企業的核心交易系統要想去除掉Oracle，要由足夠的驅動力。這個驅動力或者是國產化、安全自主可控的國家戰略影響，或者是出於下降企業IT成本的須要，不管如何都須要有足夠動力讓企業決策者去推進替換Oracle數據庫的項目。

2. 穩定性因素

OLTP系統一般做爲企業核心業務的交易系統，穩定性是第一位的。沒有企業願意在OLTP應用場景中承受穩定性的損失。即便成本或其餘因素再有吸引力，若是穩定性不達標，企業和組織機構頁不會願意冒這種風險去作變革。對於分佈式並行數據庫這種產品來講，把穩定性放在第一位是絕對正確的選擇。

3. 遷移複雜度

Oracle在去IOE運動中是最爲複雜和困難的，其緣由就在於Oracle數據庫和上層應用綁定比較緊密，替換數據庫須要涉及到應用遷移，這個工做的工做量和時間週期一般較大。

對於上層業務應用來講，若是大量使用Oracle存儲過程、自定義函數、觸發器等來實現負責的業務邏輯，那麼替換Oracle數據庫時將會很是耗時，複雜度較高、風險也比較大。

相反，若是業務應用使用Hibernate等比較成熟的開發架構，業務邏輯都封裝在應用層，那麼這類應用的遷移難度和複雜度就會比較低，這類應用進行數據庫遷移會比較容易。

4. 高性能

不少大型的業務應用系統底層的數據庫基於Oracle RAC，當數據量增大，SQL查詢的業務邏輯很複雜時，這種存儲共享的數據庫架構會受限於其擴展性的低效率和天花板問題，會出現性能瓶頸。對於併發壓力較大、數據量上TB的的業務系統來講，替換Oracle後，須要新的數據庫系統可以提供很好的性能支撐。這種狀況下，分佈式並行數據庫基本上成了不二之選。

5.可擴展性

企業核心業務系統一般對可擴展性要求較高，那麼做爲替換Oracle的新數據系統，在可擴展性方面要有必定的優點。分佈式數據庫在可擴展性方面一般作的不錯，特別是第三類和第四類分佈式數據庫。

6. 高可用性

高可用性是指一個系統通過專門的設計，從而減小停工時間，而保持其服務的高度可用性。在這方面傳統的交易型數據庫會經過雙機熱備，多節點等方式來實現。Oracle RAC、DataGuard等都是常見的方式。

而基於分佈式並行架構的數據庫系統，一般在高可用性方面作的不錯，經過多個並行計算、存儲節點以及多副本的實現方式，有效的保證了總體系統的高可用性。

7.運維複雜度

企業IT運維是保證IT能力正常支撐企業業務發展的重要流程，在OLTP應用場景中替換原有的數據庫，會對企業IT的運維能力形成衝擊和挑戰，所以，企業在整個去「O」過程當中須要有效的評估運維複雜度的變化。新的基於分佈式架構的數據庫若是可以在用戶界面、使用方式、命令、語法等方面和原有的Oracle數據庫保持儘量多的兼容，會有效減小企業對新技術的學習成本，使得運維的複雜度可控。

分佈式數據庫取代Oracle的常見應用方案

引跑科技DBOne是基於分佈式並行數據庫架構的，以下圖展現的架構圖，能夠很清楚的看到它是我前面提到的第三類或第四類分佈式數據庫架構。由於，它的引擎節點能夠部署成主備結構或者徹底對等的集羣結構。

DBOne分佈式數據庫架構圖

DBOne主要包括分佈式數據庫引擎和分佈式數據存儲節點。分佈式數據庫引擎是系統核心，其負責SQL解析、優化、路由、分發、合併等操做，同時將底層的衆多存儲節點管理起來；分佈式存儲節點使用引跑自行設計和徹底自主可控的單機iDB（Intple DB）關係型數據庫產品。用戶可靈活構建不一樣規模的數據庫集羣，經過將業務數據分片到不一樣的數據庫存儲節點中，極大下降了普通數據庫面對海量數據時的壓力；經過將用戶的SQL請求分發到各節點上執行，充分利用各節點的計算資源，從而可以使PC服務器集羣達到並超越小型機、中大型機的性能。

下面我以引跑的DBOne分佈式並行數據庫爲例，來介紹一下分佈式數據庫在取代Oracle的過程當中的常見應用場景。

如上圖所示，這是一個典型OLTP應用場景中的Oracle架構，多RAC節點的共享存儲架構模式，本地通常經過帶庫進行按期備份。若是替換這樣的Oracle數據庫，能夠採用如下的兩種應用方案。

方案一 Fusion混合模式

在這種架構下，原有Oracle數據庫和分佈式數據庫並行運行，經過同步工具進行異步或同步模式的數據同步。把上層應用對數據庫的請求進行劃分，把少許OLTP以及OLAP業務請求分流到分佈式數據庫執行。這樣對於某些應用遷移複雜度高、風險較大的狀況能夠靈活進行處理。若是原有的Oracle數據庫存在性能問題以及存儲擴容的需求，那麼能夠只在Oracle數據庫中保留「熱」數據，全量數據放在分佈式數據庫中，這種模式能夠很好的解決用戶的這些頭疼問題。

這種架構是一種在實際項目中常常用到的模式，對不少企業用戶來講，混和模式從各方面來講都更容易接受，儘管它只是一箇中間模式，卻能經過較小的代價快速解決客戶的問題。固然，應用負載的分流複雜性問題也是存在的。

方案二 徹底分佈式模式

如上圖所示，在這種分佈式數據庫架構模式中，數據徹底遷移到新的分佈式數據庫中，經過兩個相對獨立的分佈式集羣來實現本地或者異地的數據庫容災。對於不少新的應用項目這是比較好的實現方式，由於無需考慮上層應用遷移的複雜度和風險問題。從實際市場狀況來講，這種新交易型應用項目直接採用分佈式數據庫是比較常見的的，這種直接去Oracle的方式不管從風險和成本上來講都比較有優點。

大數據應用促進「分佈式架構」的繁榮

從實際市場反饋來講，分佈式並行數據庫要想取代Oracle仍然任重而道遠，這其中有不少緣由，就像我在第四節提到的那些因素，都制約着國產分佈式並行數據庫的發展。

好消息是大數據應用的繁榮會促進分佈式並行數據庫的進步，由於整個大數據應用架構都是以分佈式以及並行爲核心的。愈來愈多的企業正在探索和實踐大數據項目，隨着大數據應用規模不斷髮展和影響力的擴大，對於分佈式並行數據庫的發展有極大的促進做用。

我期待有一天可以在不改變任何原有業務邏輯和代碼的前提下，實現底層分佈式數據庫的自由伸縮和擴展。咱們會以「高穩定性、可擴展，高性能」爲核心理念，改進引跑的分佈式並行數據庫，最終咱們必定可以讓它在去Oracle的征途上越走越遠。

（責編/錢曙光 qianshg@csdn.net）

做者：張曉東，引跑科技副總裁，IT領域工做15年，曾擔任數據庫技術專家、IT服務經理、高級雲計算架構師、戰略部高級總監等職位。