Clustrix Sierra关系数据库集群

Clustrix的Sierra数据库集群引擎是一个share-nothing架构的可伸缩关系数据库集群。官方宣传的非常诱人，说是功能像集中式关系数据库一样强大，可伸缩性超强，不需要规划什么数据分区，可用性也非常高。简直是集SQL和NoSQL的优点于一身。据说最近阿里云的RDS服务很可能是基于这个，因此仔细去了解了一下，发现架构上属于软硬一体化的路子，感觉架构上还是有些问题，对硬件的要求也不低。

Sierra前端采用MySQL协议，但本身跟MySQL没有任何关系。系统是一层架构，每个节点既负责处理逻辑，又负责数据存储，没有做处理和存储分层。

表数据根据某些可指定的属性或属性组合Hash/Range分区划分为slice。slice有多个复本保证可靠性。没有专门的主复本机或从复本机，每个节点都可以存储任意复本。slice的数目与表大小有关，太大时分裂，也可以由用户来设slice的数量。slice可以在集群中在线移来移去，新节点上线时分配一些slice给它。每个slice有个主复本，只有主复本处理读操作并有缓存，写操作要更新所有复本。索引是一张内部的独立的表，即全局索引，根据索引键值分区。没有局部索引。全局索引的优点是方便支持唯一性和外键。

每个节点上都有分区信息，查询提交到任意一个节点，Database Personality Module负责将查询分解路由到多个节点并发执行。简单操作直接定位一个节点处理就行了，可伸缩性应该非常不错。复杂查询尽可能的将操作下推给数据所在节点，减少节点间交互。

并发控制使用MVCC，保证事务ACID。读操作不加锁，不会被阻塞。并发控制只在本地做，不需要全局锁，当然更新时要用原子提交。比较麻烦的问题是更新的性能问题。所有更新都是分布式的，至少要更新多个复本，还要更新多个（全局）索引，每个索引都有多个复本，这个问题听上去很夸张。Clustrix为了搞定这个问题，使用了优化的Paxos协议，但更重要的是节点之间要用两路20Gb的Infiniband来互联，还得用带电支持的NVRAM，这样才能保证更新的吞吐率和提交时的响应时间。

Clustrix不提供单独的软件，要用还得用它们的专有数据库服务器，网络设备也得配套。目前有4100和4110两种服务器，都是1U，4核CPU，内存为24/48G，7块80/160G SSD（存数据），1块500G SATA（估计是系统盘），两路20Gb Infiniband（节点间互联及数据迁移专用），4块千兆网卡，1G NVRAM。NVRAM不知道是带电支持的DRAM还是PCM。

看完了架构，我觉得这东西还是有一些缺点。首先从配置可以看出来这玩意挺贵的，存储全用SSD，还要NVRAM和Infiniband。其次没有多表共享的分区策略，这使得联接操作基本上都要分布式处理。第三没有局部索引，使得全局索引的更新对硬件性能的要求非常高。设计中的有些选择总觉得值得怀疑，比如既然非主复本是不可读的，为什么要用原子提交保证一致性，应该异步去更新就行了。

用了这么好的硬件，它的吞吐率估计还不错，但现实中有大量应用是因为数据量太大而需要分布式扩展，并不要求极高的吞吐率，这样用Sierra性价比就划不来。Clustrix是去年5月推出这个产品，现在应用情况好像很一般，估计也是由于这些原因。

最终小结一下：
1、兼容MySQL协议，支持关系数据库几乎没有功能，包括索引唯一性和外键。
2、share-nothing
3、动态可伸缩，高可用
4、单层架构，节点即负责处理也负责存储
5、根据指定属性或属性组合的Hash/Range分区
6、全局索引
7、更新所有复本，只读主复本
8、高端硬件，SSD、NVRAM、Infiniband