你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

了解数据存储模型

  • 项目

现代业务系统必须管理日益庞大的异类数据。 这种异构性意味着单一数据存储通常不是最佳的方案。 相反，更好的做法往往将不同类型的数据存储在不同的数据存储中，每个数据存储专注于处理特定的工作负荷或使用模式。 术语“多语言持久性”用于描述混合使用多种数据存储技术的解决方案。 因此，务必了解主要的存储模型及其权衡。

根据要求选择适当的数据存储是一项关键设计决策。 我们真正可以从数百种 SQL 和 NoSQL 数据库实现中进行选择。 数据存储通常根据它们将数据结构化的方式以及支持的操作类型分类。 本文介绍几种最常见的存储模型。 请注意，某种特定的数据存储技术可能支持多个存储模型。 例如，关系数据库管理系统 (RDBMS) 可能还支持键/值或图形存储。 实际上，行业中出现了一种所谓“多模”支持的总体趋势，即单个数据库系统支持多个模型。 但是，在较高层面上了解不同的模型仍然很有帮助。

并非给定类别中的所有数据存储都提供相同的功能集。 大多数数据存储提供服务器端功能用于查询和处理数据。 有时，此功能已内置在数据存储引擎中。 在其他情况下，数据存储和处理功能是分离的，另外，可能还有一些选项可用于执行处理和分析。 数据存储还支持不同的编程和管理接口。

一般而言，应该先考虑哪种存储模型最符合要求。 然后，根据功能集、成本和易管理性等因素，考虑该类别中的特定数据存储。

注意

若要详细了解如何确定和审查云采用的数据服务要求，请参阅适用于 Azure 的 Microsoft 云采用框架。 同样，你还可以了解选择存储工具和服务。

关系数据库管理系统

关系数据库可将数据组织成一系列包含行与列的二维表。 大多数供应商提供结构化查询语言 (SQL) 的方言用于检索和管理数据。 RDBMS 通常实施一个事务一致性机制，该机制遵守用于更新信息的 ACID（原子性、一致性、隔离性、持久性）模型。

RDBMS 通常支持写时架构模型，其中的数据结构已提前定义，所有读取或写入操作必须使用该架构。

当强一致性保证很重要时，此模型非常有用 - 其中的所有更改都是原子性的，事务始终可让数据保持一致状态。 但是，如果不以某种方式对数据进行分片，RDBMS 通常无法横向扩展。 此外，RDBMS 中的数据必须规范化，这并不适合每个数据集。

Azure 服务

工作负荷

  • 经常创建和更新记录。
  • 多个操作必须在单个事务中完成。
  • 使用数据库约束强制实施关系。
  • 使用索引来优化查询性能。

数据类型

  • 数据是高度规范化的。
  • 数据架构是必需的并强制实施。
  • 数据库中的数据实体之间的多对多关系。
  • 约束是在架构中定义的，并施加于数据库中的任何数据。
  • 数据需要具有高完整性。 索引和关系需要准确地维护。
  • 数据需要具有强一致性。 事务的运行方式将确保所有数据对于所有用户和进程而言都 100% 一致。
  • 各个数据条目的大小为中小型。

示例

  • 库存管理
  • 订单管理
  • 报表数据库
  • 计帐

键/值存储

键/值存储将每个数据值与唯一键相关联。 大多数键/值存储仅支持简单的查询、插入和删除操作。 若要修改某个值（修改一部分或整个值），应用程序必须覆盖整个值的现有数据。 在大多数实现中，读取或写入单个值是原子操作。

应用程序可将任意数据存储为一组值。 应用程序必须提供所有架构信息。 键/值存储只是根据键检索或存储值。

Diagram of a key-value store

键/值存储已针对执行简单查找的应用程序进行高度优化，但不太适合用于需要跨不同键/值存储查询数据的情况。 键/值存储也未针对按值查询进行优化。

单个键/值存储就具有极高的可伸缩性，因为数据存储可在独立计算机上的多个节点之间轻松分配数据。

Azure 服务

工作负荷

  • 使用单个键（例如字典）访问数据。
  • 不需要使用联接、锁定或联合。
  • 不使用聚合机制。
  • 通常不使用辅助索引。

数据类型

  • 每个键都与单个值相关联。
  • 未实施架构。
  • 实体之间没有关系。

示例

  • 数据缓存
  • 会话管理
  • 用户首选项和配置文件管理
  • 产品推荐和广告服务

文档数据库

文档数据库存储文档的集合，其中每个文档由命名字段和数据组成。 数据可以是简单的值，也可以是复杂的元素，例如列表和子集合。 按唯一键检索文档。

