數(shù)據(jù)庫（分庫分表）中間件對比

分區(qū)：對業(yè)務(wù)透明，分區(qū)只不過把存放數(shù)據(jù)的文件分成了許多小塊，例如mysql中的一張表對應(yīng)三個文件.MYD,MYI,frm。

根據(jù)一定的規(guī)則把數(shù)據(jù)文件(MYD)和索引文件（MYI）進(jìn)行了分割，分區(qū)后的表呢，還是一張表。分區(qū)可以把表分到不同的硬盤上，但不能分配到不同服務(wù)器上。

• 優(yōu)點(diǎn)：數(shù)據(jù)不存在多個副本，不必進(jìn)行數(shù)據(jù)復(fù)制，性能更高。
• 缺點(diǎn)：分區(qū)策略必須經(jīng)過充分考慮，避免多個分區(qū)之間的數(shù)據(jù)存在關(guān)聯(lián)關(guān)系，每個分區(qū)都是單點(diǎn)，如果某個分區(qū)宕機(jī)，就會影響到系統(tǒng)的使用。

?

分片：對業(yè)務(wù)透明，在物理實(shí)現(xiàn)上分成多個服務(wù)器，不同的分片在不同服務(wù)器上

個人感覺跟分庫沒啥區(qū)別，只是叫法不一樣而已，值得一提的是關(guān)系型數(shù)據(jù)庫和nosql數(shù)據(jù)庫分片的概念以及處理方式是一樣的嗎？

請各位看官自行查找相關(guān)資料予以解答

?

分表：當(dāng)數(shù)據(jù)量大到一定程度的時候，都會導(dǎo)致處理性能的不足，這個時候就沒有辦法了，只能進(jìn)行分表處理。也就是把數(shù)據(jù)庫當(dāng)中數(shù)據(jù)根據(jù)按照分庫原則分到多個數(shù)據(jù)表當(dāng)中，

這樣，就可以把大表變成多個小表，不同的分表中數(shù)據(jù)不重復(fù)，從而提高處理效率。

分表也有兩種方案：

1. 同庫分表：所有的分表都在一個數(shù)據(jù)庫中，由于數(shù)據(jù)庫中表名不能重復(fù)，因此需要把數(shù)據(jù)表名起成不同的名字。

• 優(yōu)點(diǎn)：由于都在一個數(shù)據(jù)庫中，公共表，不必進(jìn)行復(fù)制，處理更簡單
• 缺點(diǎn)：由于還在一個數(shù)據(jù)庫中，CPU、內(nèi)存、文件IO、網(wǎng)絡(luò)IO等瓶頸還是無法解決，只能降低單表中的數(shù)據(jù)記錄數(shù)。

　　　　　　表名不一致，會導(dǎo)后續(xù)的處理復(fù)雜（參照mysql meage存儲引擎來處理）

2. 不同庫分表：由于分表在不同的數(shù)據(jù)庫中，這個時候就可以使用同樣的表名。

• 優(yōu)點(diǎn)：CPU、內(nèi)存、文件IO、網(wǎng)絡(luò)IO等瓶頸可以得到有效解決，表名相同，處理起來相對簡單
• 缺點(diǎn)：公共表由于在所有的分表都要使用，因此要進(jìn)行復(fù)制、同步。

　　　　一些聚合的操作，join,group by,order等難以順利進(jìn)行

參考博客：http://www.cnblogs.com/langtianya/p/4997768.html，http://blog.51yip.com/mysql/949.html

?

分庫：分表和分區(qū)都是基于同一個數(shù)據(jù)庫里的數(shù)據(jù)分離技巧，對數(shù)據(jù)庫性能有一定提升，但是隨著業(yè)務(wù)數(shù)據(jù)量的增加，

原來所有的數(shù)據(jù)都是在一個數(shù)據(jù)庫上的，網(wǎng)絡(luò)IO及文件IO都集中在一個數(shù)據(jù)庫上的，因此CPU、內(nèi)存、文件IO、網(wǎng)絡(luò)IO都可能會成為系統(tǒng)瓶頸。

