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樹索引，索引根據用戶需要進行建立，可以嵌套在各個層次的各個容器之間構建

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

    1、堆表：數據按照向后插入的方法，一直堆積在文件末尾，使用索引結構訪問數據時，將在索引中得到數據指針，然后獲取數據，當有數據刪除時，將其從對應位置刪除，對于頻繁更新的堆表，需要定期進行優化，使用堆表，會導致數據順序訪問原則被打破(在DBMS中做了訪問優化，得到部分體能提升)，由于沒有填充因子，在相同壓縮算法下，空間能得到很大的節省，堆表很適合于順序范圍訪問，如數據倉庫等業務場景

    2、索引組織表：一般索引組織表使用B+作為構造方法，整個結構如同一個倒掛的樹(從數據訪問流來看)，路由信息存放在樹枝上，所有的數據存放在葉子節點，通過雙向指針將所有葉子根據順序方式串聯起來，由于時空訪問局限特性，這能很大提升數據性能，DBMS根據訪問存取路徑訪問及構造數據，訪問路徑深度直接影響了性能，一般建議訪問路徑控制在4以內(小于或等于3)，原因由于訪問多層路徑需要消耗更高的代價及維護索引樹代價越來越昂貴

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

    擁有AICD屬性的數據庫擁有索引維護功能，MyISAM及MongoDB由于是堆表，且沒有ACID的控制，會導致元數據與索引不一致問題，直接導致數據訪問混亂，數據不一致，但由于沒有ACID的要求，更新(本文所闡述的更新包括包括所有的寫入操作)速度將得到很大的提升，MyISAM 需要定期進行一致性check

    MySQL Cluster 架構

    Cluster分為SQL節點、數據節點、管理節點(MySQL Cluster提供了API供內部調用，外部應用程序可以通過API借口訪問任意層方法)

    SQL節點提供用戶SQL指令請求，解析、維護管理節點列表、向管理節點發起存取路徑請求、查詢優化、數據merge、sort，裁剪等功能

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

    管理節點維護著這個Cluster中所有數據節點的存取路徑規則、備份調度等功能

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

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

    管理節點維護著全局路由及規則信息，需要大量的內存來支撐，可使用分布式管理節點來解決

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

    問題：

    當新增數據節點時，需要重構存取路徑信息，對管理節點將造成數據重構壓力，該操作只能在非業務高峰時進行

    Cluster使用自動鍵值識別數據分布方案，如果數據有主鍵，則根據(1、主鍵、2唯一索引、3自動行標識rowid)集群個數進行取模分布，當使用非主鍵訪問時，將導致所有簇節點掃描，影響性能(這是Cluster面對的核心挑戰)

    MongoDB 復制集，基于MongoDB復制，構造出的分布式數據庫解決方案：

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

    Mongod： 數據訪問借口，將請求分發給Mongos節點

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

    mongo：數據存取(使用mongo協議還提供直接數據訪問)

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

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

    MongoDB面臨的問題：

    以非分片規則訪問數據時(索引可以建立在各個分片)，將導致所有Mongo簇節點全掃描(可以通過多份冗余拷貝并進行不同的分片規則實現，這也是當前數據分片應用常用的手段)

    當新增數據簇時，將導致所有數據節點重構，直接影響性能

    總結：

    MongoDB使用堆表方法組織數據、不包含ACID特性對于數據大量數據更新及查詢(對于擁有MVCC的架構，將降低在高并發、大數據集的響應速度)有很大的提升，但沒有ACID保證關鍵數據的穩定、安全

    MongoDB解決了MySQL Cluster的自動分片規則，將MySQL Cluster的SQL節點數據處理工作移交給mongos，能降低MySQL Cluster SQL節點與Cluster相互通信的瓶頸，提升體統性能，但無法解決跨分片查詢問題及數據節點添加的穩定及性能問題

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

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