您可能会达到硬件的极限，但是首先可以对查询做一些事情来帮助优化它。
最大扩展
我要做的第一件事是限制
max_expansions。前缀查询的工作方式是生成与查询中的最后一个令牌匹配的前缀列表。在您的搜索查询“ some
search term”中，最后一个标记“ term”将使用“ term”作为前缀种子进行扩展。您可以生成如下列表：
- 术语
- 条款
- 终止
- 终结者
- 白蚁
前缀扩展过程贯穿您的发布列表，以查找与种子前缀匹配的任何单词。默认情况下，此列表是无限制的，这意味着您可以生成很大的扩展列表。
第二阶段
term使用扩展将您的原始查询重写为一系列查询。扩展列表越大，针对您的索引评估的术语越多，并且速度相应降低。
如果将扩展过程限制在合理的范围内，则可以保持速度，并且通常仍会获得良好的前缀匹配：
{ "query" : { "multi_match" : { "query" : "some search term", "fields" : [ "title", "content" ], "type": "phrase_prefix", "max_expansions" : 100 } }, "size": 20, "fields" :["article_id", "feed_id"],}您将需要玩几个扩展。这是速度和召回之间的权衡。
筛选
通常，您可以添加的另一件事是过滤。如果可以过滤某些类型的条件，则可以极大地提高速度。当前，您的查询是针对整个索引（2.5亿个文档）执行的，需要进行大量评估。如果您可以添加过滤器以减少该数量，则可以看到延迟大大改善了。
归根结底，查询评估的文档越少，查询将运行得越快。过滤器减少了查询将看到，被缓存，运行非常快等的文档数量。
您的情况可能没有任何适用的过滤器，但如果有，它们确实可以提供帮助！
文件系统缓存
该建议完全取决于系统的其余部分。如果由于进行简单的搜索和过滤（例如，不分面/地理/繁重的排序/脚本）而没有充分利用堆（24gb），则可以将堆重新分配给文件系统缓存。
例如，如果最大堆使用量峰值为12gb，则可以将堆大小减小到15gb。您释放的额外10gb将返回到操作系统并帮助缓存段，这将仅由于更多操作是无盘事实而有助于提高搜索性能。
