MySQL Cluster 與 MongoDB 複製羣集分片設計及原理

分佈式數據庫計算涉及到分佈式事務、數據分佈、數據收斂計算等等要求

分佈式數據庫能實現高安全、高性能、高可用等特徵，固然也帶來了高成本（固定成本及運營成本），咱們經過MongoDB及MySQL Cluster從實現上來分析其中的設計思路，用以抽象咱們在設計數據庫時，能夠引用的部分設計方法，應用於咱們的生產系統

 首先說說關係及非關係數據庫的特徵

 MySQL的Innodb及Cluster擁有完整的ACID屬性

A 原子性  整個事務將做爲一個總體，要麼完成，要麼回滾

C 一致性 事務開始以前和事務結束之後，數據庫的完整性限制沒有被破壞

I 隔離性 兩個事務的執行是互不干擾的，兩個事務時間不會互相影響

D 持久性 在事務完成之後，該事務對數據庫所做的更改便持久地保存在數據庫之中，而且是徹底的

爲了實現ACID，引入了諸如Undo、Redo、MVCC、TAS、信號、兩階段封鎖、兩階段提交、封鎖等實現，並引入數據存取路徑，整個事情變得將極其複雜

MySQL遵循SQL標準、使用SQL標準的狀況下，能夠作到RDBMS之間的無縫遷移

其豐富的數據類型、完整的業務邏輯控制及表達能力一直做爲商業應用的首選

MongoDB使用集合表示數據，不擁有ACID屬性，其無類型、快速部署及快速開發獲得了廣泛的承認

不論是RDBMS仍是MongoDB，無一都使用了索引結構，MongoDB支持B樹索引，索引根據用戶須要進行創建，能夠嵌套在各個層次的各個容器之間構建

在數據庫中，有兩種數據存放方法：

一、堆：數據按照向後插入的方法，一直堆積在文件末尾，使用索引結構訪問數據時，將在索引中獲得數據指針，而後獲取數據，當有數據刪除時，將其從對應位置刪除，對於頻繁更新的堆表，須要按期進行優化，使用堆表，會致使數據順序訪問原則被打破（在DBMS中作了訪問優化，性能獲得部分提高），因爲沒有填充因子，在相同壓縮算法下，空間能獲得很大的節省，堆表很適合於順序範圍訪問，如數據倉庫等業務場景

二、索引組織：通常索引組織表使用B+做爲構造方法，整個結構如同一個倒掛的樹（從數據訪問流來看），路由信息存放在樹枝上，全部的數據存放在葉子節點，經過雙向指針將全部葉子根據順序方式串聯起來，因爲時空訪問侷限特性，這能很大提高數據性能，DBMS根據訪問存取路徑訪問及構造數據，訪問路徑深度直接影響了性能，通常建議訪問路徑控制在4之內（小於或等於3），緣由因爲訪問多層路徑須要消耗更高的代價及維護索引樹代價愈來愈昂貴

咱們常見的Innodb、MySQL Cluster等都是索引組織表、MyISAM爲堆表，MongoDB的組織結構爲堆

擁有AICD屬性的數據庫擁有索引維護功能，MyISAM存儲引擎及MongoDB因爲是堆組織結構，且沒有ACID的控制，會致使元數據與索引不一致問題，直接致使數據存取失效，形成數據不一致，但因爲沒有ACID的要求，更新（本文所闡述的更新包括包括全部的寫入操做）速度將獲得很大的提高，MyISAM存儲引擎須要按期進行一致性check，正是由於不具備ACID屬性，MyISAM存儲引擎須要爲數據更新鎖定表，形成大併發下更新的低性能

 MySQL Cluster 架構

Cluster分爲SQL節點、數據節點、管理節點(MySQL Cluster提供了API供內部調用，外部應用程序能夠經過API藉口訪問任意層方法)

SQL節點提供用戶SQL指令請求，解析、鏈接管理，query優化和響、cache管理等、數據merge、sort，裁剪等功能，當SQL節點啓動時，將向管理節點同步架構信息，用以數據查詢路由

數據節點提供數據存取，持久化、API數據存取訪問等功能

管理節點維護着節點活動信息，以及實施數據的備份和恢復等。管理節點會獲取整個cluster環境中節點的狀態和錯誤信息，並將各個cluster集羣中各個節點的信息反饋給整個集羣中其餘的全部節點，這對於SQL節點的數據路由規則相當重要，當節擴容時，數據將會被rebuild

