分布式数据库计算涉及到分布式事务、数据分布、数据收敛计算等等要求

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