关于Clustrix Sierra数据库的补充

本篇是2010-5-14号《最新云计算信息》，也是对周三的《云计算时代的MySQL-Clustrix Sierra分布式数据库系统》的补充，希望大家能喜欢！

本文将对Clustrix Sierra数据库系统的运行机制做进一步的解析，并主要关注分片和分布式查询这两方面。

分片

图1. Clustrix Sierra分片图

Sierra系统会将数据库Table分割成一些称为“Slice（片）”的对象，而且这些Slice会有很多的备份来保证数据的冗余。在上面这张图上，表T1有两个Slice，分别是T11或T12，而且每个Slice都有它们相对应的备份Slice（T11’ 和T12’ ）。每个Table主要会根据其大小来分割成相应数目的Slice，而且Slice和其备份在集群中的位置由系统自动设置，而且每个备份都自带一个Index。而且无论是新节点加入还是删去，系统都会在集群中对数据进行重新安排。

数据的Cache是放在数据的本地，比如T11和它的Cahe都在节点1上，当写数据时候，写的请求会写到那个Slice所有的备份，比如在节点1的T11和在节点2的T11’。但读只会涉及到那个主要的备份，这样避免同一个数据被多个节点缓存，如果某个节点资源比较紧张，系统会对使用在另一个节点的备份用来读。还有系统使用dist(<key>) 函数来分布Slice，而且这个函数可以是基于Range的，也可以基于Hash。

还有，系统没有使用全局table或者行级锁来维护一致性，而是使用MVCC（Multi-Version Concurrency Control）机制。这样能避免全局竞争的情况出现。

分布式查询

接下来通过介绍一个“两表Join”的例子来展示Clustrix Sierra系统是如何实现分布式查询的。

图2. “两表Join”的例子

主要有下面三步：

1. 将查询转译为系统本地代码。
2. 通过Sierra Planener来将查询分为对T21和T22这两个Slice的独立查询，并同时并行处理，来获取相应的数据。
3. 最后，按照查询条件对上面两个查询返回的行进行处理。
4. 总的来说，有点类似MapReduce。

最后，提一下在Clustrix Sierra数据库中一个非常重要的设计理念：“Move the query to the data, not the data to the query”，其实这个设计理念在其它分布式系统上也有体现，比如Google的MapReduce，毕竟无论摩尔定律如何加速IT设备的发展，传输Data的成本总是远大于传输Query的成本。

参考资料：

1. Clustrix: A New Approach。