自动升级为 Firestore

本页面介绍了从旧版 Cloud Datastore 升级到 Datastore 模式 Firestore 的升级路径。

Firestore 可以在 Datastore 模式下运行,因而能够向后兼容旧版 Cloud Datastore。借助 Datastore 模式 Firestore,您可以访问 Firestore 经过改进的存储层,同时保留 Datastore 的系统行为。Datastore 模式的 Firestore 去除了以下旧版 Cloud Datastore 限制:

  • 查询不再具有最终一致性。除非您明确请求最终一致性,否则查询将变得高度一致。
  • 事务中的查询不再需要是祖先查询1
  • 事务不再局限于 25 个实体群组1
  • 对实体组的写入操作不再局限于每秒 1 次1

如需详细了解 Datastore 模式,请参阅 Datastore 模式 Firestore

自 2021 年 6 月起,我们已开始从旧版 Cloud Datastore 迁移到 Datastore 模式 Firestore。迁移从流量非常低的数据库开始,并且将在未来几个月内扩展到流量更高的数据库。

1 迁移到“使用实体群组乐观”并发模式的数据库仍需要遵循 25 个实体组的事务限制以及 Datastore 模式 Firestore 的每秒写入次数限制(1 次)。事务中的查询必须是祖先查询。如需了解详情,请参阅“对实体群组的乐观并发模式”部分

自动升级为 Datastore 模式 Firestore

如果您管理的是使用旧版 Cloud Datastore 的应用,则无需更新应用代码。届时我们将通知您,以便安排将您的应用升级为 Datastore 模式 Firestore。升级不需要停机。

如果您对自动升级流程还有其他疑问,请通过支持渠道与我们联系。

查看数据库类型

您可以使用 gcloud alpha firestore databases describe 命令查看数据库类型。在输出中查找是否存在 type 字段:

  • type: DATASTORE_MODE

    数据库类型为 Datastore 模式 Firestore。它不需要升级或已完成升级。

  • 输出中不存在“type

    数据库类型为旧版 Cloud Datastore。该数据库将升级到 Datastore 模式 Firestore。

  • type: FIRESTORE_NATIVE

    数据库类型为原生模式下的 Firestore。

升级阶段

概括来讲,我们将按照此过程将您的旧版 Cloud Datastore 数据库升级为 Datastore 模式的 Firestore。此过程不需要应用停机时间:

  1. 将新的 Datastore 模式 Firestore 数据副本添加到现有的旧版 Cloud Datastore 数据库中。将实体写入操作异步复制到 Datastore 模式 Firestore。

  2. 将现有数据和索引条目从旧版 Cloud Datastore 复制到 Datastore 模式 Firestore。复制后,验证该数据。

  3. 将实体读取操作直接重定向到 Datastore 模式 Firestore。首先重定向最终一致的读取,然后重定向高度一致的读取。

  4. 将实体写入和事务读取直接重定向到 Datastore 模式 Firestore。

此过程包含以下阶段。

1. 同步应用写入

在此阶段,写入会同步应用到旧版 Cloud Datastore:在对实体和索引的所有更改均已应用到至少一个副本之前,写入操作不会报告成功。这会模拟 Datastore 模式下的 Firestore 的行为,该行为也会同步应用写入(这与旧版 Cloud Datastore 的默认行为不同,在旧版 Cloud Datastore 中,写入在提交后会异步应用)。

此阶段的目的是升级前显示在 Datastore 模式 Firestore 中同步应用的任何延迟影响。在迁移期间和迁移之后,同步应用写入将继续。

活动极少的数据库会跳过此阶段。如需确定数据库的升级是否已包含此阶段,请检查 APPLY_WRITES_SYNCHRONOUSLY 阶段的 [日志]。

2. 复制并验证

