分布式數據庫能實現高安全、高性能、高可用等特征，當然也帶來了高成本（固定成本及運營成本），我們通過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，正是因為不具有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及以後提供了分區鍵規則），透明實現分布式數據庫，數據分片規則根據1、主鍵、2唯一索引、3自動行標識rowid完成，再集群個數進行分布，其訪問數據猶如RAID訪問機制一樣，能並行從各個節點抽取數據，散列數據，當使用非主鍵或分區鍵訪問時，將導致所有簇節點掃描，影響性能（這是Cluster面對的核心挑戰）

MySQL Cluster架構

MySQL Cluster 與 MongoDB 復制群集分片設計及原理

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

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

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

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

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

MongoDB Shard架構

MySQL Cluster 與 MongoDB 復制群集分片設計及原理

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都還有很長一段路要走，不管是固有的缺陷還是管理模式上。

MySQL Cluster 與 MongoDB 復制群集分片設計及原理