MongoDB嵌入式vs数组子文档性能

Nel*_*haw 12 arrays mongodb nosql

鉴于以下竞争模式与多达100,000个朋友,我有兴趣找到最有效的我的需求.

Doc1(user_id索引)

{
"_id" : "…",
"user_id" : "1",
friends : {
    "2" : {
        "id" : "2",
        "mutuals" : 3
    }
     "3" : {
         "id" : "3",
         "mutuals": "1"
    }
   "4" : {
         "id" : "4",
         "mutuals": "5"
    }
}
}
Run Code Online (Sandbox Code Playgroud)

Doc2(user_id和friends.id上的复合多键索引)

{
"_id" : "…",
"user_id" : "1",
friends : [
   {
        "id" : "2",
        "mutuals" : 3
    },
    {
         "id" : "3",
         "mutuals": "1"
    },
   {
         "id" : "4",
         "mutuals": "5"
    }
]}
Run Code Online (Sandbox Code Playgroud)

我似乎无法找到有关子字段检索效率的任何信息.我知道mongo在内部将数据实现为BSON,所以我想知道这是否意味着投影查找是二进制O(log n)?

具体来说,给定user_id以查找是否存在具有friend_id的朋友,每个模式上的两个不同查询将如何比较?(假设上面的索引)请注意,返回的内容并不重要,只有在朋友存在时才返回非null.

Doc1col.find({user_id : "…"}, {"friends.friend_id"})
Doc2col.find({user_id : "…", "friends.id" : "friend_id"}, {"_id":1})
Run Code Online (Sandbox Code Playgroud)

同样令人感兴趣的是$ set修饰符的工作原理.对于模式1,给定查询Doc1col.update({user_id : "…"}, {"$set" : {"friends.friend_id.mutuals" : 5}),friends.friend_id上的查找如何工作?这是一个O(log n)操作(其中n是朋友的数量)?

对于模式2,查询Doc2col.update({user_id : "…", "friends.id" : "friend_id"}, {"$set": {"friends.$.mutuals" : 5})将如何与上面的查询进行比较?

Gab*_*bow 3

如果一个人的主要需求是在一个易于管理的包中向 UI 呈现数据,那么 doc1 是更好的选择。使用投影仅过滤所需的数据很简单{}, {friends.2 : 1}

\n\n

doc2 是您最强的匹配,因为您的用例不关心结果。请注意,\xe2\x80\x99s 返回的内容并不重要,索引将加快获取速度。

\n\n

最重要的是 doc2 允许更简洁的语法

\n\n
db.doc2.findOne({user_id: 1, friends.id : 2} )\n
Run Code Online (Sandbox Code Playgroud)\n\n

相对

\n\n
db.doc1.findOne({ $and : [{ user_id: 1 }, { "friends.2" : {$exists: true} }] })\n
Run Code Online (Sandbox Code Playgroud)\n\n

然而,最后一点是,人们可以在 doc1 上创建一个稀疏索引(并使用 $exists),但你可能有 100,000 个朋友——每个朋友都需要一个稀疏索引——这使得这很荒谬。与合理数量的条目相反,人口统计性别 [男性,女性],年龄组 [0-10,11-16,25-30,..] 或更多重要的事物 [杜松子酒,威士忌,伏特加,...]

\n