数据结构不断增长的 MongoDB 性能 [英] MongoDB performance with growing data structure

问题描述

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

Let's say we are designing a new system and have decided to use MongoDB as the primary database. The data schema is very similar to a blog with [growing] comments.

在MongoDB Developers"一书中，提示 #6:不要嵌入具有无限增长的字段，它说不断将数据附加到数组的末尾是低效的(但它也暗示注释是奇怪的"边缘情况").

In the book "MongoDB Developers", Tip #6: Do not embed fields that have unbound growth, it says it is inefficient to constantly append data to the end of an array (but it also hinted that comments are a "wierd edge case").

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

Let's say our new system is like those "comments" in a blog - dynamically growing all the time, but also sometimes changing or some being deleted.

那么，在认识到使用 MongoDB 可能存在性能问题之后，还有什么其他替代数据库(必须是水平可扩展的数据库)可以达到此目的?(我们不介意使用 MongoDB 作为我们的主数据库，但将评论"分开到备用数据库.有哪些可用选项?

So, having recognized that there could be a performance issue using MongoDB, what other alternative database (must be horizontally scalable database) could serve this purpose? (We don't mind using MongoDB as our primary database, but separate the "comments" to a alternative database. What are the options available?

注意事项:

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

The Redis feature of having Hashes as its data types fit the description of our "comments" data structure - constantly growing but sometimes modified or deleted - BUT we do not need a pure in-memory database (we don't wish to dedicate so much RAM when the data can be persisted to the disk) - otherwise this would be a good fit for our problem

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

What about using CouchDB? We are not investigated about this product. How does it perform with a growing data structure?

推荐答案

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

To add to what Thilo said above, the reason to "not embed fields that have unbound growth" is because this type of document size expansion can cause MongoDB to have to move the document if it exceeds the current space allocated to it. You can read more about this in the Padding Factor section of the documentation.

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

Those types of moves are relatively expensive, especially if they happen frequently. Therefore limiting the size (essentially bounding that growth) of the comments equivalent in your main collection (most recent X etc.) and perhaps even pre-populating that document field (essentially manual padding) to reduce the moves caused by comment additions/changes may well be worth it for you.

这篇关于数据结构不断增长的 MongoDB 性能的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！