資料庫分庫分表(sharding)系列(三) 關於使用框架還是自主開發以及sharding實現層面的考量
一、sharding邏輯的實現層面
從一個系統的程式架構層面來看,sharding邏輯可以在DAO層、JDBC API層、介於DAO與JDBC之間的Spring資料訪問封裝層(各種spring的template)以及介於應用伺服器與資料庫之間的sharding代理伺服器四個層面上實現。
圖1. Sharding實現層面與相關框架/產品
- 在DAO層實現
當團隊決定自行實現sharding的時候,DAO層可能是嵌入sharding邏輯的首選位置,因為在這個層面上,每一個DAO的方法都明確地知道需要訪問的資料表以及查詢引數,藉助這些資訊可以直接定位到目標shard上,而不必像框架那樣需要對SQL進行解析然後再依據配置的規則進行路由。另一個優勢是不會受ORM框架的制約。由於現在的大多數應用在資料訪問層上會依賴某種ORM框架,而多數的shrading框架往往無法支援或只能支援一種orm框架,這使得在選擇和應用框架時受到了很大的制約,而自行實現sharding完全沒有這方面的問題,甚至不同的shard使用不同的orm框架都可以在一起協調工作。比如現在的java應用大多使用hibernate,但是當下還沒有非常令人滿意的基於hibernate的sharding框架,(關於hibernate hards會在下文介紹),因此很多團隊會選擇自行實現sharding。
簡單總結一下,在DAO層自行實現sharding的優勢在於:不受ORM框架的制約、實現起來較為簡單、易於根據系統特點進行靈活的定製、無需SQL解析和路由規則匹配,效能上表現會稍好一些;劣勢在於:有一定的技術門檻,工作量比依靠框架實現要大(反過來看,框架會有學習成本)、不通用,只能在特定系統裡工作。當然,在DAO層同樣可以通過XML配置或是註解將sharding邏輯抽離到“外部”,形成一套通用的框架. 不過目前還沒有出現此類的框架。
- 在ORM框架層實現
- 在JDBC API層實現
- 在介於DAO與JDBC之間的Spring資料訪問封裝層實現
- 在應用伺服器與資料庫之間通過代理實現
二、使用框架還是自主開發?
前面的討論中已經羅列了很多開源框架與產品,這裡再整理一下:基於代理方式的有MySQL Proxy和Amoeba,基於Hibernate框架的是Hibernate Shards,通過重寫spring的ibatis template類是Cobar Client,這些框架各有各的優勢與短板,架構師可以在深入調研之後結合專案的實際情況進行選擇,但是總的來說,我個人對於框架的選擇是持謹慎態度的。一方面多數框架缺乏成功案例的驗證,其成熟性與穩定性值得懷疑。另一方面,一些從成功商業產品開源出框架(如阿里和淘寶的一些開源專案)是否適合你的專案是需要架構師深入調研分析的。當然,最終的選擇一定是基於專案特點、團隊狀況、技術門檻和學習成本等綜合因素考量確定的。
相關閱讀: