1. 首页
  2. 技术分享

先睹为快!STORJ V3 白皮书发布!

​​STORJ V3

先睹为快!STORJ V3 白皮书发布!

在无数次博客更新V3进度之后,终于在30号,STORJ官方发布了STORJ 3.0的白皮书。

作为分布式云存储的元老,STORJ是最早将分布式存储与区块链结合在一起的项目。经过时间的洗礼,官方团队在技术研发上的进展,加之Filecoin的上线临近,让本次STORJ的V3都非常令人期待。

事实上,官方也不负众望,在新版本的白皮书中,我们看到了STORJ有非常大的改变,在之前的文章中,我们也翻译了STORJ官方发布的V3 Demo:《STORJ官方团队:我们下个版本用卫星来进行存储证明》(点击可查看)。

下面,让我们来揭开STORJ V3 的神秘面纱!

0.1

摘要

去中心化的云存储代表了大规模存储的效率和经济性的根本转变。 消除中央控制允许用户在不依赖第三方存储提供商的情况下存储和共享数据。 去中心化可以降低数据丢失和传输中断的风险,同时提高存储的安全性和隐私性。 它还会促使市场提供比任何单个供应商更高效且更便宜的存储。 尽管有许多方法可以构建这样的系统,但是任何既定的方案都应该明确一些具体的责任。 根据我们在PB级存储系统方面的经验,我们引入了一个模块化框架,用于确定这些职责并构建我们的分布式存储网络。 此外,我们描述了整个框架初始的具体实现方法。

0.2

贡献者

这份白皮书代表着许多人共同的努力。以下贡献者均隶属于Storj Labs,包括但不限于:

Tim Adams, Kishore Aligeti, Cameron Ayer, Atikh Bana, Alexander Bender, Stefan Benten, Maximillian von Briesen, Paul Cannon, Gina Cooley, Dennis Coyle, Egon Elbre, Nadine Farah, Patrick Gerbes, John Gleeson, Ben Golub, James Hagans, Jens Heimbürge, Faris Huskovic, Philip Hutchins, Brandon Iglesias, Viktor Ihnatiuk, Jennifer Johnson, Kevin Leew, Alexander Leitner, Richard Littauer, Dylan Lott, JT Olio, Kaloyan Raev, Garrett Ransom, Matthew Robinson, Jon Sanderson, Benjamin Sirb, Dan Sorensen, Helene Unland, Natalie Villasana, Bryan White, and Shawn Wilkinson。

我们也要感谢为过去的Storj和Metadisk白皮书做出贡献的作者和贡献者,他们是:

Tome Boshevski, Josh Brando, Vitalik Buterin, Braydon Fuller, Gordy Hall, Jim Lowry, Chris Pollard, and James Prestwich。

我们要特别感谢Petar Maymounkov, Anand Babu Periasamy, Tim Kosse, Roberto Galoppini, Steven Willoughby, and Aaron Boodman 对这份新版白皮书的起草和审稿工作。

我们要感谢其他在分布式计算,区块链,分布式存储和去中心化存储领域的人们,他们的研究,白皮书以及和我们的沟通交流都启发了我们的工作。参考文献中有更加全面的资料清单,但在此我们想要特别感谢以下项目团队给我们的指导和鼓励,他们是:

Allmydata, Ceph, CoralCDN, Ethereum, Farsite, Filecoin, Freenet, Gluster, GFS, Hadoop, IPFS, Kademlia, Lustre, Maidsafe, Minio, MojoNation, OceanStore, Scality, Siacoin, and Tahoe-LAFS。

最后,我们非常感谢在本系统的设计和架构中与我们交谈过的每一个人,感谢他们提出宝贵的想法,反馈,意见和建议。

请发送电子邮件至paper@storj.io

1

简介

互联网是一个庞大的去中心化和分布式网络,由数十亿设备组成,不受单个组或实体的控制。 目前可通过互联网获得的大部分数据都非常集中,并掌握在少数几家拥有丰富经验和资金的,能够建立很多可以处理海量信息的数据中心的技术公司手中。 数据中心面临的一些挑战包括:数据泄露,大规模不可用时段,存储成本高以及扩展和升级的速度难以满足用户对更快数据和更大格式的需求。

