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 开发人员"一书中，提示 #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 将哈希作为其数据类型的特性符合我们对评论"数据结构的描述——不断增长但有时会被修改或删除——但我们不需要一个纯粹的内存数据库(我们不希望当数据可以持久化到磁盘时，就分配这么多内存) - 否则这将非常适合我们的问题

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屋！