数据库（分库分表）中间件对比
轉自：http://www.cnblogs.com/cangqiongbingchen/p/7094822.html
分區：對業務透明，分區只不過把存放數據的文件分成了許多小塊，例如mysql中的一張表對應三個文件.MYD,MYI,frm。
根據一定的規則把數據文件(MYD)和索引文件（MYI）進行了分割，分區后的表呢，還是一張表。分區可以把表分到不同的硬盤上，但不能分配到不同服務器上。
- 優點：數據不存在多個副本，不必進行數據復制，性能更高。
- 缺點：分區策略必須經過充分考慮，避免多個分區之間的數據存在關聯關系，每個分區都是單點，如果某個分區宕機，就會影響到系統的使用。
?
分片：對業務透明，在物理實現上分成多個服務器，不同的分片在不同服務器上
個人感覺跟分庫沒啥區別，只是叫法不一樣而已，值得一提的是關系型數據庫和nosql數據庫分片的概念以及處理方式是一樣的嗎？
請各位看官自行查找相關資料予以解答
?
分表：當數據量大到一定程度的時候，都會導致處理性能的不足，這個時候就沒有辦法了，只能進行分表處理。也就是把數據庫當中數據根據按照分庫原則分到多個數據表當中，
這樣，就可以把大表變成多個小表，不同的分表中數據不重復，從而提高處理效率。
分表也有兩種方案：
1. 同庫分表：所有的分表都在一個數據庫中，由于數據庫中表名不能重復，因此需要把數據表名起成不同的名字。
- 優點：由于都在一個數據庫中，公共表，不必進行復制，處理更簡單
- 缺點：由于還在一個數據庫中，CPU、內存、文件IO、網絡IO等瓶頸還是無法解決，只能降低單表中的數據記錄數。
表名不一致，會導后續的處理復雜（參照mysql meage存儲引擎來處理）
2. 不同庫分表：由于分表在不同的數據庫中，這個時候就可以使用同樣的表名。
- 優點：CPU、內存、文件IO、網絡IO等瓶頸可以得到有效解決，表名相同，處理起來相對簡單
- 缺點：公共表由于在所有的分表都要使用，因此要進行復制、同步。
一些聚合的操作，join,group by,order等難以順利進行
參考博客：http://www.cnblogs.com/langtianya/p/4997768.html，http://blog.51yip.com/mysql/949.html
?
分庫：分表和分區都是基于同一個數據庫里的數據分離技巧，對數據庫性能有一定提升，但是隨著業務數據量的增加，
原來所有的數據都是在一個數據庫上的，網絡IO及文件IO都集中在一個數據庫上的，因此CPU、內存、文件IO、網絡IO都可能會成為系統瓶頸。
當業務系統的數據容量接近或超過單臺服務器的容量、QPS/TPS接近或超過單個數據庫實例的處理極限等
此時，往往是采用垂直和水平結合的數據拆分方法，把數據服務和數據存儲分布到多臺數據庫服務器上。
分庫只是一個通俗說法，更標準名稱是數據分片，采用類似分布式數據庫理論指導的方法實現，對應用程序達到數據服務的全透明和數據存儲的全透明
?
讀寫分離方案
海量數據的存儲及訪問，通過對數據庫進行讀寫分離，來提升數據的處理能力。讀寫分離它的方案特點是數據庫產生多個副本，
數據庫的寫操作都集中到一個數據庫上，而一些讀的操作呢，可以分解到其它數據庫上。這樣，只要付出數據復制的成本，
就可以使得數據庫的處理壓力分解到多個數據庫上，從而大大提升數據處理能力。
?
?
?
?
1>Cobar 是提供關系型數據庫（MySQL）分布式服務的中間件，它可以讓傳統的數據庫得到良好的線性擴展，并看上去還是一個數據庫，對應用保持透明。
Cobar以Proxy的形式位于前臺應用和實際數據庫之間，對前臺的開放的接口是MySQL通信協議，將前臺SQL語句變更并按照數據分布規則發到合適的后臺數據分庫，再合并返回結果，模擬單庫下的數據庫行為。
Cobar屬于中間層方案，在應用程序和MySQL之間搭建一層Proxy。中間層介于應用程序與數據庫間，需要做一次轉發，而基于JDBC協議并無額外轉發，直接由應用程序連接數據庫，
性能上有些許優勢。這里并非說明中間層一定不如客戶端直連，除了性能，需要考慮的因素還有很多，中間層更便于實現監控、數據遷移、連接管理等功能。
Cobar屬于阿里B2B事業群，始于2008年，在阿里服役3年多，接管3000+個MySQL數據庫的schema,集群日處理在線SQL請求50億次以上。
由于Cobar發起人的離職，Cobar停止維護。后續的類似中間件，比如MyCAT建立于Cobar之上，包括現在阿里服役的RDRS其中也復用了Cobar-Proxy的相關代碼。
?
2>MyCAT是社區愛好者在阿里cobar基礎上進行二次開發，解決了cobar當時存 在的一些問題，并且加入了許多新的功能在其中。目前MyCAT社區活 躍度很高，
目前已經有一些公司在使用MyCAT。總體來說支持度比 較高，也會一直維護下去，發展到目前的版本，已經不是一個單純的MySQL代理了，
它的后端可以支持MySQL, SQL Server, Oracle,?DB2, PostgreSQL等主流數據庫，也支持MongoDB這種新型NoSQL方式的存儲，未來還會支持更多類型的存儲。
MyCAT是一個強大的數據庫中間件，不僅僅可以用作讀寫分離，以及分表分庫、容災管理，而且可以用于多租戶應用開發、云平臺基礎設施，讓你的架構具備很強的適應性和靈活性，
借助于即將發布的MyCAT只能優化模塊，系統的數據訪問瓶頸和熱點一目了然，根據這些統計分析數據，你可以自動或手工調整后端存儲，將不同的表隱射到不同存儲引擎上，而整個應用的代碼一行也不用改變。
MyCAT是在Cobar基礎上發展的版本，兩個顯著提高：后端由BIO改為NIO，并發量有大幅提高； 增加了對Order By, Group By, Limit等聚合功能
（雖然Cobar也可以支持Order By, Group By, Limit語法，但是結果沒有進行聚合，只是簡單返回給前端，聚合功能還是需要業務系統自己完成）
?
3>TDDL是Tabao根據自己的業務特點開發了(Tabao Distributed Data Layer, 外號：頭都大了)。主要解決了分庫分表對應用的透明化以及異構數據庫之間的數據復制，
它是一個基于集中式配置的jdbc datasourcce實現，具有主備，讀寫分離，動態數據庫配置等功能。
TDDL并非獨立的中間件，只能算作中間層，處于業務層和JDBC層中間，是以Jar包方式提供給應用調用，屬于JDBC Shard的思想。
TDDL源碼：https://github.com/alibaba/tb_tddl?
TDDL復雜度相對較高。當前公布的文檔較少，只開源動態數據源，分表分庫部分還未開源，還需要依賴diamond，不推薦使用。
?
4>DRDS是阿里巴巴自主研發的分布式數據庫服務（此項目不開源）,DRDS脫胎于阿里巴巴開源的Cobar分布式數據庫引擎，吸收了Cobar核心的Cobar-Proxy源碼，
實現了一套獨立的類似MySQL-Proxy協議的解析端，能夠對傳入的SQL進行解析和處理，對應用程序屏蔽各種復雜的底層DB拓撲結構，獲得單機數據庫一樣的使用體驗，
同時借鑒了淘寶TDDL豐富的分布式數據庫實踐經驗，實現了對分布式Join支持，SUM/MAX/COUNT/AVG等聚合函數支持以及排序等函數支持，
通過異構索引、小表廣播等解決分布式數據庫使用場景下衍生出的一系列問題，最終形成了完整的分布式數據庫方案。
?
5>Atlas是一個位于應用程序與MySQL之間的基于MySQL協議的數據中間層項目，它是在mysql-proxy 0.8.2版本上對其進行優化，360團隊基于mysql proxy 把lua用C改寫，
它實現了MySQL的客戶端和服務端協議，作為服務端與應用程序通訊，同時作為客戶端與MySQL通訊。它對應用程序屏蔽了DB的細節。
Altas不能實現分布式分表，所有的字表必須在同一臺DB的同一個DataBase里且所有的字表必須實現建好，Altas沒有自動建表的功能。
原有版本是不支持分庫分表， 目前已經放出了分庫分表版本。在網上看到一些朋友經常說在高并 發下會經常掛掉，如果大家要使用需要提前做好測試。
?
6>DBProxy是美團點評DBA團隊針對公司內部需求，在奇虎360公司開源的Atlas做了很多改進工作，形成了新的高可靠、高可用企業級數據庫中間件
其特性主要有：讀寫分離、負載均衡、支持分表、IP過濾、sql語句黑名單、DBA平滑下線DB、從庫流量配置、動態加載配置項
項目的Github地址是https://github.com/Meituan-Dianping/DBProxy
?
7>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以及笛卡爾積表查詢。
?
?
知名度較低的：
Heisenberg
Baidu.
其優點：分庫分表與應用脫離，分庫表如同使用單庫表一樣，減少db連接數壓力，熱重啟配置，可水平擴容，遵守MySQL原生協議，讀寫分離，無語言限制，
mysqlclient, c, java都可以使用Heisenberg服務器通過管理命令可以查看，如連接數，線程池，結點等，并可以調整采用velocity的分庫分表腳本進行自定義分庫表，相當的靈活。
https://github.com/brucexx/heisenberg（開源版已停止維護）
CDS
JD. Completed Database Sharding.
CDS是一款基于客戶端開發的分庫分表中間件產品，實現了JDBC標準API，支持分庫分表，讀寫分離和數據運維等諸多共，提供高性能，高并發和高可靠的海量數據路由存取服務，
業務系統可近乎零成本進行介入，目前支持MySQL, Oracle和SQL Server.
(架構上和Cobar，MyCAT相似，直接采用jdbc對接，沒有實現類似MySQL協議，沒有NIO,AIO，SQL Parser模塊采用JSqlParser, Sql解析器有：druid>JSqlParser>fdbparser.)
DDB
網易. Distributed DataBase.
DDB經歷了三次服務模式的重大更迭：Driver模式->Proxy模式->云模式。
Driver模式：基于JDBC驅動訪問，提供一個db.jar, 和TDDL類似， 位于應用層和JDBC之間. Proxy模式：在DDB中搭建了一組代理服務器來提供標準的MySQL服務，
在代理服務器內部實現分庫分表的邏輯。應用通過標準數據庫驅動訪問DDB Proxy, Proxy內部通過MySQL解碼器將請求還原為SQL, 并由DDB Driver執行得到結果。
私有云模式：基于網易私有云開發的一套平臺化管理工具Cloudadmin, 將DDB原先Master的功能打散，一部分分庫相關功能集成到proxy中，
如分庫管理、表管理、用戶管理等，一部分中心化功能集成到Cloudadmin中，如報警監控，此外，Cloudadmin中提供了一鍵部署、自動和手動備份，版本管理等平臺化功能。
?
OneProxy:
數據庫界大牛，前支付寶數據庫團隊領導樓方鑫開發，基于mysql官方 的proxy思想利用c進行開發的，OneProxy是一款商業收費的中間件， 樓總舍去了一些功能點，
專注在性能和穩定性上。有朋友測試過說在 高并發下很穩定。
Oceanus(58同城數據庫中間件)
Oceanus致力于打造一個功能簡單、可依賴、易于上手、易于擴展、易于集成的解決方案，甚至是平臺化系統。擁抱開源，提供各類插件機制集成其他開源項目，
新手可以在幾分鐘內上手編程，分庫分表邏輯不再與業務緊密耦合，擴容有標準模式，減少意外錯誤的發生。
?
Vitess:
這個中間件是Youtube生產在使用的，但是架構很復雜。 與以往中間件不同，使用Vitess應用改動比較大要 使用他提供語言的API接口，我們可以借鑒他其中的一些設計思想。
Kingshard:
Kingshard是前360Atlas中間件開發團隊的陳菲利用業務時間 用go語言開發的，目前參與開發的人員有3個左右， 目前來看還不是成熟可以使用的產品，需要在不斷完善。
MaxScale與MySQL Route:
這兩個中間件都算是官方的吧，MaxScale是mariadb (MySQL原作者維護的一個版本)研發的，目前版本不支持分庫分表。
MySQL Route是現在MySQL 官方Oracle公司發布出來的一個中間件。
作者：王中秋 出處：http://www.cnblogs.com/wangzhongqiu/ 本文版權歸作者和博客園共有，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文連接，否則保留追究法律責任的權利.來源:https://www.cnblogs.com/wangzhongqiu/p/7100332.html
總結
以上是生活随笔為你收集整理的数据库（分库分表）中间件对比的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： mysql分布式数据库中间件对比
- 下一篇： 如何正确地照顾家居微波炉？