查看了Firebase文档，对于选择Firestore和云功能的位置，仍然有一些问题

因此，我的大多数用户应该在印度，这就是为什么我考虑选择Asia-South1作为我的Firestore地点。但是，我收到了以下警告：

云功能客户注意：将功能部署到此位置尚不可用。如果您的功能和云Firestore位于不同的位置，那么您可能会体验到延迟和计费成本的增加

现在，文档告诉我，asia-east2是功能最接近的区域

在这方面，我有以下问题：

“云功能客户须知”是指谷歌云功能还是Firebase云功能---我只希望在我的项目中使用Firebase云函数

如果我选择asia-east2作为我的云Firestore的位置，而我的大多数用户都在asia-south1，这是否意味着我要付出额外的成本？由于我将节省因您的存储位置与云功能位置不同而产生的出口成本，因此我希望能够在这里进行成本效益分析

对于一个不执行太多或太重的云功能的简单应用程序，您更愿意建议：

a。设置2个不同的位置-将我的用户群体位置设置为云Firestore位置，将最近的云功能可用位置设置为Firebase云功能的位置

或

---

B.将两个位置都设置为最近的云功能可用位置，而不是我的用户位置。

对于任一平台上的云功能（它们几乎相同，但配置不同），您将根据调用这些功能的次数以及资源成本（内存和CPU）收费执行这些功能（当您超过任何值时）

通过将Firestore位置设置为

asia-south1

并从

asia-east2

中的云功能访问，您将获得这两个数据中心位置之间往返时间的费用（如适用）——即使云功能只是在等待响应

最终，什么最适合你完全取决于你试图做什么。以下是一些大致的分类，为您指明了正确的方向：

如果您的应用程序对成本敏感而非时间敏感，请在

asia-east2

中对功能和Firestore部署进行合并

如果您的应用程序在客户端对时间非常敏感，并且云功能的使用率非常低，您可以在两个数据中心之间拆分这两个数据中心，但准备对往返时间收费。您可以通过使用批处理写入和节省使用事务来减少网络跳数，同时还可以预期延迟和重试

如果您的应用程序在客户端对时间敏感，但云功能使用率高到足以超过免费使用限制，请在

asia-east2

中对功能和云Firestore部署进行分类

笔记：

• 完全取决于数据结构和云功能的功能，切分数据并维护两个云Firestore实例可能是有益的—一个位于

  asia-east2

  中，供以云功能为中心的操作使用，另一个位于

  asia-south1

  中，用于云功能很少使用的以客户为中心的数据

• Firebase还提供了一个可用于估算每月成本的方法。尤其重要的是网络（出口）成本，因为不清楚数据中心到数据中心的成本是否会增加这一成本

• 您还可以提交一个添加

  asia-south1

  作为受支持的云功能区域，他们可以将其传递给相关团队