當(dāng)業(yè)務(wù)系統(tǒng)的數(shù)據(jù)容量接近或超過單臺服務(wù)器的容量、QPS/TPS接近或超過單個數(shù)據(jù)庫實(shí)例的處理極限等

此時，往往是采用垂直和水平結(jié)合的數(shù)據(jù)拆分方法，把數(shù)據(jù)服務(wù)和數(shù)據(jù)存儲分布到多臺數(shù)據(jù)庫服務(wù)器上。

分庫只是一個通俗說法，更標(biāo)準(zhǔn)名稱是數(shù)據(jù)分片，采用類似分布式數(shù)據(jù)庫理論指導(dǎo)的方法實(shí)現(xiàn)，對應(yīng)用程序達(dá)到數(shù)據(jù)服務(wù)的全透明和數(shù)據(jù)存儲的全透明

?

讀寫分離方案

海量數(shù)據(jù)的存儲及訪問，通過對數(shù)據(jù)庫進(jìn)行讀寫分離，來提升數(shù)據(jù)的處理能力。讀寫分離它的方案特點(diǎn)是數(shù)據(jù)庫產(chǎn)生多個副本，

數(shù)據(jù)庫的寫操作都集中到一個數(shù)據(jù)庫上，而一些讀的操作呢，可以分解到其它數(shù)據(jù)庫上。這樣，只要付出數(shù)據(jù)復(fù)制的成本，

就可以使得數(shù)據(jù)庫的處理壓力分解到多個數(shù)據(jù)庫上，從而大大提升數(shù)據(jù)處理能力。

?

?

?

?

1>Cobar 是提供關(guān)系型數(shù)據(jù)庫（MySQL）分布式服務(wù)的中間件，它可以讓傳統(tǒng)的數(shù)據(jù)庫得到良好的線性擴(kuò)展，并看上去還是一個數(shù)據(jù)庫，對應(yīng)用保持透明。

Cobar以Proxy的形式位于前臺應(yīng)用和實(shí)際數(shù)據(jù)庫之間，對前臺的開放的接口是MySQL通信協(xié)議，將前臺SQL語句變更并按照數(shù)據(jù)分布規(guī)則發(fā)到合適的后臺數(shù)據(jù)分庫，再合并返回結(jié)果，模擬單庫下的數(shù)據(jù)庫行為。

Cobar屬于中間層方案，在應(yīng)用程序和MySQL之間搭建一層Proxy。中間層介于應(yīng)用程序與數(shù)據(jù)庫間，需要做一次轉(zhuǎn)發(fā)，而基于JDBC協(xié)議并無額外轉(zhuǎn)發(fā)，直接由應(yīng)用程序連接數(shù)據(jù)庫，

性能上有些許優(yōu)勢。這里并非說明中間層一定不如客戶端直連，除了性能，需要考慮的因素還有很多，中間層更便于實(shí)現(xiàn)監(jiān)控、數(shù)據(jù)遷移、連接管理等功能。

Cobar屬于阿里B2B事業(yè)群，始于2008年，在阿里服役3年多，接管3000+個MySQL數(shù)據(jù)庫的schema,集群日處理在線SQL請求50億次以上。

由于Cobar發(fā)起人的離職，Cobar停止維護(hù)。后續(xù)的類似中間件，比如MyCAT建立于Cobar之上，包括現(xiàn)在阿里服役的RDRS其中也復(fù)用了Cobar-Proxy的相關(guān)代碼。

?

2>MyCAT是社區(qū)愛好者在阿里cobar基礎(chǔ)上進(jìn)行二次開發(fā)，解決了cobar當(dāng)時存 在的一些問題，并且加入了許多新的功能在其中。目前MyCAT社區(qū)活 躍度很高，

目前已經(jīng)有一些公司在使用MyCAT。總體來說支持度比 較高，也會一直維護(hù)下去，發(fā)展到目前的版本，已經(jīng)不是一個單純的MySQL代理了，

