分庫分表sharding jdbc
資料庫分庫分表從網際網路時代開啟至今，一直是熱門話題。在NoSQL橫行的今天，關係型資料庫憑藉其穩定、查詢靈活、相容等特性，仍被大多數公司作為首選資料庫。因此，合理採用分庫分表技術應對海量資料和高併發對資料庫的衝擊，是各大網際網路公司不可避免的問題。
雖然很多公司都致力於開發自己的分庫分表中介軟體，但截止目前，仍無完美的開源解決方案覆蓋此領域。
分庫分表適用場景
分庫分表用於應對當前網際網路常見的兩個場景——大資料量和高併發。通常分為垂直拆分和水平拆分兩種。
垂直拆分是根據業務將一個庫（表）拆分為多個庫（表）。如：將經常和不常訪問的欄位拆分至不同的庫或表中。由於與業務關係密切，目前的分庫分表產品均使用水平拆分方式。
水平拆分則是根據分片演算法將一個庫（表）拆分為多個庫（表）。如：按照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。
通過以上表格可以看出，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執行以及結果歸併等模組。
Sharding-JDBC的整體架構圖參見圖1。
分片規則配置
Sharding-JDBC的分片邏輯非常靈活，支援分片策略自定義、複數分片鍵、多運算子分片等功能。
如：根據使用者ID分庫，根據訂單ID分表這種分庫分表結合的分片策略；或根據年分庫，月份+使用者區域ID分表這樣的多片鍵分片。
Sharding-JDBC除了支援等號運算子進行分片，還支援in/between運算子分片，提供了更加強大的分片功能。
Sharding-JDBC提供了spring名稱空間用於簡化配置，以及規則引擎用於簡化策略編寫。由於目前剛開源分片核心邏輯，這兩個模組暫未開源，待核心穩定後將會開源其他模組。
JDBC規範重寫
Sharding-JDBC對JDBC規範的重寫思路是針對DataSource、Connection、Statement、PreparedStatement和ResultSet五個核心介面封裝，將多個真實JDBC實現類集合（如：MySQL JDBC實現/DBCP JDBC實現等）納入Sharding-JDBC實現類管理。
Sharding-JDBC儘量最大化實現JDBC協議，包括addBatch這種在JPA中會使用的批量更新功能。但分片JDBC畢竟與原生JDBC不同，所以目前仍有未實現的介面，包括Connection遊標，儲存過程和savePoint相關、ResultSet向前遍歷和修改等不太常用的功能。此外，為了保證相容性，並未實現JDBC 4.1及其後釋出的介面（如：DBCP 1.x版本不支援JDBC 4.1）。
SQL解析
SQL解析作為分庫分表類產品的核心，效能和相容性是最重要的衡量指標。目前常見的SQL解析器主要有fdb/jsqlparser和Druid。Sharding-JDBC使用Druid作為SQL解析器，經實際測試，Druid解析速度是另外兩個解析器的幾十倍。
目前Sharding-JDBC支援join、aggregation（包括avg）、order by、 group by、limit、甚至or查詢等複雜SQL的解析。目前不支援union、部分子查詢、函式內分片等不太應在分片場景中出現的SQL解析。
SQL改寫
SQL改寫分為兩部分，一部分是將分表的邏輯表名稱替換為真實表名稱。另一部分是根據SQL解析結果替換一些在分片環境中不正確的功能。這裡具兩個例子：
第1個例子是avg計算。在分片的環境中，以avg1 +avg2+avg3/3計算平均值並不正確，需要改寫為（sum1+sum2+sum3）/（count1+count2+ count3）。這就需要將包含avg的SQL改寫為sum和count，然後再結果歸併時重新計算平均值。
第2個例子是分頁。假設每10條資料為一頁，取第2頁資料。在分片環境下獲取limit 10, 10，歸併之後再根據排序條件取出前10條資料是不正確的結果。正確的做法是將分條件改寫為limit 0, 20，取出所有前2頁資料，再結合排序條件算出正確的資料。可以看到越是靠後的Limit分頁效率就會越低，也越浪費記憶體。有很多方法可避免使用limit進行分頁，比如構建記錄行記錄數和行偏移量的二級索引，或使用上次分頁資料結尾ID作為下次查詢條件的分頁方式。
SQL路由
SQL路由是根據分片規則配置，將SQL定位至真正的資料來源。主要分為單表路由、Binding表路由和笛卡爾積路由。
單表路由最為簡單，但路由結果不一定落入唯一庫（表），因為支援根據between和in這樣的操作符進行分片，所以最終結果仍然可能落入多個庫（表）。
Binding表可理解為分庫分表規則完全一致的主從表。舉例說明：訂單表和訂單詳情表都根據訂單ID作為分片鍵，任意時刻分片邏輯均相同。這樣的關聯查詢和單表查詢難度和效能相當。
笛卡爾積查詢最為複雜，因為無法根據Binding關係定位分片規則的一致性，所以非Binding表的關聯查詢需要拆解為笛卡爾積組合執行。查詢效能較低，而且資料庫連線數較高，需謹慎使用。
SQL執行
路由至真實資料來源後，Sharding-JDBC將採用多執行緒併發執行SQL，並完成對addBatch等批量方法的處理。
結果歸併
結果歸併包括4類：普通遍歷類、排序類、聚合類和分組類。每種型別都會先根據分頁結果跳過不需要的資料。
普通遍歷類最為簡單，只需按順序遍歷ResultSet的集合即可。
排序類結果將結果先排序再輸出，因為各分片結果均按照各自條件完成排序，所以採用歸併排序演算法整合最終結果。
聚合類分為3種類型，比較型、累加型和平均值型。比較型包括max和min，只返回最大（小）結果。累加型包括sum和count，需要將結果累加後返回。平均值則是通過SQL改寫的sum和count計算，相關內容已在SQL改寫涵蓋，不再贅述。
分組類最為複雜，需要將所有的ResultSet結果放入記憶體，使用map-reduce演算法分組，最後根據排序和聚合條件做相關處理。最消耗記憶體，最損失效能的部分即是此，可以考慮使用limit合理的限制分組資料大小。
結果歸併部分目前並未採用管道解析的方式，之後會針對這裡做更多改進。
效能
路由結果在單庫單表的效能測試報告：
查詢操作：Sharding-JDBC的TPS為JDBC的TPS的99.8%；
插入操作：Sharding-JDBC的TPS為JDBC的TPS的90.2%；
更新操作：Sharding-JDBC的TPS為JDBC的TPS的93.1%；
可以看到，Sharding-JDBC效能損失非常低。
路由結果在多庫多表的效能測試報告：
查詢操作：TPS雙庫比單庫可以增加大約94%的效能；
插入操作：TPS雙庫比單庫可以增加大約60%的效能；
更新操作：TPS雙庫比單庫可以增加大約89%的效能；
結果表明，Sharding-JDBC可有效利用多執行緒與分散式資源大幅度提升效能；
更多詳細情況可檢視Sharding-JDBC的效能測試報告。
Roadmap
目前Sharding-JDBC集中於分庫分表核心邏輯開發，在功能穩定之後將會按照如下線路持續更新：
- 讀寫分離；
- 柔性分散式事務；
- 分散式主鍵生成策略；
- SQL重寫優化，進一步提升效能；
- SQL Hint，可指定某SQL在某具體庫表執行，基於業務規則而非SQL解析路由；
小表廣播； - HA相關；
- 流量控制；
- 資料庫建表工具；
- 資料遷移；
- 複雜SQL解析支援，如子查詢、儲存過程等；
- Oracle， SQLServer支援；
- 配置中心；
開源理念
目前國內很多開源產品都在公司內部經受過時間的考驗，然後剝離業務邏輯和敏感程式碼，再開源貢獻給社群。這樣做的優點是開源的產品相對成熟。但缺點也不可避免，主要有：
- 後續支援匱乏。產品已經滿足了該公司的業務場景需求，缺乏後續提升的動力。文件、支援也會相對較少，甚至出現文件和程式碼不同步的狀況。
- 與該公司業務場景耦合較為嚴重。大部分框架產品都是為了解決特定的問題。比如：有的公司可能並不需要分表；有的公司只需支援幾種分片策略就好。
- 開源不完整。和公司業務耦合緊密的部分不會開源。
- 缺乏粘度。較為成型的專案由於功能繁多、程式碼結構複雜，社群志願者難於擴充套件或修改核心邏輯。如果測試覆蓋率不夠，難以保證修改後的程式碼質量。以上一系列問題會導致專案對社群的粘度不高，難於找尋可合作開發的志願者。
- 分支眾多難於維護。由於開源之後公司缺乏持續提升的動力，和本公司關係不大的需求功能得不到重視，導致各公司都開發自己的分支。開源專案雖然一開始給社群注入了新鮮思想，但最終並沒有吸取社群精華。如：Dubbo一出現即引起了相當多的關注，而各公司都有自己的版本，如噹噹的DubboX，但最終Dubbo並未能持續發展。
我們考慮全新的開源策略，在Sharding-JDBC剛完成初版的時候，即向社群和噹噹內部同時推廣。這樣做的好處有：
- 後續支援完善。Sharding-JDBC與噹噹內部落地繫結，將會在噹噹內部和社群同時提供支援。雖然無法提供社群需求的優先順序高於噹噹內部的承諾，但我們會綜合考慮社群與內部的需求，以更高的視角，儘量整合與優化升級路線。
- 完整開源。程式碼的snapshot版本都會首先出現在GitHub上。
- 共同發展。Sharding-JDBC目前程式碼較為簡單。使社群開源愛好者能更加輕鬆地理解程式碼核心，為以後的持續發展奠定基礎。並且Sharding-JDBC也會吸納社群精華，讓更多地愛好者參與程式碼貢獻。
最後需要澄清，未經時間考證的Sharding-JDBC並非Bug成堆，完全不可用的專案。目前測試覆蓋率超過90%，詳細功能以及不支援項都明確地羅列在GitHub的文件中，希望讓使用者心中有數。