解決的問題
目前已經面臨或者未來可能面臨的問題有以下這些:
1.數據量越來越大,超出了單表或者單庫的最大限制。
2.數據訪問壓力越來越大,超出了數據庫系統能力。訪問壓力可能出現讀壓力過大或者寫壓力過大。
3.數據訪問層運維問題。
4.數據訪問層高可用方案。
5.數據訪問層訪問控制和管理。
暫時不解決的問題包括:
對非關系型數據存儲的統一訪問。
自主開發還是擴展?
為了解決上述問題,有很多可選的方案。自主開發和使用現有開源方案擴展的討論是經常會面臨的,詳細討論過程就不再贅述,直接列出討論的結果。
結論:基于目前開源方案進行擴展和定制實現。具體原因有以下這些:
a.我們的使用場景很簡單,大多數開源解決方案都可以很好地實現,而且目前有很多可選的開源方案,直接使用開源方案可行。
b.完全自主開發的周期更長、技術風險都非常大,這都是咱們無法承擔的。
c.選擇一個源代碼開放、需求最符合、代碼能夠擴展和定制的開源產品可行。基于該開源產品,通過
不斷深入學習使用方法,學習實現原理和源代碼實現,達到可以自由擴展和定制,以改造成完全符合
自身需求的產品。
技術方案選型可選方案分類概述
對于ddal來說,最核心的一個需求莫過于分庫分表,而對于分庫分表,已經有很多的開源產品出現了,比如cobar-、 、guzz、halo-dal、-、cobar、mysql proxy、tddl等。每一個產品都有針對于不同層面進行封裝而達到屏蔽上層對底層分庫分表的具體細節的依賴,都是加載數據庫訪問客戶端和服務端之間的一些中間層。
總結一下上述列出的各種解決方案可以歸納為一下幾大類。
1.DAO層。該方案即通過在實現DAO層代碼時候,通過硬編碼的方式加入分庫分表的邏輯,該層實現一般由項目組自行根據需求實現。
2.ORM框架層。該方案的實現是通過實現一個ORM框架,該框架自帶分庫分表功能,如:guzz;另外一種方式是基于開源成熟的ORM框架(比如、)進行擴展分庫分表特性淘寶數據庫包含哪些表,主要的開源產品有:cobar-、 shard、shalo-dal、-。
3.JDBC API層。該方案通過封裝JDBC API,實現分庫分表邏輯,這個方法比較直接,而且有比較強的可控制性,目前有淘寶開源的tddl,但是目前不支持分庫分表,只支持讀寫分離、主備自動切換,故障轉移等特性。
4.數據訪問代理層。該方案通過位于客戶端和服務端中間的代理服務器實現分庫分表邏輯,主要產品有mysql proxy、Cobar和等。
5.數據庫分區。該方案是數據庫自行實行的分庫分表特性。目前主流的關系型數據庫,商業數據庫、SQL 和DB2早就有非常成熟的數據庫分區解決方案,而主流的開源數據庫MySQL和也在5.0和8.0版本也增加了數據庫表分區的特性。
如上圖所示,展示的是各種方案之間的關系,還包括了各種方案所處的層次,圖中帶顏色的各區塊表示的是各種實現方案。
上圖中的關系是越處于下方的層次越低,上層的總是依賴下層,下層不依賴上層。各種層次的實現方案都有自己的優缺點,有自己適合的場景。
可選方案對比分析
各種可選方案都能夠從不能程度上實現分庫分表的核心需求,每種方案都有自己的優勢和適合的應用場景,同時也有它的缺點和使用上的限制,通過對各種方案的詳細各種因素的綜合對比分析才能選擇一個最適合一種或者多種方案的組合。
產品分類 產品名稱 優點 缺點 支持的特性 限制和約束 產品成熟度 開源協議 開發語言 產品主頁
DAO層
無開源產品,需參考
開放方案自行實現,在DAO
層代碼中實現分庫分表的邏輯。
實現簡單
依賴少
自由度大
成本高
周期長
分庫分表等
可自行實現任何特性
自身技術能力約束
無
ORM框架層
cobar-
簡單易用,無需引入代理服務層
與框架良好集成
與數據庫無關,支持各種數據庫
對于使用的框架及版本號都 有較強的約束,而且對于使用的框架也有版本約束,對于應用的侵入性較大,需要修改應用才能使用。
可以支持垂直和水平數據切分數據庫集群的訪問;支持雙機熱備的HA解決方案,小數據量的數據集計(), 暫時只支持簡單的數據合并.數據庫本地事務的支持, 目前采用Best 1PC模式的事務管理.數據訪問操作相關SQL的記錄, 分析等
對于和等框架的版本號有約束
成熟
java
JDBC API層
tddl
支持的特性較豐富。
遵守JDBC規范,對于應用過的侵入性較小,能夠很方便的應用在現有的應用中。
支持的數據豐富,支持MySQL和,可以方便的擴展支持其它數據庫。
開源版本目前不支持分庫分表,
強依賴配置中心項目,
1.數據庫主備和動態切換
2.帶權重的讀寫分離
3.單線程讀重試
4.集中式數據源信息管理和動態變更
5.剝離的穩定jboss數據源
6.支持mysql和數據庫
7.基于jdbc規范,很容易擴展支持實現jdbc規范的數據源
8.無,-jar形式存在,應用直連數據庫
9.讀寫次數,并發度流控,動態變更
10.可分析的日志打印,日志流控,動態變更
開源版本暫不支持分庫分表
成熟
java
數據訪問代理層
可以支持垂直和水平數據切分數據庫集群的訪問;
支持雙機熱備的HA解決方案
不支持跨庫情況下的join、分頁、排序、子查詢操作。
SET語句執行會被忽略,事務和字符集設置除外。
分庫情況下,語句必須包含拆分字段列名。
分庫情況下,語句不能更新拆分字段的值。
不支持操作。
暫時只支持MySQL數據節點。
使用JDBC時,不支持ents=true參數設置(默認為false)。
使用JDBC時,不支持=true參數設置(默認為false)。
使用JDBC時,BLOB, , 字段不能使用()或()方法設置參數。
暫時只支持MySQL數據庫。
成熟
java
最終方案
最終結論:
通過對比分析后最終的結論如下:
基于開源的tddl+cobar集成,再通過適當的擴展和定制最終實現符合自身需求的分布式數據訪問層服務。
原因如下:
1.tddl和cobar都是遵循標準協議的實現方式。使用這些方案后應用的改動都比較小,通用性較強,基本上所有的項目都能夠很方便的應用這種方案。
2.tddl實現了主備切換、讀寫分離、動態數據源、數據訪問層運維支持、訪問控制等特性淘寶數據庫包含哪些表,而cobar垂直和水平切分、高可用等特性。兩種方案的集成使用
能夠解決目前數據訪問層的大部分問題,功能強大。
3.都是使用Java語言編寫的開源項目。能夠通過不斷深入學習其源代碼,將其改造成完全符合自身需求的ddal。
4.都是非常成熟的產品。這兩個產品都是阿里集團下的公司開源出來的產品,經過了大量的生產環境驗證,質量和穩定性有保障。
Tddl( Data Layer)是整個淘寶數據庫體系里面具有非常重要的一個中間件產品,在公司內部具有廣泛的使用。
Cobar是關系型數據的分布式處理系統,它可以在分布式的環境下看上去像傳統數據庫一樣為您提供海量數據服務。
產品的約束如何解決?
對于任何DDAL產品都有自身的一些約束和局限性,無法完全與直接訪問數據庫那樣自由和特性強大,對于DDAL產品無法支持的特性,那么該如何解決呢?
1.適當放棄某些特性。例如分布式事務,在某些數據上可以放棄該需求。
2.增加替代方案或者補償機制。通過增加一些替代的解決方案來解決特性的缺失,如應用自行實現某些特性等,或者通過一些補償機制來彌補某些特性的缺失。
實施計劃
最終該方案想最終應用到項目中,需要經過一個過程,具體的實施計劃如下。
1.測試cobar和tddl的功能特性和性能指標。
測試這兩個開源產品的功能特性是否滿足要求,質量是否可靠;
引入這些產品后必然對性能產生一定影響,通過性能測試掌握其性能損耗量是否可接受。
2.在項目中小范圍應用。在某些數據量大的項目中嘗試使用該方案。
3.項目試運行。觀察使用本方案的項目的運行效果,對于發現的問題及時解決。
4.持續研究增加新特性。通過持續研究這兩個開源產品的原理及實現代碼,擴展或者調整為完全符合自身需求的ddal產品。