它的后端可以支持MySQL, SQL Server, Oracle,?DB2, PostgreSQL等主流數(shù)據(jù)庫，也支持MongoDB這種新型NoSQL方式的存儲，未來還會支持更多類型的存儲。

MyCAT是一個強(qiáng)大的數(shù)據(jù)庫中間件，不僅僅可以用作讀寫分離，以及分表分庫、容災(zāi)管理，而且可以用于多租戶應(yīng)用開發(fā)、云平臺基礎(chǔ)設(shè)施，讓你的架構(gòu)具備很強(qiáng)的適應(yīng)性和靈活性，

借助于即將發(fā)布的MyCAT只能優(yōu)化模塊，系統(tǒng)的數(shù)據(jù)訪問瓶頸和熱點(diǎn)一目了然，根據(jù)這些統(tǒng)計(jì)分析數(shù)據(jù)，你可以自動或手工調(diào)整后端存儲，將不同的表隱射到不同存儲引擎上，而整個應(yīng)用的代碼一行也不用改變。

MyCAT是在Cobar基礎(chǔ)上發(fā)展的版本，兩個顯著提高：后端由BIO改為NIO，并發(fā)量有大幅提高； 增加了對Order By, Group By, Limit等聚合功能

（雖然Cobar也可以支持Order By, Group By, Limit語法，但是結(jié)果沒有進(jìn)行聚合，只是簡單返回給前端，聚合功能還是需要業(yè)務(wù)系統(tǒng)自己完成）

?

3>TDDL是Tabao根據(jù)自己的業(yè)務(wù)特點(diǎn)開發(fā)了(Tabao Distributed Data Layer, 外號：頭都大了)。主要解決了分庫分表對應(yīng)用的透明化以及異構(gòu)數(shù)據(jù)庫之間的數(shù)據(jù)復(fù)制，

它是一個基于集中式配置的jdbc datasourcce實(shí)現(xiàn)，具有主備，讀寫分離，動態(tài)數(shù)據(jù)庫配置等功能。

TDDL并非獨(dú)立的中間件，只能算作中間層，處于業(yè)務(wù)層和JDBC層中間，是以Jar包方式提供給應(yīng)用調(diào)用，屬于JDBC Shard的思想。

TDDL源碼：https://github.com/alibaba/tb_tddl?
TDDL復(fù)雜度相對較高。當(dāng)前公布的文檔較少，只開源動態(tài)數(shù)據(jù)源，分表分庫部分還未開源，還需要依賴diamond，不推薦使用。

?

4>DRDS是阿里巴巴自主研發(fā)的分布式數(shù)據(jù)庫服務(wù)（此項(xiàng)目不開源）,DRDS脫胎于阿里巴巴開源的Cobar分布式數(shù)據(jù)庫引擎，吸收了Cobar核心的Cobar-Proxy源碼，

實(shí)現(xiàn)了一套獨(dú)立的類似MySQL-Proxy協(xié)議的解析端，能夠?qū)魅氲腟QL進(jìn)行解析和處理，對應(yīng)用程序屏蔽各種復(fù)雜的底層DB拓?fù)浣Y(jié)構(gòu)，獲得單機(jī)數(shù)據(jù)庫一樣的使用體驗(yàn)，

同時借鑒了淘寶TDDL豐富的分布式數(shù)據(jù)庫實(shí)踐經(jīng)驗(yàn)，實(shí)現(xiàn)了對分布式Join支持，SUM/MAX/COUNT/AVG等聚合函數(shù)支持以及排序等函數(shù)支持，

通過異構(gòu)索引、小表廣播等解決分布式數(shù)據(jù)庫使用場景下衍生出的一系列問題，最終形成了完整的分布式數(shù)據(jù)庫方案。

?

5>Atlas是一個位于應(yīng)用程序與MySQL之間的基于MySQL協(xié)議的數(shù)據(jù)中間層項(xiàng)目，它是在mysql-proxy 0.8.2版本上對其進(jìn)行優(yōu)化，360團(tuán)隊(duì)基于mysql proxy 把lua用C改寫，

