高可用性超大规模云导向存储系统：综述、思维导图与开放研究方向

《ACM Computing Surveys》：High Availability Ultra-Large Cloud-Oriented Storage Systems: A Review, Mind Mapping and Open Research Directions

　　

**AI 摘要**

查看此 AI 生成的摘要，您必须拥有高级访问权限。
了解更多
登录

**摘要**

云计算范式通过在互联网上将计算、存储和应用程序以服务形式、以订阅模式的方式向最终用户提供。这减少了对高度昂贵的计算基础设施、专用存储服务器以及软件应用程序的采购、部署和内部管理的依赖。企业应用程序和业务应用所产生的数据量呈指数级增长。处理和应对海量数据集是一项极具挑战性且非常耗时的任务，需要高水平的计算基础设施来实现适当的数据处理和分析。本研究旨在比较和分析云计算中超大存储系统的各个方面。讨论了云存储系统的描述、特性和分类，以及某些云计算考虑因素。此外，还探讨了大数据与云计算之间的关系，以及超大存储系统与 Hadoop 技术之间的关系。研究关注的问题包括动态性、可扩展性、可用性、数据完整性、自组织、数据质量、数据多样性、隐私以及法律和监管问题。本研究的核心动机通过以云为导向的数据存储（CODS）元素思维导图得到了详尽的解释。CODS 的七大要素——数据模型、数据一致性、数据复制、数据可扩展性、数据集成、数据虚拟化以及事务——在本研究中得到了系统的讨论。本研究还突出了一些与超大存储系统相关的开放研究问题，汇总了充分的科研努力。

**AI 摘要**

AI 生成的摘要（实验性）

此摘要使用自动化工具生成，并未由文章作者撰写或审阅。它旨在支持发现，帮助读者评估相关性，并协助相邻研究领域的读者理解该工作。它意在补充作者提供的摘要，后者仍然是论文的主要摘要。全文仍然是权威版本记录。点击此处了解更多。

点击此处对摘要的准确性、清晰度和实用性发表评论。这样做将有助于改进和未来的再生版本。要查看此 AI 生成的简明语言摘要，您必须拥有高级访问权限。

**1 引言**

云计算是一种新兴的计算范式，包含六个不同的阶段。这些阶段代表了从早期大型机到云计算的演变，如图 1 所示。在阶段 1 中，用户通过他们的哑终端连接到由多个用户共享的大型机。在阶段 2 中，这些哑终端被强大的个人计算机取代，消除了对共享大型机的需求。阶段 3 建立了计算机网络的基础，将许多计算机连接起来，使用户能够在本地网络上共享资源。阶段 4 利用互联网构建连接多个本地网络的全球网络。阶段 5 引入了网格计算的概念，允许用户透明地共享计算能力和资源。云计算是阶段 6 的时代。云计算和网格计算之间有许多相似之处，如可扩展性、适应性、安全性、敏捷性和服务性，但云计算的规模需要一种独特的应用程序架构。如果企业要将云计算作为一种新的计算范式来采纳，这种新方法至关重要。云计算利用互联网来提供按需、虚拟化和可扩展的资源，这些被称为云计算。在云环境中，所有资源都可以被视为服务，包括基础设施即服务（IaaS）、平台即服务（PaaS）、软件即服务（SaaS）、数据即服务（DaaS）、通信即服务（CaaS）、数据库即服务（DBaaS）、安全即服务（SECaaS）等。本综述的主要研究贡献如下：

图 1. 计算范式向云计算的演变。

? 突出面向云的存储管理目标和挑战。
? 面向云的数据存储（CODS）元素的思维导图：数据模型、数据一致性、数据复制、数据可扩展性、数据集成、数据虚拟化、数据事务。
? 提供数据模型在五个方面的思维导图：访问级别、数据来源、基于内容、数据暂存和抽象级别。
? 解释数据一致性的映射分支，如一致性级别、一致性模型、一致性类型、一致性度量、一致性协议和一致性维护。
? 借助单独的思维导图详细说明数据复制、集成、可扩展性和虚拟化。
? 对数据事务类型、隔离、正确性和依赖关系的思维导图，并根据产生的思维导图分析性能问题。
? 突出现有面向云的数据存储系统的功能和能力，以及它们之间的比较。

本文其余部分组织如下。第 2 节突出面向云的数据存储目标、挑战和元素思维导图。第 3 至 8 节分别描述数据模型、数据一致性、数据复制、数据可扩展性、数据集成、数据虚拟化和数据事务的思维导图。第 9 节突出开放研究问题和未来研究方向。最后，本综述以一些总结性评论结束。

**2 系统综述技术**

本研究使用 PRISMA 指南和 AMSTAR 检查表 [86] 来评估系统综述技术的方法学质量。选择了五个不同的阶段，包括识别、筛选、资格评估、纳入和定性综合，以完成本研究。识别是本系统综述技术的第一阶段。最初，从不同来源中初步筛选出 837 篇研究论文，包括期刊数据库、杂志、书籍章节、网络报告等。约 87% 的标题来自以下知名数字图书馆。其余额外记录从其他来源中识别，包括书籍、网络博客、搜索引擎、专家建议等。

- Springer（https://link.springer.com/）
- ACM（https://dl.acm.org/journals）
- IEEE eXplore（https://ieeexplore.ieee.org/）
- Taylor and Francis Online（https://www.tandfonline.com/）
- Google Scholar（https://scholar.google.com/）
- ResearchGate（https://www.researchgate.net/）
- Elsevier（https://www.sciencedirect.com/）

在筛选阶段，所有重复文章都从标题数据库中过滤掉。此外，根据研究标题和一些最常用的关键词进行总体筛选过程，包括"云计算"、"超大数据"、"大数据"和"云存储数据库"。在此阶段，578 篇研究标题被选中进入下一阶段。在筛选阶段，约 25% 的文章基于重复和文章标题被排除。资格评估是非常关键的阶段，在此阶段根据每篇文章的摘要、结论和目标进行总体初步筛选。在此，254 个标题被认定为有资格进行进一步调查。在第四阶段，基于全文评估纳入了 126 个标题。"综合分析"是本调查技术的最后阶段，最终 54 个标题被综合并基于共同挑战和参考文献进行定性分析。所有这些标题都已经过严格审阅和研究。此外，约 57% 的论文在 2018 年至 2022 年间发表，15% 的论文来自当前年份。

表 1 对现有的面向云存储系统综述研究进行了比较定性分析，重点关注七个核心架构和运行方面：数据模型、数据一致性、数据复制、数据可扩展性、数据集成、数据虚拟化和数据事务支持。每项综述从两个互补的角度进行评估：思维导图视图（MMV），反映概念和架构覆盖范围；以及研究结论（RC），指示结论和见解的解析综合程度。

**表 1. 综述数据模型、数据一致性、数据复制、数据可扩展性、数据集成、数据虚拟化、数据事务**

| 综述 | 数据模型 | 数据一致性 | 数据复制 | 数据可扩展性 | 数据集成 | 数据虚拟化 | 数据事务 |
|------|----------|------------|----------|--------------|----------|------------|----------|
| | MMV | RC | MMV | RC | MMV | RC | MMV | RC | MMV | RC | MMV | RC | MMV | RC |
| [50] | ○ | ? | ○ | ○ | ○ | ○ | ○ | ○ | ○ | ○ | ○ | ? | ○ | ○ |
| [73] | ○ | ? | ○ | ○ | ● | ● | ○ | ○ | ○ | ○ | ? | ○ | ○ | ○ |
| [15] | ○ | ? | ● | ● | ○ | ○ | ○ | ○ | ○ | ○ | ○ | ○ | ? | ? |
| [88] | ● | ● | ○ | ? | ○ | ? | ○ | ○ | ○ | ○ | ○ | ○ | ○ | ○ |
| [35] | ○ | ? | ○ | ? | ○ | ○ | ○ | ○ | ○ | ○ | ○ | ○ | ○ | ○ |
| [66] | ● | ● | ● | ● | ? | ? | ? | ? | ? | ? | ○ | ? | ● | ● |
| [65] | ? | ? | ○ | ? | ○ | ○ | ? | ● | ○ | ? | ? | ? | ○ | ○ |
| [38] | ○ | ? | ○ | ? | ○ | ? | ○ | ? | ○ | ○ | ○ | ○ | ○ | ? |
| [40] | ● | ● | ? | ? | ○ | ○ | ? | ? | ○ | ○ | ○ | ○ | ○ | ○ |
| [89] | ? | ? | ○ | ○ | ● | ● | ? | ? | ○ | ○ | ○ | ○ | ○ | ○ |
| [68] | ● | ● | ? | ? | ? | ● | ● | ? | ? | ? | ○ | ? | ○ | ? |
| [37] | ○ | ? | ? | ? | ○ | ○ | ○ | ○ | ○ | ○ | ○ | ? | ○ | ○ |
| **本综述** | **●** | **●** | **●** | **●** | **●** | **●** | **●** | **●** | **●** | **●** | **●** | **●** | **●** | **●** |

面向云存储系统的相关综述研究

MMV：思维导图视图，RC：研究结论，●：完全覆盖，?：部分覆盖，○：未覆盖。

