我已经设置了一个ES索引来索引以用户为中心的数据,每个文档都包含相关的用户ID(在贡献者字段中的所有者字段中)和2个需要使用" contains& #34;语义。该索引包含大约100M文档,每个文档的大小约为15K,具有复杂的嵌套结构。索引是使用dynamic_templates设置的,它将所有字段索引为关键字(因为不需要自由文本搜索,令牌化似乎是多余的),某些字段也使用小写过滤器进行规范化以启用不区分大小写的搜索。此时索引所有字段的原因是为了避免必须重新索引以允许在其他字段上进行搜索,以便可以快速添加新功能(索引的大小使重新编制索引非常痛苦)。群集配置有3个节点和5个分片,复制因子为1.我使用的查询如下所示:
{
"query": {
"bool": {
"must": [
{
"bool": {
"should": [
{
"wildcard": {
"document.name": {
"value": "*SEARCH_TERM*"
}
}
},
{
"wildcard": {
"externalData.properties.displayName": {
"value": "*SEARCH_TERM*"
}
}
}
]
}
}
],
"filter": [
{
"bool": {
"should": [
{
"term": {
"contributorIds": {
"value": "deadbeef-cafe-babe-cafe-deadbeefcafe"
}
}
},
{
"term": {
"document.ownerId": {
"value": "deadbeef-cafe-babe-cafe-deadbeefcafe"
}
}
}
],
"filter": [
{
"term": {
"deleted": {
"value": "false"
}
}
}
]
}
}
]
}
},
"size": 50,
"sort": [
{
"_doc": {
"order": "asc"
}
}
]
}
我注意到搜索(非常低的RPM)具有高延迟(和延迟差异,但我认为这与某些缓存机制有关),每次搜索在300毫秒到1500毫秒之间变化。我试图理解此查询中的痛点,以便了解是否可以使用不需要重新索引的解决方案(例如在相关的可搜索字段上使用ngram tokenizer)来降低延迟。 我也尝试过使用带有constant_score的过滤查询:
{
"query": {
"constant_score": {
"filter": {
"bool": {
"should": [
{
"wildcard": {
"document.name": {
"value": "*SEARCH_TERM*"
}
}
},
{
"wildcard": {
"externalData.properties.displayName": {
"value": "*SEARCH_TERM*"
}
}
}
],
"must": [
{
"term": {
"contributorIds": {
"value": "deadbeef-cafe-babe-cafe-deadbeefcafe"
}
}
},
{
"term": {
"document.ownerId": {
"value": "deadbeef-cafe-babe-cafe-deadbeefcafe"
}
}
},
{
"term": {
"deleted": {
"value": "false"
}
}
}
]
}
}
}
},
"size": 50,
"sort": [
{
"_doc": {
"order": "asc"
}
}
]
}
但延迟没有改变。任何人都可以了解这个查询中的痛点是什么?我试图理解可能的扩展路径(例如,再添加2个节点)与以不同方式重新索引数据(例如使用ngram tokenizer),如果可能的话我宁愿避免使用它。