去中心化存储已然成为了可以提供高性能,安全,私密且经济的云存储解决方案。 去中心化存储更有利于实现这些成果,因为与大规模集中式数据中心相比,其体系结构能更加自然地与整个互联网的分散架构保持一致。

过去几年中有关数据泄露事件的新闻报道向我们表明,这种违规行为的频率在2005年至2017年期间一直在增加10倍[1]。 分散存储保护数据的过程使数据泄露比数据中心使用的当前方法更加困难,同时成本低于当前的存储方法。

该模型可以解决当前的解决方案难以解决的快速扩展的数据量。 到2020年预计存在44ZB数据,并且存储市场将在同一时间内增长到920亿美元[2],我们已经确定了去中心化云存储有可能解决的几个关键细分市场。 随着去中心化云存储功能的发展,它将能够解决从基本对象存储到内容分发网络(CDN)的更广泛的用例。

去中心化的云存储在成熟度方面正在迅速发展,但其发展受制于一些特定的设计约束,这些约束定义了网络的整体要求和实施。 在设计分布式存储系统时,需要优化许多参数,例如速度,容量,无信任,拜占庭容错,成本,带宽和延迟。

我们将本文的其余部分组织成六章。 第2章讨论了Storj运行的设计以及我们的优化工作所依据的具体约束。 第3章介绍了我们的框架。 第4章提出了框架简单的具体实现方法,而第5章则解释了网络中每个操作期间发生的情况。 第6章介绍了未来的工作。 最后,第7章介绍了选定的算法。

2

STORJ 设计约束条件

在设计系统之前,确定需求非常重要。设计去中心化存储系统有许多不同的方法,但由于有一些额外的要求,潜在的设计空间显著缩小,我们的设计约束受到产品和市场适应性目标的严重影响。通过仔细考虑每个需求和约束条件,我们确保选择的框架尽可能通用。

2.1

安全和隐私

无论是集中式还是去中心化,任何对象存储平台都必须确保存储数据的隐私性和安全性。 去中心化存储平台必须减少与本质上不可信节点上的数据存储相关联的额外复杂性和风险层。由于去中心化存储平台不能采用许多相同的快捷方式,基于数据中心的方法(例如防火墙,DMZ等),去中心化存储必须从头开始设计,不仅支持端到端加密,还要在系统的各个级别增强安全性和隐私性。

某些类别的数据也受特定法规法规的约束。例如,美国关于健康保险流通与责任法案(HIPAA)对数据中心的兼容性有特定要求。欧洲国家必须起草通用数据保护条例(GDPR)来规定如何保护个人信息。美国以外的许多客户可能会认为他们有重要的地缘政治原因需要使用一种能避免美国实体侵害他们隐私的方式来存储数据[3]。其他部门对于用户数据隐私还有许多其他规定。

客户有权评估我们的软件是否正确实施、能够抵抗攻击(已知或未知)、安全且满足客户所有要求。开源软件能够透明、有效地证明整个系统的表现和广告所说的一样。

2.2

 去中心化

可以说去中心化应用程序是一种没有单一运营商的服务。此外,任何单个实体都不应单独承担与运行服务相关的成本或能够导致其他用户的服务中断。

优先考虑去中心化的主要动机之一是降低维护、运行和带宽的基础设施成本。我们认为,对于许多小型运营商而言,网络边缘存在大量未充分利用的资源。在我们经验丰富的分布式存储网络中,我们发现了一长串资源目前尚未使用或未充分利用,可提供价格合理且地理位置分散的云存储。可以想象,一些小型运营商可能比标准数据中心获得更便宜的电力,或者另一家小型运营商可以达到更便宜的冷却费用。许多这些小型运营商的环境不足以运行整个类似数据中心的存储系统。例如,一个小型企业或家庭网络附加存储(NAS)运营商可能最多能有运行十个硬盘的剩余电力。我们发现总的来说,存在足够的小型运营商环境,使得它们在因特网上的组合构成了更便宜和更快存储的重要机会和优势。

