使用上限集合作为管理空间的方式是否安全？

Question

基本上，我想创建一个基于聊天的系统，其中一个功能是为每个会员级别提供更长的聊天记录。我不认为允许大于1GB的集合，甚至看起来有点过分。然而，保持它们的小，也意味着我不需要担心它们的分片。

基本上每个'聊天'都是一个上限集合。期望是如果它们达到文件存储限制，旧项目将丢弃，这就是封顶集合的工作方式。所以在我看来，为每个聊天创建一个上限集合将是实现这一目标的简单方法。我只是应用并存储一个id作为集合名称，以便我可以访问它。

我不应该考虑这种方法吗？

Answer 1

听起来您的数据在逻辑上被chatId拆分了。我不清楚chatId的范围是按用户，按聊天还是按“会员级别”进行，因此我在这个答案中仅提及chatId。

此数据可以存储在单个集合中，索引位于chatId，允许您在查找，删除等时轻松区分每个不同的聊天。随着该集合的大小增长，您可能会达到它的大小不能支持你想要的非功能。此时，建议进行分片。当然，你可能永远不会达到这一点，一个简单的单一收集方法与合理的索引，托管硬盘上有足够的CPU，RAM等可能会满足你的需求。在不知道您的卷（当前和未来），写入吞吐量，典型读取所需的经过时间等情况下，很难说会发生什么。

但是，根据您的问题，似乎就像最终需要进行分片一样，并且为了抢占您正在考虑限制您的数据占用空间。

当使用单个集合（无论是否分片）时，可以按chatId实现上限，这将需要以下内容：

• 可以按chatId
计算存储空间
• 对于超过允许上限的每个chatId，删除最旧的条目并循环，直到存储空间为＆lt; =允许的上限。

这可以通过计划或“集合写入事件”监听器触发。

当然，使用上限集合来限制占用空间实质上是要求MongoDB为您执行此操作，因此它更简单但是该方法存在一些问题：

1. 使用单个集合推理和管理系统可能比管理具有大量（数千？）集合的系统更容易
2. 上限集合将确保每个集合的最大大小，但如果您无法限制离散chatId的数量，那么您可能仍然会遇到需要分片的情况
3. 封顶集合并不能真正取代分片;分片不仅仅是将数据分成逻辑部分，数据也分散在多个主机上，从而水平扩展。 相同 Mongo节点上将存在多个上限集合，因此上限会限制您的占用空间，但不会扩展您的处理能力或在多个主机上分散您的存储需求
4. 除非您使用WiredTiger存储引擎（在MongoDB v 3.x上），否则每个数据库的最大集合数为~24000（请参阅the docs）
5. 有limitations封顶集合，例如
   • 如果更新或替换操作更改了文档大小，则操作将失败。
   • 您无法从上限集合中删除文档
   • 等

所以，总结......

如果离散chatId的数量低于数百，那么数据库的潜在最大大小是可管理的，并且总收集计数是可管理的。在这种情况下，使用上限集合将提供一个很好的权衡;它可以防止在不损失功能的情况下进行分片。

但是，如果离散chatId s的数量为千且/或如果离散chatId的数量没有可能的上限，或者离散chatId的数量这是强迫你在每个上面应用一个吝啬的上限，然后你最终会发现自己不得不考虑分片。如果这种情况完全可能，那么我建议尽可能简单地开始;使用单个集合，只在非功能需要时才从那里移动。通过“从那里移开”，我的意思是通过应用手动删除过程开始，如果这变得无效（即，如果离散的chatId的数量是这样的，它会迫使你在每个不同的上应用一个吝啬的上限chatId）然后考虑分片。