資料庫分庫分表 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資料訪問封裝層實現
- 在應用伺服器與資料庫之間通過代理實現
相關閱讀: