假设我们正在设计一个新系统，并决定使用MongoDB作为主数据库。数据模式与具有[增长]评论的博客非常相似。
在“MongoDB开发者”一书中，提示＃6：不要嵌入具有未绑定增长的字段，它表示不断将数据附加到数组的末尾是低效的（但它也暗示评论是“奇怪的”边缘情况“）。
假设我们的新系统就像博客中的那些“评论” - 一直在动态增长，但有时也在变化或者被删除。
因此，在认识到使用MongoDB可能存在性能问题之后，还有什么其他替代数据库（必须是水平可伸缩数据库）才能实现此目的？ （我们不介意使用MongoDB作为我们的主数据库，而是将“注释”与备用数据库分开。有哪些可用选项？
注意：
将Hashes作为其数据类型的Redis功能符合我们的“注释”数据结构的描述 - 不断增长但有时被修改或删除 - 但我们不需要纯粹的内存数据库（我们不希望当数据可以持久保存到磁盘时专用如此多的RAM） - 否则这将非常适合我们的问题
使用CouchDB怎么样？我们没有对此产品进行调查。它如何在不断增长的数据结构中发挥作用？
答案 0 :(得分：6)
您可以坚持使用MongoDB，但不要将所有注释嵌入到主文档中，而只是将最近的注释嵌入到主文档中（受数字限制），并将所有其余注释保存在单独的集合中。
答案 1 :(得分：5)
要添加Thilo上面所说的内容，“不嵌入具有未绑定增长的字段”的原因是因为这种类型的文档大小扩展可能导致MongoDB在超过分配给它的当前空间时必须移动文档。您可以在文档的Padding Factor部分阅读更多相关信息。
这些类型的举动相对昂贵，特别是如果它们经常发生。因此，限制主要集合中等效注释的大小（基本上限制该增长）（最近的X等），甚至可能预先填充该文档字段（主要是手动填充）以减少由注释添加/更改引起的移动非常适合你。
答案 2 :(得分：0)
Mongo听起来对你们工作得很好，只需将“评论”保留在与另一个文档的子元素相对应的单独的集合广告中，即一个页面（继续博客示例）。
至于Mongo的表现，只要这些指数能够适合你，你应该没事。
答案 3 :(得分：0)
您的主要问题是您可能正在对不同内存页面中的数据进行更新和删除，这意味着您将无法按顺序更新。在这种情况下，许多数据库都会遇到同样的问题，因此从MongoDB切换不会解决任何问题。