Sharding-JDBC簡介及適用場景
大小：0.5 MB 人氣： 2017-10-12 需要積分：1
雖然很多公司都致力于開發自己的分庫分表中間件，但截止目前，仍無完美的開源解決方案覆蓋此領域。
分庫分表適用場景
分庫分表用于應對當前互聯網常見的兩個場景——大數據量和高并發。通常分為垂直拆分和水平拆分兩種。
垂直拆分是根據業務將一個庫（表）拆分為多個庫（表）。如：將經常和不常訪問的字段拆分至不同的庫或表中。由于與業務關系密切，目前的分庫分表產品均使用水平拆分方式。
水平拆分則是根據分片算法將一個庫（表）拆分為多個庫（表）。如：按照ID的最后一位以3取余，尾數是1的放入第1個庫（表），尾數是2的放入第2個庫（表）等。
關系型數據庫在大于一定數據量的情況下檢索性能會急劇下降。在面對互聯網海量數據情況時，所有數據都存于一張表，顯然會輕易超過數據庫表可承受的數據量閥值。這個單表可承受的數據量閥值，需根據數據庫和并發量的差異，通過實際測試獲得。
單純的分表雖然可以解決數據量過大導致檢索變慢的問題，但無法解決過多并發請求訪問同一個庫，導致數據庫響應變慢的問題。所以通常水平拆分都至少要采用分庫的方式，用于一并解決大數據量和高并發的問題。這也是部分開源的分片數據庫中間件只支持分庫的原因。
但分表也有不可替代的適用場景。最常見的分表需求是事務問題。同在一個庫則不需考慮分布式事務，善于使用同庫不同表可有效避免分布式事務帶來的麻煩。目前強一致性的分布式事務由于性能問題，導致使用起來并不一定比不分庫分表快。目前采用最終一致性的柔性事務居多。分表的另一個存在的理由是，過多的數據庫實例不利于運維管理。綜上所述，最佳實踐是合理地配合使用分庫+分表。
Sharding-JDBC簡介
Sharding-JDBC是當當應用框架ddframe中，從關系型數據庫模塊dd-rdb中分離出來的數據庫水平分片框架，實現透明化數據庫分庫分表訪問。Sharding-JDBC是繼dubbox和elastic-job之后，ddframe系列開源的第3個項目。
Sharding-JDBC直接封裝JDBC API，可以理解為增強版的JDBC驅動，舊代碼遷移成本幾乎為零：
可適用于任何基于Java的ORM框架，如JPA、Hibernate、Mybatis、Spring JDBC Template或直接使用JDBC。可基于任何第三方的數據庫連接池，如DBCP、C3P0、 BoneCP、Druid等。理論上可支持任意實現JDBC規范的數據庫。雖然目前僅支持MySQL，但已有支持Oracle、SQLServer等數據庫的計劃。
Sharding-JDBC定位為輕量Java框架，使用客戶端直連數據庫，以jar包形式提供服務，無proxy代理層，無需額外部署，無其他依賴，DBA也無需改變原有的運維方式。
Sharding-JDBC分片策略靈活，可支持等號、between、in等多維度分片，也可支持多分片鍵。
SQL解析功能完善，支持聚合、分組、排序、limit、or等查詢，并支持Binding Table以及笛卡爾積表查詢。
與常見開源產品對比
為了對其他開源項目表示尊重，我們無意評論目前仍在更新中的項目。這里僅列出目前停止更新，但仍然在數據庫分片領域非常有影響力的幾個項目，請參見表1。
表1 數據庫分片工具對比
通過以上表格可以看出，Cobar屬于中間層方案，在應用程序和MySQL之間搭建一層Proxy。中間層介于應用程序與數據庫間，需要做一次轉發，而基于JDBC協議并無額外轉發，直接由應用程序連接數據庫，性能上有些許優勢。這里并非說明中間層一定不如客戶端直連，除了性能，需要考慮的因素還有很多，中間層更便于實現監控、數據遷移、連接管理等功能。
Cobar-Client、TDDL和Sharding-JDBC均屬于客戶端直連方案。此方案的優勢在于輕便、兼容性、性能以及對DBA影響小。其中Cobar-Client的實現方式基于ORM（Mybatis）框架，其兼容性與擴展性不如基于JDBC協議的后兩者。
實現原理
前文已介紹了Sharding-JDBC是實現了JDBC協議的jar文件。基于JDBC協議的實現與基于MySQL等數據庫協議實現的中間層略有差別。
無論使用哪種架構，核心邏輯均極為相似，除了協議實現層不同（JDBC或數據庫協議），都會分為分片規則配置、SQL解析、SQL改寫、SQL路由、SQL執行以及結果歸并等模塊。
非常好我支持^.^
(0) 0%
不好我反對
(0) 0%