我的問題與mongo處理巨大數組的能力有關。Mongodb大型數組或查詢
我想在主題更新爲主題的所有訂戶時發送推送通知。假設一個話題可以有一百萬個用戶。
在擁有訂閱它的所有用戶標識的主題文檔中保存一個巨大的數組會是有效的嗎?或者保守的方式更好 - 爲每個用戶保存一系列訂閱主題,然後查詢用戶集合以查找特定主題的訂閱者?
編輯:
如果陣列是非常大的和文件累積大小超過16 MB,那麼我將持有的用戶採集反正在訂閱主題的數組(查看和編輯)
我的問題與mongo處理巨大數組的能力有關。Mongodb大型數組或查詢
我想在主題更新爲主題的所有訂戶時發送推送通知。假設一個話題可以有一百萬個用戶。
在擁有訂閱它的所有用戶標識的主題文檔中保存一個巨大的數組會是有效的嗎?或者保守的方式更好 - 爲每個用戶保存一系列訂閱主題,然後查詢用戶集合以查找特定主題的訂閱者?
編輯:
如果陣列是非常大的和文件累積大小超過16 MB,那麼我將持有的用戶採集反正在訂閱主題的數組(查看和編輯)
主要假設:主題相關和與人物相關的元數據存儲在不同的集合中,此處討論的集合僅用於跟蹤主題訂閱者。
將訂閱者作爲與主題標識符相關聯的列表/數組存儲爲文檔密鑰(意味着索引字段)使得高效的結構成爲可能。一旦你有一個感興趣的話題,你可以通過主題標識查找用戶列表。在這裏,正如@Saleem正確指出的那樣,您需要警惕大量用戶列表,導致文檔超過16MB的文檔大小限制。但是,通過使不同的集合來處理這個問題(如@Saleem所建議的),您可以簡單地將訂閱者列表(根據需要分成多個部分,使用模16MB操作)並創建多個文檔在同一個集合中的主題。鑑於主題標識符是一個索引字段,因此查找時間不會受到影響,因爲16MB可以容納顯着數量的用戶標識符,並且所需的分割數量應該相當低(如果需要的話)。
您建議的其他結構,其中訂閱者標識符是文檔關鍵字及其文檔中的所有訂閱主題,對於大型數據集而言,直觀上效率不高。這種結構將涉及查找訂閱該主題的所有訂閱者。如果訂閱的主題被存儲爲列表/數組(似乎是可能的選擇),則該查詢將涉及比索引字段查找更慢的$in
子句,即使對於大型用戶羣中的小型主題列表也是如此。
將它分成另一個集合。您可以將集合中的所有主題及其所有訂閱者分爲獨立的集合,並引用主題集合。
你的巨大有多大?任何數字? – Saleem