多项综述强调了基础存储范式，如关系型、NoSQL 和基于对象的模型。早期工作，如参考文献 [50] 和 [73] 中的综述，部分讨论了数据模型，但架构深度有限。相比之下，参考文献 [66, 68] 和 [40] 提供了更全面的处理，特别是突出了无模式和多模型存储方法。然而，许多综述的讨论仍然分散，缺乏跨异构云存储环境的综合视角。一致性模型（如强一致性、最终一致性和因果一致性）在以往综述中的处理不均匀。像 [15] 和 [66] 这样的研究提供了较强的概念解释，但关于实际权衡的结论有限。像 [88] 和 [35] 这样的综述仅部分覆盖了一致性机制，通常关注特定平台而非广义的云存储架构。容错和可用性的复制策略在文献中的讨论更为一致。参考文献 [73, 89] 和 [68] 中的综述对复制技术提供了强有力的分析结论，而像 [50] 和 [35] 这样的工作主要在概念层面介绍复制。然而，大多数综述对跨层复制挑战（存储层、网络层和应用层）的综合不足。可扩展性是云存储研究的核心主题，但其覆盖范围差异很大。像 [66, 68] 和 [40] 这样的综述通过解决水平扩展、弹性存储和性能瓶颈提供了强有力的 MMV 和 RC 覆盖。相反，像 [50] 和 [73] 这样的早期综述仅肤浅地处理可扩展性，缺乏严格的性能或架构分析。跨分布式、异构和多云环境的数据集成是最少被探索的方面之一。大多数综述，包括 [35, 50, 73] 和 [38]，要么忽略这个维度，要么仅边际地覆盖。只有少数研究，如 [66] 和 [68]，部分解决了集成挑战，主要从中件或互操作性的角度来看。启用抽象、位置透明和资源池的虚拟化技术讨论不一致。像 [65, 66] 和 [68] 这样的综述表现出更强的覆盖，特别是在虚拟存储池和软件定义存储方面。然而，许多综述，包括 [50] 和 [42]，对虚拟化影响的分析结论极少或没有。事务支持（如 ACID、BASE 和混合模型）总体上受到的关注最少。虽然参考文献 [15] 和 [66] 部分探索了分布式存储系统中的事务机制，但大多数综述如 [35, 50] 和 [38] 没有充分解决事务管理，特别是在大规模地理分布的云环境中。

如最后一行所示，本综述在 MMV 和 RC 两个维度上对所有七个方面都提供了完全覆盖。与以往工作不同，它提供了一种整体性和集成性分析，将架构基础与运行挑战和研究结论联系起来。这种全面的范围解决了早期综述中确定的关键差距，特别是在数据集成、虚拟化和事务管理方面，从而推进了面向云存储系统的知识状态。

**3 背景**

云计算已成为一个无处不在的平台，提供互联网计算服务。面向云的存储即服务（COSaaS）作为云存储服务模型是一个重要的新兴领域，用户可以在其中以虚拟机（VM）的形式获取存储空间。高效管理超大存储是一项具有挑战性的任务，旨在优化可用资源并提升 COSaaS 的性能。基于云的超大存储系统是指云服务提供商为满足企业和个人对数据存储不断增长的需求而提供的庞大且可扩展的基础设施。这些系统旨在高效、安全且经济地存储和管理海量数据。在大数据时代，由于对超大数据存储解决方案需求的增加，企业和组织正转向云环境以获得可扩展和有效的存储解决方案。云存储是处理海量数据集的最佳方法，因为它提供了一种灵活、经济且可扩展的方法来管理海量数据。本部分还突出比较了各种面向云的存储系统的功能、介质及其能力。最后，本节以研究问题和面向云的存储分类结束。

**3.1 超大面向云的存储系统**

云存储是一种云计算模型，数据存储在从互联网访问的远程服务器上。它由云存储服务提供者在基于虚拟化技术构建的存储服务器上进行维护、操作和管理。表 9（附录 A）展示了所有 21 个知名面向云的存储系统的主要特性。该表提供了各种面向云的存储系统的全面比较，重点关注其关键特性和能力。该表分为几列，代表七种不同的存储能力，包括自组织、可扩展性、高可用性、复制、持久性、一致性和存储类型，均已进行了严格的审查。该表展示了云存储系统在能力和预期用例方面的多样性。

云存储能力的详细信息如下：

**表2.工具**

| 服务类别 | 服务模式 | 目标 | 参考 |
|---|---|---|---|
| CloudFuice | SaaS | Web工程模型和混搭开发；基于任务的执行方法，允许在云中并行执行数据流 | [92] |
| iProX | IaaS | 超融合模型；通过统一且完全虚拟化的资源池来满足计算和存储需求；实现高可扩展性 | [64] |
| SnapLogic | PaaS | HR、CRM；提供数据集成以及应用多点连接策略；处理更多样化的用例场景 | [76] |
| WorkDay | SaaS | HR、CRM遗留应用；提供预构建连接器、直观的用戶界面和报告结构 | [47] |
| Adeptia | SaaS | B2B、SOA、社交网络；提供应用和数据集成服务，包括连接、数据映射、转换和提取 | [55] |
| Scribe | PaaS | 移动应用模型；提高应用生命周期；增加市场细分中的云适应能力 | [62] |
| Nginx | PaaS | 微服务模型；集成API代理和API网关，为微服务用户提供支持 | [58] |

**面向云的存储集成工具**

**表3.**

| 访问级别 | 用例 | 数据库示例 |
|---|---|---|
| 列式 | 数据仓库、事务处理、商业智能分析、自索引、数据压缩等 | Apache Kudu、HBase、MariaDB、MonetDB、GreenplumDB、ClickHouse、CrateDB等 |
| 键值 | 消息队列、缓存、会话管理等 | Redis、Dynamo、Aerospike、Berkeley DB、Cassandra、ArangoDB、Voldemort、Keyspace、Hibari、Venti、Oracle NoSQL数据库等 |
| 文档式 | 内容管理、实时数据分析、资源管理、商业分析等 | ArangoDB、CouchDB、Cloudant、DocumentDB、MarkLogic、MongoDB、Cosmos DB、Qizx、Sedna、SimpleDB、Solr、Elasticsearch、BaseX等 |
| 基于图 | 电子商务推荐引擎、符号人工智能、上下文感知服务、欺诈检测、语义搜索等 | Neo4J、ArangoDB、Amazon Neptune、DGraph、MarkLogic、OrientDB、RedisGraph、TigerGraph、TerminusDB等 |

**不同数据访问级别的用例**

**表4.**

| 一致性级别 | 可用性 | 延迟 | 吞吐量 |
|---|---|---|---|
| 强一致性 | 低 | 高 | 低 |
| 会话 | 中 | 中 | 中 |
| 有界陈旧性 | 中 | 中 | 中 |
| 弱一致性 | 高 | 低 | 高 |

**一致性级别与可用性、延迟和吞吐量的对比**

**表5.**

| 客户端中心 | 弱 | 随意 | 顺序 | LIN | 单调读取αβγδ | 单调写入αβγδ | 读取你写入的数据αβγδ | 写入跟随读取αβδδ |
|---|---|---|---|---|---|---|---|---|
| 与数据中心一致性模型的关联 |

**客户端中心与数据中心一致性模型之间的关系**

**表6.**

| 一致性模型 | 主要优势 | 局限性 | 部署场景 |
|---|---|---|---|
| 分析洞察 | 放宽模型：高吞吐量、低协调开销和高可扩展性；临时不一致性和非确定性状态收敛；适合对象存储、社交平台、IoT数据摄取；最适合读多写少、对延迟敏感且对新鲜度要求不高的工作负载 | 事务模型：保证严格正确性和数据完整性；高协调成本、有限可扩展性、在争用时存在死锁风险；适用于金融系统、银行交易、库存管理、关键企业系统；适合对正确性要求高但对地理分布或高延迟环境不适配的工作负载 | 数据中心：基于数据关键性实现细粒度一致性控制；设计和运维复杂度增加；适用于微服务架构、多租户SaaS、混合云平台；反映现代系统设计，仅在有需要的地方选择性强制执行强一致性，提高整体效率 | 客户端中心：改善感知一致性、低读取延迟和减少用户可见异常；有限的全局保证和跨客户端协调挑战；适用于移动应用、协作系统、边缘和用户中心服务；在地理分布用户环境中有效，通常层叠在最终一致性后端之上 |

**数据一致性模型与部署场景的分析对比**

**表7.**

| 度量 | 目标 | 排序 | 陈旧性 | 持续 | 预期 |
|---|---|---|---|---|---|
| k-陈旧性 | 使用客户端可观察和数据中心版本滞后进行分布函数 | × | √ | √ | 客户端和数据中心 |
| t-可见性 | 使用客户端和数据中心不一致窗口进行分布函数 | × | √ | √ | 客户端和数据中心 |
| k-安全性 | 最大违规版本日志 | √ | √ | × | 数据中心 |
| k-原子性 | 最大违规版本日志 | √ | √ | × | 数据中心 |
| k-规则性 | 最大违规版本日志 | √ | √ | × | 数据中心 |

**一致性度量及其要求**

**表8.**

| 标准 | 主节点协议 | 复制写入协议 |
|---|---|---|
| 一致性 | 通过主节点更容易确保强一致性 | 需要复杂的一致性机制，如法定人数或共识 |
| 写入处理 | 由主节点集中处理 | 由多个副本分散处理 |
| 复杂度 | 实现较简单，但需要故障转移机制 | 由于分布式协调，复杂度更高 |
| 容错性 | 主节点故障需要故障转移 | 容错性更高，多个节点可以接受写入 |
| 用例 | 传统关系型数据库、单主系统 | 分布式系统、NoSQL数据库、大规模分布式数据库 |

**主节点协议与复制写入协议的对比**

**(i) 自组织：** 这一方面涉及系统自动组织和管理数据的能力，无需人工干预。自组织系统可以优化数据放置、分布和检索。这一特性在数据量大且不断变化的云环境中尤为有益。自组织描述了系统在无需外部帮助的情况下将各部分组织为任务组织结构的能力。自组织系统可以在不需要人类协助的情况下更改系统组件。以下overlay结构已被用于对自组织系统进行分类：

