分割槽：對業務透明，分割槽只不過把存放資料的檔案分成了許多小塊，例如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、從庫流量配置、動態載入配置項

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的分庫分表指令碼進行自定義分庫表，相當的靈活。

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公司釋出出來的一箇中間件。