索引时文档的排序会提高 Elasticsearch 搜索性能吗?
Would ordering of documents when indexing improve Elasticsearch search performance?
我正在将大约 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/min。但这可能是由于各种因素。任何提高此类工作流程性能的提示(一次加载并多次搜索)将不胜感激。
但是,我特别想知道在编制索引时是否可以先按业务键对数据进行排序,以便该业务键的数据位于一个 Lucene 段中,因此查找会更快。这样的思路对吗?考虑到它是关键字术语,这是 ES 已经做的事情吗?
分片(和段)越多,索引速度越快,分片(和段)越少,查询速度越快。
如果您正在执行 one-time 负载,您可以强制合并段 post 索引,并考虑添加更多副本 post 索引以分布搜索并增加吞吐量。
如果每个查询都将特定于业务键,则在索引时分离数据并为每个与业务键相关的文档创建一个索引可能会有所帮助。同样,在查询时将查询定向到与所查询的业务键相关的特定索引。
浏览以下链接可能会有帮助
这是一个非常好的性能优化use-case,正如您已经提到的,将会有一个您需要执行的性能优化列表。
我可以看到,您已经正确地构建了查询,即根据 businessKey
过滤记录而不是搜索剩余的文档,这样您就已经在利用 elasticsearch 的 filter-cache .
由于您有大量文档 ~40M 文档,将所有文档都放在单个段中没有意义,段的默认最大大小为 5 GB 及以上
merge 进程将在段上被阻塞,因此您几乎不可能只有 1 个段用于您的数据。
我认为您可以做的几件事是:
- 在完成摄取数据和准备搜索索引后禁用刷新间隔。
- 当您使用过滤器时,应该使用您的 request_cache 并且您应该在查询时监控缓存使用情况并监控结果来自缓存的次数。
GET your-index/_stats/request_cache?human
- 当你有更多的副本时,读取吞吐量更大,如果你的 elasticsearch 集群中有节点,确保这些节点有你的 ES 索引的副本。
- 监控每个节点上的搜索队列并确保其不会耗尽,否则您将无法增加吞吐量,请参阅threadpools in ES了解更多信息
你的主要问题是吞吐量,你想超过 21k/min 的当前限制,所以它需要大量的索引和集群配置优化,我已经写了 short tips to improve search performance 请参考他们和让我知道进展如何。
我正在将大约 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/min。但这可能是由于各种因素。任何提高此类工作流程性能的提示(一次加载并多次搜索)将不胜感激。
但是,我特别想知道在编制索引时是否可以先按业务键对数据进行排序,以便该业务键的数据位于一个 Lucene 段中,因此查找会更快。这样的思路对吗?考虑到它是关键字术语,这是 ES 已经做的事情吗?
分片(和段)越多,索引速度越快,分片(和段)越少,查询速度越快。 如果您正在执行 one-time 负载,您可以强制合并段 post 索引,并考虑添加更多副本 post 索引以分布搜索并增加吞吐量。
如果每个查询都将特定于业务键,则在索引时分离数据并为每个与业务键相关的文档创建一个索引可能会有所帮助。同样,在查询时将查询定向到与所查询的业务键相关的特定索引。
浏览以下链接可能会有帮助
这是一个非常好的性能优化use-case,正如您已经提到的,将会有一个您需要执行的性能优化列表。
我可以看到,您已经正确地构建了查询,即根据 businessKey
过滤记录而不是搜索剩余的文档,这样您就已经在利用 elasticsearch 的 filter-cache .
由于您有大量文档 ~40M 文档,将所有文档都放在单个段中没有意义,段的默认最大大小为 5 GB 及以上 merge 进程将在段上被阻塞,因此您几乎不可能只有 1 个段用于您的数据。
我认为您可以做的几件事是:
- 在完成摄取数据和准备搜索索引后禁用刷新间隔。
- 当您使用过滤器时,应该使用您的 request_cache 并且您应该在查询时监控缓存使用情况并监控结果来自缓存的次数。
GET your-index/_stats/request_cache?human
- 当你有更多的副本时,读取吞吐量更大,如果你的 elasticsearch 集群中有节点,确保这些节点有你的 ES 索引的副本。
- 监控每个节点上的搜索队列并确保其不会耗尽,否则您将无法增加吞吐量,请参阅threadpools in ES了解更多信息
你的主要问题是吞吐量,你想超过 21k/min 的当前限制,所以它需要大量的索引和集群配置优化,我已经写了 short tips to improve search performance 请参考他们和让我知道进展如何。