分庫分表：中間件方案對比

背景

分庫分表這個詞相信很多人都不陌生，在互聯網公司數據到達一定規模的時候，多數都會對數據進行分庫分表，或者也有人叫分片，英文翻譯為Sharding；

    更加准確來說我們常常關心的是水平分片，即單個業務的某些表到達一定規模后，即使建立索引也無法從根本上帶來很大的性能提升，這時我們會考慮把單表拆分。

以MySQL為例，B+樹索引的深度會隨着記錄的增多而逐漸加深，根據索引查詢的開銷也會越來越大，而單表拆分成多個表之后，B+樹深度降低，每個單表獨立查詢的速度也會加快，如果同時還分庫的話，並且在不同的實例上，大量的查詢壓力也會分擔到不同的機器上，這對單個數據庫機器減壓也帶來好處。

分庫分表的技術方案總體上來講分為兩大類：應用層依賴類中間件、中間層代理類中間件。

 
應用層依賴類中間件

這類分庫分表中間件的特點就是和應用強耦合，需要應用顯示依賴相應的jar包（以Java為例），比如知名的TDDL、當當開源的sharding-jdbc、蘑菇街的TSharding、攜程開源的Ctrip-DAL等。

此類中間件的基本思路

    就是重新實現JDBC的API，通過重新實現DataSource、PrepareStatement等操作數據庫的接口，讓應用層在基本（注意：這里用了基本）不改變業務代碼的情況下透明地實現分庫分表的能力。

    中間件給上層應用提供熟悉的JDBC API，內部通過sql解析、sql重寫、sql路由等一系列的准備工作獲取真正可執行的sql，然后底層再按照傳統的方法（比如數據庫連接池）獲取物理連接來執行sql，最后把數據結果合並處理成ResultSet返回給應用層。

優點

    就是無需額外部署，只要和應用綁定一起發布即可

缺點

    就是不能跨語言，比如Java寫的sharding-jdbc顯然不能用在C#項目中，所以攜程的dal也要重新寫一套C#的客戶端。

ShardingSphere

 

    ShardingSphere是一套開源的分布式數據庫中間件解決方案組成的生態圈，它由Sharding-JDBC、Sharding-Proxy和Sharding-Sidecar（計划中）這3款相互獨立的產品組成。 他們均提供標准化的數據分片、分布式事務和數據庫治理功能，可適用於如Java同構、異構語言、容器、雲原生等各種多樣化的應用場景。

    ShardingSphere定位為關系型數據庫中間件，旨在充分合理地在分布式的場景下利用關系型數據庫的計算和存儲能力，而並非實現一個全新的關系型數據庫。 它與NoSQL和NewSQL是並存而非互斥的關系。NoSQL和NewSQL作為新技術探索的前沿，放眼未來，擁抱變化，是非常值得推薦的。反之，也可以用另一種思路看待問題，放眼未來，關注不變的東西，進而抓住事物本質。 關系型數據庫當今依然占有巨大市場，是各個公司核心業務的基石，未來也難於撼動，我們目前階段更加關注在原有基礎上的增量，而非顛覆。

Sharding-JDBC

定位為輕量級Java框架，在Java的JDBC層提供的額外服務。 它使用客戶端直連數據庫，以jar包形式提供服務，無需額外部署和依賴，可理解為增強版的JDBC驅動，完全兼容JDBC和各種ORM框架。

    適用於任何基於Java的ORM框架，如：JPA, Hibernate, Mybatis, Spring JDBC Template或直接使用JDBC。
    基於任何第三方的數據庫連接池，如：DBCP, C3P0, BoneCP, Druid, HikariCP等。
    支持任意實現JDBC規范的數據庫。目前支持MySQL，Oracle，SQLServer和PostgreSQL。

 

Sharding-Proxy

定位為透明化的數據庫代理端，提供封裝了數據庫二進制協議的服務端版本，用於完成對異構語言的支持。 目前先提供MySQL版本，它可以使用任何兼容MySQL協議的訪問客戶端(如：MySQL Command Client, MySQL Workbench等)操作數據，對DBA更加友好。

    向應用程序完全透明，可直接當做MySQL使用。
    適用於任何兼容MySQL協議的客戶端。

Sharding-Sidecar（TBD）