——**完全去中心化：** 在完全去中心化的overlay中，云存储系统中的所有节点都是平等的，具有相同的职责和能力。没有中心权威或协调点，每个节点独立管理其数据，并直接与其他节点通信以存储和检索数据。由于没有单点故障，它具有很高的容错性 [7]。

——**部分中心化：** 部分中心化的overlay结合了中心化和去中心化的元素。在这种结构中，一些节点充当协调器或超级节点，管理路由、索引或资源分配等特定功能，而其他节点则更加独立地运行。它通过减少完全去中心化系统的开销同时避免完全中心化系统中存在的单点故障，在可扩展性和效率之间取得平衡 [85]。

——**网状overlay：** 在网状overlay中，网络中的每个节点都连接到多个其他节点，形成网状结构。节点可以与其邻居直接通信，并通过多跳与较远的节点间接通信。此overlay不依赖于中心权威，节点可以动态发现并维持与其他节点的联系。它提供了高容错性，因为任意两个节点之间存在多条路径，确保数据可以绕过故障进行路由 [56]。

——**混合overlay：** 它结合了不同类型overlay的特性，根据系统的特定需求定制结构。它提供了灵活性，使系统能够利用不同类型overlay的优势，同时减轻其劣势。例如，它可以通过中心化组件实现高效的数据检索和管理，同时通过去中心化元素保持容错性和可扩展性 [28]。

——**树状overlay：** 在树状overlay中，节点被组织成层次化的树结构，每个节点都有一个父节点（根节点除外），并且可能有多个子节点。这种结构通常用于组播或广播操作，数据需要从源节点分发给多个接收者。它通过受控方式分发数据，每个节点将数据转发给其子节点，从而减少冗余传输，效率较高 [55]。

所有这些overlay结构都有各自的一套规则来执行不同的操作 [4, 75]。一些著名的自组织存储模型总结在表10（附录B）中。

**(ii) 可扩展性：** 可扩展性是系统处理不断增加的数据和负载的能力。可扩展的存储系统可以根据需求增长或缩减，而不会损害性能。这在数据量波动很大的云环境中尤为重要。通过提供可扩展性，存储解决方案可以有效地处理数据存储和处理不断增长的需求，确保即使工作负载增加，系统性能仍保持最优。此外，可扩展的存储系统还允许成本效益高的资源分配，因为组织可以轻松调整其存储容量以满足当前需求，而无需不必要的开支。

**(iii) 高可用性：** 高可用性意味着存储系统能够可靠且一致地访问。它确保数据始终可用，最大限度地减少停机时间和服务中断。此外，高可用性还提供了容错能力，因为它允许在多个存储设备上进行冗余和数据复制。这意味着即使一个设备发生故障，数据仍然可以从另一个设备访问，确保持续运行并防止数据丢失。

**(iv) 复制：** 复制涉及在多个位置或服务器上创建和维持数据的重复副本。这是为了增强数据可用性、容错性和灾难恢复。在复制中，数据的重复副本会实时或按固定间隔进行同步，以确保一致性和完整性。这允许无缝故障转移和负载均衡，因为请求可以重定向到其他具有复制数据的服务器。此外，复制还促进了高效的数据分布和可扩展性，使组织能够处理不断增加的工作负载并满足不断增长的用户需求。

**(v) 持久性：** 持久性衡量数据随时间的持久性。耐用的存储系统确保数据不会因硬件故障或其他问题而丢失或损坏。它可以通过数据备份、冗余以及错误检测和纠正机制等技术来实现。通过确保数据的持久性，组织可以对其存储信息的长期可用性和可靠性充满信心。这对于关键系统和应用尤为重要，在这些系统中数据丢失或损坏可能会导致严重后果。

**(vi) 一致性：** 一致性指数据在整个存储系统中的统一性。在一致的系统中，所有节点或数据副本向客户端提供相同的视图，确保用户看到的是最新和正确的信息。对于数据丢失或损坏可能产生严重后果的应用来说，一致的至关重要。

**(vii) 存储类型：** 这包括每个系统提供的不同类型存储解决方案，如对象存储、文件存储、块存储等。每种类型服务于特定的用例并具有其自身的特性，允许客户选择最适合其需求的存储解决方案。各种存储介质及其目标、优势和缺点的比较分析在表11附录C中突出显示。

### 3.2 超大规模存储管理能力

云计算中的超大规模存储管理是指分布式系统中存储、管理和扩展大量数据的能力。主要侧重于可扩展性、弹性、性能和成本效益，同时确保数据安全、完整性和合规性。这些系统利用分布式架构和高级数据管理技术，以灵活和弹性的方式处理大量数据。Cloudera Manager、NoSQL数据库和工作流管理工具是云存储和大数据处理生态系统中的关键组件。它们各自服务于不同的目的，但协同工作，为管理、存储和处理大量数据提供全面解决方案。Cloudera Manager管理和监控分布式存储生态系统，包括HDFS，它为管理员提供了配置和维护HDFS集群的集中接口 [33]。在云存储和大数据生态系统中，NoSQL数据库可能与HDFS一起使用，以满足不同的数据存储和检索需求 [69]。工作流管理工具可以与HDFS集成，调度和协调数据处理任务和工作流。它们还可以与Cloudera Manager交互，监控Hadoop集群的健康状况和性能。此外，工作流管理工具可能在更广泛的数据处理管道中协调涉及NoSQL数据库的任务。大规模数据分析面临许多挑战，包括数据传输、数据集成、数据管理、数据控制、数据标准化等 [19, 83]。目前已有许多新的解决方案可以应对此类各种挑战，其中包括大规模数据管理能力。

### 3.3 面向云的存储管理与集成服务

云计算服务凭借其低成本和无限虚拟扩展数据来满足用户需求的能力，在企业中占据了一席之地。云应用集成依赖于同步、数据迁移、质量和复制。大多数云集成工具基于SaaS提供商。表2总结了一些主要的最新云数据集成工具。表中的每个工具都与特定的服务模式相匹配，决定了其架构和提供给用户的控制级别。像Nginx和Scribe这样的工具高度专业化，分别专注于微服务和移动应用管理。相比之下，像Adeptia和SnapLogic这样的工具提供更通用的集成服务，支持广泛的业务流程。云应用集成依赖于同步、数据迁移、质量和复制。大多数云集成工具基于SaaS提供商。超大规模存储和集成管理的整体框架如图2所示。

**图2. 超大规模数据存储和集成管理。**

### 3.4 云存储管理：目标与挑战

本节概述了部署超大规模面向云的存储系统的一些主要目标和挑战。总体而言，超大规模云数据存储系统由于其规模和复杂性面临特定的目标和挑战。所有这些挑战均来自合格来源，包括研究论文、书籍、杂志等。

**目标：** 面向云的存储系统旨在满足以下要求：

**(i) 数据可用性：** 是指确保重要数据在组织的IT基础设施中即使出现问题仍然可用的能力。它强调确保存储的数据能够可靠且一致地访问以进行检索和处理。实现高数据可用性涉及解决数据复制、分布和容错等问题。

**(ii) 弹性：** 弹性定义了系统在应对工作负载变化时的能力，通过去配置资源使可用资源随时尽可能密切地匹配当前需求。

**(iii) 多租户：** 是一种云计算架构，使客户能够在公有云或私有云中共享计算资源。

每个租户的数据是相互隔离的，对其他租户不可见。

(iv) 负载均衡使组织能够通过将资源分配到不同的网络或服务器上来管理工作负载需求或应用需求。

(v) 容错能力确保了当一个系统或系统的任何部分发生故障后，服务仍能持续运行。

(vi) 灵活性使定制化和变更的水平在必要时可以随时提高。

(vii) 高数据保密性是指保护信息不被未授权用户访问。

(viii) 可扩展性是指系统处理增加负载的能力。

(ix) 高可用性是指根据用户需求动态配置资源。它专注于最小化停机时间，并确保整个系统保持运行和可访问状态，而不仅仅是数据。实现高可用性需要解决系统的各种组件问题，包括硬件、软件、网络和其他。

(x) 高持久性保证了系统的长期存活。

挑战：部署超大规模云导向数据存储系统并非简单或直截了当的任务。主要挑战列举如下：

(i) 数据保密性：云存储服务通常涉及在第三方提供商拥有和维护的远程服务器上存储数据。确保云存储系统中数据保密性的关键方面和措施包括加密、访问控制、身份认证、审计日志、安全审计、数据防泄漏等。

(ii) 数据锁定：指的是用户或组织对特定云服务提供商产生严重依赖的情况，这使得将数据迁移到另一个提供商或迁移回本地解决方案变得困难。

(iii) 数据传输瓶颈：云存储系统中的数据传输瓶颈会影响性能和用户体验。识别和解决这些瓶颈对于优化数据传输速度和效率至关重要。

(iv) 应用程序并行性：云数据存储中的并行性指的是同时执行多个操作的能力，这可以显著提高性能和可扩展性。然而，实现有效的应用程序并行性存在一些挑战，如表13（附录E）所示。该表概述了云存储系统中实现应用程序并行性的主要挑战，并提出了应对这些挑战的缓解策略。该表按不同的并行性因素进行组织，这些因素对于优化云存储系统的性能、可靠性和可扩展性至关重要。

