摘要：曾经MySQL推出的一个MySQL的高可用模式，MySQL Cluster. 为什么说这是一个失败的产品，因为这个产品在以下几个地方，有一些值得人思考的问题。
大家是否记得 Oracle的一个数据库产品 MySQL中的一个项目 NDB，说这个可能还有人想不起来，MYSQL Cluster，想起来了吧。
曾经MySQL推出的一个MySQL的高可用模式，MySQL Cluster. 为什么说这是一个失败的产品，因为这个产品在以下几个地方，有一些值得人思考的问题。
产品设计混乱，如果ORACLE有 RAC，ORACle Real Applicaiton Clusters，那么这个产品就是再此概念上做出来的 MySQL也应该有一个和Oracle 一样的高可用产品的思路。可我特别想问几个问题，如果ORACLE 有RAC ，那么客户关注的事什么，用MySQL的客户为什么也要关心这个事情。ORACLE 的客户画像是什么，ORACLE的产品经理，应该有这个分析和报告。
那么按照ORACLE的客户画像来，翻印的MySQL客户也有这个需求，是从何而来的这个结论。Oracle RAC 是一种“共享一切”的数据库集群架构。它由两个或多个计算机构成一个集群，这些计算机（节点）通过高速网络（Interconnect）连接，并共享同一组磁盘存储（Shared Storage）。
MySQL的NDB，一个类似Oracle 的RAC的东西，最初是为电信计费设计的，他强调的事毫秒响应时间，高可用以及分布式冗余，并且要求再此上的事务高度结构化，且短事务。
此时不禁要问一句，ORACLE 你已经有了ORACLE这样的数据库巨无霸，而搞出MySQL NDB的缘由是什么。
NDB的核心设计是在分片和shared nothing的架构上，数据分布在多个节点，对于主键的查询速度非常快，而只要涉及到普通数据库的 join, group by 等就马上不行了。
同时ORACLE在NDB上进行了一些努力，但是基于分布式的概念在0RACLE天生的缺陷，如设计了协调器而数据的性能大量损耗在网络通信和数据传输中。同时基于NDB非常不擅长复杂查询的特性，虽然也研究了下推的方式减少网络和节点传输数据，但存在JOIN的列的类型限制等诸多问题。
同时一些自身的ORACLE的专家，还试图给ORACLE刷白，我们来看这段。
But the way MySQL Cluster splits data in a sharded manner over the data node pairs means that it supports queries best if they are lookups for specific rows by their primary key. Range queries likely have to span many data nodes. Join queries also have to span many data nodes. Complex reporting queries have terrible performance.
Many people who don't understand this tradeoff attempt to port their existing application to use MySQL Cluster, and are disappointed in the performance. It may give no improvement over using InnoDB, or it can even show a drop in performance.
This isn't a weakness of MySQL Cluster -- it's a weakness of a physically sharded architecture in general.
但是 MySQL Cluster 在数据节点对上以分片方式分割数据的方式意味着，如果查询是通过主键查找特定行，它最支持查询。范围查询可能必须跨越许多数据节点。连接查询也必须跨越许多数据节点。复杂的报告查询性能很差。 许多不理解这种权衡的人试图将他们现有的应用程序移植到使用 MySQL 集群，并对性能感到失望。它可能不会比使用 InnoDB 有任何改进，甚至会显示性能下降。 这不是 MySQL Cluster 的弱点 —— 这是一般物理分片架构的弱点。
这上面这位仁兄的解释是，不支持复杂查询不是MySQL Cluster的弱点，而是分片结构的弱点。
继续辩解为mysql cluster
硬件预算。您需要大量服务器，而每台服务器都需要大量 RAM。您可能还需要将集群放在专用子网上，并为您的所有主机购买高端 NIC。软件是免费的，但基础设施和操作可能很昂贵。 配置和调优知识。NDB 不是 MySQL 站点中最常用的存储引擎 InnoDB。所以很多调优智慧和留档并不适用。找到能够有效操作 MySQL 集群站点的 DBA 很难。或者你可以从一个有主流 MySQL 知识的称职 DBA 开始，给他们时间来培训 NDB，但这也既耗时又昂贵。 模式设计。任何分片架构都需要有一个旨在利用分片的模式。如果查询只触及一个分片，查询效果很好。但有时您还需要运行一个范围查询，该查询将触及所有分片。我的雇主Percona为几家公司提供咨询，他们阅读了 MySQL 集群的高基准数字，因此他们简单地将现有应用程序导入 MySQL 集群实例，发现它比使用传统 MySQL 实例时性能更差。
上面一些国外数据库专家为MySQL Cluster的辩解，让我们可以窥见更多的MySQL Cluster的缺陷。
总结为：
需要大内存，以及更多的主机，因为数据全部要在内存中处理数据的格式和数据的操作方式，并不和MySQL完全兼容之前在MySQL可以很好解决的一般复杂SQL查询的问题，在NDB集群并不能很好的解决现有的应用程序，如果构建在MySQL上，是无法安全的且完全的移植到应该主键查询，且对于范围查询十分的不友好MySQL Cluster 文档
而官方的我找到的MYSQL CLUSTER的文档，对于以上问题，一概不谈，都是围绕数据库的高可用去谈论数据库产品的，对于数据查询的难点，和应用的改造只字不提。
后来查了一下这个系统的历史，这个系统并不是Oracle自研的，而是收购Ericsson 而来了，而当初这个系统的产生完全是针对电信行业特定的系统而生，并不是为了广泛的数据库应用而设定的。Ericsson
所以从上述的信息收集和信息的分析，MySQL Cluster本身就不是为了广泛的数据库客户服务的，他出自瑞典爱立信的内部的数据库系统。
最后根据网络查询的NDB的问题点总结如下：
核心是同步内存分布式架构，shared Nothing In Memory数据节点全部内存驻留，虽然后期支持磁盘，但是性能会急剧下降所有更新操作都需要两阶段在多个节点提交完成，节点数量变大将导致写放大，和网络数据同步的消耗变大无法完成JOIN 的数据查询，导致数据库无法完成普通数据库可以完成的任务，官方建议使用 KEY VALUE进行数据的提取和存储。系统没有分布式性能优化器，仅仅支持 RC的隔离级别对于MYSQL 本身支持的功能不支持，全文索引，空间索引，约束，外键，触发器，存储过程，等管理极其复杂，包含了 NDB_MGMD , NDBD ,MYSQLD 等组件配置极其复杂对于系统启动顺序要求非常敏感写到这里，让我想起另一个数据库的类似杰作，PostgreSQL XL XC系统。
另外一些论坛中对于NDB系统的有一个用户的评价，就怕出问题，出了问题，一修就是半天。
综上所述，MySQL CLUSTER 系统是一个ORACLE 在自己数据库产品中失败的杰作，收购，且针对极为特殊的业务场景，与当前的大部分数据库系统相比，无法完成基本的JOIN SQL查询的工作，系统扩展后，并不能得到系统的性能提升，种种问题。
NDB 测试场景（顺便说一句，ORACLE在官方文档开始淡化 NDB CLUSTER）
测试场景预期结果（NDB）简单主键 KV 写入（单表）表现良好，近似线性扩展跨分区 Join（两张表）性能急剧下降，延迟飙升增加节点数至 8~10写入延迟开始不稳定，事务失败率上升SQL 节点横向扩展（多前端）复杂查询性能无明显改善模拟网络抖动 + 节点重启集群一致性恢复慢，容易出现事务挂起或数据不一致作者介绍
刘华阳，20年经历风霜雨打的 DBA，5年的 DBA 架构和团队管理经验，只要是数据库都喜欢学习。PostgreSQL ACE，MongoDB 狂热者，10年的 MYSQL 工作经验，现在在玩 POLARDB 与时俱进。
来源：dbaplus社群一点号