我们对基础设施(如存储)的去中心化目标也是因为我们希望为目前主导市场的少数主要中心化存储实体提供可行的替代方案。我们认为,信任具有相当大比例的全球数据的单个实体、公司或组织存在固有风险。事实上,我们认为通过任何第三方保管个人数据的风险都有相关的隐性成本。一些可能的高昂代价包括公司路线图的变化导致产品变得不那么有用;公司在数据收集方面的出发点发生变化可能导致其向广告商出售客户数据;甚至公司可能会停业或以其他方式无法保证客户数据的安全。通过创建一个等效或更好的去中心化系统,许多关注单一实体风险的用户将有一个可行的替代方案。通过去中心化架构,Storj即使停止运营,数据也依然安全。

我们决定采用去中心化架构,因为尽管存在权衡,我们认为去中心化可以更好地满足云存储的需求,并解决集中化带来的许多核心限制、风险和成本问题。在此背景下,去中心化产生了一个全球分布式网络,可以为从文档到CDN的各种存储用例提供服务。但集中式存储系统则需要不同的体系结构、实现和基础结构来解决每个相同的用例。

2.3

市场和经济

公共云计算——特别是公共云存储——已被证明是大型中心化云提供商极富吸引力的商业模式。云计算在2018年预计拥有1864亿美元的市场,到2021年预计将达到3025亿美元[4]。

公共云存储模型为终端用户提供了引人注目的经济模型。它不仅使最终用户能够按需扩展,而且还让他们省去了设施、电力及数据中心人员的大量固定成本。与自行部署存储系统和人员相比,公共云存储对许多终端用户来说是一个经济、耐用、高性能的选择。

然而,公共云存储模型本质上导致了高度中心化。固定成本由网络运营商承担,他们投资数十亿美元建立数据中心网络,然后享受显著的规模经济。巨大的前期成本和规模经济的结合意味着公共云存储的供应商数量极其有限(可以说全球不到五家)。这些少数供应商也是经济回报的主要受益者。

我们相信去中心化存储可以为中心化云提供可行的替代方案。但是,为了鼓励合作伙伴或客户将数据传输到网络,存储和带宽的价格 — 再加上去中心化存储的其他好处 — 必须比竞争的存储解决方案更具吸引力和经济效益。在我们的Storj设计中,我们寻求为四个不同的群体创造经济优势:

终端用户 我们必须提供与公共云存储相同的经济优势:无需前期成本又能按需扩展。此外,最终用户必须在给定的容量、耐用性、安全性和性能水平上获得更好的体验。

存储节点运营商 对于存储节点运营商来说帮助构建网络必须要有利可图。 它们必须公平、透明地得到报酬,并且对于它们产生的任何边际成本能够获得合理的利润。成为存储节点运营商不仅要利用未充分利用的容量,还要创建更多的容量,这样我们才能使整个网络超越当前已有的容量,这在经济上是有利的。由于节点可用性和可靠性对网络的可用性、成本和耐久性具有很大影响,因此存储节点运营商应当具有能够提供维持可靠且连续的网络连接的能力。

需求提供商 对于开发商和企业来说,把客户和数据传播到Storj网络上必须有利可图。我们必须以合理和透明的方式设计系统,为合作伙伴提供利润。我们相信,提供开源软件(OSS)公司和项目大有机会在,这些公司和项目在未获得直接收入的情况下,可以驱动超过三分之二的公共云工作负载,这是可持续收入的来源。

网络运营商 为了维持对代码、功能、网络维护和需求的持续投资,网络运营商(目前是Storj Labs)必须能够保持合理的利润。运营商必须保持这种利润,但与此同时,运营商向终端用户的收费要少于公共云提供商,还要与存储节点运营商和需求提供商共享利润。

此外,网络必须能够确保有效、收费及时、支付流程、税务和其他报告的合规性。为了在支付方面具有全球通用性,我们的网络必须能够满足多种类型的交易(例如加密货币、银行支付和其他形式的易货交易)。最后,Storj路线图必须与网络的经济驱动因素保持一致。框架组件具体实现的新功能和更改必须通过对特定对象存储用例的适用性以及功能和性能与存储价格和带宽相对于这些用例的关系来驱动。

2.4

Amazon S3性能

在本文发布时,部署最广泛的公共云是亚马逊网络服务Amazon Web Service [5]。亚马逊网络服务不仅是最大的云服务生态系统,还具有先发优势。亚马逊的第一个云服务产品是亚马逊简单存储服务Amazon Simple Storage Service,简称Amazon S3。虽然没有获得统计数据支持,但Amazon S3可能是部署最为广泛的云存储协议。大多数云存储产品都提供与亚马逊S3应用程序接口(API)架构的某种形式的兼容性。