(v) 应用程序调试：调试超大规模分布式存储系统可能是一项复杂且具有挑战性的任务，因为其规模、分布式性质以及各种潜在问题。在此类系统中调试应用程序的一些知名策略和最佳实践包括：分布式追踪、性能剖析、故障注入、静态分析等。这些策略和最佳实践帮助开发人员识别和定位系统不同组件中的问题，如网络延迟、数据损坏或资源争用[104]。

(vi) 强一致性：在云存储系统的背景下，强一致性是指系统中的每个节点始终从同一视角看到数据的级别。换言之，写操作之后执行的所有读操作都将返回最近写入的值。对于数据完整性和准确性至关重要的应用程序，必须实现强一致性。在分布式系统中，一致性模型各不相同，强一致性是最严格的。它难以实现，因为分布式环境存在固有的问题，包括高可用性要求、节点故障和网络延迟[14]。

(viii) 互操作性问题：当不同的云平台、应用程序或系统之间难以无缝交换数据和服务时，就会在云存储系统中出现此类问题。这些问题会阻碍用户在云环境中期望获得的灵活性、效率和协作潜力[12]。

(viii) 数据完整性问题：在超大规模云存储系统中确保数据完整性是一项关键挑战，因为这些环境具有规模大、复杂性和分布式等特点。数据完整性指的是存储在云中的数据准确性、一致性和可靠性。

成功实现这些目标并克服这些挑战，需要超大规模云数据存储系统的高级技术、架构设计考量以及持续优化努力的结合。

3.5 云导向数据存储要素

本节重点介绍整体云导向数据存储要素及其思维导图，如图3所示。云导向数据存储要素的思维导图包括数据模型、数据一致性、数据复制、数据可扩展性、数据集成、数据虚拟化和数据事务。每个要素对于云环境中超大规模数据存储系统的有效管理都是至关重要的。这些要素的优势突出了使用云存储进行可扩展、可靠且高效数据管理的优势。然而，它们的缺点强调了在设计和使用云存储解决方案时需要解决的复杂性和挑战。为便于阅读，这些要素的比较和洞察分析分别在表12（附录D）和附录G中进行了说明。主要地，该表突出展示了每个云导向数据存储要素的优势和劣势。所有这些要素在后续章节中进行了系统阐述。云计算根据用户需求按需提供无限的可扩展、可靠和灵活的计算服务、存储空间和网络资源。通常，这些服务被归类为基础设施即服务（IaaS），其中云导向存储即服务（COSaaS）是其最关键的组成部分之一。COSaaS在全球范围内提供了多样化的数据存储。

图3. 云导向数据存储要素思维导图。

4 数据模型

数据模型在云存储系统中起着至关重要的作用，决定了数据如何在分布式环境中被结构化、存储、访问和管理。在云存储中，数据模型需要支持各种用例，从简单的文件存储到复杂的多租户应用。数据模型的主要关键方面包括其高效处理非结构化、半结构化和结构化数据的能力，以及其对查询、索引和数据一致性等操作的支撑。设计良好的云存储数据模型还应具备可扩展性，确保随着数据量的增长，系统的性能和可靠性得以维持。本讨论将探讨在不同数据模型（如键值存储、对象存储和关系数据库）之间选择的权衡，每种模型在性能、可扩展性和灵活性方面各有其独特的优势和挑战。数据模型展示了信息如何逻辑地排列、存储在存储中、被访问以及在存储中被修改。数据建模的重要性（有时被忽视为云计算的一个组成部分）应随着云计算在数据仓库和商业智能领域获得牵引力而提升。本节描述了数据模型的各种组件及其全面思维导图，如图4所示。

图4. 数据模型思维导图。

4.1 访问级别

通常，云数据库不采用关系模型，因为它们与多种操作模型相关。目前，云存储系统中主要有五种访问级别，包括键值型、列式、文档型[93]和图型[38, 71]。各种访问级别的用例和一些主要示例在表3中进行了说明。该表提供了各种数据访问级别的全面概述，包括其相关用例以及支持这些访问级别的数据库示例。该表将数据库分为五种主要访问级别：列式、键值型、文档型和图型。每个级别都针对不同的数据管理需求进行定制。该表突出了不同数据库架构如何针对特定用例进行优化，反映了根据应用需求选择合适数据库模型的重要性。

4.1.1 键值型

键值数据库通过管理和存储关联数组来工作。这些数组基于字典和哈希表，由各种键值对组成。在此，键作为唯一标识符用于获取关联数据。这些数据可能是简单对象、复杂对象或JSON结构。键值数据库将数据以无结构或无关系的方式存储在仓库中。它将任何数据视为不透明的数据块。它还取决于应用程序及其结构方式。键值对中的键应足够唯一，以便能够检索关联数据。键可以是整数键（iKey）或字符串键（sKey）。有时可以使用哈希方法来生成iKey。键值对是键和值的组合，而桶包含所有这样的键值对。值可以保存为图像、文本、标记文本（如HTML或XML代码）、程序代码、数字、文件、音频、视频等。一些键值数据库还允许存储关联值的列表、集合和数组。

4.1.2 列式

列式数据库以列而不是行的形式存储数据。它提供更为精确的数据访问，而不是丢弃或扫描行中的数据。数据被插入表格后，系统内部会为其分配一个唯一标识符，即row_id。此row_id完全独立于用户分配的唯一标识符，如customer_id、employee_id等。它将所有列值序列化在一起，并同样处理后续的所有列。这可能取决于给定工作负载下存储设备访问的效率。它更适合对大数据集进行高度复杂的查询。

4.1.3 文档型

文档型是一种广泛用于存储、检索和管理信息的云数据库。它也被称为半结构化数据库。此外，它利用XML属性，是键值数据库的一个子类型。文档的内部组织被文档型系统用于提取元数据。通常，文档型数据库用于内容管理、实时数据分析、资源管理、商业分析等。

4.1.4 图型

图型数据库更接近文档型数据库。它以文档形式存储数据，且不遵循预定义的架构。它在文档型数据库的基础上增加了另一层，强调关系而非单个文档。主要用例包括欺诈检测、推荐系统、上下文感知服务等。图型数据库的一些重要组件如下：

(i) 节点：表示单个实体。它基于关系模型。

(ii) 边：建立节点之间的关系。主要地，边可以是无向边或有向边。

(iii) 属性：指定与特定节点相关的实际信息。

4.2 数据来源

在超大规模云存储系统中，数据模型被设计为高效处理多种数据类型和来源。这些数据模型有助于在存储基础设施内组织、结构化和管理数据。这些模型的数据来源可以差异很大，反映了此类系统中数据的多样性。不同数据来源及其详细信息列于表14（附录F）。

4.3 内容类型

结构化、半结构化和非结构化内容指的是不同类型的数据组织和表示方式，每种方式都有其自身的特点和影响。这些术语常用于数据库、信息检索和数据管理的背景下，用于描述数据的组织和表示方式。结构化内容指的是以高度组织和预定义方式组织的数据。其特征是固定的架构或数据模型，信息被组织成定义良好的字段。它具有预定义的结构，每个字段有特定的数据类型，数据通常以表格形式组织为行和列。传统的关系数据库如MySQL、PostgreSQL和Oracle的存储示例即为结构化数据。相比之下，非结构化数据指的是没有预定义结构或格式的信息。它可以包括文本文档、图像、视频、社交媒体帖子等。

4.4 数据暂存

数据暂存是一种着陆空间，数据在发送到存储系统之前可以被复制到此空间中。如图5所示，它充当外部数据来源和存储系统之间的接口。插入、删除和更新等所有操作都已快速完成。在复制数据时，会对数据结构进行一些更改。在第二步——数据暂存到存储系统的过程中，应用了清洗、归一化和转换操作。数据复制完成后，数据暂存空间中的所有数据会立即被删除。数据暂存是临时存储空间，通常与外部数据来源和存储系统相比规模较小。

图5. 数据暂存。

4.5 抽象级别

通常，数据库系统更加复杂并使用不同类型的 数据结构。由于大量的复杂性，许多与数据库相关的无关细节被隐藏起来，使用户不必面对这些问题。

因此，在整个系统中已划分出三个不同的抽象级别：文件级、块级和DBMS级。文件是最低的抽象级别，包含实际的存储系统。它也被称为“存储系统的物理视图。” “块”是中间级别的抽象，指定了在存储系统中可以存储哪些数据。在此级别上，某个对象的所有属性都已定义，包括其类型、关系等。块级抽象指定了系统的逻辑视图。

**4.6 总结**

云存储系统的有效性在很大程度上取决于其数据模型的选择和实施。一个健壮的数据模型可以显著增强系统的可扩展性、高效管理数据的能力，并为用户提供快速的访问，使其能够跨分布式环境进行访问。相反，设计不当的数据模型会导致效率低下，例如数据访问中的瓶颈、扩展困难以及在管理数据一致性和可用性方面的复杂性增加。因此，结论强调了选择与应用程序的具体需求、预期的数据增长以及对高可用性和持久性的需求相匹配的数据模型的重要性。

**5 数据一致性**

在过去十年中，快速扩展的基于互联网的服务，如博客、社交网络、搜索和电子商务，极大地改变了个人交流、访问资源、交换信息和进行交易的方式。另一方面，传统的RDBMS面临着新的挑战，因为对可扩展性和新应用需求的要求不断增加。Not Only SQL（NoSQL）是一种新兴的低价、高性能数据库系统类别，它开始威胁到关系数据库的主导地位[15]。数据一致性在云存储系统中是一个基本方面，影响着数据在分布式节点之间如何可靠且准确地存储和检索。在云环境中，由于网络延迟、系统故障以及数据存储的分布式性质等因素，维持一致性变得具有挑战性。各种一致性模型，如强一致性、最终一致性和因果一致性，在性能、可用性和可靠性之间提供了不同的权衡。本节探讨了数据一致性模型对应用设计、用户体验以及云存储系统整体效率方面的影响。关于数据一致性的思维导图（如图6所示）进行了详细讨论，包括其级别、模型、类型、度量、协议和维护。