定位為Kubernetes或Mesos的雲原生數據庫代理，以DaemonSet的形式代理所有對數據庫的訪問。 通過無中心、零侵入的方案提供與數據庫交互的的嚙合層，即Database Mesh，又可稱數據網格。

Database Mesh的關注重點在於如何將分布式的數據訪問應用與數據庫有機串聯起來，它更加關注的是交互，是將雜亂無章的應用與數據庫之間的交互有效的梳理。使用Database Mesh，訪問數據庫的應用和數據庫終將形成一個巨大的網格體系，應用和數據庫只需在網格體系中對號入座即可，它們都是被嚙合層所治理的對象。

 

      Sharding-JDBC     Sharding-Proxy     Sharding-Sidecar
數據庫     任意     MySQL     MySQL
連接消耗數     高     低     高
異構語言     僅Java     任意     任意
性能     損耗低     損耗略高     損耗低
無中心化     是     否     是
靜態入口     無     有     無
混合架構

    Sharding-JDBC采用無中心化架構，適用於Java開發的高性能的輕量級OLTP應用；
    Sharding-Proxy提供靜態入口以及異構語言的支持，適用於OLAP應用以及對分片數據庫進行管理和運維的場景。

    OLTP與OLAP的介紹

    數據處理大致可以分成兩大類：聯機事務處理OLTP（on-line transaction processing）、聯機分析處理OLAP（On-Line Analytical Processing）。

    OLTP是傳統的關系型數據庫的主要應用，主要是基本的、日常的事務處理，例如銀行交易。

    OLAP是數據倉庫系統的主要應用，支持復雜的分析操作，側重決策支持，並且提供直觀易懂的查詢結果。

    OLTP 系統強調數據庫內存效率，強調內存各種指標的命令率，強調綁定變量，強調並發操作；
    OLAP 系統則強調數據分析，強調SQL執行市場，強調磁盤I/O，強調分區等。

ShardingSphere是多接入端共同組成的生態圈。 通過混合使用Sharding-JDBC和Sharding-Proxy，並采用同一注冊中心統一配置分片策略，能夠靈活的搭建適用於各種場景的應用系統，架構師可以更加自由的調整適合於當前業務的最佳系統架構。

 

ShardingSphere功能列表

    數據分片【Sharding-JDBC】

        分庫 & 分表
        讀寫分離
        分布式主鍵

    分布式事務(Doing)【Sharding-Proxy】

        XA強一致事務
        柔性事務

    數據庫治理【Sharding-Sidecar（TBD）】

        配置動態化
        熔斷 & 禁用
        調用鏈路追蹤
        彈性伸縮 (Planning)

ShardingSphere規划線路圖

 

中間層代理類中間件

這類分庫分表中間件的核心原理是在應用和數據庫的連接之間搭起一個代理層，上層應用以標准的MySQL協議來連接代理層，然后代理層負責轉發請求到底層的MySQL物理實例，這種方式對應用只有一個要求，就是只要用MySQL協議來通信即可，所以用MySQL Workbench這種純的客戶端都可以直接連接你的分布式數據庫，自然也天然支持所有的編程語言。比較有代表性的產品有開創性質的Amoeba、阿里開源的Cobar、社區發展比較好的Mycat 等。
MyCat

    MyCat是一個開源的分布式數據庫系統，是一個實現了MySQL協議的服務器，前端用戶可以把它看作是一個數據庫代理，用MySQL客戶端工具和命令行訪問，而其后端可以用MySQL原生協議與多個MySQL服務器通信，也可以用JDBC協議與大多數主流數據庫服務器通信，其核心功能是分表分庫，即將一個大表水平分割為N個小表，存儲在后端MySQL服務器里或者其他數據庫里。

在技術實現上除了和應用層依賴類中間件基本相似外，代理類的分庫分表產品必須實現標准的MySQL協議，某種意義上講數據庫代理層轉發的就是MySQL協議請求，就像Nginx轉發的是Http協議請求。

上述無論哪種類型的產品，除了實現分庫分表這一主要功能外，都會額外實現一些其他很有實用價值的功能，比如讀寫分離、負載均衡等。
————————————————
版權聲明：本文為CSDN博主「琦彥」的原創文章，遵循 CC 4.0 BY-SA 版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/fly910905/article/details/87101059