通常，文档包含单个实体的数据，例如客户或订单。 文档可以包含要在 RDBMS 中多个关系表之间分散的信息。 文档不需要具有相同的结构。 随着业务需求的变化，应用程序可在文档中存储不同的数据。

Diagram of a document store

Azure 服务

工作负荷

  • 插入和更新操作很常见。
  • 没有对象关系阻抗不匹配。 文档可以更好地匹配应用程序代码中使用的对象结构。
  • 单个文档将作为单个块进行检索和写入。
  • 数据需要基于多个字段编制索引。

数据类型

  • 可以采用非规范化的方式管理数据。
  • 单个文档的数据大小相对较小。
  • 每个文档类型可以使用其自己的架构。
  • 文档可以包括可选字段。
  • 文档数据是半结构化的，这意味着每个字段的数据类型不是严格定义的。

示例

  • 产品目录
  • 内容管理
  • 库存管理

图形数据库

图形数据库存储两种类型的信息：节点和边缘。 边缘指定节点之间的关系。 节点和边缘都可以包含一些属性用于提供有关该节点或边缘的信息（类似于表中的列）。 边缘还可以包含一个方向用于指示关系的性质。

图形数据库可以跨节点和边缘的网络高效地执行查询，并分析实体之间的关系。 下图显示了一个已结构化为图形的组织人员数据库。 实体为员工和部门，边缘指示隶属关系以及员工所在的部门。

Diagram of a document database

这种结构使执行查询变得简单，例如“查找直接或间接向 Sarah 报告的所有员工”或“谁与 John 在同一部门工作？”。对于具有大量实体和关系的大型图表，则可非常快速执行非常复杂的分析。 多个图形数据库提供一种可用于高效遍历关系网络的查询语言。

Azure 服务

工作负荷

  • 数据项之间的关系非常复杂，涉及相关数据项之间的许多跃点。
  • 数据项之间的关系是动态的并且随时间变化。
  • 对象之间的关系是头等关系，不需要使用外键和联接进行遍历。

数据类型

  • 节点和关系。
  • 节点类似于表行或 JSON 文档。
  • 关系与节点同等重要，并且是直接以查询语言公开的。
  • 复合对象（例如具有多个电话号码的人员）通常分解为多个单独的较小节点，这些节点通过可遍历的关系组合在一起

示例

  • 组织结构图
  • 社交关系图
  • 欺诈检测
  • 推荐引擎

数据分析

数据分析存储提供用于引入、存储和分析数据的大规模并行解决方案。 数据分布在多个服务器上，以最大程度地提高可伸缩性。 分隔符文件 (CSV)、parquet 和 ORC 等大型数据文件格式广泛用于数据分析。 历史数据通常存储在数据存储中（例如 blob 存储或 Azure Data Lake Storage Gen2），然后由 Azure Synapse、Databricks 或 HDInsight 作为外部表进行访问。 有关使用存储为 parquet 文件的数据来提高性能的典型方案，请参阅文章将外部表与 Synapse SQL 结合使用。

Azure 服务

工作负荷

  • 数据分析
  • 企业 BI

数据类型

  • 来自多个源的历史数据。
  • 通常是非规范化的，采用“星型”或“雪花型”架构，包含事实数据表和维度表。
  • 通常按计划定期加载新数据。
  • 维度表通常包括实体的多个历史版本，称为渐变维度。

示例

  • 企业数据仓库

列系列数据库

列系列数据库将数据组织成行与列。 最简单形式的列系列数据库可能与关系数据库十分类似，至少在概念上是这样。 列系列数据库的真正强大之处在于，它能够以非规范化方式将稀疏数据结构化。

可将列系列将数据库视为使用行与列保存表格数据，但是，列已分割为称作“列系列”的组。 每个列系列保存一组逻辑相关的、通常以单元形式检索或处理的列。 其他单独访问的数据可存储在单独的列系列中。 在列系列中，可以动态添加新列，行可以稀疏分布（即，行不需要包含每个列的值）。

下图显示了包含两个列系列（Identity 和 Contact Info）的示例。 在每个列系列中，单个实体的数据具有相同的行键。 此结构体现了列系列方法的重要优势，其中的列系列中任意给定对象的行可能动态变化，因此，这种形式的数据存储非常适合用于存储结构化的易失性数据。

Diagram of a column-family database

与键/值存储或文档数据库不同，大多数列系列数据库根据键顺序而不是通过计算哈希来存储数据。 许多实现允许基于列系列中的特定列创建索引。 使用索引可以根据列值而不是行键检索数据。

