分佈式數據庫中間件對比

原文出自： https://blog.csdn.net/jornada_/article/details/82947677

通常對於業務記錄類隨時間會不斷增長的數據，當數據量增長到必定量（通常認爲整型值爲主的表達到千萬級，字符串爲主的表達到五百萬）的時候，性能將遇到瓶頸，同時調整表結構也會變得很是困難。爲了不生產遇到這樣的問題，在作系統設計時須要預估可能產生的數據量：預估記錄主體個數*預估記錄主體產生的記錄數（e.g.用戶訂單表預估數據量=預估用戶數*單用戶產生訂單數），預估達到必定量時，就不得不考慮分庫分表了，目前國內比較成熟的開源數據庫中間件有sharding-jdbc、mycat；而drds是阿里雲最近推出的商業產品，考慮到大部分公司都在使用阿里雲，作一個全家桶，也是一個不錯的選擇。接下來將對這三款產品的優缺點及適用場景作以介紹。

 

 

 

        能夠看出sharding-jdbc做爲一個組件集成在應用內，而mycat則做爲一個獨立的應用須要單獨部署，drds則是阿里雲的一個獨立產品，不過須要結合rds一塊兒使用。從架構上看sharding-jdbc更符合分佈式架構的設計，直連數據庫，沒有中間應用，理論性能是最高的（實際性能須要結合具體的代碼實現，理論性能能夠理解爲上限，經過不斷優化代碼實現，逐漸接近理論性能）。同時缺點也很明顯，因爲做爲組件存在，須要集成在應用內，意味着做爲使用方，必需要集成到代碼裏，使得開發成本相對較高；另外一方面，因爲須要集成在應用內，使得須要針對不一樣語言（java、C、PHP……）有不一樣的實現（事實上sharding-jdbc目前只支持java），這樣組件自己的維護成本也會很高。最終將應用場景限定在由java開發的應用這一種場景下。

sharding-jdbc後續發展爲Sharding-Sphere，包含sharding-jdbc、Sharding-Proxy、Sharding-Sidecar

 

 

 

       mycat是支持SQL92標準，遵照Mysql原生協議，跨語言，跨平臺，跨數據庫的通用中間件代理。做爲對比能夠參考上表中的Sharding-Proxy，須要單獨部署，因爲遵照Mysql原生協議，應用時不須要特殊處理，和使用MySQL是同樣的，因此應用場景不受限制；可是mycat不支持二維路由，僅支持單庫多表或多庫單表，同時因爲自定義鏈接池，這樣就會存在mycat自身維護一個鏈接池，MySQL也有一個鏈接池，任何一個鏈接池上限都會成爲性能的瓶頸，而mycat的鏈接池設計也略顯粗暴，當請求連接數大於設置鏈接池上限時直接拋出異常，所以在配置mycat鏈接池的大小是，須要結合場景作合理設置。總的來講，mycat以邏輯表的形式屏蔽掉應用處理分庫分表的複雜邏輯，遵照Mysql原生協議，跨語言，跨平臺，有着更爲通用的應用場景。

       DRDS 兼容 MySQL 協議和語法，支持分庫分表、平滑擴容、服務升降配、透明讀寫分離和分佈式事務等特性，具有分佈式數據庫全生命週期的運維管控能力。能夠當作mycat的商業化產品，也就是mycat全部的優勢它都有，並且做爲一個商業化產品使用上更爲簡單透明，功能也更爲豐富；若是不差錢並且正準備對數據作重構，那麼drds是一個不錯的選擇，之因此說準備作數據重構時考慮用drds，是由於drds不是一個簡單的作sharding路由，即便原來使用的是rds，也沒法經過drds作路由，惟一的辦法新建drds實例，定義路由規則（drds支持二維路由），導入歷史數據，而後就能夠開心的使用drds了。

     而後作個簡單總結