*图6 数据一致性的思维导图。*

**5.1 一致性级别**

数据一致性级别确定在集群中必须接受多少个副本，然后才能接受读或写操作。通常，一致性级别影响数据库的可用性、延迟和吞吐量。云存储系统的主要目标是提供高可用性和可扩展性，这有时会以牺牲强一致性为代价。这里，数据一致性级别的选择至关重要，并且经常受到系统规模、分布和性能要求等因素的影响。

一般的云数据库使用四种一致性级别，包括：强一致性、会话一致性、有界陈旧一致性和弱一致性。不同一致性级别的影响在表4中进行了描述。

**5.1.1 强一致性**

强一致性提供线性保证，这意味着服务请求是并发执行的。它也被称为“即时一致性”。在这里，更新后数据可以被立即查看，从而确保所有用户看到的数据是一致的。

**5.1.2 会话一致性**

会话一致性是单用户和全球分布式应用中最广泛使用的一致性级别。它提供了适合在用户上下文中运行的应用程序所需的一致性保证。在单个客户端会话内，读操作保证遵守一致前缀、单调读、单调写、读己之写和写跟随读保证。

**5.1.3 有界陈旧一致性**

在有界陈旧一致性中，读操作保证遵守一致前缀保证。通常，“有界陈旧”可以配置为两种类型：(i) 版本数 和 (ii) 时间间隔。它在陈旧窗口之外提供总的全局顺序。

**5.1.4 弱一致性**

弱一致性也被称为最终一致性。读操作没有顺序保证，并且在没有写操作的情况下，副本最终会收敛。它是最弱的一致性级别形式，因为客户端可以读取比之前读取的值更旧的值。有时候，如果应用程序不需要任何顺序保证，这可能是理想的。

表4阐明了在一致性、可用性、延迟和吞吐量之间的权衡，强调了实现更高的一致性通常以牺牲更低可用性和更高延迟为代价。相反，较弱的一致性模型可以提高可用性和吞吐量，但代价是牺牲一致性。强一致性提供了最严格的数据一致性保证，但代价是低可用性和高延迟。系统确保所有用户同时看到相同的数据，这需要大量的系统间协调，导致吞吐量降低。会话一致性提供了一种平衡，在单个会话内保持数据一致性，从而带来中等水平的可用性、延迟和吞吐量。有界陈旧一致性提供了中等水平的可用性、延迟和吞吐量。它允许数据在定义的时期内略微过时（或“陈旧”），在一致性和系统性能之间取得平衡。弱一致性强调可用性和低延迟，从而实现高吞吐量。

**5.2 一致性模型**

一致性模型是全球分布式数据存储和计算之间的一项协议，计算同意遵循某些规则来存储数据，以保证工作完美。通常，一致性模型基本指的是应该为共享内存数据保持的一致性程度[16]。一致性模型可以分为四类：(i) 放松模型，(ii) 事务模型，(iii) 数据为中心模型和 (iv) 客户端为中心模型。

**5.2.1 放松模型**

放松模型是一种不太严格的一致性模型，在其中，顺序一致性要求被放松。换句话说，放松程序顺序或写操作所需的原子性，以提高系统性能。在放松程序顺序的情况下，以下操作顺序对可以被放松：写后写、读后写和读/写后读。在放松的写原子性范式下，一个进程可以在任何其他进程之前看到自己的写操作。

**5.2.2 事务模型**

事务模型结合了缓存一致性和内存一致性的思想。通常，事务是一组由进程执行的活动，将数据从稳定状态转换到稳定状态。当没有争议时，事务提交或回滚。事务完成后，所有更改对其他所有进程都可访问，而回滚则抹去所有更改。放松的一致性方法比事务一致性模型更难以使用。它在性能方面也优于顺序一致性方法。

**5.2.3 客户端为中心模型**

客户端为中心模型是一种具有成本效益的模型，它指定的是并发操作而不是顺序操作。客户端为中心的一致性模型的一些例子是——(i) 单调读 (MR)，(ii) 单调写 (MW)，(iii) 读己之写 (RYW) 和 (iv) 写跟随读 (WFR)。第一个模型，单调读，确保读取了版本n的客户端在那之后总是读取版本n之后的版本。这很有用，因为在应用程序中，数据可见性可能不是即时的，但版本至少是按时间顺序可见的。单调写一致性确保来自同一客户端的两次更新按存储系统接收到的特定顺序进行序列化。读己之写确保写入版本n的客户端将来能够读取至少和版本n一样新的版本。它防止了用户或程序因为认为初始尝试失败而多次发送相同请求的情况。最后一个模型，写跟随读，确保在读取版本n之后，更新只会在至少是版本n的副本上运行。

**5.2.4 数据为中心模型**

数据为中心模型的所有度量都需要访问存储系统的实际副本。测试应用程序增加了系统的负担。然后，通过挖掘副本日志来获取结果，其中应包含每个请求的以下信息：在每个副本上的开始和结束时间戳、唯一的请求ID和请求类型（读、写）。因此，利用这些信息可以确定t可见性、k陈旧度、顺序违规数量以及相关的一致性模型。客户端为中心模型与数据为中心模型之间的关系可以用以下几点来指定：
(α) 单个请求可能偶尔得到保证，但这只是偶然的。
(β) 对于大量的请求，保证可以得到满足。
(γ) 单个客户端的保证得到满足。
(δ) 保证扩展到了所有客户端在同一时刻。

每个数据一致性模型都在一致性、性能和复杂性之间提供独特的权衡。模型的选择取决于应用程序的具体要求，例如对强一致性、低延迟或对跨分布式系统扩展能力的需求。理解这些权衡对于设计满足所需可靠性、效率和用户体验水平的系统至关重要。

表5显示了客户端为中心模型和数据为中心模型之间的关系。该表比较了四种客户端操作——单调读、单调写、读己之写和写跟随读——在四种数据为中心的一致性模型下的表现：弱一致性、因果一致性、顺序一致性和线性一致性 (LIN)。对于弱一致性，保证是最小的。在因果一致性下，操作在发出大量请求时通常得到满足，表明了一致性的高可能性。顺序一致性提供了更强的保证，确保单个客户端的一致性。最后，最强的模型，线性一致性，提供最高水平的一致性，确保所有客户端在同一时刻体验到相同的数据一致性。

表6突出了数据一致性模型的分析比较以及推荐的部署场景和洞察。从分析角度来看，没有一个一致性模型是普遍最优的；选择取决于工作负载特征、故障容忍度、地理分布和应用程序语义。强事务一致性对于正确性至关重要的领域仍然不可或缺，但其可扩展性限制使其不适合现代地理分布式云系统。相比之下，放松和客户端为中心模型在大规模Web、物联网和边缘部署中占据主导地位，其中延迟和可用性是优先考虑的因素。新兴的数据为中心和混合方法代表了向自适应一致性转变的趋势，使系统能够根据数据重要性和访问模式动态平衡正确性和性能。这一趋势与当代的基于云和微服务架构相一致，其中异质一致性要求在同一系统中共存。最近的系统越来越多地采用混合和自适应一致性策略，为关键数据结合事务保证，为性能敏感操作结合放松或客户端为中心一致性。

**5.3 一致性类型**

在云数据存储中，一致性指的是如何维持跨分布式系统和存储在云中的多份数据的数据一致性。超大云存储系统中的一致性类型与分布式系统中的缓存一致性概念密切相关，但也涵盖了云环境特有的更广泛考量[82]。有六种数据一致性类型，如下所列[3, 11, 60]：

* **顺序一致性 (Sequential):** 它是由Lamport开发的低严格一致性模型。不同处理器对变量的写入必须以相同的顺序被所有处理器看到，但不一定要被看到写入到某个变量。所有动作必须似乎立即或原子地相对于其他每一个处理器执行，以维护处理器之间的执行顺序。
* **缓存一致性 (Cache):** 它指的是存储在可能属于分布式计算环境的不同的缓存中的数据同步。确保分布式系统中的一致性对于避免数据冲突和不一致至关重要。有几种缓存一致性模型，每种都有自己管理缓存数据一致性的方法。一些常见的缓存一致性类型有：(i) 写直通 (Write-Through)，(ii) 写回 (Write-Behind)，(iii) 写一次 (Write-Once)，(iv) 写失效 (Write-Invalidating)，(v) 读己之写 (Read-Your-Write)。选择合适的缓存一致性类型取决于分布式系统的特定需求和特征，以及一致性、可用性和分区容错性之间的权衡。
* **释放一致性 (Release):** 它通过将进入同步操作与退出同步操作分离来放松弱一致性模型。在弱排序下，当同步操作是可观察时，所有处理器中的所有活动必须在同步操作完成且处理器继续之前可见。
* **进入一致性 (Entry):** 进入一致性模型是释放一致性模型的一个子集。它还需要使用获取（acquire）和释放（release）指令来清楚地表示关键区域的进入或退出。然而，在进入一致性下，每个共享变量都拥有自己的同步变量。

它能够实现共享变量的多个关键部分同时运作。

本地一致性：本地一致性是指在一个本地上下文或系统子集中保持一致性的场景，通常忽略全局状态。这种情况可能出现在分布式系统中，其中本地操作保持一致，但可能与全局状态暂时偏离。例如，在分布式数据库中，单个节点内的事务可能本地一致，即使跨所有节点的全局一致性并未立即实现。

