你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
了解数据存储模型
现代业务系统管理越来越多的异类数据。 这种异质性意味着单个数据存储通常不是最佳方法。 相反，最好在不同的数据存储中存储不同类型的数据，每个数据存储都侧重于特定的工作负荷或使用模式。 术语 多语言持久性 用于描述采用多种数据存储技术的解决方案。 因此，了解主要存储模型及其权衡非常重要。
为要求选择正确的数据存储是一个关键的设计决策。 从 SQL 和 NoSQL 数据库中进行选择，确实有数百种实现方案可供选择。 数据存储通常按其结构数据和支持的操作类型进行分类。 本文介绍几种最常见的存储模型。 请注意，特定的数据存储技术可能支持多个存储模型。 例如，关系数据库管理系统（RDBMS）还可能支持键/值或图形存储。 事实上，所谓的 多模型 支持的一般趋势是，单一数据库系统支持多个模型。 但是，在高级别上了解不同的模型仍然很有用。
并非给定类别中的所有数据存储都提供相同的功能集。 大多数数据存储都提供服务器端功能来查询和处理数据。 有时，此功能内置于数据存储引擎中。 在其他情况下，数据存储和处理功能是分开的，并且可能有几种处理和分析选项。 数据存储还支持不同的编程和管理接口。
通常，应首先考虑哪种存储模型最适合你的要求。 然后，根据功能集、成本和易于管理等因素，考虑该类别中的特定数据存储。
注意
若要详细了解如何确定和审查云采用的数据服务要求，请参阅适用于 Azure 的 Microsoft 云采用框架。 同样，你还可以了解选择存储工具和服务。
关系数据库管理系统
关系数据库将数据组织为包含行和列的一系列二维表。 大多数供应商提供结构化查询语言（SQL）的方言来检索和管理数据。 RDBMS 通常实现符合 ACID（Atomic、Consistent、Isolated、Durable）模型的事务一致性机制，用于更新信息。
RDBMS 通常支持架构写入模型，其中数据结构是提前定义的，并且所有读取或写入操作都必须使用架构。
当强大的一致性保证非常重要时，此模型非常有用，其中所有更改都是原子的，事务始终使数据保持一致状态。 但是，RDBMS 通常无法横向扩展，除非以某种方式分片数据。 此外，RDBMS 中的数据必须规范化，这不适用于每个数据集。
Azure 服务
- Azure SQL 数据库 | （安全基线）
- Azure Database for MySQL | （安全基线）
- Azure Database for PostgreSQL | （安全基线）
- Azure Database for MariaDB | （安全基线）
工作量
- 经常创建和更新记录。
- 多个操作必须在单个事务中完成。
- 使用数据库约束强制实施关系。
- 使用索引来优化查询性能。
数据类型
- 数据高度规范化。
- 需要并强制实施数据库架构。
- 数据库中数据实体之间的多对多关系。
- 约束在架构中定义，并对数据库中的任何数据施加。
- 数据需要高完整性。 索引和关系需要准确地维护。
- 数据需要高度一致性。 事务的运行方式将确保所有数据对于所有用户和进程而言都 100% 一致。
- 单个数据条目的大小为小到中型。
例子
- 清单管理
- 订单管理
- 报表数据库
- 会计学
键/值存储
键/值存储将每个数据值与唯一键相关联。 大多数键/值存储仅支持简单的查询、插入和删除操作。 要修改一个值（无论是部分还是全部），应用程序必须覆盖这个值的整个现有数据。 在大多数实现中，读取或写入单个值是原子操作。
应用程序可以将任意数据存储为一组值。 应用程序必须提供所有架构信息。 键/值存储只是根据键检索或存储值。
键/值存储针对执行简单查找的应用程序进行高度优化，但如果需要跨不同的键/值存储查询数据，则不太合适。 键/值存储也未针对按值查询进行优化。
单个键/值存储可以极其可缩放，因为数据存储可以轻松地在单独的计算机上的多个节点上分布数据。
Azure 服务
- Azure Cosmos DB for Table 和 Azure Cosmos DB for NoSQL | （Azure Cosmos DB 安全基线）
- Azure Redis 缓存 | （安全基线）
- Azure 表存储 | （安全基线）
工作量
- 使用单个键（如字典）访问数据。
- 不需要使用联接、锁定或联合。
- 不使用聚合机制。
- 通常不使用辅助索引。
数据类型
- 每个键都与单个值相关联。
- 未实施架构。
- 实体之间没有关系。
例子
- 数据缓存
- 会话管理
- 用户首选项和用户资料管理
- 产品推荐和广告服务
文档数据库
文档数据库存储文档的集合，其中每个文档由命名字段和数据组成。 数据可以是简单值或复杂元素，例如列表和子集合。 文档由唯一键检索。
通常，文档包含单个实体的数据，例如客户或订单。 文档可能包含将分布在 RDBMS 中的多个关系表中的信息。 文档不需要具有相同的结构。 随着业务需求的变化，应用程序可以将不同的数据存储在文档中。
文档存储的关系图 
Azure 服务
工作量
- 插入和更新操作很常见。
- 没有对象关系阻抗不匹配。 文档可以更好地匹配应用程序代码中使用的对象结构。
- 单个文档将作为单个块进行检索和写入。
- 数据需要对多个字段编制索引。
数据类型
- 数据可以以非规范化的方式进行管理。
- 单个文档数据的大小相对较小。
- 每个文档类型都可以使用自己的架构。
- 文档可以包含可选字段。
- 文档数据是半结构化的，这意味着不严格定义每个字段的数据类型。
例子
- 产品目录
- 内容管理
- 清单管理
图形数据库
图形数据库存储两种类型的信息、节点和边缘。 边缘指定节点之间的关系。 节点和边缘可以具有提供有关该节点或边缘的信息的属性，类似于表中的列。 边缘还可以包含一个方向用于指示关系的性质。
图形数据库可以有效地跨节点和边缘网络执行查询，并分析实体之间的关系。 下图显示了组织以图形的形式构建的人员数据库。 实体是员工和部门，边缘表示报告关系以及员工工作所在的部门。
通过此结构，可以直接执行查询，例如“查找直接或间接向 Sarah 报告的所有员工”或“谁与 John 在同一部门工作？”对于具有大量实体和关系的大型图，可以快速执行非常复杂的分析。 许多图形数据库提供了一种查询语言，可用于高效遍历关系网络。
Azure 服务
工作量
- 数据项之间的关系非常复杂，涉及相关数据项之间的许多跃点。
- 数据项之间的关系是动态的，随时间而变化。
- 对象之间的关系是头等关系，不需要使用外键和联接进行遍历。
数据类型
- 节点和关系。
- 节点类似于表行或 JSON 文档。
- 关系与节点一样重要，并且直接在查询语言中公开。
- 复合对象（如具有多个电话号码的人员）往往被分解为单独的较小节点，并通过可遍历的关系结合在一起。
例子
- 组织结构图
- 社交关系图
- 欺诈检测
- 推荐引擎
数据分析
数据分析存储提供大规模并行解决方案，用于引入、存储和分析数据。 数据分布在多个服务器上，以最大程度地提高可伸缩性。 大型数据文件格式（如分隔符文件（CSV）、parquet和 ORC）在数据分析中广泛使用。 历史数据通常存储在 Blob 存储或 Azure Data Lake Storage Gen2等数据存储中，然后由 Azure Synapse、Databricks 或 HDInsight 作为外部表进行访问。 有关使用存储为 parquet 文件的数据来提高性能的典型方案，请参阅文章将外部表与 Synapse SQL 结合使用。
Azure 服务
- Azure Synapse Analytics | （安全基线）
- Azure Data Lake | （安全基线）
- Azure 数据资源管理器 | （安全基线）
- Azure Analysis Services
- HDInsight | （安全基线）
- Azure Databricks | （安全基线）
工作量
- 数据分析
- 企业 BI
数据类型
- 来自多个源的历史数据。
- 通常是非规范化的，采用“星型”或“雪花型”架构，包含事实数据表和维度表。
- 通常按计划加载新数据。
- 维度表通常包括实体的多个历史版本，称为 渐变维度。
例子
- 企业数据仓库
列系列数据库
列系列数据库将数据组织成行与列。 最简单的形式是，列系列数据库看起来与关系数据库非常相似，至少从概念上讲。 列系列数据库的真正强大之处在于，它能够以非规范化方式将稀疏数据结构化。
可以将列系列数据库视为包含行和列的表格数据，但这些列分为称为 列系列的组。 每个列系列保存一组在逻辑上相关的列，通常作为一个单元进行检索或操作。 其他单独访问的数据可以存储在单独的列系列中。 在列系列中，可以动态添加新列，行可以稀疏（也就是说，行不需要为每个列提供值）。
下图显示了一个包含两个列系列（Identity 和 Contact Info）的示例。 在每个列系列中，单个实体的数据具有相同的行键。 这种结构，其中列系列中任何给定对象的行可以动态变化，是列系列方法的重要优势，使得这种形式的数据存储非常适用于存储结构化、易失性数据。
列族数据库关系图
与键/值存储或文档数据库不同，大多数列系列数据库按键顺序存储数据，而不是通过计算哈希。 许多实现允许在列系列中的特定列上创建索引。 索引允许按列值而不是行键检索数据。
针对行执行的读取和写入操作通常是对单个列系列执行的原子操作，不过，某些实现可提供跨多个列系列的整行读写原子性。
Azure 服务
工作量
- 大多数列系列数据库执行写入操作的速度非常快。
- 更新和删除操作很少见。
- 旨在提供高吞吐量和低延迟访问。
- 支持对较大记录中特定字段集的轻松查询访问。
- 可大规模缩放。
数据类型
- 数据存储在由键列和一个或多个列系列组成的表中。
- 具体的列可能因各个行而异。
- 可通过 get 和 put 命令访问单个单元格
- 使用扫描命令返回多行数据。
例子
- 建议
- 个性化
- 传感器数据
- 遥测
- Messaging
- 社交媒体分析
- Web analytics
- 活动监测
- 天气和其他时序数据
搜索引擎数据库
搜索引擎数据库允许应用程序搜索外部数据存储中保存的信息。 搜索引擎数据库可以为大量数据编制索引，并提供对这些索引的近实时访问。
索引可以是多维的，并且可能支持跨大量文本数据的自由文本搜索。 可以使用由搜索引擎数据库触发的拉取模型或者使用由外部应用程序代码启动的推送模型来执行索引编制。
搜索可能精确或模糊。 模糊搜索查找与一组字词匹配的文档，并计算它们匹配程度。 某些搜索引擎还支持语言分析，可以基于同义词、类别扩展（例如将 dogs 匹配到 pets）以及词干分析（匹配具有相同词根的词）返回匹配项。
Azure 服务
工作量
- 来自多个源和服务的数据索引。
- 查询是临时的，可以很复杂。
- 全文搜索是必需的。
- 即席自助查询是必需的。
数据类型
- 半结构化或非结构化文本
- 引用结构化数据的文本
例子
- 产品目录
- 站点搜索
- 日志记录
时序数据库
时序数据是按时间组织的一组值。 时序数据库通常从大量源实时收集大量数据。 更新很少见，删除操作通常作为批量操作执行。 虽然写入时序数据库的记录通常很小，但通常有很多记录，并且总数据大小可以迅速增长。
Azure 服务
工作量
- 记录通常按时间顺序追加。
- 绝大部分 (95-99%) 的操作是写入。
- 更新很少见。
- 删除会批量发生，并针对连续块或记录进行。
- 数据按升序或降序顺序按顺序读取，通常并行读取。
数据类型
- 时间戳用作主键和排序机制。
- 标记可以定义有关该条目的类型、源和其他信息的其他信息。
例子
- 监控和事件遥测。
- 传感器或其他 IoT 数据。
对象存储
对象存储针对存储和检索大型二进制对象（图像、文件、视频和音频流、大型应用程序数据对象和文档、虚拟机磁盘映像）进行优化。 此模型中还经常使用大型数据文件，例如分隔符文件（CSV）、parquet，以及 ORC。 对象存储可以管理极其大量的非结构化数据。
Azure 服务
工作量
- 由键进行标识。
- 内容通常是诸如分隔符、图像或视频文件的资产。
- 内容必须是持久的，并且独立于任何应用层。
数据类型
- 数据量很大。
- 值是不透明的。
例子
- 图像、视频、Office 文档、PDF
- 静态 HTML、JSON、CSS
- 日志和审核文件
- 数据库备份
共享文件
有时，使用简单的平面文件可能是存储和检索信息的最有效方法。 使用文件共享可以跨网络访问文件。 鉴于适当的安全性和并发访问控制机制，通过这种方式共享数据可以让分布式服务提供高度可缩放的数据访问，以便执行基本的低级别操作，例如简单的读取和写入请求。
Azure 服务
工作量
- 从与文件系统交互的现有应用迁移。
- 需要 SMB 接口。
数据类型
- 一组分层文件夹中的文件。
- 可以使用标准 I/O 库进行访问。
例子
- 旧文件
- 可在多个 VM 或应用实例之间访问的共享内容
借助这种对不同数据存储模型的理解，下一步是评估工作负荷和应用程序，并确定哪些数据存储将满足你的特定需求。 使用 数据存储决策树 来帮助完成此过程。