通过添加区域来扩展 Firebase 的推荐方法 [关闭]答案

【问题标题】：Recommended way of scaling firebase by adding regions [closed]通过添加区域来扩展 Firebase 的推荐方法 [关闭]
【发布时间】：2019-01-28 08:03:46
【问题描述】：

目前我有 3 个用于应用的 firebase 项目：live、beta、development

这些处理各自的环境并且都在美国区域内。

未来如果应用在全球范围内使用，在欧洲/亚洲+美国推荐的扩展方式是什么？我最初的直觉是创建额外的 firebase 项目，例如 live-eu、live-asia，但我在这里看到了一个问题：

这些项目可以使用我的美国项目当前使用的相同应用 ID 吗？我无法从美国项目导入数据，因为它有 uid's 在那里，这些肯定不会与其他项目的身份验证一起使用吗？但我需要允许用户过渡到其他地区。

我也无法在一个地方收集所有地区的分析数据，对吗？

因此问题是，有没有办法在 firebase 项目中扩展/添加多区域支持？对 Firestore 和云功能特别感兴趣，因为这些功能可以减少延迟。

【问题讨论】：

是的，我也不明白。我知道存储桶可以有多个区域，但数据库/云只有 1 个区域。他们声明您应该将您的数据库和云功能放在您的用户所在的区域。但是，如果我同时针对欧盟和美国用户，该放在哪里呢？ :(
可能会有帮助：groups.google.com/forum/#!topic/google-cloud-firestore-discuss/…
您的解决方案是写密集型还是读密集型？如果它是读取密集型的，您应该在边缘级别寻找缓存机制。
这个问题应该改写以避免征求意见/建议，否则它可能会被关闭为“主要基于意见”。我认为这个问题的意图很好，但应该被问为“我的选择是什么？”问题，而不是“你推荐什么？”或“什么是最佳实践？”。您也可能通过这种方式获得更多答案。
@3D1T0R 如果您是 firebase 用户并正确阅读问题，您将得到他的实际问题。

标签： firebase firebase-realtime-database google-cloud-firestore google-cloud-functions

【解决方案1】：

我在 cmets 中进行了询问，但没有得到回复，因此我假设您的应用具有 READ 密集型工作负载。对于这些情况，为了减少来自世界各地的请求的延迟，您应该使用 CDN 来缓存静态文件和响应（即利用边缘位置和边缘计算）。您甚至不需要为此坚持使用 Firebase（有像 Akamai 和 CloudFront 这样的解决方案可能满足您的需求并轻松插入您的 Firebase 解决方案），但如果您需要，请查看 Firebase Hosting。

如果您的工作负载是 WRITE 密集型，请尝试使用异步机制，例如消息队列，以保证您向用户提供更快的反馈。通常，写入操作不需要立即/同步执行，但同样，最好了解您的工作量以给出更准确的答案。

编辑：谷歌最近宣布Firestore——他们提供多区域支持以提高可用性：

多区域位置是一般地理区域，例如美国。多区域位置中的数据在多个区域中复制。在一个区域内，数据跨区域复制。

在可扩展性方面，这是他们在their blog 中给出的声明：

Cloud Firestore [...] 建立在为一些非常流行的应用程序提供支持的同一 Google Cloud 基础架构之上。因此，它能够比实时数据库更轻松地扩展，并且容量更大。

借助新的查询结构，所有 Cloud Firestore 查询都可以根据您的结果集的大小进行扩展，而不是您的数据的大小。这意味着，无论您的数据库中有 300 家、30 万家还是 3000 万家餐厅，搜索芝加哥前 10 家餐厅的餐厅评论应用程序所花费的时间都是相同的。正如这里的一位工程师喜欢说的，“在 Cloud Firestore 中创建慢查询基本上是不可能的。”

请注意，Firestore 中的写入具有强一致性（这意味着与最终一致性解决方案相比，它们具有更高的延迟）。

【讨论】：

我的用例确实涉及两者，它是一个游戏，所以会发生很多写入和读取，我也不相信缓存在这里会有任何好处，即设备和统计数据等玩家数据会改变经常：/
您考虑过 Firestore 吗？ firebase.googleblog.com/2017/10/…
我做了，但它不是也与一个区域相关联，即您的项目之一吗？
他们在文档中说是多区域的，但是处于测试阶段。
确实如此，但我相信它指的是多个区域的可用性，但是一旦您的项目有一个区域，您就不能为每个用户更改它，对吗？