自动升级为 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。迁移从流量非常低的数据库开始,并且将在未来几个月内扩展到流量更高的数据库。

事务中的查询必须是祖先查询。如需了解详情,请参阅“对乐并发组的乐观做法”部分

自动升级为 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 的默认行为,即提交后异步写入数据)。

此阶段的目的是升级前显示在 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 支持三种并发模式:

  • 乐观

    对于 Datastore 模式 Firestore 中的事务,大多数旧版 Cloud Datastore 数据库都将使用乐观并发处理。乐观并发可以在旧版 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 阶段的日志来查找并发模式。

使用并发实例组模式时保持乐观

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

  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 实体页面中将会显示一个信息横幅。此横幅包含用于打开 Cloud Logging 的链接和获取迁移更新的过滤器。

转到 Datastore 实体

在 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 指标