它實(shí)現(xiàn)了MySQL的客戶端和服務(wù)端協(xié)議，作為服務(wù)端與應(yīng)用程序通訊，同時作為客戶端與MySQL通訊。它對應(yīng)用程序屏蔽了DB的細(xì)節(jié)。

Altas不能實(shí)現(xiàn)分布式分表，所有的字表必須在同一臺DB的同一個DataBase里且所有的字表必須實(shí)現(xiàn)建好，Altas沒有自動建表的功能。

原有版本是不支持分庫分表， 目前已經(jīng)放出了分庫分表版本。在網(wǎng)上看到一些朋友經(jīng)常說在高并 發(fā)下會經(jīng)常掛掉，如果大家要使用需要提前做好測試。

?

6>DBProxy是美團(tuán)點(diǎn)評DBA團(tuán)隊(duì)針對公司內(nèi)部需求，在奇虎360公司開源的Atlas做了很多改進(jìn)工作，形成了新的高可靠、高可用企業(yè)級數(shù)據(jù)庫中間件

其特性主要有：讀寫分離、負(fù)載均衡、支持分表、IP過濾、sql語句黑名單、DBA平滑下線DB、從庫流量配置、動態(tài)加載配置項(xiàng)

項(xiàng)目的Github地址是https://github.com/Meituan-Dianping/DBProxy

?

7>sharding-JDBC是當(dāng)當(dāng)應(yīng)用框架ddframe中，從關(guān)系型數(shù)據(jù)庫模塊dd-rdb中分離出來的數(shù)據(jù)庫水平分片框架，實(shí)現(xiàn)透明化數(shù)據(jù)庫分庫分表訪問。

Sharding-JDBC是繼dubbox和elastic-job之后，ddframe系列開源的第3個項(xiàng)目。

Sharding-JDBC直接封裝JDBC API，可以理解為增強(qiáng)版的JDBC驅(qū)動，舊代碼遷移成本幾乎為零：

• 可適用于任何基于Java的ORM框架，如JPA、Hibernate、Mybatis、Spring JDBC Template或直接使用JDBC。
• 可基于任何第三方的數(shù)據(jù)庫連接池，如DBCP、C3P0、 BoneCP、Druid等。
• 理論上可支持任意實(shí)現(xiàn)JDBC規(guī)范的數(shù)據(jù)庫。雖然目前僅支持MySQL，但已有支持Oracle、SQLServer等數(shù)據(jù)庫的計(jì)劃。

Sharding-JDBC定位為輕量Java框架，使用客戶端直連數(shù)據(jù)庫，以jar包形式提供服務(wù)，無proxy代理層，無需額外部署，無其他依賴，DBA也無需改變原有的運(yùn)維方式。

Sharding-JDBC分片策略靈活，可支持等號、between、in等多維度分片，也可支持多分片鍵。

SQL解析功能完善，支持聚合、分組、排序、limit、or等查詢，并支持Binding Table以及笛卡爾積表查詢。

?

?

知名度較低的：

Heisenberg

Baidu.
其優(yōu)點(diǎn)：分庫分表與應(yīng)用脫離，分庫表如同使用單庫表一樣，減少db連接數(shù)壓力，熱重啟配置，可水平擴(kuò)容，遵守MySQL原生協(xié)議，讀寫分離，無語言限制，

