我们的索引包含大约100万份文件，每份文件代表电子商务商店的产品。我们使用聚合来计算表示产品的每个属性的属性值的桶。如果我们进行搜索，将结果集限制为2000个产品，那么性能很好（Elastic在不到10毫秒的时间内返回结果）。但是，如果我们进行matchall查询以获取所有产品及其相应的聚合，弹性需要超过3秒才能返回结果。如果我们禁用聚合，性能再次变得更加激烈。因此，在使用聚合时，性能似乎非常依赖于结果集的大小（使用matchall查询我们可以获得大约1000个桶）。在Elastic中我们需要注意一些特殊的东西吗？为了让一个matchall查询执行类似于查询，返回2000个产品？
在我们开始使用Elastic之前，我们已经与Lucene合作，并在Lucene之上构建了我们自己的方面抽象，以便能够处理上述场景。在这种情况下，我们在索引启动时预先计算了facet，并将每个facet表示为具有相应bitset的项。在进行搜索时，我们为有问题的查询检索了一个bitset，并使用我们想要在给定方案中显示的每个方面的预先计算的bitset对其进行“AND”。通过此实现，我们能够计算方面结果的速度根据给定查询的结果集的大小而没有差异。只有文档数量和方面数量影响了速度。通过这种实现，我们能够在每个搜索请求中计算超过10.000个方面（存储桶），索引为100万个文档，并且仍然可以在不到100毫秒的时间内获得结果集和方面结果。
任何人都可以告诉我这是否可以通过Elastic实现，以及指向我们做错的任何指针（我们目前正在find.no的设置上运行测试，其中1个集群具有4个2,5Ghz核心和1GB内存。 Elastic索引占用大约3.5GB的磁盘空间
示例查询（我们可以通过不使用嵌套聚合来节省大约1/3的查询时间）：
{
"query": {
"match_all": {}
},
"aggs": {
"nested_aggs": {
"nested": {
"path": "specs"
},
"aggs": {
"combined": {
"filter": {
"match_all": { }
},
"aggs": {
"ul1": {
"terms": {
"field": "unspscNameLevel1",
"size": 50
} ,
"aggs": {
"parent_count": {
"reverse_nested": {}
}
}
},
"ul2": {
"terms": {
"field": "unspscNameLevel2",
"size": 50
} ,
"aggs": {
"parent_count": {
"reverse_nested": {}
}
}
},
"ul3": {
"terms": {
"field": "unspscNameLevel3",
"size": 50
} ,
"aggs": {
"parent_count": {
"reverse_nested": {}
}
}
},
"ul4": {
"terms": {
"field": "unspscNameLevel4",
"size": 50
} ,
"aggs": {
"parent_count": {
"reverse_nested": {}
}
}
},
"rl1": {
"terms": {
"field": "requirementSpecificationNameLevel1",
"size": 50
} ,
"aggs": {
"parent_count": {
"reverse_nested": {}
}
}
},
"rl2": {
"terms": {
"field": "requirementSpecificationNameLevel2",
"size": 50
} ,
"aggs": {
"parent_count": {
"reverse_nested": {}
}
}
},
"rl3": {
"terms": {
"field": "requirementSpecificationNameLevel3",
"size": 50
} ,
"aggs": {
"parent_count": {
"reverse_nested": {}
}
}
},
"t1": {
"terms": {
"field": "tilslutningskrav",
"size": 50
}
},
"t2": {
"terms": {
"field": "tildelingsform",
"size": 50
}
},
"t3": {
"terms": {
"field": "tildelingskriterie",
"size": 50
}
}
}
}
}
},
"nested_aggs2": {
"nested": {
"path": "specs.attributes"
},
"aggs": {
"combined": {
"filter": {
"match_all": { }
},
"aggs": {
"n4": {
"terms": {
"field": "4. niv. kategori",
"size": 50
} ,
"aggs": {
"parent_count": {
"reverse_nested": {}
}
}
},
"ffv": {
"terms": {
"field": "form forvaltningsopgave",
"size": 50
} ,
"aggs": {
"parent_count": {
"reverse_nested": {}
}
}
},
"fh": {
"terms": {
"field": "form hovedområde",
"size": 50
} ,
"aggs": {
"parent_count": {
"reverse_nested": {}
}
}
},
"fo": {
"terms": {
"field": "form opgaveområde",
"size": 50
} ,
"aggs": {
"parent_count": {
"reverse_nested": {}
}
}
},
"fs": {
"terms": {
"field": "form serviceområde",
"size": 50
} ,
"aggs": {
"parent_count": {
"reverse_nested": {}
}
}
},
"s": {
"terms": {
"field": "styresystem",
"size": 50
} ,
"aggs": {
"parent_count": {
"reverse_nested": {}
}
}
}
}
}
}
},
"supplierCategory": {
"filter": {
"match_all": { }
},
"aggs": {
"sc": {
"terms": {
"field": "supplierCategory.raw",
"size": 50
}
},
"on": {
"terms": {
"field": "organisationName.raw",
"size": 50
}
},
"mn": {
"terms": {
"field": "manufacturerName.raw",
"size": 50
}
}
}
}
}
}