DDAL技術方案選型

DDAL技術方案選型

(轉自:http://ywbrj042.iteye.com/blog/1923890)

 

解決的問題

目前已經面臨或者將來可能面臨的問題有如下這些：

1.數據量愈來愈大，超出了單表或者單庫的最大限制。

2.數據訪問壓力愈來愈大，超出了數據庫系統能力。訪問壓力可能出現讀壓力過大或者寫壓力過大。

3.數據訪問層運維問題。

4.數據訪問層高可用方案。

5.數據訪問層訪問控制和管理。

暫時不解決的問題包括：

對非關係型數據存儲的統一訪問。

自主開發仍是擴展？

爲了解決上述問題，有不少可選的方案。自主開發和使用現有開源方案擴展的討論是常常會面臨的，詳細討論過程就再也不贅述，直接列出討論的結果。

結論：基於目前開源方案進行擴展和定製實現。具體緣由有如下這些：

a.咱們的使用場景很簡單，大多數開源解決方案均可以很好地實現，並且目前有不少可選的開源方案，直接使用開源方案可行。

b.徹底自主開發的週期更長、技術風險都很是大，這都是我們沒法承擔的。

c.選擇一個源代碼開放、需求最符合、代碼可以擴展和定製的開源產品可行。基於該開源產品，經過

不斷深刻學習使用方法，學習實現原理和源代碼實現，達到能夠自由擴展和定製，以改形成徹底符合

自身需求的產品。

技術方案選型

可選方案分類概述

對於ddal來講，最核心的一個需求莫過於分庫分表，而對於分庫分表，已經有不少的開源產品出現了，好比cobar-client、hibernate shards、guzz、halo-dal、ibatis-sharding、cobar、mysql proxy、tddl等。每個產品都有針對於不一樣層面進行封裝而達到屏蔽上層對底層分庫分表的具體細節的依賴，都是加載數據庫訪問客戶端和服務端之間的一些中間層。

總結一下上述列出的各類解決方案能夠概括爲一下幾大類。

1.DAO層。該方案即經過在實現DAO層代碼時候，經過硬編碼的方式加入分庫分表的邏輯，該層實現通常由項目組自行根據需求實現。

2.ORM 框架層。該方案的實現是經過實現一個ORM框架，該框架自帶分庫分表功能，如：guzz；另一種方式是基於開源成熟的ORM框架（好比MyBaits、HIbernate）進行擴展分庫分表特性，主要的開源產品有：cobar-client、hibernate shard、shalo-dal、ibatis-sharding。

3.JDBC API層。該方案經過封裝JDBC API，實現分庫分表邏輯，這個方法比較直接，並且有比較強的可控制性，目前有淘寶開源的tddl，可是目前不支持分庫分表，只支持讀寫分離、主備自動切換，故障轉移等特性。

4.數據訪問代理層。該方案經過位於客戶端和服務端中間的代理服務器實現分庫分表邏輯，主要產品有mysql proxy、Cobar和amoeba等。

5.數據庫分區。該方案是數據庫自行實行的分庫分表特性。目前主流的關係型數據庫，商業數據庫Oralce、SQL server和DB2早就有很是成熟的數據庫分區解決方案，而主流的開源數據庫MySQL和PostGre也在5.0和8.0版本也增長了數據庫表分區的特性。

 

如上圖所示，展現的是各類方案之間的關係，還包括了各類方案所處的層次，圖中帶顏色的各區塊表示的是各類實現方案。

上圖中的關係是越處於下方的層次越低，上層的老是依賴下層，下層不依賴上層。各類層次的實現方案都有本身的優缺點，有本身適合的場景。

可選方案對比分析

各類可選方案都可以從不能程度上實現分庫分表的核心需求，每種方案都有本身的優點和適合的應用場景，同時也有它的缺點和使用上的限制，經過對各類方案的詳細各類因素的綜合對比分析才能選擇一個最適合一種或者多種方案的組合。

產品分類 產品名稱 優勢 缺點 支持的特性 限制和約束 產品成熟度 開源協議 開發語言 產品主頁

DAO層	無開源產品，需參考 開放方案自行實現，在DAO 層代碼中實現分庫分表的邏輯。	實現簡單  依賴少  自由度大	成本高  週期長	分庫分表等  可自行實現任何特性	自身技術能力約束	無
ORM框架層	cobar-client	簡單易用，無需引入代理服務層  與ibatis框架良好集成  與數據庫無關，支持各類數據庫	對於使用的mybatis框架及版本號都 有較強的約束，並且對於使用的Spring框架也有版本約束，對於應用的侵入性較大，須要修改應用才能使用。	能夠支持垂直和水平數據切分數據庫集羣的訪問;支持雙機熱備的HA解決方案, 小數據量的數據集計(Aggregation), 暫時只支持簡單的數據合併. 數據庫本地事務的支持, 目前採用Best Efforts 1PC模式的事務管理. 數據訪問操做相關SQL的記錄, 分析等	對於mybatis和Spring等框架的版本號有約束	成熟		java	http://code.alibabatech.com/docs/cobarclient/zh/
JDBC API層	tddl	支持的特性較豐富。  遵照JDBC規範，對於應用過的侵入性較小，可以很方便的應用在現有的應用中。  支持的數據豐富，支持MySQL和Oracle，能夠方便的擴展支持其它數據庫。	開源版本目前不支持分庫分表，  強依賴diamond配置中心項目，	1.數據庫主備和動態切換  2.帶權重的讀寫分離   3.單線程讀重試   4.集中式數據源信息管理和動態變動   5.剝離的穩定jboss數據源  6.支持mysql和oracle數據庫  7.基於jdbc規範，很容易擴展支持實現jdbc規範的數據源  8.無server,client-jar形式存在，應用直連數據庫  9.讀寫次數,併發度流控，動態變動  10.可分析的日誌打印,日誌流控，動態變動	開源版本暫不支持分庫分表	成熟		java	https://github.com/alibaba/tb_tddl
數據訪問代理層	corbar			能夠支持垂直和水平數據切分數據庫集羣的訪問; 支持雙機熱備的HA解決方案	不支持跨庫狀況下的join、分頁、排序、子查詢操做。  SET語句執行會被忽略，事務和字符集設置除外。  分庫狀況下，insert語句必須包含拆分字段列名。  分庫狀況下，update語句不能更新拆分字段的值。  不支持SAVEPOINT操做。  暫時只支持MySQL數據節點。  使用JDBC時，不支持rewriteBatchedStatements=true參數設置(默認爲false)。  使用JDBC時，不支持useServerPrepStmts=true參數設置(默認爲false)。  使用JDBC時，BLOB, BINARY, VARBINARY字段不能使用setBlob()或setBinaryStream()方法設置參數。  暫時只支持MySQL數據庫。	成熟		java	http://code.alibabatech.com/wiki/display/cobar/Home

最終方案

最終結論：

經過對比分析後最終的結論以下：
基於開源的tddl+cobar集成，再經過適當的擴展和定製最終實現符合自身需求的分佈式數據訪問層服務。

緣由以下：

1.tddl和cobar都是遵循標準協議的實現方式。使用這些方案後應用的改動都比較小，通用性較強，基本上全部的項目都可以很方便的應用這種方案。

2.tddl實現了主備切換、讀寫分離、動態數據源、數據訪問層運維支持、訪問控制等特性，而cobar垂直和水平切分、高可用等特性。兩種方案的集成使用

可以解決目前數據訪問層的大部分問題，功能強大。

3.都是使用Java語言編寫的開源項目。可以經過不斷深刻學習其源代碼，將其改形成徹底符合自身需求的ddal。

4.都是很是成熟的產品。這兩個產品都是阿里集團下的公司開源出來的產品，通過了大量的生產環境驗證，質量和穩定性有保障。

Tddl(Taobao Distribute Data Layer)是整個淘寶數據庫體系裏面具備很是重要的一箇中間件產品，在公司內部具備普遍的使用。

Cobar是關係型數據的分佈式處理系統，它能夠在分佈式的環境下看上去像傳統數據庫同樣爲您提供海量數據服務。

• 產品在阿里巴巴B2B公司已經穩定運行了3年以上。
• 目前已經接管了3000+個MySQL數據庫的schema，爲應用提供數據服務。
• 據最近統計cobar集羣目前平均天天處理近50億次的SQL執行請求。

 

產品的約束如何解決？
對於任何DDAL產品都有自身的一些約束和侷限性，沒法徹底與直接訪問數據庫那樣自由和特性強大，對於DDAL產品沒法支持的特性，那麼該如何解決呢？
1.適當放棄某些特性。例如分佈式事務，在某些數據上能夠放棄該需求。
2.增長替代方案或者補償機制。經過增長一些替代的解決方案來解決特性的缺失，如應用自行實現某些特性等，或者經過一些補償機制來彌補某些特性的缺失。

實施計劃

最終該方案想最終應用到項目中，須要通過一個過程，具體的實施計劃以下。

1.測試cobar和tddl的功能特性和性能指標。

測試這兩個開源產品的功能特性是否知足要求，質量是否可靠；

引入這些產品後必然對性能產生必定影響，經過性能測試掌握其性能損耗量是否可接受。

2.在項目中小範圍應用。在某些數據量大的項目中嘗試使用該方案。

3.項目試運行。觀察使用本方案的項目的運行效果，對於發現的問題及時解決。

4.持續研究增長新特性。經過持續研究這兩個開源產品的原理及實現代碼，擴展或者調整爲徹底符合自身需求的ddal產品。