`
cloudtech
  • 浏览: 4811788 次
  • 性别: Icon_minigender_1
  • 来自: 武汉
文章分类
社区版块
存档分类
最新评论

云存储的故事——元数据归来

 
阅读更多
云存储服务是云计算的重要组成部分。技术上,云存储属于大型分布式在线存储范畴。云存储是一大类特殊的共享存储。作为提供存储资源的服务,云存储需要保证用户存放的数据可靠,不丢失。同时,云存储必须确保实时在线,任何宕机都会给用户造成损失。因而,云存储的基本要求是高可靠和高可用。此外,云存储是海量数据的存储,规模巨大。而且,出于成本和现金流量的考虑,云存储的集群规模必须随着用户数据量的不断增加而扩展。云存储的架构,设计和技术运用都是围绕这四个基本要求展开。反之,无论多么漂亮先进的技术,只要可能影响这些目标的实现,都不能应用于云存储。

在我开始接触存储的时候,一致性哈希(以及著名的Dynamo)是非常热门的技术。技术上一致性哈希很漂亮,简洁,并且高效。但在实际应用中,却是另一种表现。本文将对集中式的元数据存储方案和一致性哈希作对比分析,以期说明元数据是更加适合云存储的选择。

1. 对象存储,块存储

实用的云存储可以分作两类:对象存储和块存储。对象存储存储是地道的数据仓储,仅仅存放key/value数据:用户有一个数据对象,需要存储起来,他就给这个对象起一个名字(key),然后将对象连同名字一起存放入对象存储。当需要的时候,用这个名字作为key,向存储系统索要。而对象存储系统必须在需要的时候将数据返还给用户,除非用户已将此数据从存储系统中删除。

块存储则是充当操作系统底下的块设备(笼统地说,就是磁盘),供系统使用。块存储实际上就是一种SAN(Storage Attach Network),将集群的存储空间分配给用户,挂载到操作系统,作为磁盘使用。因为块存储需要模拟磁盘的行为,因此必须确保低延迟。

尽管两种云存储有完全不同的目标、用途和特性,但在分布式存储基本特性方面都面临着相同的问题,这里的讨论对两者都有意义。为了简便起见,这里只讨论对象存储的情况。但很多内容和结论可以外推到块存储。

2. 存储的基础

云存储功能非常简单,存储用户的数据而已。但简单归简单,几个要点还是需要做的。当用户将一个key-value对上传至存储时,存储系统必须找合适的服务器,保存数据。通常会保存在多台服务器上,以防止数据丢失。这叫多副本。

于是,一个关键的问题就是如何选择存放数据的服务器。服务器的选择是很有技术含量的事,需要兼顾到几个要点:首先,数据必须在服务器之间平衡。不能把数据集中到少数几台服务器,造成一部分服务器撑死,而另一部分饿死。其次,在用户读取数据时,可以方便快捷定位。随后,满足云存储服务高可靠高可用大规模的特点。最后,尽可能简单。

于是,对于每个对象,都有一个key到数据存储位置的映射: key->pos。映射方式很多,最直接的,就是将每一个对象的key->pos数据对保存下来。这些数据通常被称为"元数据"。

但还有一些更巧妙的方式:根据key的特征,将key空间划分成若干分组,并将这些分组对应到不同的存储节点上。这种方式可以笼统地成为”Sharding"。如此,可以直接按照一个简单规则定位到服务器。常用的分组方式之一是按key的区间划分,比如a开头的是一组,b开头的是一组等等。而另一种更具"现代感"的分组方式,就是对key哈希后取模。哈希方案实际上就是哈希表的自然延伸,将桶分布到多台服务器中。

这两大类映射方式实质上是在不同的粒度上进行映射。"元数据"在对象粒度上,而sharding则是在一组对象的粒度。这两种不同的粒度,决定了它们有着完全不同的特性。也决定了它们在实际应用中的表现。

3. 元数据和一致性哈希

于是,在云存储方案中产生了两大流派:元数据模型和Sharding模型。而Sharding模型中,一致性哈希最为流行。一致性哈希本身很难直接用作实际使用,进而产生了很多衍生方案,其中包括著名的"Dynamo"。这里用“一致性哈希方案”指代所有基于一致性哈希的设计。

元数据方案是对象级别的key->pos映射,也就是一个会无休止增长的"map"。每多一个对象,就会多一条元数据。通常会将元数据保存在一组数据库中,方便检索和查询。元数据方案没有什么特别的地方,其核心是元数据存储部分。这部分设计的好坏,关系到系统整体的特性。关于元数据存储的设计不是本文的重点,本文将集中探讨元数据方案和一致性哈希方案的比较。

标准的一致性哈希模型是对key进行哈希运算,然后投射到一个环形的数值空间上。与此同时,对节点(存储服务器)进行编码,然后也做哈希运算,并投射到哈希环上。理论上,只要哈希算法合适,节点可以均匀地分布在哈希环上。节点根据自身在哈希环上的位置,占据一个哈希值区间,比如从本节点到下一个节点间的区间。所有落入这个区间的key,都保存到该节点上。

在这个模型中,key到数据存储逻辑位置的映射不通过存储,而是通过算法直接得到。但是,逻辑位置(哈希环上的位置)到物理位置(节点)的转换无法直接得到。标准的做法是任选一个节点,然后顺序寻找目标节点,或者采用二分法在节点之间跳转查找。这种查找方式在实际的存储系统中是无法忍受的。所以,实用的存储系统往往采用的是一个混合模型(暂且称之为“混合方案”):系统维护一个哈希区间->节点的映射表。这个映射本质上也是一种元数据,但是它是大粒度的元数据,更像是一个路由表。由于粒度大,变化很少,所以即便用文本文件都可以。这个映射表也需要多份,通常可以存放在入口服务器上,也可以分散到所有的存储节点上,关键是保持一致即可,这相对容易。

一致性哈希解决了标准哈希表改变大小时需要重新计算,并且迁移所有数据的问题,只需迁移被新加节点占据的哈希区间所包含的数据。但是,随着新节点的加入,数据量的分布会变得不均匀。为了解决这个问题,包括Dynamo在内的诸多模型,都采用了"虚拟结点"的方案:将一个节点分成若干虚拟节点。当节点加入系统时,把虚拟节点分散到哈希环上,如此可以更加"均匀地"添加一个节点。

一致性哈希及其衍生方案,将数据按一定规则分片,按一定规则将分片后的数据映射到相应的存储服务器上。因此,它只需要维护一个算法,或者一个简单的映射表,便可直接定位数据。更加简单,并且由于少了查询元数据,性能上也更有优势。

但是,这只是理论上的。

如果我们只考虑存储的功能(get,put,delete),一致性哈希非常完美。但实际情况是,真正主宰云存储架构的,是那些非功能性需求:

1、 大规模和扩展性

2、 可靠性和一致性

3、 可用性和可管理

4、 性能

在实际的云存储系统中,非功能需求反而主导了架构和设计。并且对key-pos映射的选择起到决定性的作用。

4 规模和扩展

首先,云存储最明显的特点是规模巨大。对于一个公有云存储服务,容纳用户数据是没有限度的。不可能以"容量已满"作为理由,拒绝用户存放数据。因此,云存储是“规模无限”的。意思就是说,云存储系统,必须保证任何时候都能够随意扩容,而不会影响服务。

另一方面,云存储作为服务,都是由小到大。一开始便部署几千台服务器,几十P的容量,毫无意义。资源会被闲置而造成浪费,对成本和现金流量产生很大的负面作用。通常,我们只会部署一个小规模的系统,满足初始的容量需求。然后,根据需求增长的情况,逐步扩容。

于是,云存储系统必须是高度可扩展的。

面对扩展,元数据方案没有什么困难。当节点增加时,系统可以更多地将新来的写请求引导到新加入的节点。合适的调度平衡策略可以确保系统平衡地使用各节点的存储空间。

但对于一致性哈希和它的衍生方案而言,却麻烦很多。原始的哈希表一旦需要扩容,需要rehash。在基于哈希的分布式存储系统中,这就意味着所有数据都必须重新迁移一遍。这当然无法忍受的。一致性哈希的出现,便可以解决此问题。由于对象和服务器都映射到哈希环上,当新节点加入后,同样会映射到哈希环上。原来的区段会被新节点截断,新加入的节点,会占据被切割出来的哈希值区间。为了完成这个转换,这部分数据需要迁移到新服务器上。相比原始的哈希,一致性哈希只需要传输被新服务器抢走的那部分数据。

但是终究需要进行数据迁移。数据迁移并非像看上去那样,仅仅是从一台服务器向另一台服务器复制数据。云存储是一个在线系统,数据迁移不能影响系统的服务。但迁移数据需要时间,为了确保数据访问的延续性,在迁移开始时,写入操作被引导到目标服务器,而源节点的待迁移部分切换至只读状态。与此同时,开始从源节点迁移数据。当用户试图读取迁移范围内的数据时,需要尝试在源和目标节点分别读取。这种单写双读的模式可以保证服务不受影响。但是,必须控制数据迁移的速率。如果迁移操作将磁盘吞吐能力跑满,或者网络带宽耗尽,服务必然受到影响。

另一个问题是,除非成倍地增加节点,否则会存在数据不平衡的问题。为了平衡数据,需要迁移更多的数据,每台节点都需要迁出一些,以确保每个节点的数据量都差不多。虚拟节点的引入便是起到这个作用。于是实际的数据迁移量同增加的容量数成正比,系数是当前存储系统的空间使用率。

于是,一个1P的系统,三副本,70%的消耗,扩容200T,那么需要迁移大约140T*3=420T的数据,才能使数据存储量得到平衡。如果使用现在常用的存储服务器(2T*12),需要新增21台。如果它们都并发起来参与迁移,单台迁移速率不超过50MBps,那么这次扩容所需的时间为420T/(50M*21)=400000秒,大约4.6天。这是理想状况,包括软硬件异常,用户访问压力,迁移后的检验等情况,都会延长迁移时间。很可能十天半月泡在这些任务上。而在数据迁移完成,老服务器的存储空间回收出来之前,实际上并未扩容。那么万一扩容实在系统空间即将耗尽时进行,(别说这事不会碰到,一个懒散的供货商,或者厂家被水淹,都可能让这种事情发生。云计算什么事都会遇到),那么很可能会因为来不及完成扩容而使系统停服。云存储,特别是公有云存储,扩容必须是快速而便捷的。

更复杂的情况是迁移过程中出错,硬件失效等异常情况的处理过程会很复杂,因为此时数据分布处于一种中间状态,后续处理必须确保系统数据安全一致。

系统的扩容规模越大,困难程度越大。当系统有100P的规模(很多系统宣称可以达到的规模),而用户数据增长迅猛(公有云存储有明显的马太效应,规模越大,增长越快),在几百上千台服务器之间迁移成P的数据,是多么骇人的场景。

数据迁移会消耗网络带宽,吃掉磁盘负载,搅乱服务器的cache等等,都是云存储的大忌,能不做尽量不做。

元数据方案一般情况下不需要做迁移。迁移只有存储服务器新旧更替,或者租借的服务器到期归还时进行。由于数据对象可以放置在任何节点上,因而可以把一台节点需要迁移的数据分散到其他节点上。并且可以从其他副本那里多对多并发地传输数据。负载被分散到整个集群,对服务的影响更小,也更快捷。实际上,这个逻辑和数据副本修复是一样的。

很显然,相比一致性哈希方案动不动来回迁移数据的做法,元数据方案提供一个动态平衡的机制,可以无需数据迁移,服务器一旦加入集群,可以立刻生效,实现平静地扩容。

5 可靠性和一致性

可靠性(本文特指数据的可靠性,即不丢失数据)无疑是云存储的根本。用户将数据托付给你,自然不希望随随便便地丢失。维持可靠性是云存储最困难的部分。(当然,更难的是在保持高可靠性的前提下确保高可用)。

在任何一个系统中,硬件和软件都无法保障完全可靠。芯片会被烧毁,电路可能短路,电压可能波动,老鼠可能咬断网线,供电可能中断,软件会有bug,甚至宇宙射线会干扰寄存器…。作为存储的核心部件,硬盘反而更加脆弱。在标准的服务器中,除了光驱和风扇以外,硬盘是唯一的机电元件。由于存在活动部件,其可靠性不如固态电路,更容易受到外界的干扰。所以,硬盘时常被看作消耗品。在一个有几万块硬盘的存储集群中,每周坏上几块硬盘是再寻常不过的事。运气不好的时候,一天中都可能坏上2、3块。

因此,只把数据保存在一块盘中是无法保障数据可靠的。通常我们都会将数据在不同的服务器上保存多份,称之为“副本”。原则上,副本越多,越可靠。但是,过多的副本会造成存储成本的增加,并且降低性能,增加维持一致性的难度。一般会保持3副本,是一个比较均衡的数字。

但是,在确定的副本数下,真正对可靠性起到关键作用的,是副本丢失后的恢复速度。比如,一个3副本存储系统中,当一个磁盘损坏后,它所承载的数据对象就只剩2个副本了。在这块盘修复之前,如果再坏一块盘,恰巧和尚未修复的盘有共同的数据对象,那么这些数据就只剩一个副本在支撑着,这是非常危险的状态。更有甚者,一个3副本的存储系统,在运行过程中,即便没有硬盘损坏,总会有一些对象由于种种原因处于两副本状态,尚未来得及修复。比如写入数据时,有一个副本写完后发现校验码不对,需要重写。此时,如果一块盘损坏了,上面正好有这些2副本的对象。于是,从这一刻开始,这个对象只有1副本。坏盘上的数据被修复之前,另一块盘包含此对象的硬盘也坏了,那么数据就丢了。尽管这种概率很小,但是云存储系统是经年累月地运行,大规模加上长时间,任何小概率事件都会发生。而且在实际运行的系统中,很多因素会导致硬盘寿命远小于理论值,比如机架震动、电源不稳、意外失电、辐射等等。而且,对于成批采购的硬盘,通常都会集中在一段时间内一起进入失效期,多块磁盘同时损坏的概率会大幅提高。

如果数据修复的速度足够快,可以抢在另一块盘损坏之前,修复丢失的副本,那么数据丢失的概率会大大减小。(严格地讲,无论修复时间有多短,在修复期间坏第二块盘的概率始终存在,只是修复时间越短,这个概率越小。关键是要让它小到我们可以接受的程度)。

一致性哈希方案中,如果将一块磁盘同一个hash区间一一绑定。因此,数据恢复时,只能先更换坏盘,然后从其他副本处读取数据,写入新磁盘。但是,磁盘的持续写入能力通常也只有50-60MBps。如果是一块有1.5T数据的硬盘失效,那么恢复起来至少需要30000秒,将近9个小时。考虑到服务器的整体负载和网络状况,时间可能会接近12小时。在这个时间尺度里,第二块盘,甚至第三块盘损坏的概率还是相当大的。而且,硬盘更换的时间取决于机房管理的响应能力,这往往是一个薄弱环节。

如果方案中让节点同hash区间一一对应,在节点内部,再将数据分散存储到一块磁盘中,那么当需要恢复副本时,节点将损坏的磁盘上的数据对象分散存放到其他磁盘上。这样,可以先发起修复,从其他副本那里都到数据,并发地向多个磁盘恢复数据,磁盘的吞吐限制会得到缓解。但问题的解决并不彻底。首先,网络会成为瓶颈。1个千兆网口最多支持到120MBps,这个速率也仅仅比磁盘快一倍,而且实际使用中也不能将带宽全部用光,否则影响服务,毕竟其他硬盘还是好的,还需要正常工作。原则上可以通过增加网口数量拓宽吞吐量,但这增加了网络设备方面的成本。而且这也仅仅是增加3、4倍的吞吐能力,我们真正需要的是近10倍地缩小恢复时间。至于光纤,那不是普通公有云存储所能奢望的。即便网络吞吐问题解决了,还有一个更核心的问题。因为数据在节点内部任意分散到各磁盘上,那么节点就需要维护一个key->磁盘的映射,也就是节点内的局部元数据。这个元数据需要服务器自己维护,由于单台服务器的资源有限,元数据的可靠性、可用性和一致性的维持非常麻烦。一套存储一套元数据存储已经够麻烦的了,何况每个节点一套元数据。一旦这个元数据丢失了,这个节点上所有的数据都找不到了。理论上,这个元数据丢失了,也不会影响全局,可以利用一致性哈希算法到其他副本那里恢复出丢失的数据。但不得不将原来服务器上的所有数据都传输一遍,这个数据量往往有一二十T,恢复起来更困难。更现实的做法是直接扫描各磁盘,逆向地重建元数据。当然,这将是一个漫长的过程,期间整台节点是不可用的,此间发生的写入操作还需的事后重新恢复(具体参见本文“可用性”部分)。

副本恢复最快,影响最小的方法就是,不让数据对象副本绑死在一台节点上,只要数据对象可以存放到任意一台节点,那么便可以在节点之间做多对多的数据副本恢复。集群规模越大,速度越快,效果越好。基于元数据的方案,每一个对象同节点,乃至硬盘的映射是任意的,在副本恢复方面,有得天独厚的优势。而一致性哈希严格地将数据同节点或磁盘绑定,迫使这种并发无法进行。

有一些基于混合方案的衍生方案可以解决一致性哈希在副本修复速度问题:将哈希环划分成若干slot(bucket,或者其他类似的称谓),数量远远大于将来集群可能拥有的节点数,或磁盘数。(好吧,我们说过规模无限,无限自然不可能,只要足够大就行了,比如2^32)。slot到节点或者磁盘的映射,通过一个映射表维护。各副本集群中的slot分布互不相同。当一个磁盘损坏时,找出所包含的slot,将这些slot分散到其他节点和磁盘上去,这样便可以并发地从其他节点以slot为单位恢复副本。在损坏磁盘更换之后,再将一些slot,可以是原来的,也可以是随意的,迁移到新硬盘,以平衡整体的数据分布。迁移的时候,副本已经恢复,迁移操作的时间压力就很小了,可以慢慢来,磁盘吞吐的瓶颈也不会有什么的影响。

但相比之下,元数据方案修复副本之后不存在数据迁移这一步,在这方面对象级元数据的存在使副本恢复简单很多。

同数据可靠性相关的一个问题是一致性。一致性问题可以看作可靠性问题的一个部分。因为当各副本的数据版本不一致时,便意味着数据对象的当前版本是缺少副本的。(实际上,从存储角度来讲,一个数据对象的不同版本,就是不同的数据)。确保一个数据对象的一致性最实用的方法是所谓W+R>N。即N个副本中,一个版本写入时确保有W个成功,而读取时确保有R个成功,只要满足W+R>N的情况,便可以保证始终可以读到最后写入成功的版本。

W+R>N的使用有一个问题,需要并发地从所有副本上尝试读取数据,然后通过读取的数据对象版本(或者时间戳)的比对,以确定是否满足一致性公式的要求。如果所读取的数据有几十上百MB,甚至上G的对象,一口气读出所有副本,而最终只取其中一个,着实浪费,系统压力会整整大上N倍。解决的方法是先做一次预读,读出所有副本的版本信息,进行一致性比对,确定有效副本后,再行数据本身的读取。

元数据方案在一致性上简单的多。元数据为了保证可靠,也会使用多副本。因为元数据很小,可以保持更多的副本数,比如5个,甚至7个。如此多的副本,基本上不必担心其可靠性。重点在于一致性。同样也是采用W+R>N的策略,但却将元数据读取和一致性保障在一次访问中解决。对于数据存储服务器而言,任务更多地是在保障每一个副本和版本的完整。

随着时间的推移,数据会发生退化,有各种原因造成副本的丢失。一致性也是一样。对于热数据,经常被访问,存储数据出错很快就会发现。但冷数据需要依靠定期检查发现错误。这个核对工作在元数据方案里,就是比对元数据和节点的每个盘上的对象清单,元数据保存的永远是最新版本,只要不匹配,就可以认定出错,立刻加以修复。但在一致性哈希方案中,需要交叉核对一个哈希区间的三个副本所包含的对象清单,以确定哪个对象是最新副本。然后再修正数据问题。

当一个节点由于种种原因下线,那么期间的所有写入操作都无法完成。此时,元数据方案处理起来很简单:另外挑选一台合适的节点,写入副本,更新相应的元数据项后,操作完成,一切太平。

一致性哈希方案要复杂得多。对于一个哈希区间的一个副本,被固定在一个节点上。换句话说,一组副本必须存放在特定的一个节点上,不能随意放置。如果需要定位到其他节点上,必须整区间的迁移。这个特性的结果就是,当这台节点下线后,无法写入相应的副本,也无法随意地将副本写到其他节点上。后续处理有2种方法:1、将副本或者key写入一个队列,等节点恢复后,发起修复操作,从其他的副本获得数据,补上缺失的副本。问题是这个队列必须有足够的可靠性,否则待修复key丢失,相应的对象会长时间缺少副本,直到数据一致性检测发现问题。这会增加一致性检测的压力,使得原本就复杂的过程雪上加霜;2、按一定规则写入其他节点,待恢复后原样迁移回来。这个方案相对简单些,但整个调度逻辑比较复杂,涉及到数据节点之间的协调。但是这种点到点的数据恢复,会给暂存服务器产生压力,不利于稳定运行。不管哪种方案,数据迁移或者复制都是免不了的。这中间的异常处理,负载控制等都需要花费心思。

元数据方案在节点失效时的处理要比一致性哈希方案单纯简洁的多。节点失效是云存储的常态,处理方式越简洁越好。在大集群中,几个节点同时下线都是很平常的事,一致性哈希如此复杂的节点失效管理,就是运维的地狱。

6. 可用性和可管理性

可用性在某些方面同可靠性有着共同的解决方案,比如多副本可以消除单点,提高可用性。但是它们在其他方面却存在着矛盾。当一个副本写入失败,从可靠性角度而言,应当设法重试,或者索性告诉用户写入失败。但这样势必造成响应变慢,或者可用性降低。(响应变慢超过一个程度后,便会被认为是失败,不管最终是否成功)。此外,为了保障可靠性的诸多措施,比如副本修复,数据迁移等,会消耗系统资源,从而影响到可用性。

在上面对于可靠性的分析中可以看到,由于副本被绑定在特定节点上,一致性哈希要确保同元数据相当的可靠性的话,不得不放弃一些可用性,将有副本写入出错的操作返回失败。因为元数据方案的数据存储位置没有限制,对于多数的副本写入失败可以通过重选服务器得到更正。一致性哈希则无此便利,要么放弃一定的可用性,要么承担可靠性的风险。

根本上而言,一致性哈希在副本写入上制造了局部的隐式单点,尽管是短期的或者临时的,但依旧会对系统产生影响。一个设计良好的分布式系统会尽量地减少单点出现的可能性,这直接关系到系统的持续和瞬时可用性。元数据方案可以确保数据分布上不存在任何形式的单点。对于一个对象而言,任何节点都没有特殊性,这种无差别化才能真正保证消除单点。

在云存储系统中,使用公式R+W>N的地方,便是影响系统可用性的核心要点。可用性和一致性往往是一对冤家。在这个地方,需要向N台服务器同时发出请求,而最终的有效性取决于服务器反馈的情况。一般来说,N越大,越容易在确保一致性的前提下,维持可用性。(实际上是取决于X=R+W-N的值,越大越好。这个值表示当X+1个副本下线或丢失后,系统将不能保证临时的或永久的一致性)。但是,N-R和N-W越小,对可用性的影响越大。如果N=R,那么只要有一台服务器下线,会造成系统不可读取。如果N-R=3,那么即便是3台服务器下线,系统还能正确读取。对于W也一样。在这里,一致性和可用性是一对矛盾。当副本数足够多(N数可以很大),可以很容易地获得较高的X数。比如N=7, R=W=5,X=3,N-R=2,N-W=2,意味着即便有2台服务器下线,也能保证读写的有效性,同时确保一致性。

但如果N=3,无论如何也只能让R=3或者W=3,此时尽管可以获得X=3的一致性保障级别,但即便一台服务器下线,也会造成系统不可用。如果R=W=2,可以保证1台服务器下线,系统还是可用,但一致性保障级别降低到了X=1。

在元数据方案中,元数据的副本数(N)可以大些,故障和异常造成的副本下线,或者丢失,对系统的可用性和一致性产生的影响很小,对于这类问题的处理的紧迫性会低一些。相反,一致性哈希的一致性依赖于数据存储节点,面对大大小小的数据对象,无法使用很多副本,通常都会用3。在这个N数下,无论一致性还是可用性,都很脆弱。

对于可用性而言,最后,也是最重要的一点是运维管理。运维的好坏直接决定了可用性。前文已述,一致性哈希在一些关键的系统维护点上相比元数据方案多出不少环节。在同样运维水平和强度下,一致性哈希更加容易出现可用性问题。这方面对可用性的影响很难明确地给出量化的评判,但是运维是云存储系统高可用保障的核心,运维的复杂性往往决定了最终9的个数。

现在来看看元数据方案的运维特点。元数据方案相比标准一致性哈希方案多出了一个元数据存储系统。元数据通常有更多的副本,副本数越多,一致性的维持越发困难。一般的方案都是依赖异步执行的版本同步机制,尽快同步各副本。但是,为防止同步失效,会定期全面扫描核对所有元数据,确保元数据不会退化。这个过程伴随者很大的数据吞吐和计算量。但这个过程是离线操作,并且没有非常严格的时间要求,即便失败,也不会过多地影响系统的运行。它的时间裕度比较大。元数据量不会很大,在合适的算法下,一致性比对的时间也不会很长,通常不超过2、3小时。并且可以根据需要增减所需的服务器数量。

一致性哈希运维的重点则在另一头。一致性哈希模型及其各种变形由于需要确保数据平衡,不得不在扩容时进行大范围的数据迁移。在不影响服务的情况下,迁移速率必须受到限制,导致迁移时间很长。但有时数据迁移的时间要求很高。因为在迁移完成之前,迁移的数据源所占的空间还不能回收。此时所添加的空间暂时无法使用。而且数据回收也需要花费时间。在可用空间紧迫的情况下,迁移速度的压力会很大。一旦迁移过程中出现异常,将会雪上加霜。在长达几天的数据迁移过程中发生磁盘损坏的可能性非常大,修复操作将迫使数据迁移减速,甚至停止。修复的优先级更高。迁移操作涉及很多服务器的并发,协调和控制工作很复杂。而且不同的迁移原因会有不同的迁移策略。再加上各种异常处理,运维管理内容很多,将是非常痛苦的事。随着规模越来越大,最终可能超出运维能力的极限,无力维持存储的可用性。

元数据方案在绝大多数情况下不会进行数据迁移。少掉这样一个复杂重载的环节,对于系统维护的压力会小很多。

因此,尽管元数据方案多出了一个元数据的存储集群,但它相比一致性哈希方案反而更容易维持可用性。

7. 性能

性能是大多数程序员都关心的东西,往往被放在很高的位置。但在云存储中,性能反倒是级别较低的问题。存储是io密集型的系统,无论如何优化代码,都不可避免地受到物理设备的限制。

云存储的性能要点首先在于并发。做好并发,确保所有请求不会相互间阻塞,便可以从大的方面保证性能。元数据方案中,元数据存取存在大量的并发访问。每个用户的数据访问请求,在这里会转化成N个并发请求。系统不得不管理巨大数量的并发操作,并且小心维护并发之间的逻辑关系。传统上使用的线程池很难满足需要,不得不采用异步模型,从而增加开发难度。

一致性哈希在这方面有自身的优势。因为N数不大,并发的放大效应相比元数据方案要小很多。当然前面也说了,小N数会减小一致性的裕度,也不利于可用性。

云存储性能优化另一个重要的要点是,减少一次用户请求中跨服务器访问的次数。跨越网络的访问必然存在延迟,跨的次数越多,整体延迟越大。同时也会增加网络的负担。元数据方案天生多一次元数据检索操作,因而在这方面处于劣势。但一致性哈希在读取对象时,也没有好到哪里去。前面讨论一致性的时候已经说过,为了执行W+R>N的逻辑,又不能读取所有副本,只能采取一次并发预读操作。这样一致性哈希的跨服务器访问次数也同元数据方案扯平了。只是并发数少一些。这是以降低容错能力为代价的。

元数据在性能方面的主要劣势是元数据的访问。系统对元数据的访问主要是检索操作,因此通常会采用数据库,或者具备检索功能的数据存储引擎。这些模块在重载情况下有性能限制。由于副本数多,简单地扩展服务器数量代价较大。好在这些部分的优化,特别是数据库优化,有很成熟的经验,花些功夫也是能做好的。

8. 其他

在功能方面,一致性哈希还有一个不足。尽管一致性哈希可以实现对象存储的基本功能,但存储服务有时需要提供一些额外的功能,比如列出一个用户所保存的对象key清单。如果有元数据,那么这些用户的信息可以保存在元数据里,需要的时候检索这些信息即可。但是,在一致性哈希方案中,所有的key在系统中已经被哈希,分散到所有服务器上。如果要获得用户的对象清单,那么就不得不在所有存储节点上执行相应的检索操作,想象一下一个几千,甚至几万台节点的存储集群,执行一次这样的操作,会是什么结果?

对于存放了大量数据对象的用户,列出对象清单的操作可能没有什么直接意义。或许不提供此类功能,用户也能忍受。但是,另一个用户相关的问题却无法回避。这就是计费。计费就是计算出一个用户所有的对象所占据的容量,然后制作成费用清单,提供给计费系统。

计费最简单的办法是通过用户的访问记录,累积出来,写入就加,删除就减。但是实际没那么简单。对于一个key的覆盖写入,那么必须先扣除原有的对象大小,然后再加上新对象的大小。

更重要的,由于访问记录可能出错或者丢失,这种相对计算方式随着时间的增长会产生累积误差。需要定期校准。校准的方式就是统计所有用户的对象大小,做绝对容量的计算。由于对象大小存放在所有数据存储节点中,这又是一个恐怖的全系统的数据扫描。同时还必须确保对象属性的一致性,以免计费出错。

计费涉及到钱,通常用户会非常敏感,应当尽可能不出错。校准需要尽量频繁。但是全集群的计费校准代价实在太高,还是应当尽量少做。于是这对矛盾怎么调和,对于开发运维人员都是个巨大的挑战。

在元数据方案中,计费所需信息都可以保存在元数据中,计费操作只局限在元数据上。元数据量少,可以直接将数据dump出来,在额外的服务器上计算。这种操作相对轻量很多,可以更频繁地执行,提高用户账单的准确性。

9. 总结

经过大体的分析,可以看到在仅考虑云存储功能需求的情况下,一致性哈希具备简单高效的优势。但是,大型的云存储系统的功能不是影响其架构的主要因素。包括规模、可扩展性、可靠性、可用性和一致性等方面的非功能性需求才是云存储需要重点考虑的地方。一致性哈希及其各种变形方案,在这些方面存在诸多缺陷。尽管每个方面的缺陷并非不可逾越的障碍,往往都可以通过一些设计和运维手段加以解决。但是系统复杂度和运维难度随之增加。最关键的,每个方面的问题整合起来所产生的叠加效应,会轻而易举地摧垮一个云存储系统。

一般而言,一致性哈希适合一些有既定规模,不太需要扩展,数据尺寸不大的场合。这些特性意味着一致性哈希无法很好地适用于大型的云存储系统。元数据方案尽管在架构上复杂些,但其优点是灵活。而这种灵活性更加适合云存储的需要。
分享到:
评论

相关推荐

    Huffman 压缩算法的C++实现源代码

    这种编码方式能够显著减少数据的存储空间,提高压缩效率。 在C++中实现哈夫曼压缩算法通常包括以下几个关键步骤: 1. **统计字符频率**:首先,需要读取输入文件并计算每个字符出现的频率。可以使用一个`std::map,...

    24灯十字旋转LED蓝牙版制作资料

    POV系列-24灯十字旋转LED,资料有原理图、PCB丝印图、 改字软件 以及单片机固件,如果有单片机基础完全可以制作参考制作

    大创项目_24.zip

    大学生创业项目源码

    B端安全网关的简单实现#Java#Springboot源码分享

    已实现http协议下的请求转发。支持GET,POST请求以及文件上传,支持IP白名单、apiKey配置。

    【毕业设计】基于uniapp微信小程序电影院选座订票系统设计【源码+论文+答辩ppt+开题报告+任务书】.zip

    【项目资源】:包含前端、后端、移动开发、操作系统、人工智能、物联网、信息化管理、数据库、硬件开发、大数据、课程资源、音视频、网站开发等各种技术项目的源码。包括STM32、ESP8266、PHP、QT、Linux、iOS、C++、Java、MATLAB、python、web、C#、EDA、proteus、RTOS等项目的源码。 【项目质量】:所有源码都经过严格测试,可以直接运行。功能在确认正常工作后才上传。 【适用人群】:适用于希望学习不同技术领域的小白或进阶学习者。可作为毕设项目、课程设计、大作业、工程实训或初期项目立项。 【附加价值】:项目具有较高的学习借鉴价值,也可直接拿来修改复刻。对于有一定基础或热衷于研究的人来说,可以在这些基础代码上进行修改和扩展,实现其他功能。 【沟通交流】:有任何使用上的问题,欢迎随时与博主沟通,博主会及时解答。鼓励下载和使用,并欢迎大家互相学习,共同进步。

    weixin056基于微信小程序的购物系统+php(文档+源码)_kaic

    weixin056基于微信小程序的购物系统+php(文档+源码)_kaic

    使用mingw编译的openssl-3.4.1,有需要的自取吧

    使用mingw编译的openssl-3.4.1,有需要的自取吧

    Oracle19c netca.rsp

    Oracle19c netca.rsp

    前端小白必看!HTML、CSS、JavaScript 基础全解析

    本资源聚焦前端三剑客基础。课程从 HTML 构建网页结构开始,深入 CSS 样式美化,再到 JavaScript 实现交互逻辑。无论你是零基础小白,还是想巩固基础的学习者,都能通过学习,具备搭建静态网页与简单交互页面的能力,轻松迈进前端开发领域。

    Invoke-WmiCommand.zip

    Invoke-WmiCommand

    (转载)五子棋python

    python五子棋 转载的!!!

    基于springboot框架的Javaweb学科竞赛管理系统(完整源码+数据库sql文件+项目文档+Java项目编程实战+编程练手好项目).zip

    关键词:学科竞赛管理,Java语言,MYSQL数据库,Vue框架 摘 要 I ABSTRACT II 1绪 论 1 1.1研究背景 1 1.2设计原则 1 1.3论文的组织结构 2 2 相关技术简介 3 2.1Java技术 3 2.2B/S结构 3 2.3MYSQL数据库 4 2.4Spring Boot框架 4 2.5Vue框架 5 3 系统分析 6 3.1可行性分析 6 3.1.1技术可行性 6 3.1.2操作可行性 6 3.1.3经济可行性 6 3.1.4法律可行性 6 3.2系统性能分析 7 3.3系统功能分析 7 3.4系统流程分析 8 3.4.1注册流程 8 3.4.2登录流程 9 3.4.3添加信息流程 10 4 系统设计 11 4.1系统概要设计 11 4.2系统结构设计 11 4.3 系统顺序图 12 4.4数据库设计 14 4.4.1 数据库实体(E-R图) 14 4.4.2 数据库表设计 16 5 系统的实现 19 5.1学生功能模块的实现 19 5.1.1 学生注册界面 19 5.1.2 学生登录界面 20 5.1.3 赛项详情界面 21 5.1.4 个人中心界

    大创项目go后台.zip

    大学生创业项目源码

    基于Wav2Lip384的AI主播项目整合包

    开源项目整合包 更多内容可以查阅 项目源码搭建介绍: 《我的AI工具箱Tauri+Django开源git项目介绍和使用》https://datayang.blog.csdn.net/article/details/146156817 图形桌面工具使用教程: 《我的AI工具箱Tauri+Django环境开发,支持局域网使用》https://datayang.blog.csdn.net/article/details/141897682

    智慧园区解决方案-16PPT(21页).pptx

    智慧园区,作为未来城市发展的重要组成部分,正逐步从传统园区向智能化、高效化转型。这一转型不仅提升了园区的运营管理水平,更为入驻企业和民众带来了前所未有的便捷与高效。智慧园区的总体设计围绕现状分析、愿景规划、设计理念及六位一体配套展开。传统园区往往面临服务体系不完善、智慧应用面不广、信息资源共享能力不足等问题,而智慧园区则致力于打破这些壁垒,通过物联网技术、大数据分析等手段,构建起一个完整的运营服务体系。这一体系不仅覆盖了企业成长的全周期,还通过成熟的智慧运营经验,为产业集群的发展提供了有力支撑。智慧园区的愿景在于吸引优秀物联网企业和人才入驻,促进产业转型,提高社会经济效应,并为民众打造更安全、高效的智慧生活方式。 在智慧园区的服务体系及配套方面,园区围绕“1+1+1”(学院+创客+基地)、“两中心”(园区指挥中心+金融中心)、“三平台”(成果展示+招商+政府)等核心配套,辅以日常生活各方面的配套,真正实现了从人才培养、研发、转化、孵化、加速到发展的六位一体示范园区。园区服务体系包括园区运营管理体系、企业服务体系和产业社区服务体系。园区运营管理体系通过协同办公、招商推广、产业分析等手段,打破了信息数据壁垒,构建了统一园区运营服务。企业服务体系则提供了共享智能展厅、会议室预定、园区信息服务、办事大厅等一系列便捷服务,助力企业快速成长。产业社区服务体系则更加注重周边生活的便捷性,如物联网成果展示平台、智慧物流、共享创客空间等,为入驻企业和民众提供了全方位的生活配套。这些服务体系不仅提升了园区的整体竞争力,还为入驻企业创造了良好的发展环境。 智慧园区的场景应用更是丰富多彩,涵盖了智慧停车、智慧访客、公共服务、智慧楼宇、智慧物业等多个方面。智慧停车系统通过车牌识别、车位引导、缴费等子系统,实现了停车场的智能化管理,极大提升了停车效率。智慧访客系统则通过预约、登记、识别等手段,确保了园区的安全有序。公共服务方面,智慧照明、智慧监控、智慧充电桩等设施的应用,不仅提升了园区的整体品质,还为民众带来了更加便捷、安全的生活环境。智慧楼宇和智慧物业系统更是通过智能化手段,实现了楼宇和园区的统一化管理,提升了运营效率和居住舒适度。此外,智慧园区还通过O2O平台、医疗系统、综合服务系统等手段,将线上线下资源有机整合,为入驻企业和民众提供了全方位、便捷的服务体验。这些场景应用不仅展示了智慧园区的智能化水平,更为读者提供了丰富的想象空间和实施方案参考。 综上所述,智慧园区作为未来城市发展的重要方向,正以其独特的魅力和优势吸引着越来越多的关注。通过智能化手段的应用和服务体系的完善,智慧园区不仅提升了园区的整体竞争力和运营效率,还为入驻企业和民众带来了前所未有的便捷与高效。对于写方案的读者来说,智慧园区的解决方案不仅提供了丰富的案例参考和实践经验,更为方案的制定和实施提供了有力的支撑和启示。

    成熟STM32直流电压电流采集与检测方案:包含PCB设计、KEIL源码及原理图与详细设计说明,完备STM32直流电压电流采集与检测解决方案:PCB、KEIL源码、原理图、设计说明,lunwen复现新型

    成熟STM32直流电压电流采集与检测方案:包含PCB设计、KEIL源码及原理图与详细设计说明,完备STM32直流电压电流采集与检测解决方案:PCB、KEIL源码、原理图、设计说明,lunwen复现新型扩展移相eps调制,双有源桥dab变器,MATLAB simulink仿真 ,核心关键词:lunwen复现; 新型扩展移相eps调制; 双有源桥dab变换器; MATLAB simulink仿真;,复现新型扩展移相EPS调制:DAB双有源桥变换器在MATLAB Simulink中的仿真研究

    大创项目——考古土方运输车小程序端.zip

    大学生创业项目源码

    清华大学 deepSeek 三部曲全集

    清华大学deepseek三部曲PDF

    蓝桥杯算法实战详解:编程界‘奥林匹克’的技术提升之路

    内容概要:本文介绍了蓝桥杯编程竞赛的历史背景及其重要意义,强调其作为编程领域中‘奥林匹克’的地位。文章全面解析了蓝桥杯中涉及的不同类型的赛题,如数学计算、字符串处理、排序算法、图论算法、动态规划、模拟题等,通过实例详细讲解这些算法的设计思路及其实现方式。还分享了在比赛过程中应掌握的实际技巧,包括如何选择恰当的算法、优化代码性能,以及调试技巧等,旨在全面提升编程能力。 适合人群:对编程感兴趣的在校生及初学者、想要提升编程能力的从业者。 使用场景及目标:帮助读者了解并掌握蓝桥杯的比赛内容和技术要点;培养解决复杂编程问题的能力;激发编程兴趣并为参赛做准备。 其他说明:文中穿插成功案例——小乐同学的经历,展现如何从零基础成长为优秀程序员,并通过自身努力在全国比赛中获奖的例子来鼓励读者积极参与此类活动以提升自我价值。最后号召更多编程爱好者参与到蓝桥杯当中,在实践中锻炼和成长。

Global site tag (gtag.js) - Google Analytics