數據庫中間件(分表分庫路由)

分區：對業務透明，分區只不過把存放數據的文件分紅了許多小塊，例如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公司發佈出來的一箇中間件。