我们的目标是在更广泛的云存储行业中积极竞争,并将去中心化的云存储带入主流。在去中心化的云存储协议被广泛采用之前,Amazon S3兼容性通过减少用户的许多转换成本,为中心化提供商创建了一个优雅的过渡方案。为此,Storj允许以前针对AmazonS3构建的应用程和与Storj仅通过少量修改即可兼容。S3兼容性增加了对功能集性能和持久性的要求,至少需要实现图2.1中描述的方法。

先睹为快!STORJ V3 白皮书发布!

2.5

耐用性、设备故障和流失

存储平台并没有什么用,除非它还能用作检索平台。对于任何有价值的存储平台,即使在系统内存在各种可能的故障时,也必须小心不能丢失数据。我们的系统存储的数据必须具有高耐用性,且具有可忽略的数据丢失风险。

对于所有设备,组件出故障都是必然的。所有硬盘驱动器在经过相当的损耗后都会失效[6],提供网络访问这些硬盘驱动器的服务器也终将损坏。网络链接可能会失效,电源故障可能会造成严重破坏,存储介质会随着时间的推移而变得不可靠。数据存储必须有足够的冗余,以便从单个组件故障中恢复。更重要的是,没有数据可以永远存在同一个地方。在这样的环境中,必须要认识到冗余、数据维护、修复和更换丢失的冗余是不可避免的,系统必须考虑到这些问题。

此外,去中心化系统容易受到高流失率的影响,参与者加入网络,然后在硬件出故障之前就因各种原因离开。在许多现实世界的点对点系统中,参与者在网络中持续的中位时间从几小时到几分钟不等[7]。节点与去中心化网络连接一小时的概率是正常运行时间的递增函数(图2.2 [8])。换句话说,长时间在线的节点不太可能导致整个节点流失。

存储节点可能由于硬件或软件故障、断断续续的网络连接、断电、完全磁盘故障或软件关闭或移除而下线。存在的网络流失越多,就需要越多的冗余来弥补更高的节点丢失率。所需的冗余越多,系统正确运行所需的带宽就越多。事实上,网络流失、额外冗余和带宽可用性之间存在紧密关系[9]。为了保持较低的背景带宽使用率和冗余度,我们的网络必须具有较低的网络流失率并强烈支持长期稳定节点。参见第7.3.3节[9]中讨论修复带宽如何随节点流失而变化。

2.6

延迟

分散式存储系统可以充分利用并行的大量机会,包括提高传输速率、处理能力和整体吞吐量,即使个别网络速度很慢。但是,并行性本身不能改善延迟。如果将单个网络链接是某个操作的一部分,那么它的延迟将是整个操作的下限。因此,任何用于高性能应用的分布式系统都必须持续且积极地不仅在单个工艺上优化,还要在系统的整个架构上向低延迟优化。

先睹为快!STORJ V3 白皮书发布!

2.7

带宽

全球带宽可用性逐年增加。不幸的是,全球范围内对高带宽互联网连接的访问分布不均匀。虽然一些用户可以轻松访问对称、高速、无限制的带宽连接,但其他用户在获得相同类型的访问方面存在很大困难。

在美国和其他国家,许多家庭的互联网服务提供商(ISP)运行的方法对去中心化网络协议的设计者提出了两个具体的挑战。第一个挑战是许多ISP提供的是非对称互联网连接。客户根据ISP广告宣称的网络下载速度订阅了互联网服务,但上传速度可能要慢一两个数量级。第二个挑战是ISP有时会在客户超过每月固定流量时“限制”带宽。例如,在许多美国市场,ISP Comcast每月有1TB带宽上限,对超过此限制的客户处以高额罚款[10]。即使ISP宣称速度为10 MB / s或更高,上个月1 TB /月上限的互联网连接在不超过月带宽限额的情况下平均不超过385 KB / s。这种上限对任何给定时刻的网络可用带宽都施加了很大的限制。

由于设备故障和节点流失,任何去中心化的系统都将具有相应数量的修复流量。因此,重要的是不仅要考虑数据存储和检索所需的带宽,还要考虑数据维护和修复所需的带宽[9]。设计一个不考虑带宽使用的存储系统不仅会给存储节点运营商带来不必要的高速带宽,而且会在一定程度上使系统中心化。为了使存储系统尽可能去中心化并在尽可能多的环境中工作,必须积极地最小化带宽使用。

