我有一组文档,每个文档都包含一组任意且可更改的统计信息,因此为了不必不断地更改索引,我将它们全部存储为按名称索引的子文档 . 任何给定的文档可能具有不同索引顺序的这些子文件,并且任何给定文档可能缺少具有特定名称的子文件的某些子集 . 例如 . :
{
_id:"Document_1_id",
stats:[
{
name: 'Stat Name 1',
value: 10
},
{
name: 'Stat Name 2',
value: 3
}
]
},
{
_id:"Document_2_id",
stats:[
{
name: 'Stat Name 2',
value: -5
},
{
name: 'Stat Name 4',
value: 20
}
]
}
我这里有两个问题:
-
虽然我可以索引子文档名称或值(或两者,使用复合索引),但我无法弄清楚是否可以根据子文档的子集进行排序 . 例如,我可以通过其子文件的
value
对文档进行排序,但只使用name
等于'Stat Name 1'
的子文件吗?我想要退回原始文件 . -
如果它有数千(至10万)与我的搜索对象匹配的文档,但只想一次提供少量文件(几十个或更少),则根据这些统计值进行排序 . 虽然我可以在数据库前面进行一些缓存,但这些请求会经常发生 .
看起来Mongo的聚合管道可能就是这样做的,但是我对它们不太熟悉,无法理解我发现的各种例子如何适用于我的案例 . 我也不知道这样的操作会有多昂贵,因为我会经常提出这些问题 .
Update: 通过与一些知识渊博的人进行更多的挖掘和交谈,似乎这里至少有三种选择 .
简单选项:将所有这些 stats
子文档拆分为自己的集合,其中每个文档都存储原始父文档的 _id
. 这样做的缺点是需要对许多任务进行两次查询,但允许根据需要进行排序 . 这也在客户端引入了用于制作和管理这些多个查询的复杂性 .
硬选项:使用聚合管道,可能使用 $unwind
. 这需要一堆步骤,特别是因为我想要恢复原始数据(管道都是关于返回新的,被操纵的数据) . 这会影响查询的复杂性,我不知道我是否能想出一个有效的管道 .
放弃选项:我可能只是看看我是否可以通过这种方式获得排序集合...