流水线RAM：流水线RAM（PRAM）是最早的一致性模型之一，由Lipton和Sandberg于1988年提出。在PRAM一致性中，所有进程观察单个进程的操作顺序与它们由该进程发出的顺序相同，但由不同进程发出的操作可能以各种顺序被观察到。PRAM的一致性不如CPU的一致性可靠。PRAM消除了要求所有处理器维护对单一位置一致性的需求。

5.4 一致性度量

一般而言，一致性度量有两个角度：客户端角度和提供商角度。客户端角度侧重于客户端能够看到的保证。这种角度被称为以客户端为中心的一致性。提供商角度也称为以数据为中心的一致性，因为它依赖于内部同步机制和副本之间的通信。这完全取决于角度来度量不同的方面。

5.4.1 k-陈旧性

根据基于陈旧性思想的一致性模型，读取可能会返回旧的、陈旧的已写入数据。它们提供了比最终一致性语义更多的保证，但仍然不足以允许比线性化更高效的实现。它确定某个读取落后了多少个版本。它还取决于当前系统的工作负载。可重现性是k-陈旧性一致性度量主要局限性之一。只有在能够重复生成相同工作负载的情况下，它才可以重现。

5.4.2 t-可见性

它报告不一致窗口的分布函数，并以时间形式表示陈旧性。它还计算大量执行中特定不一致窗口长度的可能性。t-可见性度量是可重复的，因为它们提供了陈旧性值的分布函数，而不是单个度量值。存储提供商对t-可见性感兴趣，因为它提供了关于副本在更新后同步所需时间的全面信息。由于可以使用任何分布函数，t-可见性既是连续的，也是细粒度的指标，因为它仅度量陈旧性而没有排序。

5.4.3 其他度量

通常认为同一内存位置中的操作是原子的，并且它们以特定方式发生。但这种假设可以被放宽，允许在同一内存位置中同时进行的操作。在这方面，Lamport定义了三个一致性度量类别：k-Safe、k-Atomicity和k-Regular。其中，k指定正整数。k-Safe选项是最脆弱的，因为它假设与任何写入不并发的读取将获取最近写入的k个值之一。除了与写入重叠的读取获取的值必须是寄存器的可能值之一之外，关于与写入重叠的读取获取的值不做任何假设。

更多信息请参阅L. Lamport于1985年发表的题为"On Interprocess Communication"的研究论文[57]。这些度量基本要求见表7.5。

5.5 一致性协议

一致性协议提供了一致性模型的系统化实现方式。它根据一致性模型控制操作序列来实现一致性模型。一致性协议可以归类为两部分：（i）基于主节点的协议和（ii）复制写协议。两者都以特定一致性模型实现。

5.5.1 基于主节点的协议

基于主节点的协议更容易实施。顺序排序是基于主节点协议的一个例子。本地写和远程写都可以被视为基于主节点的协议。每个数据项都有一个主服务器，负责协调其变更。所有读写操作都在同一服务器上执行。在本地写协议中，主副本在愿意执行更新的进程之间移动。

5.5.2 复制写协议

在这种协议中，写操作传播到所有副本，而读取在本地执行。写操作可以使用点对点通信或组播进行传播。在分布式系统中，面对数据复制实现一致性涉及定义多个副本如何处理写的协议。有几种协议，选择取决于系统的具体要求。一些常见的复制写协议包括基于仲裁和基于共识的协议。这些协议确保更新在副本间正确同步以维护分布式系统中的一致性。协议的选择取决于容错要求、性能考虑和期望的一致性保证水平等因素。

为便于阅读，主节点协议与复制写协议的比较列于表8中。主节点协议更简单，提供强一致性，但可能因主节点故障而遭受瓶颈或可用性问题。复制写协议将更新责任分配到多个副本，提供更好的容错性和可用性。然而，它们更复杂，需要仲裁或共识等机制来确保一致性。

5.6 数据一致性的主要挑战

通常发生的是选择满足本部分所述要求的适当一致性指标。然而，在查看一致性行为时，仍面临许多挑战，如下所示：

（i）可重现性：在存储系统执行相似的前提下，重复系统基准测试时，测量组件应产生相同的值。

（ii）广泛应用性：测量策略不应局限于单一系统。相反，它应能够涵盖广泛的系统，以确保结果具有可比性。

（iii）分辨率：评估和测量系统的方法应不仅利用具有足够分辨率的度量，而且能够使用它。

（iv）微服务架构：在微服务中的一个逻辑原子操作通常跨越多个微服务。甚至单体系统也可能使用多个数据库或通信技术。

5.7 总结

在云存储系统中选择数据一致性模型对系统性能、可扩展性和用户满意度产生深远影响。虽然强一致性确保数据准确性，但可能对可用性和响应性造成限制，使其对某些优先考虑速度和正常运行时间的云应用不太理想。相反，最终一致性在分布式环境中提供了更大的灵活性和效率，但需要应用处理暂时不一致的可能性。结论强调没有一刀切的解决方案；相反，最优一致性模型取决于应用的具体要求，例如对实时数据准确性的需求与对高可用性和低延迟需求的对比。

6 数据复制

在超大规模云存储系统中，数据复制是确保分布式基础设施中数据可用性、容错能力和灾难恢复的关键策略。通过在不同地理位置或存储节点上创建数据的多个副本，复制增强了系统对硬件故障、网络中断和数据损坏的抵抗力。然而，大规模实施数据复制引入了诸如管理一致性、延迟和存储成本之间的权衡等挑战。同步复制要求所有副本同时更新，确保强一致性，但可能导致延迟增加和系统性能降低，特别是在地理分散的环境中。而异步复制通过允许更新延迟传播到副本，提供了更好的性能和更低的延迟，但可能导致暂时的不一致。数据被复制以在组织中实现高可用性、备份和/或灾难恢复。数据复制的心智图见图7。

图7 数据复制的心智图

6.1 复制模型

6.1.1 事务复制

通常在开始事务复制之前，会捕获已发布数据库对象和数据的快照。初始快照之后，发布者通常将后续数据更新和模式变更作为（接近实时）事件发送给订阅者。数据更新以与在发布者上应用时相同的序列和相同的事务边界应用到订阅者；因此，在一个发布内保证了事务一致性。

6.1.2 虚拟同步

虚拟同步是用来描述具有自我管理成员资格的动态进程组的术语。应用可以随时加入或离开进程组：进程组类似于网络化的复制变量。第二个要求与性能有关。虚拟同步复制概念被广泛使用，应用范围从空中交通管制和股票市场系统到IBM和微软的数据中心管理平台[18]。

6.1.3 状态机复制

状态机复制是一种通用方法，通过复制服务器并协调客户端与副本的交互来创建容错服务。此外，该方法为理解和创建复制管理方法提供了基础[84]。它由存储当前状态信息的状态变量和改变它的指令组成。每个命令由确定性程序实现；命令的执行相对于其他命令是原子的，它改变状态变量和/或产生一些输出。状态机的客户端请求执行命令。请求识别状态机，指定要执行的命令，并包含操作可能需要的任何其他信息。请求处理可以将数据发送到执行器（例如，在过程控制系统中）、磁盘或终端，或等待之前请求回复的客户端。

6.2 复制类型

今天组织使用的复制有几种形式，取决于所使用的数据复制技术。以下是一些最常见的复制类型：

事务复制：在这种方法中，数据复制软件从源创建数据的完整初始副本到目标，之后订阅者数据库在任何数据更新时接收更新。因为每次数据更新时复制的行数较少，这种复制选项更高效。在服务器到服务器的场景中，事务复制最常见。

合并复制：这种类型的复制在服务器到客户端场景中很常见，允许发布者和订阅者都进行动态数据变更。合并复制通过合并两个或多个数据库的数据形成单一数据库来增加技术的复杂性。

快照复制：使用快照复制，数据会精确复制其在任何给定时间点出现的样子。与其他技术不同，快照复制不受数据变更影响。当数据变更较少时，例如在发布者和订阅者之间执行初始同步时，采用这种复制样式。

6.3 复制组件

今天存储、处理和访问的数据量空前庞大。企业希望其IT部门保持数据在线并使其无限期可用，对存储和处理数据的系统造成很大压力。我们需要用新的、更敏捷的方法来取代过时和低效的遗留程序，以适应今天的需求。实现这些目标的一种方法是数据复制。数据复制涉及在不同存储系统或位置创建和维护数据的多个副本。通过实施数据复制，企业可以增强数据可用性，改进灾难恢复能力，并降低数据丢失的风险。此外，它允许更快的信息访问并实现更好的可扩展性以适应当今数字环境中不断增长的数据量。

6.4 复制程度

数据复制涉及持续复制事务，使得副本始终保持最新并与源同步。在数据复制中，数据在多个位置可用，但特定关系只能存在于一个位置。复制程度可以归类为完全或部分。完全复制可以在每个位置存储整个数据库。最严重的例子涉及在分布式系统的所有站点复制整个数据库。由于只要至少有一个站点正常运行系统就能继续运行，系统的可用性将增加。

部分复制也是可行的，在这种方式中，一些频繁使用的数据库片段会被复制，而另一些则不会。

**6.5 复制调整**

在同步复制中，数据库以同步方式进行复制，使得所有副本具有相同的值。在所有站点中，访问某个数据项的事务将能够访问相同的值。修改数据项的事务会扩展为在所有副本中执行相同的修改，以确保一致性。在大多数情况下，采用两阶段提交技术。

**6.5.1 同步**

