mongodb - Mongo 树数据模型设计

Question

我的目标是设计一个可扩展的递归树数据模型，该模型不受垂直大小、水平大小、树不平衡和总体大小的影响。

在 Mongo 的网站上，他们在这里谈论树结构数据:

http://docs.mongodb.org/manual/applications/data-models-tree-structures/

有趣的是，他们呈现的每个数据模型都表示一个新的集合条目；即使对于子元素

让我们从 mongodb.org 示例 A 中调用以下内容:

db.categories.insert( { _id: "MongoDB", parent: "Databases" } )
db.categories.insert( { _id: "dbm", parent: "Databases" } )
db.categories.insert( { _id: "Databases", parent: "Programming" } )
db.categories.insert( { _id: "Languages", parent: "Programming" } )
db.categories.insert( { _id: "Programming", parent: "Books" } )
db.categories.insert( { _id: "Books", parent: null } )

现在，让我们把这个例子称为 B:

singleEntry =
{
    _id: "Books",
    children:
    [
        {
            _id: "Programming",
            parent: "Books",
            children:
            [
                {
                    _id: "Languages",
                    parent: "Programming"
                },
                {
                    _id: "Databases",
                    parent: "Programming",
                    children:
                    [
                        {
                            _id: "MongoDB",
                            parent: "Databases"
                        },
                        {
                            _id: "dbm",
                            parent: "Databases"
                        }
                    ]
                }
            ]
        }
    ]
}

db.categories.insert(singleEntry)

我非常喜欢示例 B；虽然双引用父子关系是多余的，但在实际使用中我找不到避免这种情况的方法。此外，查询涉及更多:

db.categories.find(
    {
        'children.children.children._id' : 'MongoDB'
    }
)

但我不介意，只要示例 A 中的所有内容都适用于示例 B。

我觉得可能不是。我担心的其他陷阱是:

1. 最大条目大小
2. 最大堆栈大小
3. 插入到高度嵌套的集合条目中，对重新排列内存内容的引擎造成严重破坏

我最初对 Mongodb 的理解是它是为这样的模式设计而设计的。然而，当我查看文档、示例，甚至是 shell 方法时，看起来他们真的希望它像示例 A 一样。

关于示例 A 的一些事情似乎太相关了；这就是我试图摆脱的东西。如果我选择示例 A，为什么不直接使用 SQL？如果我使用示例 B，我会遇到什么？

Answer 1

您将遇到的一个问题是 document size limit of 16MB .对于示例 B 中的方法来说，这绝对是 killer 锏，除了非常小的数据库。

NoSQL 和 MongoDB 数据建模的工作方式与 SQL 数据库的数据建模有着根本的不同。以下内容略有简化，但您明白了。

使用 SQL 数据库，您可以根据您的实体对数据建模并确定它们之间的关系。在下一步中，您尝试确定如何回答您的用例中出现的问题。

在 MongoDB 数据建模中，您首先要确定用例中出现的问题，然后相应地对数据建模，以最有效的方式回答您的问题。

此外，在用例中，一般的 NoSQL 数据库或 MongoDB 并不理想。然而，在 SQL 数据库中对树结构进行建模通常也是一件令人头疼的事情。使用像 Neo4J 这样的树数据库可能更适合高度结构化的树。但是，几乎可以使用任何数据库来构建商店系统或某物的类别结构。我会根据项目的几乎任何其他功能和非功能需求来选择数据库。