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还是NoSQL，无一都使用了索引结构，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提供了和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都还有很长一段路要走，不管是固有的缺陷还是管理模式上。

原创文章，转载请注明： 文章地址 MySQL Cluster 与 MongoDB 复制集分片设计及原理