performance - ElasticSearch 搜索性能

Question

我们有一个双节点集群(私有(private)云中的虚拟机、64GB 内存、每个节点 8 核 CPU、CentOS)、一些小索引(约 100 万文档)和一个包含约 2.2 亿文档的大索引(2分片，170GB 空间)。 24GB内存分配给每个box上的elasticsearch。

文档结构:

 {
        'article_id': {
            'index': 'not_analyzed',
            'store': 'yes',
            'type': 'long'
        },
        'feed_id': {
            'index': 'not_analyzed',
            'store': 'yes',
            'type': 'string'
        },
        'title': {
            'index': 'analyzed',
            'type': 'string'
        },
        'content': {
            'index': 'analyzed',
            'type': 'string'
        },
        'lang': {
            'index': 'not_analyzed',
            'type': 'string'
        }
    }

运行以下查询大约需要 1-2 秒:

{
    "query" : {
        "multi_match" : {
            "query" : "some search term",
            "fields" : [ "title", "content" ],
            "type": "phrase_prefix"
        }
    },
    "size": 20,
    "fields" :["article_id", "feed_id"]
}

此时我们是否达到了硬件限制，或者是否有优化查询或数据结构以提高性能的方法？

提前致谢!

Answer 1

您可能会达到硬件的极限，但您可以先对查询执行一些操作以帮助优化它。

最大扩展

我要做的第一件事是限制 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"],

}

您将不得不考虑您想要的扩展数量。这是速度和召回率之间的权衡。

过滤

一般来说，您可以添加的另一件事是过滤。如果您可以根据某种类型的标准进行过滤，则可能会大大提高速度。目前，您的查询正在针对整个索引(250m 文档)执行，这需要进行大量评估。如果您可以添加过滤器来减少该数字，您会发现延迟得到了很大改善。

归根结底，查询评估的文档越少，查询运行的速度就越快。过滤器减少了查询将看到的文档数量、被缓存、操作非常快等。

您的情况可能没有任何适用的过滤器，但如果有，它们真的可以提供帮助!

文件系统缓存

这个建议完全依赖于系统的其余部分。如果您没有充分利用您的堆 (24gb)，因为您正在进行简单的搜索和过滤(例如，不是分面/地理/重分类/脚本)，您可以将您的堆重新分配给文件系统缓存。

例如，如果您的最大堆使用量峰值为 12gb，则将堆大小减小到 15gb 可能是有意义的。您释放的额外 10gb 将返回给操作系统并帮助缓存段，这将有助于提高搜索性能，因为更多操作是无盘的。