针对行执行的读取和写入操作通常是对单个列系列执行的原子操作，不过，某些实现可提供跨多个列系列的整行读写原子性。

Azure 服务

工作负荷

  • 大多数列系列数据库都极快地执行写入操作。
  • 更新和删除操作很少发生。
  • 设计用于提供高吞吐量低延迟访问。
  • 支持轻松以查询方式访问非常大的记录中的一组特定字段。
  • 高度可伸缩。

数据类型

  • 数据存储在由一个键列和一个或多个列系列组成的表中。
  • 具体的列可能因各个行而异。
  • 可以通过 get 和 put 命令访问各个单元格
  • 使用扫描命令返回多个行。

示例

  • 建议
  • 个性化
  • 传感器数据
  • 遥测
  • 消息传递
  • 社交媒体分析
  • Web analytics
  • 活动监视
  • 天气和其他时序数据

搜索引擎数据库

搜索引擎数据库允许应用程序搜索外部数据存储中保存的信息。 可以使用搜索引擎数据库为大量数据编制索引，并以接近实时的速度访问这些索引。

索引可以是多维的，且支持跨大量文本数据执行自由文本搜索。 可以使用由搜索引擎数据库触发的拉取模型或者使用由外部应用程序代码启动的推送模型来执行索引编制。

搜索可以采用精确匹配或模糊匹配。 模糊搜索查找与一组字词匹配的文档，并计算它们的匹配程度。 某些搜索引擎还支持语言分析，此功能可根据同义词、类型扩展（例如，将 dogs 与 pets 匹配）和词干（将单词与同一个字根进行匹配）返回匹配结果。

Azure 服务

工作负荷

  • 来自多个源和服务的数据索引。
  • 查询是即席的，可能会很复杂。
  • 全文搜索是必需的。
  • 即席自助查询是必需的。

数据类型

  • 半结构化的或非结构化的文本
  • 其中引用了结构化数据的文本

示例

  • 产品目录
  • 站点搜索
  • 日志记录

时序数据库

时序数据是按时间组织的一组值。 时序数据库通常实时从大量源收集大量数据。 更新极少发生，而删除操作往往以批量操作的形式执行。 尽管写入时序数据库的记录通常较小，但记录数量往往很大，并且总数据大小可能迅速增长。

Azure 服务

工作负荷

  • 记录通常按时间顺序依次追加。
  • 绝大部分 (95-99%) 的操作是写入。
  • 很少进行更新。
  • 删除批量进行，并且针对连续的块或记录执行。
  • 数据按升序或降序时间顺序依次读取，通常以并行方式。

数据类型

  • 时间戳，用作主键和排序机制。
  • 标记，用于定义关于条目的类型、来源和其他信息的附加信息。

示例

  • 监视和事件遥测。
  • 传感器或其他 IoT 数据。

对象存储

经优化的对象存储适合用于存储和检索大型二进制对象（图像、文件、视频和音频流、大型应用程序数据对象和文档、虚拟机磁盘映像）。 此模型中也普遍使用大型数据文件，例如分隔符文件 (CSV)、parquet 和 ORC。 使用对象存储可以管理极大量的非结构化数据。

Azure 服务

工作负荷

  • 由键进行标识。
  • 内容通常是诸如分隔符、图像或视频文件的资产。
  • 内容必须是持久性的，并且位于任何应用程序层的外部。

数据类型

  • 数据大小较大。
  • 值是不透明的。

示例

  • 图像、视频、Office 文档、PDF
  • 静态 HTML、JSON、CSS
  • 日志和审核文件
  • 数据库备份

共享文件

有时，使用简单的平面文件可能是存储和检索信息的最有效方法。 使用文件共享可以跨网络访问文件。 在提供了相应的安全和并发访问控制机制的前提下，以这种方法共享数据可让分布式服务提供高度可缩放的数据访问方式来执行基本的低级别操作，例如简单的读取和写入请求。

Azure 服务

工作负荷

  • 从与文件系统进行交互的现有应用进行迁移。
  • 需要 SMB 接口。

数据类型

  • 一组分层文件夹中的文件。
  • 可以通过标准 I/O 库进行访问。

示例

  • 旧式文件
  • 可以从许多 VM 或应用实例访问的共享内容

了解各种数据存储模型后，下一步是评估工作负载和应用程序，并确定哪种数据存储满足特定需求。 使用数据存储决策树来帮助完成此过程。

后续步骤