Cloud Firestore 的位置

预配 Cloud Firestore 实例时，您必须为该实例选择位置。为减少延迟并提高可用性，请将您的数据存储在需要这些数据的用户和服务附近。

如果您的项目使用的是随用随付 Blaze 定价方案，则可以选择在项目中创建多个数据库，每个数据库都有自己的位置设置。

请注意，预配数据库实例后，您将无法更改其位置设置。

位置类型

您可以将 Cloud Firestore 数据存储在多区域位置或单区域位置。

多区域位置

如果您想要最大限度地提高数据库的可用性和耐用性，请选择多区域位置。

多区域位置由一组定义的区域（其中存储了数据库的多个副本）组成。每个副本要么是包含数据库中所有数据的读写副本，要么是不保留全部数据但参与复制的见证者副本。

通过在多个区域之间复制数据，即使整个区域丢失，系统也能继续传送数据。在一个区域内，数据会跨可用区复制，因此，即使可用区丢失，系统也能继续在该区域内传送数据。

Cloud Firestore 支持以下多区域位置：

多区域名称 多区域说明 读写区域 见证者区域
eur3 欧洲 europe-west1（比利时）、europe-west4（荷兰） europe-north1（芬兰）
nam5 美国 us-central1（爱荷华）、us-central2（俄克拉荷马 - 不公开的 GCP 区域） us-east1（南卡罗来纳）

请注意，如果您的项目已有位置为 us-central 或 europe-west 的 App Engine 应用，则您的默认 Cloud Firestore 数据库将被视为多区域数据库。

单区域位置

单区域位置是具体的地理位置，如南卡罗来纳州。单区域位置中的数据会复制到单个区域内的多个可用区。每个单区域位置与其他单区域位置至少相隔 100 英里。

如果您的应用对延迟较敏感，或者您想要与其他 Google Cloud 资源共用位置，请选择单区域位置以降低成本和写入延迟。

Cloud Firestore 支持以下区域级资源位置：

区域名称区域说明
北美洲
us-west1俄勒冈
us-west2洛杉矶
us-west3盐湖城
us-west4拉斯维加斯

us-central1

 艾奥瓦
northamerica-northeast1蒙特利尔

northamerica-northeast2

 多伦多

northamerica-south1

 克雷塔罗
us-east1南卡罗来纳
us-east4北弗吉尼亚

us-east5

 哥伦布

us-south1

 达拉斯
南美洲

southamerica-west1

 圣地亚哥
southamerica-east1圣保罗
欧洲
europe-west2伦敦

europe-west1

 比利时

europe-west4

 荷兰

europe-west8

 米兰

europe-southwest1

 马德里

europe-west9

 巴黎

europe-west12

 都灵

europe-west10

 柏林
europe-west3法兰克福

europe-north1

 芬兰
europe-central2华沙
europe-west6苏黎世
中东

me-central1

 多哈

me-central2

 Dammam

me-west1

 特拉维夫
亚洲
asia-south1孟买

asia-south2

 德里
asia-southeast1新加坡
asia-southeast2雅加达
asia-east2香港
asia-east1台湾
asia-northeast1东京
asia-northeast2大阪
asia-northeast3首尔
澳大利亚
australia-southeast1悉尼

australia-southeast2

 墨尔本
非洲

africa-south1

 约翰内斯堡

位置 SLA

您的 Cloud Firestore 位置类型决定了服务等级协议 (SLA) 正常运行时间百分比：

涵盖的服务 每月正常运行时间百分比
Cloud Firestore 多区域 >= 99.999%
Cloud Firestore 区域级 >= 99.99%

位置价格

您的 Cloud Firestore 位置决定了数据库操作的费用。

如需了解每个区域和每个区域类型的定价的全面说明，请参阅了解 Cloud Firestore 计费方式。

查看数据库的位置

在 Firebase 控制台中，前往“Cloud Firestore 数据”标签页，查看数据库实例及其位置的列表。

由于“默认 Google Cloud 资源的位置”而可能存在的位置依赖关系

“默认 Google Cloud 资源的位置”是指与 Google App Engine 关联的所有项目资源的位置设置，包括以下内容：

  • 默认的 Cloud Firestore 数据库实例
  • Firebase 存储桶的默认 Cloud Storage，其名称格式为 *.appspot.com
  • Google Cloud Scheduler，专门用于第 1 代预定函数

此“默认 Google Cloud 资源的位置”设置不可更改。此外，当您为某个关联资源设置位置时，由于这些关联资源与 App Engine 共同关联，您会间接地为所有资源设置位置。

不过，Firebase 和 Google Cloud 生态系统在过去几年发生了许多变化，资源与 App Engine 的关联也随之不断发生变化。最值得注意的是，从 2024 年 10 月 30 日开始，所有新配置的 Firebase 存储桶的默认 Cloud Storage 的名称格式都为 *.firebasestorage.app，并且不与 App Engine 相关联。

以下是可能的位置依赖项中发生变化的详细信息：

  • 从 2024 年 10 月 30 日开始，如果默认 Cloud Firestore 实例和 Firebase 存储桶的默认 Cloud Storage 尚未配置，则：

    • 预配默认的 Cloud Firestore 实例会为项目中日后预配的任何 App Engine 应用设置位置。不过，它不会决定未来默认 Cloud Storage 存储桶的位置。

    • 配置默认的 Cloud Storage 存储桶不再会配置 App Engine 应用。因此，默认 Cloud Storage 存储桶的位置不会决定未来默认 Cloud Firestore 实例的位置。

  • 从 2024 年 10 月 30 日开始，如果默认 Cloud Firestore 实例已配置，但 Firebase 存储桶的默认 Cloud Storage 尚未配置：

    • 现有的默认 Cloud Firestore 实例不会决定未来默认 Cloud Storage 存储桶的位置 (*.firebasestorage.app)。

  • 从 2024 年 10 月 30 日开始，如果 Firebase 存储桶的默认 Cloud Storage 已配置（具体而言，是 *.appspot.com 存储桶），但默认 Cloud Firestore 实例未配置：

    • 在配置默认 Cloud Storage 存储桶 (*.appspot.com) 时，还配置了 App Engine 应用，因此当时就设置了未来默认 Cloud Firestore 实例的位置。即使您删除了 *.appspot.com 存储桶，也无法删除 App Engine 应用，因此未来默认 Cloud Firestore 实例的位置设置已设置。

如果您使用的是第 1 代预定函数，则其位置会设置为默认 Google Cloud 资源的位置。这是因为 Cloud Scheduler 和 App Engine 之前相互关联。此外，如果您在预配共用此位置信息设置的其他资源之前设置了第 1 代预定函数，那么您也需要设置其位置信息。

请注意，如果您有位置为 us-central 或 europe-west 的 App Engine 应用，则默认 Google Cloud 资源的位置将被视为多区域。

后续步骤

  • 如需详细了解如何构建应用以满足您的延迟、可用性和耐用性要求，请参阅地理位置和区域。