同步意味着两个或更多数据副本被保持更新状态，但不一定每个副本都包含所有数据。通常，它会在预先确定的时间间隔之后执行，相当于将不同副本的变更重新合并到主数据库中。它用于分布式数据库和系统，以确保在一个节点上做出的更改能够立即且一致地复制到一个或多个其他节点上。它还有助于维护分布式系统的数据一致性和完整性[72]。

**6.5.2 分布**

分布式复制是将数据复制到分布式系统中的多个节点或不同位置的过程。其主要目标是确保数据可用性、容错性和负载均衡。它常用于各种分布式计算环境，包括分布式数据库、云存储系统和内容分发网络，以提高性能和可扩展性。

**6.5.3 整合与摄取**

整合复制将数据集中和整合到单一位置，使其更易于分析和从中提取见解。通过从各种来源摄取数据，企业可以获得对其运营的全面视图并做出数据驱动的决策。摄取复制是将数据从数据源移动和复制到目标位置的过程，例如云数据湖或云数据仓库。

**6.6 复制粒度**

数据复制中的粒度是指大规模分布式存储系统中在不同节点或位置之间复制的数据单元的细节程度或大小。它涉及确定哪些部分的数据被复制以及复制过程发生的频率。一些粒度级别包括——记录级、表级、数据库级、文件级和对象级。复制粒度的选择取决于多种因素，包括数据的性质、更新的频率、数据单元的大小以及系统的性能要求。更细的粒度（如记录级复制）可以提供更精细的控制和实时一致性，但可能带来更高的开销；而较粗的粒度（如数据库级复制）可能简化复制过程，但在某些情况下可能导致不必要的数据传输。

**6.7 复制放置**

数据复制放置是指在分布式系统中关于数据副本存储位置做出的战略性决策。在分布式系统中，复制通常用于提高容错性、可用性和性能。决定这些副本放置在哪里是设计满足其目标的高效系统的关键方面。在确定复制数据的位置时，需要考虑各种因素。这些因素包括网络延迟、数据访问模式和整体系统架构。

**6.8 复制传播**

一般来说，复制是在数据节点之间使用两种不同的数据复制策略设置的：同步和异步。同一数据被复制多份并分布在多个节点上。复制传播的唯一动机如下：
——使数据在地理上靠近用户。
——提高数据可用性。
——通过利用模拟数据的并行读取来提高性能。
——为灾难恢复做准备。

在同步复制中，主节点在更新自己的数据副本后，开始在其副本上执行写操作。当副本收到更新时，它们对数据副本进行必要的更改，然后向主节点确认。主节点在收到所有副本的确认后，响应客户端并完成任务。

**6.9 总结**

数据复制对于超大云存储系统的可靠性和效率至关重要，因为它在维护分布式环境中的数据可用性和完整性方面起着关键作用。同步和异步复制方法之间的选择通常取决于应用程序的具体需求，有些优先考虑强一致性，而其他则重视性能和成本效益。

**7 数据可扩展性**

数据可扩展性是超大云存储系统中的根本问题，在其中，高效处理不断增加的数据和用户的能力至关重要。可扩展性不仅涉及添加存储容量，还涉及确保性能指标（如延迟、吞吐量和数据访问时间）随着系统增长而保持一致。它是在云计算中添加或撤出计算、存储和网络服务的过程，以满足工作负载对资源的需求，并在用量增长时维护可用性和性能。它包括扩展资源、容纳额外数据存储需求以及在面对增长的工作负载时提供一致性能的能力。数据可扩展性的思维导图已在图8中可视化展示。

图8. 数据可扩展性思维导图。

**7.1 方法**

在数据可扩展性的背景下，抽样方法涉及使用数据子集来执行分析或操作，而不是处理整个数据集。这种技术在处理大型数据集时特别有用，因为它有助于减少计算和存储需求，同时仍然提供对数据整体特征的见解。索引是数据可扩展性的关键组成部分，因为它显著影响数据检索操作的效率。适当的索引可以增强查询性能并使系统能够随着数据集的增长有效扩展。通过使用索引，系统可以快速定位和检索特定数据点，减少搜索整个数据集所需的时间和资源。

**7.2 类型**

数据可扩展性是指系统随着需求增加而高效处理和管理不断增长的数据量的能力。不同类型的数据可扩展性解决了系统设计和架构的各个方面，以确保系统能够有效扩展。可扩展性可以通过两个重要方面实现：
(i) 横向扩展——它连接多个云以集成并创建单一逻辑云。具有计算亲和性的云可以访问异构平台的数据。云数据与计算-数据之间的集成关系更为关键。
(ii) 纵向扩展：它通过放大现有系统和增强通信带宽来提高云存储和计算能力。它有能力通过添加新数据库、处理力等来增加当前资源。

**7.3 存储结构**

评估：云存储系统中的存储结构是影响数据如何在大规模下存储、管理和访问的关键因素。评估存储结构涉及评估数据如何在不同存储层（包括对象存储、块存储和文件系统）之间组织。评估过程还考虑存储结构如何支持数据冗余、容错和数据访问模式，确保系统能够处理当前和未来的数据需求。此评估中的关键指标包括存储效率、延迟、吞吐量以及系统在不降低性能的情况下管理大量数据的能力。

分区：它将大型数据集划分为更小的、可管理的部分或"分区"，这些分区可以分布在多个存储节点上。这种方法使系统能够横向扩展，因为当系统需要增长时，可以将额外的分区分配给新节点。分区可以使用各种技术实现，例如基于范围的分区（根据键范围划分数据）或基于哈希的分区（根据哈希函数的输出分布数据）。

**7.4 分类**

数据可扩展性分类围绕处理不断增长的数据量、用户负载和性能要求的策略和方法展开。云存储系统利用各种可扩展性分类以确保灵活性、效率和可靠性。一些主要的分类算法包括贝叶斯分类器、决策树、k近邻、神经网络、遗传算法、支持向量机等。这些算法常用于云存储系统中，根据数据的特征和模式对数据进行分类和组织。通过实施这些可扩展性分类，云存储系统可以有效处理大量数据，同时保持最佳性能并满足用户需求。这些可扩展性分类使云存储系统能够高效分配资源并将数据分布在多个服务器上。

**7.5 总结**

数据可扩展性对于超大云存储系统的长期可行性至关重要，因为它直接影响系统在不牺牲性能的情况下支持不断增长的数据集和用户群体的能力。结论强调，可扩展的存储系统必须以灵活性为导向进行设计，使其能够在不显著重新配置的情况下通过添加存储节点或资源来实现无缝扩展，同时保持可靠性、可用性和效率。此外，系统应纳入智能数据分布和负载均衡机制，以确保规模扩大不会导致瓶颈或资源不平衡。

**8 数据集成**

本节重点介绍了数据集成方案、方法和阶段的各个方面。为了更好地理解数据完整性方案，我们根据其处理的数据类型、使用的元数据类型、能力、使用的实现原语以及部署场景构建了一个主题分类法。由于其低成本和潜在无限的可扩展性，能够满足不断增长的数据需求，云计算服务在行业中已确立了一席之地。数据集成思维导图已在图9中可视化展示。

图9. 数据集成思维导图。

**8.1 数据集成方法**

确保数据完整性的两种知名方法是统计技术和确定性技术。统计技术采用随机选定的数据块来评估完整性，提供的保证不足100%。而确定性技术需要访问整个文件才能评估完整性，并提供100%的拥有保证[36]。确定性技术不适合巨大的文件，如数据大小为GB或TB级别的归档文件，因为验证这样文件的完整性将花费太长时间。因此，用户执行完整性验证的能力可能受到限制。因此，对于巨大的数据集，统计技术更为适合。

**8.2 数据集成方案**

使用数据完整性方案可以快速发现任何数据损坏或删除，然后可以采取必要步骤恢复数据[102]。为了帮助人们更好地理解数据完整性方案，我们构建了一个主题分类法，基于方案处理的数据类型、使用的元数据类型、其能力、使用的实现原语以及依赖的部署场景。图10可视化展示了各种数据集成方案的详细分类。

图10. 数据集成方案。

**8.2.1 审计**

数据完整性方案允许公共审计和私人审计。公共审计引发了与用户匿名和数据泄漏相关的隐私问题。保护隐私的公共审计策略被进一步细分为若干组。Krzywiecki和Kuty[53]提供了带有开放可审计性的广播加密和带有拉格朗日插值的安全伪随机数（SPRN）。由于可追踪性，公共审计被允许同时保持匿名，可追踪性使原始用户可以追踪签名到块并识别签名者。Wang等人[95]研究的另一个重要功能和能力是支持大量用户而不影响验证过程的效率。根据Shen和Tzeng[87]的方法，鼓励审计权限的委托；不允许再委托。被授予授权的审计用户不能将授权提供给另一个用户。Wang[96]描述了称为专有安全高效代理可证明数据拥有（PPDP）的云存储方法的优缺点。

**8.2.2 加密**

数据集成过程涉及从多个来源收集信息并将其呈现为单一、一致的数据集。多年来，数据完整性方案使用了非对称和不对称加密来确保安全。作者Ateniese等人[10]通过使用对称密钥加密和加密哈希函数实现了可扩展性和效率。2009年，Wang等人[97]提出了一种可检索性证明方法，使用BLS签名来实现公共可验证性和动态数据操作。

Zhu等人[105]提出了一种基于双线性配对的协作PDP（CPDP）系统，并建议了一种提供知识可靠性的技术。该方案基于同态可验证响应（HVR）和哈希索引层级（HIH）。Lee和Chang[59]提出了一种有效的数据完整性验证方法，该方法采用了结合对称加密和非对称加密的混合方法。

**8.2.3 倾向**