有关带宽可用性和修复流量如何限制可用空间的讨论,请参见第7.1.1节。

2.8

对象大小

我们可以按平均对象大小将大型存储系统大致分为两组。为了区分这两个组,我们将“大”文件分类为几兆字节或更大的大小。数据库是存储许多小信息的首选解决方案,而对象存储或文件系统是存储许多大文件的理想选择。

Storj Labs提供的初始产品主要用于实现较大文件的去中心化对象存储。虽然未来的改进可能会启用类似数据库的用例,但对象存储是本文中描述的主要初始用例。我们的协议设计假设绝大多数存储对象都是4MB或更大。虽然我们也支持较小的文件,但存储起来的成本可能更高。

值得注意的是,这不会对需要读取大量小于1兆字节的文件的用例产生负面影响。用户可以通过聚合和存储许多小文件作为一个大文件来解决这个问题。该协议支持gand流中的搜索,这将允许用户下载小文件而无需完全检索聚合对象。

2.9

拜占庭容错

与Amazon S3等中心化解决方案不同,Storj在不受信任的环境中运行,在这个环境中单个存储提供商不一定是需要值得信赖的。Storj通过公共互联网运营,允许任何人注册成为存储提供商。

我们采用拜占庭,利他,理性(BAR)模型[11]来讨论网络中的参与者。

拜占庭节点可能会出于某些原因与建议的协议任意偏离。例如一些被破坏的节点或主动尝试破坏协议的节点。通常,拜占庭节点是一个坏节点,或者是一个优化效用函数的节点,该效用函数独立于建议的协议给出的效用函数。

除了不可避免的硬件故障因素,利他主义节点是好节点,会遵循建议的协议即使更理性的做法是不遵循。

理性节点是中立的参与者,只有在符合其最佳利益时才参与或离开。

一些分布式存储系统(例如,基于数据中心的云对象存储系统)在所有节点都是利他节点的环境中操作。例如,除了硬件故障或安全漏洞之外,亚马逊的存储节点除了代码明确要求要做的事情之外不会做任何事情,因为亚马逊拥有并运行所有这些节点。

相反,Storj在一个每个节点都由自己独立的运营商管理的环境中运行。在这种环境中,我们可以预期大多数存储节点是理性节点,少数是拜占庭节点。Storj假定没有利他节点。

我们必须包括鼓励网络的激励措施,以确保网络上的理性节点(大多数运营商)尽可能地与利他节点的预期行为相似。同样,必须最小化或消除拜占庭行为的影响。

请注意,创建一个面对拜占庭行为足够强大的系统不需要拜占庭容错共识协议——我们避免拜占庭共识。详细信息,请参见第4.9,6.2节和附录A。

2.10

避免协调

越来越多的分布式数据库研究表明,尽可能避免协调的系统具有比子组件被迫协调以实现正确性的系统更好的吞吐量[12-19]。我们使用Bailis等人的非正式定义,即协调是同时执行同步通信或停滞以完成操作的要求[16]。这种情况发生在所有规模上,不仅适用于分布式网络,而且适用于在同一计算机内协调的并发执行线程。一旦需要协调,系统中的参与者将需要等待其他参与者,而等待——由于协调问题——可能会产生巨大的成本。

虽然网络中许多类型的操作可能需要协调(例如,需要线性化的操作[15,20,21]),但选择避免协调的策略(例如高可用性事务[15])在广域网上可以提供两到三个性能数量级的增益。事实上,通过尽可能谨慎地避免协调,Anna数据库[17]在相应的环境中比Cassandra和Redis快10倍,比以性能为重点的内存数据库快700到800倍,如Masstree或Intel的TBB [22]。并非所有的协调都可以避免,但是新的框架(例如Invariant Confluence [16]或CALM原则[18,19])允许系统架构师理解何时需要协调以保持一致性和正确性。正如Anna的成功表现所证明的那样,尽可能避免协调是最有效的。

最小化协调的系统在从小型到大型工作负载的扩展方面要好得多。向协调避免系统添加更多资源将直接提高吞吐量和性能。但是,向协调相关系统(例如比特币[23]或甚至Raft [24])添加更多资源不会产生太多额外的吞吐量或整体性能。

