TopDB產品分析
1.1產品的背景
1.2用戶需求和產品定位
1.3相關數據庫的分析
1.4TopDB架構
1.5
TopDB的未來規劃
?
1.1產品的背景
自從斯諾克事件引發國家對信息安全的憂慮,要求金融、通訊等核心領域逐漸使用自主可控的軟件、硬件來替代傳統的IOE廠商。其中重中之重就是數據庫,而在銀行業,DB2和Oracle兩家就占了70%以上的份額。從政治層面上來說,國家已要求各大銀行開始逐漸嘗試使用自主可控的數據庫來替代傳統的Oracle、DB2。同時也可以看出,近年來隨著互聯網金融領域的崛起,銀行也存在對成本控制的問題,之前動輒數十萬一個license的數據庫對于銀行來說,也同樣需要考慮成本和收益。除此之外,不滿足傳統單機數據庫,要求數據庫替代產品具有可擴展性等要求。這些要求是銀行領域要求使用新型數據庫的背景。
?
1.2產品定位
考慮銀行的核心需求:
1.要求數據庫自主可控,這要求數據庫要么使用開源產品,要么自研,或者兩者結合。
2.保證數據庫具有傳統Oracle、DB2的基本特性,可以理解為具有數據庫的ACID特性。
3.要求具有可擴展性,暗含使用MPP分布式并行處理架構。
4.對現有系統系統影響最小
5.其他數據庫需求,如高可用、異地容災等。
基于以上背景,我們的產品定位是能夠替代Oracle、DB2的具有可擴展性的分布式關系型數據庫。要求滿足:
1.是傳統的關系型數據庫
2.滿足數據庫的ACID屬性,尤其是銀行的事務屬性。
3.同時支持OLTP和OLAP
4.采用分布式架構,具有高可擴展性
從以上的定位可以看出,我們的數據庫首先仍然是傳統的關系型數據庫,具有分布式架構,同時需要在分布式架構下解決事務實時一致性問題。從客戶的角度來說,本身銀行業雖然是IT行業最重要的領域,但是也是對新技術最保守的行業。因此,要想逐步替代傳統的Oracle、DB2數據庫來說,最好的辦法還是使用通用的關系型數據庫來替代。同時,在此基礎上,使用并行處理框架,采用分布式架構。采用分布式架構帶來的好處是很容易進行線性擴展,包括存儲、性能上的擴展。但是分布式架構帶來的問題是CAP理論決定的,在分布式情況下,一致性和可服務性難以同時支持。因此需要在可服務性和一致性之間尋找一個平衡點。
?
1.3相關數據庫產品的分析
? ? 數據庫按照其架構特點,可以分為傳統的關系型數據庫OldSQL、NoSQL、NewSQL。
? ? 從技術路線上來說,NoSQL主要是非結構化的形式來存儲數據,大多數是基于KV的形式來存儲數據,要求查詢場景基本固定,特別適用于互聯網行業。其代表為DynamoDB、BigTable、HBase等,使用的廠家包括:Google、Facebook、阿里等。NoSQL處理非結構化數據占據優勢,但是對于銀行系統來說,最大問題還是不滿足ACID屬性。
? ? ?
NewSQL從技術上來講,一般是以列式形式存儲數據,這也決定了其批量讀取速度快、存儲空間小的特點,適用于OLAP分析型應用。但是對于現階段的銀行應用來說,其最大問題是實時的更新刪除速度響應比較慢,無法滿足金融行業實時性要求。其代表的廠商有Vertica、Greenplum、GBase等。
? ? 而OldSQL也即基于行式存儲的關系型數據庫,大的廠商有如Oracle、DB2,但是其本身成本大,同時對于一些海量數據,其本身也無法很好支撐,存在性能上的天花板。另外還有一些優秀的開源數據庫如MySQL、PostgreSQL、MariaDB等,這些數據庫本身在中小企業、互聯網領域應用也都比較多。其本身最大的問題是本身數據庫可以支撐的數據有限,并不支持海量的數據。
總結如下:
數據庫類型
|
最大特性
|
優勢 |
劣勢
|
代表廠商
|
OldSQL
|
1.基于行的關系型數據庫
2.支持ACID
|
產業鏈成熟
同時支持OLAP和OLTP
|
擴展性差
價格高昂
性能有限
|
DB2 Oracle
MySQL PostgreSQL
|
NewSQL
|
1.基于列的關系型數據庫
2.支持ACID
?
|
批量讀取速度快
存儲壓縮
?
|
對于OLTP實時型差
|
Vertica
Greenplum
GBase
|
NoSQL
|
基于KV存儲
內存數據庫 |
讀取速度快
海量存儲
可擴展性強
適用于OLAP
|
產業鏈不成熟
對事務支持有限
?
|
HBase DynamoDB BigTable Memecached
|
?
1.4TopDB產品分析
TopDB架構如上圖所示,類似于Greenplum、阿里的TDDL架構。下面簡單分析下TopDB的架構
數據存儲層是采用MPP架構,數據根據規則分配在所有數據庫上,每個數據庫采用主備同步保證系統高可用性。對于前置中間件來說,一方面他需要將客戶端下發來的SQL語句處理后下發到對應的數據節點上,另外一方面他需要將底層數據庫返回的結果匯聚處理后返回給客戶端。而對于數據庫事務,通過全局事務處理中心來進行分布式事務控制。
?
其架構優點:
1.采用傳統的關系型數據庫,能夠保持ACID屬性。
2.采用分布式架構,數據分布在不同節點上,可擴展性強
3.數據節點、前置中間件節點都采用集群的方式對外提供服務,本身不會出現單節點的故障和性能瓶頸。
4.分布式架構,請求可以均分到多個數據節點上,其性能強勁,支持高并發
?
架構缺點:
1.對于大規模的跨庫關聯查詢,其速度回比較慢(需要將數據撈出來后,放在前置中間計算結果)
2. 對于單個SQL語句來說,其需要經過前置中間件分析,執行的時延會增長。SQL語句的時延依賴于前置中間件的性能。
?
架構難點:
1.前置中間件需要做語法解析和SQL計劃,這塊就需要對SQL語言的分析過程了解透徹。
2.由于數據分布在多個節點,必須通過特殊機制才能保證分布式事務的實時一致性。
?
架構分析:
? ? ? ? 從TopDB的架構可以看出,底層的數據庫集群仍然是MySQL這樣的關系型數據庫,多個關系型數據庫上構建成數據庫集群,再加上前置中間件對外包裝成一個數據庫整體對外服務。本身是關系型數據庫,對當前銀行使用的數據庫是一個繼承關系,滿足通用性數據庫要求。同時通過MPP分布式并行處理架構,使得系統具有良好的可擴展性。除此之外通過分布式事務處理機制,保證可以實現分布式事務控制。在此之外,通過前置中間件集群、數據庫雙擊和集群可以看出系統不存在單點故障和性能瓶頸,具有良好的高可用性和可擴展性。
? ? ? ? 從以上的分析可以看出TopDB能夠作為銀行領域替換Oracle、DB2的替代產品。但是需要注意的是前置中間件需要做語法解析和計劃,因此需要考慮設計成滿足通用的SQL語法,這對前置中間件的要求非常高。
?
1.5TopDB的未來規劃
? ? ? ? TopDB的未來規劃的內容主要包含幾個方面,一方面是前置中間中自身語法解析、SQL計劃的性能優化和提升、系統時延的降低、并發的提升。另外一方面本身TopDB作為同時具有OLTP和OLAP特性的通用型數據庫,在做大規模跨庫的關聯查詢時,性能會下降厲害,因此需要考慮如何加強OLAP這塊的性能。
? ? ? ?上述前者主要是對自身內部的優化,而后者就需要在系統層面上考慮TopDB的架構設計了。其中一個思路是將TopDB和大數據系統進行對接,利用大數據系統來進行OLAP分析類應用,將TopDB和BigData作為整體對外提供服務。TopDB和BigData通過接口將兩邊的數據進行對接,TopDB將數據吐給BigData進行分析,BigData將分析后的數據再返回給TopDB。
? ? ? ? 另外一個思路是利用新型的列式存儲來完成OLAP,但是列式存儲和行式存儲本身只能兩者取其一,兩者結合使用除了使用數據導入導出方法以外,如何將兩者進行結合到現在為止仍然沒有很好的思路。
?
1.6總結
? ? ? ? 順應時代的要求,在銀行領域替換Oracle、DB2數據庫,因此設計成通用型的關系型數據庫,同時考慮系統擴展性,采用MPP分布式并行處理架構。從產品本身來說,十分貼切銀行的真實需求,但是同時也需要看到,架構中前置中間件需要做的事情很多,難度較大。從產品的應用前景來看,在金融領域、通訊領域,證券領域,這些本身相對保守需要使用關系型數據庫來保存數據,同時又由于數據量和性能要求的增加需要提升系統容量和性能的領域。
? ? ? ?金融和通訊為了提升系統性能和降低成本,使用開源或者國產通用型數據庫替代Oracle、DB2將是一個延續不斷地過程。有如互聯網領域去IOE的態勢一樣,這些領域將在未來若干年,逐漸使用其他替代產品來替換Oracle和DB2。不同的技術路線如NoSQL和NewSQL都會存在一些生存空間,NoSQL適用于銀行領域對應于靠近互聯網的應用。而NewSQL適用于這些領域的數據倉庫。這些領域需要能夠找到同時滿足OLTP和OLAP的通用型數據庫,同時又具有高性能和大存儲,因此我們的TopDB應孕而生。
更多文章、技術交流、商務合作、聯系博主
微信掃碼或搜索:z360901061

微信掃一掃加我為好友
QQ號聯系: 360901061
您的支持是博主寫作最大的動力,如果您喜歡我的文章,感覺我的文章對您有幫助,請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧,狠狠點擊下面給點支持吧,站長非常感激您!手機微信長按不能支付解決辦法:請將微信支付二維碼保存到相冊,切換到微信,然后點擊微信右上角掃一掃功能,選擇支付二維碼完成支付。
【本文對您有幫助就好】元
