我的问题与mongo处理巨大数组的能力有关。Mongodb大型数组或查询
我想在主题更新为主题的所有订户时发送推送通知。假设一个话题可以有一百万个用户。
在拥有订阅它的所有用户标识的主题文档中保存一个巨大的数组会是有效的吗?或者保守的方式更好 - 为每个用户保存一系列订阅主题,然后查询用户集合以查找特定主题的订阅者?
编辑:
如果阵列是非常大的和文件累积大小超过16 MB,那么我将持有的用户采集反正在订阅主题的数组(查看和编辑)
我的问题与mongo处理巨大数组的能力有关。Mongodb大型数组或查询
我想在主题更新为主题的所有订户时发送推送通知。假设一个话题可以有一百万个用户。
在拥有订阅它的所有用户标识的主题文档中保存一个巨大的数组会是有效的吗?或者保守的方式更好 - 为每个用户保存一系列订阅主题,然后查询用户集合以查找特定主题的订阅者?
编辑:
如果阵列是非常大的和文件累积大小超过16 MB,那么我将持有的用户采集反正在订阅主题的数组(查看和编辑)
主要假设:主题相关和与人物相关的元数据存储在不同的集合中,此处讨论的集合仅用于跟踪主题订阅者。
将订阅者作为与主题标识符相关联的列表/数组存储为文档密钥(意味着索引字段)使得高效的结构成为可能。一旦你有一个感兴趣的话题,你可以通过主题标识查找用户列表。在这里,正如@Saleem正确指出的那样,您需要警惕大量用户列表,导致文档超过16MB的文档大小限制。但是,通过使不同的集合来处理这个问题(如@Saleem所建议的),您可以简单地将订阅者列表(根据需要分成多个部分,使用模16MB操作)并创建多个文档在同一个集合中的主题。鉴于主题标识符是一个索引字段,因此查找时间不会受到影响,因为16MB可以容纳显着数量的用户标识符,并且所需的分割数量应该相当低(如果需要的话)。
您建议的其他结构,其中订阅者标识符是文档关键字及其文档中的所有订阅主题,对于大型数据集而言,直观上效率不高。这种结构将涉及查找订阅该主题的所有订阅者。如果订阅的主题被存储为列表/数组(似乎是可能的选择),则该查询将涉及比索引字段查找更慢的$in
子句,即使对于大型用户群中的小型主题列表也是如此。
将它分成另一个集合。您可以将集合中的所有主题及其所有订阅者分为独立的集合,并引用主题集合。
你的巨大有多大?任何数字? – Saleem