在 Azure Cosmos DB for NoSQL 中更改源设计模式

使用 Azure Cosmos DB 更改源，可以高效地处理具有大量写入量的大型数据集。 它提供查询整个数据集以标识更改的替代方法。 本文介绍常见的更改源设计模式、其权衡和限制，以帮助构建可缩放的解决方案。

Scenarios

Azure Cosmos DB 非常适合 IoT、游戏、零售和作日志记录应用程序。 这些应用程序中的一种常见设计模式是使用数据更改来触发其他操作。 这些操作包括：

• 插入、更新或删除项时触发通知或 API 调用。
• 用于 IoT 的实时流处理或作数据的分析。
• 数据移动，例如与缓存、搜索引擎、数据仓库或冷存储进行同步。

Azure Cosmos DB 中的更改源使你可以为这些模式生成高效、可缩放的解决方案，如下图所示：

事件计算和通知

Azure Cosmos DB 更改源简化了触发通知或基于特定事件调用 API 的方案。 使用 更改源处理器 自动轮询容器中的更改，并为每个写入、更新或删除调用外部 API。

有选择地触发通知或基于特定条件调用 API。 例如，如果要使用 Azure Functions 从更改源进行读取，请将逻辑添加到函数，以便仅在满足条件时才发送通知。 尽管 Azure 函数代码针对每个更改执行，但仅当满足条件时才发送通知。

实时流处理

使用 Azure Cosmos DB 更改源可以针对 IoT 执行实时流处理，或对作数据进行实时分析。 例如，从设备、传感器、基础结构和应用程序接收和存储事件数据，并使用 Spark 实时处理这些事件。 下图显示了如何使用 Azure Cosmos DB 更改源实现 lambda 体系结构：

在许多情况下，流处理实现首先会将大量传入数据接收到 Azure 事件中心或 Apache Kafka 等临时消息队列中。 由于 Azure Cosmos DB 能够支持持续较高的数据引入速率，并保证较低的读取和写入延迟，因此，更改源是极佳的替代方案。

数据持久性

写入 Azure Cosmos DB 的数据将显示在更改源中。 在 最新版本模式下，数据将保留在更改源中，直到删除。 消息队列通常具有最长的保留期。 例如，Azure 事件中心提供的最长数据保留期为 90 天。

查询功能

除了从 Azure Cosmos DB 容器的更改源读取外，还要对 Azure Cosmos DB 中存储的数据运行 SQL 查询。 更改源不是对容器中已有的数据进行复制，它只是一种不同的数据读取机制。 因此，如果从更改源中读取数据，数据始终与同一 Azure Cosmos DB 容器的查询一致。

高可用性

Azure Cosmos DB 提供高达 99.999% 读写可用性。 与许多消息队列不同，Azure Cosmos DB 数据可以多区域分布，并使用零的 恢复时间目标（RTO） 进行配置。

在处理更改源中的项后，生成具体化视图并在 Azure Cosmos DB 中保留聚合值。 例如，使用 Azure Cosmos DB 的更改源基于已完成游戏的分数实现实时排行榜。

数据移动

从更改源读取实时数据移动。

例如，更改源允许你有效地执行以下任务：

• 使用 Azure Cosmos DB 中存储的数据更新缓存、搜索索引或数据仓库。

• 零停机迁移到其他 Azure Cosmos DB 帐户或其他具有不同逻辑分区键的 Azure Cosmos DB 容器。

• 实现应用程序级数据分层和存档。 例如，将“热数据”存储在 Azure Cosmos DB 中，将“冷数据”过期到 Azure Blob 存储等其他存储系统。

如果必须反规范化各个分区和容器中的数据，可以从容器的更改源（用作此数据复制操作的源）中读取数据。 具有更改源的实时数据复制仅保证最终一致性。 在 Azure Cosmos DB 容器中处理更改时，可以监视更改源处理器的滞后程度。

事件溯源

事件溯源模式涉及使用仅追加存储来记录对数据的完整动作序列。 在所有数据引入都建模为写入（无更新或删除）的事件溯源体系结构中，Azure Cosmos DB 的更改馈送是作为中心数据存储的理想选择。 在这种情况下，对 Azure Cosmos DB 的每次写入都是一个“事件”，所以更改源中包含以往事件的完整记录。 中心事件存储发布的事件的典型用途是维护具体化视图或者与外部系统集成。 由于更改源中没有保留时间限制，因此可以通过从 Azure Cosmos DB 容器的更改源开头读取，重播所有过去的事件。

可以让多个更改源使用者订阅同一个容器的更改源。 使用更改源只需支付租用容器的预配吞吐量费用，此外不会产生其他费用。 不管是否使用更改源，都会在每个容器中提供更改源。

Azure Cosmos DB 是事件溯源模式中一个出色的仅限中央追加的持久数据存储，因为它在水平可伸缩性和高可用性方面具有优势。 此外，更改源处理器提供 “至少一次” 保证，确保不会错过处理任何事件。

当前限制

更改源具有多个模式，每个模式都有你应该理解的重要限制。 设计在最新版本模式或所有版本和删除模式下使用更改源的应用程序时，需要考虑多个方面。

中间更新

Deletes

保留

保证顺序

所有更改源模式在单个分区键值内（而不是多个分区键值内）具有顺序保证。 应该选择可以提供有意义的顺序保证的分区键。

请考虑使用事件溯源设计模式的零售应用程序。 在此应用程序中，每个不同的用户操作都是一个“事件”，这些事件建模为对 Azure Cosmos DB 的写入。 假设按以下顺序发生了一些示例事件：

1. 客户将商品 A 添加到其购物车。
2. 客户将商品 B 添加到其购物车。
3. 客户从购物车中删除商品 A。
4. 客户结帐，然后卖家寄送购物车内容。

将为每个客户保留当前购物车内容的具体化视图。 此应用程序必须确保按事件的发生顺序处理这些事件。 例如，如果在删除项目 A 之前处理购物车结帐，则可能是将商品 A 寄送到客户，而不是客户想要的项目 B。 为了确保按顺序处理这四个事件，它们应位于同一分区键值内。 如果选择 username（每个客户都有唯一的用户名）作为分区键，则可以保证这些事件按照它们写入到 Azure Cosmos DB 的顺序显示在更改源中。

示例

下面是最新版本模式的实际更改源代码示例，这些示例超出了提供的示例范围：

• 在 更改源简介中了解详细信息。
• 在 以更改源为中心的 IoT 用例中了解详细信息。
• 在 以更改源为中心的零售用例中了解详细信息。

相关内容

• 更改源概述
• 更改源模式
• 读取更改源的选项