关于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

你可能感兴趣的:(mapreduce,mysql,cache,Google,云计算)