解析：數的限制（）

Question

任何誰的閱讀解析文檔已經在this

買者跌跌撞撞：查詢計數率都限制在最多每分鐘160個請求。他們也可以返回超過1,000個對象的類的不準確結果。因此，建議您的應用程序避免此類計數操作（例如，使用計數器）。

爲什麼會存在此類限制和不準確性？

Answer 1

該限制僅僅是爲了阻止人們使用計數太多，他們就像運行時成本高，因爲完整查詢有效。

不準確是因爲查詢限制爲1000個結果對象（默認爲100），並且計數具有相同的硬限制。

你可以運行一個遞歸查詢來建立一個計數，但這是一個糟糕的選擇。因此，在這個時間點（並且就我們將來可以看到的）而言，唯一真正好的選擇是保持您感興趣計數的事物的索引，並在發生任何變化時更新計數。您通常會在雲代碼中保存掛鉤。

Answer 2

引述解析工程博客文章：Building Scalable Apps on Parse

假設你正在構建一個產品目錄。您可能想要在頂級導航 屏幕上顯示每個類別中產品的數量 。如果您爲這些UI元素中的每一個運行計數查詢，那麼它們 將無法​​在大型數據集上高效運行，因爲MongoDB不會 使用計數B樹。相反，我們建議您使用一個單獨的解析對象來跟蹤每個類別的計數。每當添加或刪除 產品時，您都可以在afterSave或afterDelete Cloud代碼處理程序中增加或減少 計數。

要添加到這一點，這裏是從the Parse Developers Google Group

計數查詢另一個報價由赫克託·拉莫斯一直是昂貴的，一旦你在拋出一些 約束。如果你只關心總規模 集合，您可以運行計數查詢沒有任何限制，並且應該是非常快的，因爲獲取記錄總數是一個 不同的問題，而不是計算其中有多少個匹配任意約束列表的任意一個 列表。這只是使用數據庫 系統的現實。

這種不準確性是不由於1000請求對象的限制。計數查詢將嘗試獲取記錄的總數，而不考慮大小，但由於該操作可能需要大量時間才能完成，因此可能在該窗口期間數據庫已更改，並且返回的計數值可能不是更有效。

處理計數的推薦方法是使用保存掛鉤之前/之後的基本維護自己的索引。但是，這也是一個非理想的解決方案，因爲保存鉤子可以任意部分通過，並且（更糟糕）postSave鉤子沒有錯誤傳播。