NDB存储引擎

   

为什么我们会选择NDB引擎呢？

    我想可能有这么两点需求：

       1.我们需要高可用，传说中的FIVE NINE

       2.我们需要高性能，多SQL节点提供更好的并发服务

    由此出发，看起来NDB引擎都能满足。可是为啥真正使用CLUSTER之后，发现，其实并不是像想象中的那么美好？我们从MYSQL CLUSTER的架构上来看看。

 

MySQL Cluster  由三类节点组成： 
    1、 数据节点（Data Nodes） 存储所有属于 MySQL Cluster 的数据。这些数据在数据
节点之间被复制以保证在一个或多个节点出现故障时集群仍然持续可用。 而且数据节点也管
理数据库的事务处理。 随着数据复制份数的增加整个系统的数据冗余性相应提高。 应用程序
使用 NDB API 直接访问数据节点，而不是通过 MySQL 服务器。 
    2、 管理节点(Management Server Nodes)   控制系统启动时的初始配置，在集群设置
发生改变时又被重新利用。通常只需配置一个管理节点；然而为了排除单点故障需要，有可
能的话，请增加管理节点的数量。以提供管理操作的高可用性。
管理节点只在集群启动和系统重配置后起作用， 集群启动以后， 无论管理节点处于什么状态， 
整个集群都将保持其在线和可用状态。
    3、 MySQL 节点(MySQL Server Nodes)   用于存取集群数据节点上的数据，给软件开
发者提供了一个标准的 SQL 语言编程接口。MySQL 服务节点负责向数据节点传送访问请
求，这使 MySQL 使用者无需知道具体的集群过程，也无需进行数据库操作的底层编程。特
别是通过增加 MySQL  服务节点数量，就可以提高集群系统性能。这种设计给 MySQL 增
加可扩展性、数据规模和系统性能提供了更广的方法和措施。
应用程序如果对实时性能要求较高， 请直接使用 NDB API， 而不是通过 MySQL 节点。
现在可以使用 C++,Java,HTTP 版本的 NDB API， 这给开发人员提供了极大的方便， 并且使
得 MySQL 集群可以应用于广泛的 web 和企业级应用。
数据库在内部被分割为一个个分区，   这些分区分布于数据节点之间。 为了避免单点故
障，至少会有两个以上的节点会用于存储特定分区的数据，这些节点组成一个节点组。 
 
    节点之间的数据交互是使用网络的，7.0之后加强了这个功能。各表数据是水平分割的，由此数据切分整合的性能瓶颈出现了。由这个架构，我们可以推论出，mysql cluster在执行类似where a=1且a唯一这样的查询时，由于其水平分割，并行处理，可以获得相对较好的性能。但当其执行类似where a>10这样的范围查询则不可避免的会执行多个NDB节点的记录集union，多表查询时多个NDB节点记录集的join，union。显而易见的，这样的应用并不适合在CLUSTER上去跑。

    我们注意到，引擎的选用是根据业务的特点来的，根据的业务选择合适引擎，这个才是王道。

    本文转载自：http://blog.chinaunix.net/uid-9375738-id-333322.html