1. 程式人生 > >為什麼選擇第三代分散式關係資料庫而不是分庫分表的二代方案

為什麼選擇第三代分散式關係資料庫而不是分庫分表的二代方案

       “網際網路經濟”所帶來的巨大流量使得企業、機構面臨外部訪問負載以及資料量的大幅飆升,很多企業資訊系統目前所採用的傳統集中式關係型資料庫越來越不適應海量資料以及高併發環境下對資料處理能力的要求,在應對此類場景時資料庫逐漸成為整體系統的瓶頸,擴充套件成本較高。

        為了解決這些問題,網際網路企業最先進行了嘗試和探索,他們採用分庫、分表,使用 MySQL+資料庫中介軟體方案來解決問題,我們把這種方案稱作 "第二代分散式資料庫方案",簡稱 "二代方案" 。另一種解決問題的方法是基於分散式計算理論、演算法和新的技術,採用新的架構設計,吸收了關係型資料庫和NoSQL資料庫各自的優點 ,建立新一代分散式關係型資料庫從根本上加以解決,有人把它稱作New SQL資料庫。我們把這種New SQL資料庫稱作 "第三代分散式關係型資料庫",簡稱 "三代庫" 。

         無論是二代方案還是三代庫,他們的初衷是相同的,都是為了解決傳統關係型資料庫擴充套件能力問題的。在下面的內容中,將給出優先選擇三代庫的理由。

1. 社會經濟發展趨勢決定
    近些年,網際網路、移動網際網路、雲端計算、大資料和人工智慧等技術飛速發展,已經滲透到社會經濟的各個領域,給各行業乃至整個國家的經濟結構帶來了深刻的影響和變革。未來,網際網路經濟體系一定會成為社會經濟的主流。
    “網際網路經濟”帶來的巨大流量使得企業、機構面臨的外部訪問負載以及資料量大幅提升,這使得企事業單位的IT架構、基礎設施以及應用系統等都面臨著變革。作為系統核心資源的“關係型資料庫”也要適應和滿足這種發展趨勢帶來的影響和挑戰,用“新的架構”和“新的技術”進行升級換代。

2. 技術發展趨勢決定
    在“網際網路經濟”下,“分散式資料庫”是資料庫發展的大勢所趨。“分散式資料庫”能夠顯著提升大容量資料的儲存和管理能力,既能夠滿足大量使用者的高併發訪問需求,又能夠保障面對業務變化的彈性擴充套件能力。
    目前全球頂尖的資料庫廠商,都在設計研發和推廣第三代分散式關係資料庫,它可以徹底解決第二代分散式資料庫方案在關鍵計算領域難以突破的困境。

3. 技術優勢決定
    為了解決傳統關係型資料庫在高併發支援和擴充套件能力等方面的瓶頸,網際網路企業引入並逐漸完善了 "二代庫方案" 。這種方案能夠比較好地滿足網際網路企業自身的業務需求,但是它不是為金融業務場景打造的,無法實現對應用透明的金融級分散式交易事務;無法在不影響應用的情況下完成彈性伸縮;應用開發的難度較高、運維工作的挑戰較大。
    “第三代分散式關係資料庫”無須中介軟體,在資料庫引擎上通過先進的架構、工程設計和演算法,能夠滿足金融行業對高可用、高可靠、高擴充套件能力的苛刻要求。能夠在對業務無影響、無制約的情況下,實現自動地、可靠地強一致性和完備的分散式事務處理。

     下表是二代方案和三代庫的主要技術特性對比:

對比條目

二代庫分散式資料庫方案

三代庫

易用性

強一致性分散式事務

部分支援

支援(引擎內建)

水平擴充套件

人工操作

支援(引擎內建)

複雜查詢(JOIN/GROUP BY/子查詢)

部分支援

支援(引擎內建)

無人工介入的高可用

不支援

支援(引擎內建)

業務靈活性

應用開發透明性

開發和運維成本

4.成本和風險決定
   在現階段新的金融類專案中如果考慮二代方案,將會面臨三個風險: 
   (1) 技術滯後風險
   二代方案雖然也採用了分散式架構,但是它的出發點是基於已有的資料庫產品進行改良,因此其採用的設計、演算法和技術都是圍繞著改良進行的。我們認為,二代方案是一種“中間過渡”產品,未來不會是主流。
   (2)業務場景受限的風險 
   二代方案可能僅限於某些安全等級低,且和金融相關業務關係不大,業務程式碼可以隨意調整的類網際網路/電商類業務場景。
   (3)較高的開發和運維成本風險 
    網際網路公司背後有大量的資料庫相關的運維專家和人力投入以支援二代架構的開發和運維,這不是傳統企業的技術體制和人力資源池能夠輕鬆支撐的。