此阶段表示迁移的开始。此阶段引入了 Datastore 模式 Firestore 副本并执行以下步骤:

  1. 日志

    对旧版 Cloud Datastore 的实体写入操作也开始通过边信道流向 Datastore 模式 Firestore 副本。此过程是旧版 Cloud Datastore 现有复制系统的一部分。这些写入操作不会影响写入延迟时间。Datastore 模式 Firestore 副本会缓冲这些写入操作,以在复制步骤完成后应用。

  2. 复制

    在 Datastore 模式 Firestore 副本中,创建现有数据和索引条目的离线副本。复制步骤不会影响旧版 Cloud Datastore 操作。此步骤可能持续几天。

  3. 排空日志

    将来自日志步骤的写入应用到离线副本的数据。

  4. 验证数据

    通过与旧版 Cloud Datastore 中的数据进行比较,重新验证 Datastore 模式 Firestore 中的数据。

3. 重定向最终一致性读取

从 Datastore 模式 Firestore 处理最终一致的读取(没有祖先实体过滤条件的查询)。此时,读取的旧版 Cloud Datastore 语义仍然适用:

  • 祖先查询具有高度一致性。
  • 非祖先查询具有最终一致性。
  • 查询具有高度一致性(明确配置以进行最终一致性的查询除外)。

Datastore 模式 Firestore 将继续充当旧版 Cloud Datastore 数据的副本。

4.重定向高度一致性读取

从 Datastore 模式 Firestore 提供高度一致性(非事务性)读取。请注意,旧版 Cloud Datastore 的读取语义仍然适用。虽然读取现在直接来自 Firestore,但 Firestore 仍然依赖旧版 Cloud Datastore 来保证数据处于最新状态,以实现高度一致的读取。

5. 重定向写入

将实体写入和事务读取重定向到 Datastore 模式 Firestore。针对同一实体进行的并发修改将继续导致事务中止。对同一实体组中不同实体的并发修改不再导致事务中止。

在此阶段开始时,Datastore 模式 Firestore 仍然依赖于旧版 Cloud Datastore,以确保每次写入前都处于最新状态。通过确保先前的所有写入都得到应用的最终通过后,Datastore 模式 Firestore 会停止查询旧版 Cloud Datastore。

6. 迁移已完成

现在,用于读取操作的 Datastore 模式 Firestore 的语义均适用:所有查询均具有高度一致性。

价格保持不变,但您的结算现在会列出 Firestore SKU。“App Engine 配额”页面开始显示 Firestore 用量,而不是旧版 Cloud Datastore 用量。

事务

Datastore 模式 Firestore 支持三种并发模式:

  • 乐观

    大多数旧版 Cloud Datastore 数据库都将对 Datastore 模式 Firestore 中的事务使用乐观并发控制。乐观并发控制保留了旧版 Cloud Datastore 中事务的现有行为。

  • 对实体群组持乐观态度

    依赖实例组事务语义的数据库将迁移到此并发模式。如需了解详情,请参阅“对实体组并发模式的乐观性”部分

  • 悲观

    之前迁移的一些活动极少的数据库,迁移时对 Datastore 模式 Firestore 中的事务使用悲观锁

您可以通过 Firestore projects.databases REST 资源访问并发模式:

curl -X GET -H "Authorization: Bearer "$(gcloud auth print-access-token) \
"https://firestore.googleapis.com/v1/projects/PROJECT_ID/databases"

您还可以通过检查 PREPARE 阶段的日志找到并发模式。

乐观使用实体群组并发模式

如需消除使用实体群组查询、事务和写入吞吐量的“乐观”限制,请将项目的并发模式更改为“乐观”。为确保此更改与您的项目兼容,请执行以下操作:

  1. 在 Datastore 模式下的 Firestore 中创建测试项目。

  2. 请将测试项目的并发模式更改为 OPTIMISTIC。发出 HTTP PATCH 请求,如下所示。

  3. 对测试项目运行测试,以确保工作负载在没有实体群组的情况下按预期运行。

  4. 将主项目的并发模式从 OPTIMISTIC_WITH_ENTITY_GROUPS 更改为 OPTIMISTIC

