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

假设我们正在设计一个新系统，并决定使用MongoDB作为主数据库。数据模式非常类似于评论不断增加的博客

在《MongoDB开发者》一书中，小贴士6：不要嵌入具有无绑定增长的字段，它说不断将数据追加到数组末尾是低效的（但它也暗示了注释是一种“wierd边缘情况”）

比如说，我们的新系统就像博客中的“评论”——不断动态增长，但有时也会改变或删除一些评论

所以，在认识到使用MongoDB可能会出现性能问题之后，还有什么其他替代数据库（必须是水平可伸缩的数据库）可以达到这一目的呢？（我们不介意使用MongoDB作为我们的主数据库，但是将“注释”分离到另一个数据库中。有哪些选项可用

注:

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

---

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

您可以坚持使用MongoDB，但不要将所有注释嵌入主文档，而只嵌入最近的注释（受数量限制），并将所有其他内容保存在一个单独的集合中。

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

---

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

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

除了Thilo上面所说的之外，“不嵌入具有未绑定增长的字段”的原因是，这种类型的文档大小扩展可能会导致MongoDB在文档超过当前分配给它的空间时不得不移动文档。您可以在文档的一节中了解更多信息

---

这些类型的移动相对昂贵，尤其是在频繁发生的情况下。因此，限制主集合（最近的X等）中等价注释的大小（基本上限制增长），甚至可能预先填充该文档字段（基本上是手动填充）减少注释添加/更改引起的移动对您来说可能是值得的。

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