为什么重复数据删除对于云存储而言如此重要?

标签:云存储云应用数据

访客:12437  发表于:2017-02-10 09:57:44

大多数人认为云存储服务较实体存储更便宜。毕竟大家可以根据性能与访问需求以每TB每年276美元甚至更低的价格租用存储资源。相比之下,企业数据仓库的每TB每年使用成本一般在2500美元到4000美元之间。

然而除了一级数据之外,大家还需要在云环境下对数据进行备份或者副本保存,这无疑会令资源使用支出大幅提升。设想一下,若企业需要以三年为周期每月保留100 TB备份数据,则其原始备份数据约等于3.6 PB,每月支出将超过83000美元。而且这还不算数据访问以及检索带来的成本。

正因为如此,高效的重复数据删除技术对于内部及云存储体系皆极为重要,特别是在企业需要长期保留其归档数据的情况下。事实证明,如果无法进行重复数据删除处理,云环境下的存储资源使用成本将迅速提升至无法接受的水平。

为什么重复数据删除对于云存储而言如此重要?

云存储的承诺:成本低廉、可扩展、永远可用

云存储一直被视为一种廉价、可靠且能够无限扩展的资源——事实也基本就是如此。AWS S3等对象存储服务每月每TB的标准层使用成本仅为23美元,连续访问层则为每TB 12.5美元。众多现代应用已经能够发挥对象存储的既有优势。云服务供应商提供自己的文件或者块存储选项,例如AWS EBS每月每TB块存储资源成本为100美元,且可按小时计费。亦有不少第三方方案可作为后端用于将传统文件或块存储同对象存储系统对接。

即使是每年每TB 1200美元的AWS EBS,其使用成本也仅为内部解决方案的二分之一到三分之一,而且后者还需要更高昂的前期投入。正因为如此,企业纷纷选择云存储以降低运营成本及前期投入,且享受由此带来的按使用量计费收益(而非像传统方案那样购置远超实际需求的资源容量)。

云存储成本的爆表之路:无穷无尽的副本

云存储与传统内部存储间的成本差异在于,前者的成本要素更为分散。云存储的成本要素主要包括:

1)一级数据存储成本,包括对象或者块存储。

2)副本、快照、备份或数据归档的成本。

3)数据传输成本。

第一项之前已经讨论过了,下面看看后两项。

数据副本。这与您存储在云内的具体数据量无关——上传数据并不收费,而且存储单一副本也用不了多少投入。最可怕的是保存多份数据副本——包括备份、归档或者其它需求——这会在不经意间带来可怕的支出。即使大家并未主动进行数据复制,应用程序或数据库的内置数据冗余与数据复制功能亦会默认扩大资源需求。

在云环境中,每套副本都会产生与原始对象相同的成本。虽然云供应商可能会在后台进行重复数据删除或压缩,但这种情况并不常见。以消费级云存储服务Dropbox为例,复制十套文件副本即会占用十倍的存储配额。

对企业而言,这意味着快照、备份与归档数据都会产生额外费用。举例来说,AWS EBS的每月存储快照成本为每GB 0.05美元。虽然快照会进行压缩并仅存储增量数据,但由于不具备重复数据删除机制,100 TB数据集的快照每年需要花费60000美元。

数据访问。公有云供应商通常会向不同云服务区或者云外部间的数据传输收费。例如在不同Amazon服务区间移动或复制1 TB的AWS S3数据会带来20美元成本,而将其移动至互联网的成本则为90美元。事实上,GET、PUT、POST、LIST以及DELETE等请求都会产生对应的数据访问成本。

重复数据删除对于云存储的重要意义

云应用在设计上具备分布式特性,且标准部署在非关系型大规模可扩展数据库内。在非关系型数据库中,即使不进行复制,大多数数据仍然属于冗余信息。以MongoDB或者Cassandra为例,其复制因子为3,意味着为了确保数据完整性,其会在分布式集群中保留3份副本。

备份或者次级副本通常由快照进行创建及维护。数据库体系结构决定当我们保存快照时,实际上同时也制作出了三份副本。

不仅是重复数据删除——还有重复语义删除

大多数重复数据删除技术作用于存储层,即对数据块进行重复删除。这种作法对于SAN或NAS等集中式存储非常有效,但却不太适用于MongoDB等分布式数据库的数据层。在这一领域,重复删除技术需要解决两大基本问题:

1)需要立足数据层起效,而非存储层。为了在分布式集群中实现重复数据删除,软件需要理解并解释底层数据结构。

2)需要抢在冗余数据被写入数据库前将其清除。一旦数据写入,则会在集群内进行复制,这意味着必须利用实时重复数据删除方可解决。

原文标题:Why Deduplication Matters for Cloud Storage

原文作者:Jeannie Liou

来源:51CTO

评论(0)

您可以在评论框内@您的好友一起参与讨论!

<--script type="text/javascript">BAIDU_CLB_fillSlot("927898");