用于更改数据库并发模式的 HTTP PATCH 请求:

curl --request PATCH \
--header "Authorization: Bearer "$(gcloud auth print-access-token) \
--header 'Accept: application/json' \
--header 'Content-Type: application/json' \
--data '{"concurrencyMode":"OPTIMISTIC"}' \
"https://firestore.googleapis.com/v1/projects/PROJECT_ID/databases/(default)?updateMask=concurrencyMode"

日志记录和进度通知

升级过程使用 Cloud Logging 发布进度更新。如需查看这些日志,请使用日志浏览器Cloud Logging APIGoogle Cloud CLI

更新会发布到 datastore.googleapis.com 日志记录服务名称下的两条日志

日志名称 受监控的资源 载荷
migration_state datastore_database type.googleapis.com/google.datastore.admin.v1.MigrationStateEvent
migration_progress datastore_database type.googleapis.com/google.datastore.admin.v1.MigrationProgressEvent

如果升级的整体状态(RUNNINGCOMPLETE)发生变化,则 migration_state 日志会更新。

每次升级进入新阶段(PREPARESTARTAPPLY_WRITES_SYNCHRONOUSLYCOPY_AND_VERIFYREDIRECT_EVENTUALLY_CONSISTENT_READSREDIRECT_STRONGLY_CONSISTENT_READSREDIRECT_WRITES)时,migration_progress 日志即会更新。

如需在升级过程中接收通知,您可以根据两个日志创建基于日志的指标,并根据这些指标创建提醒

Google Cloud 控制台中的迁移横幅

在迁移过程中,当您的旧版 Cloud Datastore 数据库处于迁移阶段时,Google Cloud 控制台的 Datastore Studio 页面中将显示一个信息横幅。此横幅包含用于打开 Cloud Logging 的链接和获取迁移更新的过滤器。

  1. 在 Google Cloud 控制台中,转到数据库页面。

    前往“数据库”

  2. 从数据库列表中选择所需的数据库。

  3. 在导航菜单中,点击 Datastore Studio

在 CLI 上查看当前状态

如需快速查看迁移的当前状态,请使用以下 gcloud 命令:

gcloud datastore operations describe datastore-firestore-migration

正在暂停迁移

大型数据库迁移可以暂停和恢复。暂停迁移会阻止其进入下一阶段,直到它恢复为止。暂停迁移可能有助于您确定观察到的行为或性能变化是由迁移过程还是无关因素导致的。

收到有关数据库迁移的电子邮件通知后,您可以运行下面的暂停命令,检查数据库是否可以暂停和恢复。如果迁移不符合条件,则将返回错误,表明相应功能不可用。

如果数据库的迁移可以暂停和恢复,则在迁移达到 START 阶段后,以下命令即会开始生效。

要暂停迁移,请执行以下操作:

curl --request POST \
--header "Authorization: Bearer "$(gcloud auth print-access-token) \
--header 'Accept: application/json' \
--header 'Content-Type: application/json' \
--data '{}' \
"https://datastore.googleapis.com/v1/projects/PROJECT_ID:pauseMigration"

如需继续迁移,请执行以下操作:

curl --request POST \
--header "Authorization: Bearer "$(gcloud auth print-access-token) \
--header 'Accept: application/json' \
--header 'Content-Type: application/json' \
--data '{}' \
"https://datastore.googleapis.com/v1/projects/PROJECT_ID:resumeMigration"

迁移完成后,这些命令将不再有效。

如果您需要将迁移暂停超过一周,请通过支持渠道与我们联系。两周后,您的迁移可能会自动继续。

Cloud Monitoring 指标

Datastore 数据库可用的 Cloud Monitoring 指标在整个升级过程中保持不变,请参阅可用的 Datastore 指标