大資料將促進分散式資料庫發展及去Oracle

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

http://www.csdn.net/article/2015-09-11/2825678

分散式資料庫簡介

分散式資料庫系統通常使用較小的計算機系統，每臺計算機可單獨放在一個地方，每臺計算機中都可能有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一直是市場的領導者，緊隨其後的IBM DB2、MS SQL Server等都在這個領域佔據重要市場地位。

近年來，隨著開源資料庫的發展，MySQL、PostgreSQL為主的開源資料庫逐步佔據了OLTP領域較大一塊市場，在市場份額上對傳統的交易型資料庫廠商造成了衝擊。特別是在網際網路領域，開源資料庫應用非常廣泛。但是，在中大型企業及政府機構領域傳統交易型資料庫三強（Oracle、DB2、SQL Server）仍然佔有極大的比重。

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

對於企業而言，如果在OLTP應用場景要去Oracle資料庫，還是一個比較大的變革，源於Oracle和上層應用的緊密繫結，所以真正要做去“O”的決定，一般需要考慮以下因素：

1. 變革驅動因素

企業的核心交易系統要想去除掉Oracle，要由足夠的驅動力。這個驅動力或者是國產化、安全自主可控的國家戰略影響，或者是出於降低企業IT成本的需要，無論如何都需要有足夠動力讓企業決策者去推動替換Oracle資料庫的專案。

1. 穩定性因素

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

1. 遷移複雜度

Oracle在去IOE運動中是最為複雜和困難的，其原因就在於Oracle資料庫和上層應用繫結比較緊密，替換資料庫需要涉及到應用遷移，這個工作的工作量和時間週期通常較大。

對於上層業務應用來說，如果大量使用Oracle儲存過程、自定義函式、觸發器等來實現負責的業務邏輯，那麼替換Oracle資料庫時將會非常耗時，複雜度較高、風險也比較大。

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

1. 高效能

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

5.可擴充套件性

企業核心業務系統通常對可擴充套件性要求較高，那麼作為替換Oracle的新資料系統，在可擴充套件性方面要有一定的優勢。分散式資料庫在可擴充套件性方面通常做的不錯，特別是第三類和第四類分散式資料庫。

1. 高可用性

高可用性是指一個系統經過專門的設計，從而減少停工時間，而保持其服務的高度可用性。在這方面傳統的交易型資料庫會通過雙機熱備，多節點等方式來實現。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的征途上越走越遠。