【发布时间】:2020-06-10 01:23:22
【问题描述】:
为了方便阅读,我使用了反规范化。工作流程就是这样。
有两个集合
- 用户
- 活动
事件具有开始、结束时间戳和状态。 开始、结束时间戳指示事件何时开始和结束 状态保持,如果其即将到来或生活或完成或取消 通过收听每分钟调度程序来更新状态。
当用户注册一个事件时,我将事件对象复制到 users/{user-id}/events 下。这是必需的,因为我需要获取用户注册的事件。
问题
假设有 100 万用户订阅了状态为“即将到来”的事件。当状态从 Upcoming 变为 Live 时,我需要为所有用户更新 users/{user-id}/events 集合下的所有文档。
如果我进行顺序批量写入,则需要近 1000000/500 = 2000 批,并且需要近 15 到 30 分钟来更新一个事件更改。随着事件的增加,我认为问题太多了。
我非常担心每秒对整个 Firestore 进行 10,000 次更新以使用并行批量写入的限制。
如何处理这种情况,以便写入不会达到限制并且可以尽可能快地写入?
【问题讨论】:
-
您知道这项手术的成本吗?
-
是的。不幸的是,仅仅因为没有具有多个字段的查询功能(这里是开始和结束时间戳),我必须通过更新状态标志。我认为这是一个非常普遍的用例,但不确定其他人如何能够大规模解决它!
-
云任务似乎只是一种解决方法,但更新这些文档仍然需要大量时间。到那时,在最坏的情况下,用户可能需要等待 15-30 分钟才能改变状态,这实际上是无法接受的。
-
云任务允许您控制速率限制,但不能加速此操作。 Firestore/Datastore 不是为同时处理/更新多个文档而设计的,它对于每个事务处理一个或几个文档非常有效。
-
没错!这就是我想出来的。您对这项工作有什么建议吗?喜欢并行使用其他数据库作为 Firestore 的助手?
标签: google-cloud-firestore google-cloud-functions