为了达到EB级规模,最小化协调是我们战略的关键组成部分之一。令人惊讶的是,许多去中心化的存储平台正致力于需要大量协调的架构,其中大多数(如果不是全部)操作必须由单个全局账本来解决。为了使我们达到EB规模,将热路径协调域限制为完全可由每个用户控制的小范围是一个基本要求。这限制了区块链解决方案对我们用例的适用性。

3

框架

在考虑了我们的设计约束之后,本章概述了仅由最基本的组件组成的框架的设计。 框架描述了满足约束条件必须存在的所有组件。 只要我们的设计约束保持不变,这个框架将尽可能地描述现在和现在十年后的Storj。 虽然框架内将有一些设计自由,但该框架将完全消除对未来重新架构的需求,因为独立组件将能够在不影响其他组件的情况下被替换。

3.1

框架概述

在我们框架内的所有设计将会完成下列任务:

存储数据 当数据在网络内存储时,客户端会对其进行加密并将其分解为多个部分。 这些部分通过网络分发给节点。此时,网络将生成元数据,其中包含有关再次查找数据的位置的信息。

检索数据 从网络检索数据时,客户端将首先引用元数据以识别先前存储的块的位置。 然后将检索这些碎片,并在客户端的本地计算机上重新组装原始数据。

维护数据 当冗余量低于某个阈值时,将重新生成并替换缺失部分的必要数据。

使用费用 应该发送一个价值单位来换取所提供的服务。

为了方便理解,我们将设计分解为八个独立组件的集合,然后将它们组合在一起以形成所需的框架。

这些独立组建是:

存储节点

点对点通信和发现

冗余

元数据

加密

审计和声誉

数据修复

支付

3.2

存储节点

存储节点的作用是存储和返回数据。 除了可靠地存储数据之外,节点还应提供网络带宽和适当的响应能力。 选择存储节点以基于各种标准存储数据:ping时间,延迟,吞吐量,带宽上限,足够的磁盘空间,地理位置,正常运行时间,准确响应审计的历史记录等等。 作为对他们服务的回报,节点是有偿的。

由于存储节点是通过更改协议外部的变量来选择的,因此节点选择在我们的框架中是一个明确的,非确定性的过程。 这意味着我们必须通过少量元数据跟踪每次上传选择的节点; 我们不能选择类似Dynamo [25]这样的系统:存储数据的节点的选择都是随机的或者完全确定的。 与GFS [26],HDFS [27]或Lustre [28]一样,该决定意味着要求元数据存储系统跟踪所选节点(参见第3.5节)

3.3

点对点的通信和发现

网络上的所有节点都通过标准化协议进行通信。该框架要求该协议:

提供节点可达性,即使在可能的情况下面对防火墙和NAT也是如此。这可能需要STUN [29],UPnP [30],NAT-PMP [31]等技术。

提供身份验证,如S / Kademlia [32],其中每个参与者以加密方式证明与其对话的节点的身份,以避免人为中间的攻击。

提供完整的隐私。在带宽测量等情况下(参见第4.17节),客户端和存储节点必须能够在没有任何风险的情况下进行通信,而不存在有被窃听的风险。协议应确保默认情况下所有通信都是私有的。

此外,该框架需要一种通过唯一标识符查找节点网络地址的方法,以便在给定节点的唯一标识符的情况下,任何其他节点都可以连接到该节点网络地址。此责任类似于互联网的标准域名系统(DNS)[33],是标识符到短暂连接地址的映射,但与DNS不同,它可能没有集中注册过程。为实现这一目标,可以在我们选择的节点通信协议之上构建网络覆盖,例如Chord [34],Pastry [35]或Kademlia [8]。有关实现细节,请参见第4.6节。

3.4

冗余

我们假设任何时候,任何存储节点都可以永久地发挥作用。我们的冗余策略必须以高概率提供数据访问的方式存储数据,即使任何给定数量的单个节点可能处于异常状态。为了达到特定的耐久性水平(定义为面对故障时数据仍然可用的概率),该领域中的许多产品都使用简单复制。不幸的是,这与网络扩展系数的持久性有关,网络扩展系数是可靠存储数据的存储开销。这显着增加了存储数据的总成本。

