数据结构不断增长的 MongoDB 性能答案

【问题标题】：MongoDB performance with growing data structure数据结构不断增长的 MongoDB 性能
【发布时间】：2017-07-08 19:39:48
【问题描述】：

假设我们正在设计一个新系统并决定使用 MongoDB 作为主数据库。数据模式非常类似于具有 [增长] cmets 的博客。

在《MongoDB 开发人员》一书中，提示 #6：不要嵌入具有无限增长的字段，它说不断将数据附加到数组的末尾是低效的（但它也暗示 cmets 是一个“奇怪的边缘情况”）。

假设我们的新系统就像博客中的那些“cmets”——一直在动态增长，但有时也会发生变化或被删除。

那么，在认识到使用 MongoDB 可能存在性能问题之后，还有什么其他替代数据库（必须是水平可扩展的数据库）可以达到此目的？（我们不介意使用 MongoDB 作为我们的主数据库，但将“cmets”分离到备用数据库。有哪些可用选项？

注意事项：

将哈希作为其数据类型的 Redis 特性符合我们“cmets”数据结构的描述 - 不断增长，但有时会修改或删除 - 但我们不需要纯内存数据库（我们不希望当数据可以持久保存到磁盘时，专用这么多 RAM） - 否则这将非常适合我们的问题

使用 CouchDB 怎么样？我们没有对此产品进行调查。它在不断增长的数据结构中表现如何？

【问题讨论】：

【解决方案1】：

补充一下 Thilo 上面所说的，“不嵌入具有无限增长的字段”的原因是因为这种类型的文档大小扩展可能会导致 MongoDB 如果超过当前分配给它的空间就必须移动文档。您可以在文档的Padding Factor 部分阅读更多相关信息。

这些类型的移动相对昂贵，特别是如果它们经常发生。因此，限制您的主集合（最近的 X 等）中等效 cmets 的大小（基本上限制增长），甚至可能预先填充该文档字段（基本上是手动填充）以减少由注释添加/更改引起的移动可能对你来说是值得的。

【讨论】：

我对最初的建议有点恼火，在我看来，您希望在文档数据库中执行此操作，否则您将回到表格方法。如果说一个数组从 0 开始并增长到 1000（例如，每天添加一次），您知道文档需要移动多少次吗？
如果它是一个固定或已知大小的数组，您可以手动填充它 - 最初用假数据填充它，然后删除假数据。这意味着它在超过该限制之前不会触发移动。至于它发生的频率，由于填充因子的计算方式，这实际上取决于文档的大小和集合的使用情况（基于移动与非移动操作的比率）

【解决方案2】：

您可以坚持使用 MongoDB，但不要将所有 cmets 嵌入到主文档中，而只是将最新的 cmets（受数量限制），并将所有其余部分保存在单独的集合中。

【讨论】：

【解决方案3】：

Mongo 听起来对你们来说很好用，只需将“cmets”放在单独的集合广告中，而不是另一个文档的子元素，即页面（继续博客示例）。

至于 Mongo 的性能，只要这些索引可以放入 ram 中就可以了。

【讨论】：

【解决方案4】：

您的主要问题是您可能会更新和删除不同内存页面中的数据，这意味着您将无法按顺序更新。在这种情况下，许多数据库都会遇到相同的问题，因此从 MongoDB 切换不会解决任何问题。

【讨论】：