performance - MongoDB 数据模式性能

Question

我试图了解 MongoDB 文档中数组和散列的内部分配和放置(据我所知，它们是通过数组实现的)。

在我们的领域中，我们的文档包含数千到数十万个键值对，逻辑分组深度可达 5-6 层(想想嵌套哈希)。

我们用点表示键中的嵌套，例如 x.y.z，插入 MongoDB 后会自动变成如下所示:

{
    "_id" : "whatever",
    "x" : {
        "y" : {
            "z" : 5
        }
    }
}

最常见的操作是递增一个值，我们使用原子 $inc 执行此操作，通常使用单个更新命令一次增加 1000 多个值。随着时间的推移会添加新 key ，但不会很频繁，比如每天 100 次。

我想到另一种表示方法是不在名称中使用点，而是使用其他分隔符并创建一个平面文档，例如

{
    "_id" : "whatever",
    "x-y-z" : 5
}

鉴于键值对的数量和 $inc 更新和新键插入方面的使用模式，我正在寻找有关两种方法之间权衡的指导:

• 磁盘空间开销

• $inc 更新的性能

• 新键插入的性能

Answer 1

MongoDB 中文档的磁盘存储是 BSON 格式。这里有对BSON格式的详细描述: - http://bsonspec.org/#/specification

虽然使用短键名可以节省一些磁盘空间(因为，正如您通过查看规范可以看到的那样，键名嵌入在文档中)，但在我看来几乎没有净差异两种设计在所用磁盘空间方面的差异——通过使用分隔符 (-) 所使用的额外字节将被回收，因为不必为单独的键值设置字符串终止符。

$inc 两种格式的更新时间应该几乎相同，因为它们都是内存操作。与从磁盘读取文档所花费的时间相比，内存更新时间的任何改进都将是最小的舍入误差。

新 key 插入物的性能也应该几乎相同。如果添加新的键/值对使新文档足够小以适合磁盘上的旧位置，那么所发生的只是更新内存中的版本并写入日志条目。最终，内存中的版本将写入磁盘。

如果文档超出了先前为其分配的空间，则新的键插入会出现更多问题。在这种情况下，服务器必须将文档移动到新位置并更新指向该文档的所有索引。这通常是一个较慢的操作，应该避免。但是，您正在讨论的架构更改不应影响文档移动的频率。同样，我认为这是一种洗礼。

我的建议是使用最适合开发人员生产力的模式。如果您遇到性能问题，那么您可以单独询问有关如何扩展系统或提高性能或两者兼而有之的问题。