例如,假设有某种持久性的需求,需要一种可以产生8个副本的策略。这产生了8倍或800%的扩展系数。然后,在该过程中需要使用带宽将该数据存储在网络上。因此,更多复制会导致固定数据量的带宽使用量增加。正如协议设计约束(第2.7节)和Blake等人所讨论的那样[9],高带宽使用会阻碍规模化进程,因此对于确保文件高度持久性来说,这是不合理的策略。

作为简单复制的替代方法,纠删码提供了一种更有效的方法来实现冗余。纠删码在分布式和节点存储系统中得到了很好的验证[36-42]。纠删码是一种编码方案,用于提高数据持久性而不将其与带宽使用联系起来,并且已经确认可以在复制时显着改善修复流程[9]。重要的是,它们可以改变持久性而不改变膨胀系数。

纠删码通常由两个数字k和n描述。 如果用(k,n)纠删码编码数据块,总共产生了n个数据碎片,则只需要其中任意k份来恢复原始数据块。 如果数据块是s字节,则每个数据碎片大约是s / k字节。 除了k = 1(复制)的情况,所有的数据碎片都是唯一的。

有趣的是,纠删码(k = 20,n = 40)的持久性优于纠删码(k = 10,n = 20),即使两者的扩展系数(2x)相同。 这是因为在(k = 20,n = 40)情况下风险分散在更多的节点上。 这些考虑因素使得纠删码成为我们总体框架的重要组成部分。

为了更好地理解纠删码如何在不增加扩展系数的情况下提高耐持久性,下表显示了k和n的各种选择,以及扩展因子和相关的持久性:

先睹为快!STORJ V3 白皮书发布!

译者注:D意为Durability(持久性),Exp. factor意为冗余度(即冗余数据量为原数据的倍数),最右的公式P(D | p=10%) 为条件概率,意为:在每月节点流失率为10%的情况下,仍能获取所有数据的概率

相反,对于相同的耐久性,复制需要显着更高的扩展系数。下表显示了复制方案的持久性:

先睹为快!STORJ V3 白皮书发布!

为了了解这些表是如何计算的,我们将从简化的假设开始,即p是每月节点流失率(即平均一个月内将会下线的节点比例)。 在数学上,对于取决于时间的过程,根据泊松分布进行建模,其中假设在给定的时间单位中观察到λ事件。 因此,我们将耐久性建模为泊松分布的累积分布函数(CDF),其中均值λ= pn,其中我们假设每月丢失文件的λ个片段。 为了估计耐久性,我们将CDF上限设置为n-k,考虑一个月内文件中最多n-k个部分丢失但文件仍然可以重建的概率。 CDF由下列公式给出:

先睹为快!STORJ V3 白皮书发布!

扩展系数仍然在耐久性中起着重要作用,如下表所示:

先睹为快!STORJ V3 白皮书发布!

通过能够独立于扩展系数调整耐久性,纠删码允许以令人惊讶的低扩展系数实现非常高的耐久性。由于带宽作为一种资源是有限的,以完全消除复制作为策略并仅使用纠删码来实现冗余会导致带宽占用大幅减少。

纠删码还会导致存储节点获得更多报酬。 高扩展系数会稀释更多存储节点上每字节的收益; 因此,低扩展系数(例如由纠删码提供的那些冗余)允许存储节点运营商更直接地获得收益。

3.4.1 纠删码对数据流的影响

纠删码用于许多流媒体环境,如音频CD和卫星通信[38],因此重要的是要指出,使用纠删通常不会使我们的流设计要求(Amazon S3的兼容性要求,见2.4节)更具有挑战性的。 无论为我们的框架选择什么纠删码,如同CD一样,可以通过一次编码小部分来添加流,而不是尝试一次编码所有文件。有关详细信息,请参见第4.8节。

3.4.2 纠删码对“长尾”的影响

纠删码可以带来巨大的性能优势,即能够避免等待“长尾”响应时间[43]。长尾效应发生在由于不可预测因素的同时发生而使所需服务器反应变慢的情况下。长尾效应得名于其罕见的平均发生率而具有高度可变性,在概率密度图中看起来像“长尾”。总的来说,长尾响应是分布式系统设计中的一个大问题。