数据完整性方案的倾向可以是仅验证，也可以是验证加数据恢复。这两种倾向都是可能的。按照倾向划分，数据完整性方案可分为两大类：数据所有权和可检索性证明[99]。数据所有权方案基于概率模型，因为它们随机选取数据块进行检查，而不是读取整个文件。原始数据经过预处理生成一些信息。这些元数据与原始数据一起保存，并用于验证用户数据的真实性。

**8.2.4 元数据**

大多数数据完整性方案将原始数据与一些额外的元数据相结合，这些元数据在整个完整性验证过程中都会使用。这些元数据可能是具有同态和可验证特性的"标签"，有助于在验证过程中生成聚合值[101, 103]。元数据也可能是"签名"，用于替代标签，例如代数签名，以提升类似Reed-Solomon编码的方法。最后，网络编码（也允许数据恢复）可以作为元数据替代标签和签名，用于检测少量数据[9, 20]。

**8.2.5 部署环境**

部署环境描述了数据完整性技术将实施的场景类型。由于数据存储在云端，而云端可以是"简单型"、"混合云"或"多云"，因此数据完整性方案必须满足一些额外的要求。云存储系统的数据集成涉及利用云服务和工具无缝地合并和管理来自不同来源的数据。集成的主要目标包括：云端数据提取、云端数据转换、将数据加载到云存储中、数据质量保证、元数据管理和集成工作流。Curtmola等人[32]提出了一个名为"多重副本可证明数据拥有（MR-PDP）"的方案，当原始数据丢失或更改时按需创建数据的新副本。

**8.2.6 数据性质**

此属性描述方案的适用数据性质。数据可以是静态或动态性质的[101]。数据性质在方案评估中也起着重要作用[31, 103]。Ateniese等人[9]提出的方案仅适用于静态数据，因为当在现有数据中间插入新数据时，需要重新计算完整文件的标签。同样，Ateniese等人[10]支持修改、删除和追加操作。

**8.3 总结**

数据集成对于释放超大规模云存储系统的全部潜力至关重要，它使组织能够利用全面的洞察信息并推动更好的决策。有效的集成策略确保来自不同来源的数据无缝合并并在整个云基础设施中可访问，支持从日常运营到高级分析的各种需求。

**9 数据虚拟化**

数据虚拟化是一个逻辑数据层，它集成了来自不同系统的所有业务数据，通过统一的数据控制实现集中式安全和治理，并实时分发给业务用户。它指的是在硬件和软件层之间以及软件层之间提供抽象层的技术，从而简化与这些层的交互。数据虚拟化的思维导图表11所示，它展示了数据虚拟化技术的各个方面，包括抽象、数据访问、转换、数据联合和交付。在隐藏背景信息的同时向用户和开发者表达重要功能的行为称为抽象。抽象和虚拟化类似，但虚拟化并不一定隐藏基础层的细节。在计算机领域，"抽象"一词被应用于多个层次。数据虚拟化的抽象基础在于位置、存储架构、API和访问语言。要构建自主的数据平台，我们需要紧密集成的云平台，包括第三方的云平台，但最重要的是需要基于CNCF社区理念构建的云原生框架[77]。虚拟化是云计算的基础，因为它能够更高效地利用实际的计算机硬件。它使企业能够获得对其硬件投资的更大回报。

**图11. 数据虚拟化的思维导图。**

**10 数据事务**

"事务"是由一个或多个实体执行的一组活动。每个事务都保证是原子的，即事务永远不会被部分执行。事务的所有活动要么全部执行，要么全部不执行。数据事务的思维导图如图12所示。数据事务分类突出了云环境中数据事务的四个不同方面：类型、隔离性、正确性和依赖性。三种主要的事务类型是读写事务、只读事务和只写事务。每种事务类型服务于不同的目的，并且在数据访问和修改方面具有特定的要求。

**图12. 数据事务的思维导图。**

当今的Web服务通常使用可扩展的存储系统，将数据分区到多台服务器上，因为数据量已经超过了单台机器的容量。跨多个分片进行一致的数据读取需要事务隔离。Fekete等人[43]提出了避免非串行化事务执行的标准，以确保在数据库系统提供强SI的情况下保证串行化。他们建议通过生成事务之间的冲突来静态修改工作负载，使事务在"先提交者胜"规则下有效串行化。Schenkel等人研究了如何在提供强SI的数据库系统上确保1SR事务。

事务依赖性按类型分为可在多版本历史中出现的有序冲突。例如，一种类型涉及产生同一数据项连续版本的两个事务，另一种类型涉及一个写入操作创建了数据项版本，而该版本被随后发生的数据项读取所看到[43]。Adya等人[2]引入了依赖性定义，这些定义可用于任何多版本历史，甚至可以应用于不同的锁定隔离级别。实际上，在这篇文章中，作者建议使用他们在ANSI隔离级别定义中建立的依赖性，这些依赖性对特定的并发管理机制保持中立。Adya等人[2]定义了基于每个数据项版本排序的事务依赖性，即知道每个版本替代了哪个先前的版本。

**11 开放研究问题与方向**

云计算在数据共享或信息从一个地方转移到另一个地方方面起着重要作用。它以高效的方式向用户共享数据并快速响应用户。尽管如此，云计算仍然存在许多缺陷。所有这些缺陷都推动了研究的发展。本节讨论了与云计算中云存储系统相关的一些主要研究问题。

**11.1 动态性与可扩展性问题**

大量共享计算基础设施的组织单位实现各自特殊任务组合，其总体需求和到达模式更加动态。此类环境必须表现为在短时间间隔内存在大量按需请求的资源，且具有高度变化性。将产生大量调度结果，包括动态虚拟网络功能（VNF）[80]的快速任务调度决策、之前分配决策的修正以及包含动态资源请求驻留的长时间运行的任务，通过时间预测难以预测的资源介入。一些问题包括：SLA违规、预测不准确、资源约束以及工作负载的异质性和变异性。

**11.2 超大规模数据集成问题**

云数据集成是协调不同、基础设施和应用的更具挑战性和耗时的过程。在将特定云域迁移到其他环境之前，需要制定计划来确定云存储系统数据集成服务的正确技术评估。与数据集成相关的某些关键问题包括：数据传输跟踪[13]、数据迁移、性能不足、防火墙调解、维护和升级[63]。通过少量规划和一些好的技术，数据集成问题可以快速解决，云存储系统也变得显而易见。

**11.3 计算效率**

在将数据外包到云存储服务器之前，所有数据完整性技术都会对信息进行预处理。同样，云存储服务器会从原始数据中创建元数据。执行此类处理的费用可能会降低数据完整性算法的计算效果。对于小型数据集，预处理阶段的计算效率无关紧要，但对于大型数据集，它具有重要影响。用户检查外包数据准确性的频率受限于服务器端创建证明的处理成本。数据完整性方案中元数据原语的使用也会影响计算时间。

**11.4 基础设施问题**

大量数据需要基础设施和空间来存储，这通常意味着购买最先进的服务器，这些服务器将占用办公室或设施中的大量空间。最简单的解决方案之一是采用云托管和云存储，利用另一家企业的基础设施来节省空间并免去自行设置的麻烦。

**11.5 高能耗问题**

科学计算、商业应用和其他应用领域对性能有持续改进的需求，在部署云存储系统时必须加以考虑[91]。高能耗的原因包括设备的冷却目的和向整个基础设施传输电力[90]。服务器消耗的能源占云数据中心总消耗的70%。然而，这种改进增加了能耗限制。根据亚马逊的数据，面向云的存储服务器能耗成本为47%，冷却基础设施为23%，网络设备为21%，其余9%为其他。因此，目标是最大限度地减少所有面向云的存储系统的总功耗。存储系统中的能耗主要来自服务器、网络设备和磁盘存储的计算。

**11.6 管理数据一致性和数据复制的复杂性**

在分布式数据复制系统中，维持多个对称节点之间的数据一致性比在集中式系统中要复杂得多。另一个主要问题是确保一致性的同时平衡读写操作的成本。为解决此问题，已提出了多种协议。但这些协议在某些层面上解决了问题，如网络分区、节点故障、一致性模型之间的权衡和复杂拓扑。因此，我们需要一种有效的方法来解决这个问题，同时保持读写操作成本均衡[65]。

**11.7 正常操作中的数据丢失**

网络通信和其他相关问题始终与分布式环境相关。同样，云计算中的数据复制和管理系统也面临着相同的挑战。必须建立可靠的通信通道，以确保数据可用并避免正常操作中的数据丢失。在开发组通信协议方面已进行了大量研究。数据复制需要可靠的全序多播以确保有序的副本更新，而组通信的存在限制了可扩展性。此外，组通信层使网络配置和调优变得复杂[1, 24]。

**12 结论**

在过去几十年中，通过互联网连接的设备和应用产生了大量数据。数据增长的主要原因是计算能力的持续增长以及物联网等近期技术的进步。在本研究中，我们回顾了云存储系统的七个主要元素，包括数据模型、数据一致性、数据复制、数据可扩展性、数据集成、数据虚拟化和数据事务。本研究为每个元素提供了额外的思维导图及其组件展示。我们对每个元素进行了深入研究，包括合适的图表和示例。在对数据建模的不同方面进行回溯研究后，我们发现了大量已被一些权威来源分析的主要问题。

所有这些问题都必须得到解决，才能进一步开展研究工作。主要的是，我们观察到数据一致性、数据集成和数据虚拟化存在若干问题，这些问题已在相应章节中列明。现有的数据一致性算法和协议对于超大型存储数据库来说是不够的。基于同样的原因，应该实施一些高效且经过优化的方法。研究工作必须集中于这些问题，并开发出有效的技术。