2

我已閱讀有關transactional update operations on Firestore的文檔。根據Quotas and Limits只有兩個限制與關於交易:Cloud Firestore交易限制

  • 用於交易最大尺寸:10 MIB
  • 時限事務:270秒,在60秒的空閒期滿時間

沒有明確的交易有關的限制提到,許多文件或集合如何可以讀取和/或交易過程中被修改,或者有關於集合任何額外的限制,其中TRA事件更新發生。

  1. 這是否意味着,客戶端可以做高達500個文件,在每一個不同的收藏事務更新,只要更新保持內這些和其他一般限制?

  2. 如果客戶端讀取一個事務中的多個文檔,但僅更新其中的一個 - 做公司的FireStore仍然(默默)寫入未修改的文件(序列化或左右)...所以我不得不考慮將寫即使對於客戶端未明確修改的文檔,每秒每個文檔的寫入限制也是如此。

P.S:我之所以問的是,數據存儲有25個實體,集團在交易的限制,也看到了在熱點實體只讀內許多寫入事務(「文件」)。例如,請參閱this answer by Dan McGrath。我只是想知道數據存儲的哪些特徵傳遞給Firestore,並且在設計Firestore數據庫時必須考慮這些特徵。

回答

3

請參閱「可傳遞給提交操作的最大文檔數」,它定義了500個文檔的限制。這是您的交易限制,因爲我們需要使用單個提交將所有內容應用於交易。

我不認爲無需再進行無聲寫入來確定文檔是否在事務中發生了更改。

沒有與25實體組限制等價的相關限制。

+1

如果我們想要做500多個更新,我們應該使用多個批次?或我們如何實現這一目標?我有一種情況,我需要更新'用戶Feed'的Dinic參考。在我添加到集合中的Id's +用戶所做的每個Post後的一些信息,並且如果我取消關注用戶,則需要刪除此文檔。 現在一切正常,但如果將來我的應用程序增長,並且用戶超過500個帖子,當嘗試更新此數據時,我的「雲功能」將崩潰。 –