數據節點使用分片及多份數據存儲，至少存放2份，數據存放於內存中，根據管理節點的規則進行持久化，做爲數據存取地，須要大量內存支持

SQL節點做爲查詢入口，須要消耗大量cpu及內存資源，可以使用分佈式管理節點，並在SQL節點外封裝一層請求分發及HA控制機制可解決單點及性能問題，其提供了線性擴展功能

管理節點維護着全局規則信息，當節點發生故障時，將會發生故障通告

在整個Cluster體系中，任何一個組建都支持動態擴展，線性擴展，提供了高可用，高性能的解決方案

問題：

當新增數據節點時，須要重構存取路徑信息，對管理節點將形成數據重構壓力，該操做建議在非業務高峯時進行

Cluster使用自動鍵值識別數據分片方案，用戶無需關心數據切片方案（在5.1及之後提供了分區鍵規則），透明實現分佈式數據庫，數據分片規則根據一、主鍵、2惟一索引、3自動行標識rowid完成，再集羣個數進行分佈，其訪問數據猶如RAID訪問機制同樣，能並行從各個節點抽取數據，散列數據，當使用非主鍵或分區鍵訪問時，將致使全部簇節點掃描，影響性能（這是Cluster面對的核心挑戰）

MySQL Cluster架構

 MongoDB 複製集架構，基於MongoDB複製，構造出的分佈式數據庫解決方案：

MongoDB提供了和MySQL Cluster相似的架構，在configre server、mongos、mongo中，包含：

configure server： 提供集羣元數據，其中包含基本信息，每一個replica set，trunk及trunk大小等信息

Mongs： 數據訪問路由、查詢優化、數據merge、sort，裁剪等功能，請求推送等

mongo+replica set：數據存取（使用mongo協議還提供直接數據訪問）

MongoDB Shard架構

 

MongoDB在構建集合時，須要提供數據分片規則，該規則將被記錄在mongoDB中，查詢請求mongos發起請求，mongos根據存取路徑在Replica中訪問數據

因爲MongoDB爲用戶提供了一個選擇性，將數據如何進行切片，在對用戶訪問透明的狀況下，快速存取數據

MongoDB面臨的問題：

以非分片規則訪問數據時（索引能夠創建在各個分片），將致使全部Mongo簇節點全掃描（能夠經過多份冗餘拷貝並進行不一樣的分片規則實現，這也是當前數據分片應用經常使用的手段）

當新增數據簇時，將致使全部數據節點重構，直接影響性能

 總結：

MongoDB使用堆存取路徑方法組織數據、不包含ACID特性對於數據大量數據更新及查詢（對於擁有MVCC的架構，將下降在高併發、大數據集的響應速度）有很大的提高，但沒有ACID保證關鍵數據的穩定、安全

MongoDB解決了MySQL Cluster的自動分片規則（5.1之後提供了用戶定義功能），將MySQL Cluster的SQL節點數據處理工做移交給mongos，MySQL Cluster使用SQL->節點->SQL的訪問路徑，MongoDB使用 Mongos-> replica set ->Mongos 的訪問路徑，從架構上來講，MySQL Cluster和MongoDB的架構相似（MongoDB Replica set模式使用兩階段提交，性能將被大大下降）

MySQL Cluster擁有完整的商業支持及通用標準支持，相對豐富的管理工具，MongoDB擁有相對局部的性能優點，但缺乏強大的穩定及安全支撐，豐富的管理工具，二者有各自的優點，但有差很少相同的致命弱點。

MySQL Cluster能夠實現基於複製的拓撲架構，在不改變內部拓撲架構的狀況下將數據同步至異地，造成星形拓撲，MongoDB在這方面還缺乏相關的技術解決方案（固然能夠是複製方案，但MySQL Cluster在較高的層次實現，MongoDB在較低層的方面實現，對於管理來講，將面臨很大的挑戰）

從商業上來講，MySQL Cluster擁有足夠的商業使用價值，但缺陷也很明顯，MongoDB對MySQL Cluster的改進很值得思考及在平常數據架構設計，模式設計中引入，但做爲大面積商業應用，MySQL Cluster和MongoDB都還有很長一段路要走，不論是固有的缺陷仍是管理模式上。

歡迎學Java和大數據的朋友們加入java架構交流： 855835163 羣內提供免費的架構資料還有：Java工程化、高性能及分佈式、高性能、深刻淺出。高架構。性能調優、Spring，MyBatis，Netty源碼分析和大數據等多個知識點高級進階乾貨的免費直播講解  能夠進來一塊兒學習交流哦