來源：mysqlops
分散式資料庫計算涉及到分散式事務、資料分佈、資料收斂計算等等要求
分散式資料庫能實現高安全、高效能、高可用等特徵，當然也帶來了高成本（固定成本及運營成本），我們通過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架構
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都還有很長一段路要走，不管是固有的缺陷還是管理模式上。