MongoDB 数据架构性能

Question

我试图了解 MongoDB 文档中数组和散列（据我的理解是通过数组实现）的内部分配和放置。

在我们的领域中，我们的文档包含数千到数十万个键值对，其逻辑分组深度可达 5-6 级（想想嵌套散列）。

我们用一个点表示键中的嵌套，例如，x.y.z，它在插入 MongoDB 时会自动变为：

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

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

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

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

考虑到键值对的数量和$inc 更新和新键插入方面的使用模式，我正在寻找关于在以下方面权衡这两种方法的指导：

• 磁盘空间开销

• $inc 更新的性能

• 新密钥插入的性能

Answer 1

MongoDB 中文档的磁盘存储采用 BSON 格式。这里有BSON格式的详细说明： - http://bsonspec.org/#/specification

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

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

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

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

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