mysqlclient, c, java都可以使用Heisenberg服務(wù)器通過管理命令可以查看，如連接數(shù)，線程池，結(jié)點(diǎn)等，并可以調(diào)整采用velocity的分庫分表腳本進(jìn)行自定義分庫表，相當(dāng)?shù)撵`活。

https://github.com/brucexx/heisenberg（開源版已停止維護(hù)）

CDS

JD. Completed Database Sharding.
CDS是一款基于客戶端開發(fā)的分庫分表中間件產(chǎn)品，實(shí)現(xiàn)了JDBC標(biāo)準(zhǔn)API，支持分庫分表，讀寫分離和數(shù)據(jù)運(yùn)維等諸多共，提供高性能，高并發(fā)和高可靠的海量數(shù)據(jù)路由存取服務(wù)，

業(yè)務(wù)系統(tǒng)可近乎零成本進(jìn)行介入，目前支持MySQL, Oracle和SQL Server.
(架構(gòu)上和Cobar，MyCAT相似，直接采用jdbc對接，沒有實(shí)現(xiàn)類似MySQL協(xié)議，沒有NIO,AIO，SQL Parser模塊采用JSqlParser, Sql解析器有：druid>JSqlParser>fdbparser.)

DDB

網(wǎng)易. Distributed DataBase.
DDB經(jīng)歷了三次服務(wù)模式的重大更迭：Driver模式->Proxy模式->云模式。

Driver模式：基于JDBC驅(qū)動訪問，提供一個db.jar, 和TDDL類似， 位于應(yīng)用層和JDBC之間. Proxy模式：在DDB中搭建了一組代理服務(wù)器來提供標(biāo)準(zhǔn)的MySQL服務(wù)，

在代理服務(wù)器內(nèi)部實(shí)現(xiàn)分庫分表的邏輯。應(yīng)用通過標(biāo)準(zhǔn)數(shù)據(jù)庫驅(qū)動訪問DDB Proxy, Proxy內(nèi)部通過MySQL解碼器將請求還原為SQL, 并由DDB Driver執(zhí)行得到結(jié)果。

私有云模式：基于網(wǎng)易私有云開發(fā)的一套平臺化管理工具Cloudadmin, 將DDB原先Master的功能打散，一部分分庫相關(guān)功能集成到proxy中，

如分庫管理、表管理、用戶管理等，一部分中心化功能集成到Cloudadmin中，如報警監(jiān)控，此外，Cloudadmin中提供了一鍵部署、自動和手動備份，版本管理等平臺化功能。

?

OneProxy:

數(shù)據(jù)庫界大牛，前支付寶數(shù)據(jù)庫團(tuán)隊(duì)領(lǐng)導(dǎo)樓方鑫開發(fā)，基于mysql官方 的proxy思想利用c進(jìn)行開發(fā)的，OneProxy是一款商業(yè)收費(fèi)的中間件， 樓總舍去了一些功能點(diǎn)，

專注在性能和穩(wěn)定性上。有朋友測試過說在 高并發(fā)下很穩(wěn)定。

Oceanus(58同城數(shù)據(jù)庫中間件)

Oceanus致力于打造一個功能簡單、可依賴、易于上手、易于擴(kuò)展、易于集成的解決方案，甚至是平臺化系統(tǒng)。擁抱開源，提供各類插件機(jī)制集成其他開源項(xiàng)目，

新手可以在幾分鐘內(nèi)上手編程，分庫分表邏輯不再與業(yè)務(wù)緊密耦合，擴(kuò)容有標(biāo)準(zhǔn)模式，減少意外錯誤的發(fā)生。

?

Vitess:

這個中間件是Youtube生產(chǎn)在使用的，但是架構(gòu)很復(fù)雜。 與以往中間件不同，使用Vitess應(yīng)用改動比較大要 使用他提供語言的API接口，我們可以借鑒他其中的一些設(shè)計(jì)思想。

Kingshard:

Kingshard是前360Atlas中間件開發(fā)團(tuán)隊(duì)的陳菲利用業(yè)務(wù)時間 用go語言開發(fā)的，目前參與開發(fā)的人員有3個左右， 目前來看還不是成熟可以使用的產(chǎn)品，需要在不斷完善。

MaxScale與MySQL Route:

這兩個中間件都算是官方的吧，MaxScale是mariadb (MySQL原作者維護(hù)的一個版本)研發(fā)的，目前版本不支持分庫分表。

MySQL Route是現(xiàn)在MySQL 官方Oracle公司發(fā)布出來的一個中間件。

作者：leon66666出處：http://www.cnblogs.com/wangzhongqiu/https://www.cnblogs.com/wangzhongqiu/p/7100332.html

總結(jié)

以上是生活随笔為你收集整理的数据库分库分表中间件对比（很全）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。