译者注长尾理论应用于已经应用于多个领域,“长尾”意为概率分布图中概率较小的事件的总和。因概率较小,但可能性较多,故在概率分布图中是一条很接近x轴的线,长的很像一条长长的尾巴,因此得名

在MapReduce中,长尾响应被称为“落后者”。MapReduce执行称为“备份任务”的冗余请求,以确保如果特定的落后者需要太长时间,整个操作仍然可以继续进行而无需等待。如果在MapReduce中禁用了备份任务机制,则即使完成基本操作也需要多44%的时间才能完成,即使这样,其备份任务机制仍然导致重复工作[44]。

通过使用纠删码,我们可以为存储创建类似MapReduce的备份任务[39,40]。对于上传,可以将文件编码为比所需更高的(k,n)比率。在上传过程中,在上传了足够多的内容以获得所需的冗余后,可以取消剩余的其他上传内容。取消剩余上传内容允许上传继续与最快的节点一样快,而不是等待最慢的节点。下载也有类似的改进。由于存在比所需更多的冗余,因此可以从最快的节点提供下载,从而无需等待暂时反应缓慢或离线的节点。

结果是参与任何既定任务的最快节点可以满足每个请求,而不需要等待较慢的节点。专注于结果仅依赖于随机节点群中最快节点的操作将可能的潜在责任(来自各个参与者的高度可变性能)转变为分布式存储网络强大能力的来源,同时仍然提供强大的负载平衡特点。

这种对文件进行充分编码的能力极大地有助于对网络上流行内容的动态负载平衡。有关我们计划如何解决负载平衡非常活跃的文件的讨论,请参见第6.1节。

3.5

元数据

一旦我们使用纠删码分割对象并选择存储新部分的存储节点,就需要跟踪我们选择的存储节点。我们允许用户根据地理位置,性能特征,可用空间和其他功能选择存储。因此,我们必须使用显式节点选择方案,例如基于目录的查找[45],而不是随机节点选择,例如使用像Dynamo [25]这样的一致散列的方案。此外,为了保持Amazon S3的兼容性,用户必须能够选择通常被视为路径的任意密钥,以识别数据到节点的这种映射。这些特征显示一个元数据存储系统是必要的。

Amazon S3的兼容性再次强加了一些严格的要求。我们应该支持:分层对象(带前缀的路径),每个对象的键/值存储,任意大的文件,任意大量的文件等等。对象应该能够通过任意键存储和检索;此外,需要对这些密钥进行确定性迭代以允许分页列表。

每次添加,编辑或删除对象时,都需要调整此元数据存储系统中的一个或多个条目。因此,此元数据系统可能会出现大量流失,并且在整个用户群中,元数据本身可能最终变得相当大。

例如,假设在几年内网络存储整整一个EB的数据,其中对象平均大小为50MB,并且我们的纠删码被选择为n = 40。一个EB大概是200亿个50M的对象。 该元数据系统需要跟踪为每个对象选择的40个节点。 如果每个元数据元素大约是40·64 + 192个字节(每个选定节点的信息加上路径和一些一般开销),则有超过55TB的元数据要跟踪。

幸运的是,元数据可以由用户进行大量分区。存储100TB的50M对象的用户将仅产生5.5K的元数据开销。 值得指出的是,这些数字随对象大小的变化而变化:平均对象大小越大,元数据开销越小。

另一个框架重点是使该组件的元数据存储可以互换。具体来说,我们希望该平台包含多个元数据存储实现,用户可以在其中进行选择。这大大有助于我们在用户之间避免协调的设计目标(参见第2.10节)。

除了规模要求,为了实现Amazon S3兼容性,所需的API简单明了:Put(在给定路径存储元数据),Get(在给定路径下检索元数据),List(现有路径的分页,确定性列表) ,和Delete(删除路径)。 有关详细信息,请参见图2.1。

(未完待续)

先睹为快!STORJ V3 白皮书发布!

先睹为快!STORJ V3 白皮书发布!

原创文章,作者:点对点资讯,如若转载,请注明出处:https://ipfsdrop.com/tech/xianduweikuaistorj-v3-baipishufabu/

发表评论

电子邮件地址不会被公开。 必填项已用*标注

联系我们

(+86)18301922335

在线咨询:点击这里给我发消息

邮件:haskell@freechains.cn

工作时间:7×24小时

QR code