索引时文档的排序是否会提高elasticsearch的性能?

piztneat  于 2021-06-10  发布在  ElasticSearch
关注(0)|答案(2)|浏览(480)

我正在将大约4000万个文档编入elasticsearch。它通常是一次性的数据加载,然后我们在上面运行查询。索引本身没有进一步的更新。不过,elasticsearch的默认设置并没有让我获得预期的吞吐量。
因此,在一长串需要调优和验证的内容中,我想知道按业务键排序是否有助于提高搜索吞吐量。我们所有的分析查询都使用这个键,它已经被索引为一个关键字,我们对它进行如下筛选,

{
    "query" : {
        "bool" : {
            "must" : {
                "multi_match" : {
                  "type": "cross_fields",
                  "query":"store related query", 
                  "minimum_should_match": "30%",      
                  "fields": [ "field1^5", "field2^5", "field3^3", "field4^3", "firstLine", "field5", "field6", "field7"] 
                }
            },
            "filter": {
                "term": {
                    "businessKey": "storename"
                }
            }

        }
    }
}

这个查询在几个小时内以批量方式运行了大约2000万次。目前我不能超过21k/分钟,但这可能是因为各种因素。任何提示,以提高这种工作流程的性能(加载一次,搜索很多)将不胜感激。
不过,我特别想知道,在索引时是否可以先按业务键对数据进行排序,以便该业务键的数据位于一个lucene段中,因此查找会更快。这种想法正确吗?这是es已经做过的,因为它是关键字吗?

y3bcpkx1

y3bcpkx11#

这是一个非常好的性能优化用例,正如您已经提到的,这里将列出您需要进行的性能优化。
我可以看到,您已经正确地构建了查询,该查询基于 businessKey 而不是搜索剩余的文档,这样你已经利用了elasticsearch的过滤器缓存。
由于您有大量文档(约4000万个文档),将所有文档放在单个段中是没有意义的,默认的最大段大小为5 gb,超过此值,合并过程将在段上被阻止,因此您几乎不可能只有一个数据段。
我认为你可以做的几件事是:
在接收数据并准备索引进行搜索时禁用刷新间隔。
在使用过滤器时,应该使用请求缓存,并且在查询时应该监视缓存使用情况,并监视结果来自缓存的次数。

GET your-index/_stats/request_cache?human

当您有更多的副本时,读取吞吐量会更高,如果您的elasticsearch集群中有节点,请确保这些节点有es索引的副本。
监视每个节点上的搜索队列,确保其未耗尽,否则将无法增加吞吐量,有关详细信息,请参阅es中的线程池
你的主要问题是围绕吞吐量和你想超过目前的限制,21k/分钟,所以它需要大量的索引和集群配置优化,以及我写了简短的提示,以提高搜索性能请参考他们,让我知道如何去。

stszievb

stszievb2#

索引速度更快,碎片(段)越多,查询速度更快,碎片(段)越少。如果是一次性加载,可以在索引后强制合并段,还可以考虑在索引后添加更多副本,以分发搜索并提高吞吐量。
如果每个查询都特定于一个业务键,那么在为每个与业务键相关的文档编制索引和创建索引时隔离数据可能会有所帮助。类似地,在查询时,将查询定向到与所查询的业务键相关的特定索引。
浏览以下链接可能会有所帮助
调谐搜索
索引调整
优化搜索

相关问题