[转] 分布式存储系统(GlusterFS, Swift, Cassandra)设计对比

之前转过一篇分布式文件系统比较的文章，几大分布式文件系统全方位比较，这里再从存储的角度转一个。应该说者三个开源软件各自侧重的领域不一样，但是都具备分布式存储的特征，因此这篇文章主要是从存储的角度来进行对比。

总结：

1、 文件定位：三者均采用hash算法，另外amazon的Dynamo也是采用一致性哈希；还有采用中心路由的定位方式：如HBASE,HDFS。哈希算法的特点是读写速度比较快，但是如果增减机器会造成数据移动，采用一致性哈希算法并引入虚节点的机制可以大大减少数据的移动。中心路由机制增减节点不会造成数据移动（但是为了数据均衡，生产中常常还是会执行负载均衡操作，从而也会引起数据块移动）。

2、 数据恢复方式：GlusterFS采用了与Zookeeper类似选举leader节点的算法方式，一般情况下，该算法没什么问题，但在具体实现中，GlusterFS在某些特殊情况下可能出现脑裂，即GlusterFS不能选举出来哪份数据是完整的；swift在存储数据的时候，同时也会保存期元数据如上传时间，及其md5值等在sqlite数据库及其扩展属性内，在读取及其定时检查的时候通过检查md5值，对象大小即可确定哪份副本是OK的。Cassandra没仔细研究，但是通过其他人的分析可得出，数据恢复方式与swift类似，如周期性副本之间互相检查副本是否OK。在HDFS的处理中，数据块的恢复采用中心节点进行统一处理，通过判断DataNode是否正常（退役，死亡），数据块是否损坏来判断，如果集群规模很大，该机制就会造成中心节点（NameNode）比较忙。

3、 写数据方式：不管是大文件还是小文件，glusterFS，swift均是每个文件单位写到磁盘上，因此如果是小文件，性能可能相对比较差，因为随机写大并发很耗费磁盘性能。Cassandra的产品特点是分布式数据库（nosql），如果是文件则主要适合存储小文件，其在存储端采用三级写：首先写日志到commitlog；然后将数据写内存，当达到一定条件（数据大小，时间，key数量）将数据flush到磁盘上，该种方式也是业界处理小文件的常用方式：如Hbase，bookkeeper（yahoo），keystack（facebook），TFS（淘宝）等都用该种方式将随机写转化成为顺序写，提供小文件的写性能。而glusterfs，swift，HDFS等系统没有这方面的小文件解决方案，所以小文件支持会比较差，同时HDFS写文件通信次数多，并且强一致性等特点也是导致小文件性能差的原因。值得一提的是HDFS，Mysql等将操作日志也是将操作追加写入到一个文件，这也是通过顺序写来提高写性能的方法。

4、NWR：该理论值得一提, NWR是一种在分布式存储系统中用于控制一致性级别的一种策略。在Amazon的Dynamo云存储系统中，就应用NWR来控制一致性。每个字母的涵义如下：

N：同一份数据的Replica的份数

W：是更新一个数据对象的时候需要确保成功更新的份数

R：读取一个数据需要读取的Replica的份数

在分布式系统中，数据的单点是不允许存在的。即线上正常存在的Replica数量是1的情况是非常危险的，因为一旦这个Replica再次错误，就可能发生数据的永久性错误。

5、增减节点：在线上环境中，添加节点是很常见的，一次往往会添加一批机器，因此添加机器的方便性，是否对集群有影响等等非常重要，这也是设计者会经常考虑的问题。

6、数据删除：glusterFS直接删除文件,swift与cassandra采用先标记再周期性删除,后者从系统响应时间来说更加优秀，采用该方法的还有haystack，TFS等。HDFS也采用类似先标记，还可以选择放入回收站，不放入回收站也会尽快删除。其实对于小文件，也可以选择在系统比较闲的时间段进行删除（因为小文件本身占用空间就比较小）。

7、稳定性：虽然我上面没列到，它确是最重要的一个方面，twitter等弃用cassandra可能就有这方面原因，一个系统如果设计得再牛X,稳定性没有得到充分的验证，可能也会让我们却步。

转载信息：链接。