我有一组文档,每个文档都包含一组任意且可更改的统计信息,因此为了不必不断地更改索引,我将它们全部存储为按名称索引的子文档 . 任何给定的文档可能具有不同索引顺序的这些子文件,并且任何给定文档可能缺少具有特定名称的子文件的某些子集 . 例如 . :

{
  _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 . 这需要一堆步骤,特别是因为我想要恢复原始数据(管道都是关于返回新的,被操纵的数据) . 这会影响查询的复杂性,我不知道我是否能想出一个有效的管道 .

放弃选项:我可能只是看看我是否可以通过这种方式获得排序集合...