身安不如心安,屋宽不如心宽 。

Elasticsarch 亿级数据搜索慢问题

匿名 | 发布于2020年06月18日 | 阅读数:432

大佬们,我用es做聚合查询和搜索服务(日志和业务查询),在千万级数据的时候,确实性能很好,毫秒级返回,但是当数据上亿之后,搜索性能直线下降。
日志按照时间区间搜索,要好几秒才出结果
全文检索,一个doc大约几十个英文单词,也是要4 5秒才出结果,doc都是简短的英文,用的自定义分词
"en_customer_analyzer" : {
               "type" : "pattern_capture",
               "preserve_original" : true,
               "patterns" : [
                  "(\\p{Ll}+|\\p{Lu}\\p{Ll}+|\\p{Lu}+)",
                  "(\\d+)"
               ]
}
请问有哪些优化思路? 日志打算做冷热,或者只保留近期日志
物理机128G内存 24C
已邀请:

dadaball

赞同来自:

kibana dev-tools 有個 Search profiler 可以把您的查詢語句放進去執行,可以觀測有右方的視窗,看是哪句DSL 慢,再看看有沒有機會優化語句。

tulong - 80 IT

赞同来自:

两种思路:1、既然千万级数据能保持毫秒级搜索,那么就让数据保持在千万级,采用你自己的方案保留最近一段时间的数据,删除过期数据,不过因为删除数据后,segment中实际还是存在的,只是物理数据标记了删除,分片返回数据的时候过滤掉了,这样同样会增加数据匹配的性能消耗,不知道有没有办法删除数据后强制清除segment中的索引内容(不知道这个是不是对的,我们运维说是es会自动清理被删除的索引。我理解是如果没有强制触发segment的合并,那么删除的数据还是会存在原来的索引上,匹配的时候仍然会消耗cpu);
2、扩大集群配置,增加数据节点,
 
不过也可以先看下目前的分片配置是否合理,是否需要扩大分片,看下分片上的数据是否已经超过了某个大小(我查询到的资料是说20-50G)
还可以看下搜索线程池设置是否合理(24*3)/2+1=37
 

laoyang360 - Elastic认证工程师 [死磕Elasitcsearch]知识星球地址:http://t.cn/RmwM3N9;微信公众号:铭毅天下; 博客:https://elastic.blog.csdn.net

赞同来自:

1、profile:true 看看 慢在哪里了?
2、看下日志:是否有 gc?
3、内存和堆内存设置是否合理,看有没有优化空间。
4、集群节点角色设置是否合理?
5、分片数、单分片大小是否合理?
6、你提到的冷热数据分离。
 
以上都要考虑排查一下。
匿名用户

匿名用户

赞同来自:

ES 不建议实时聚合,跟物理机数量关系不大,数据到了一定数量后,性能急剧下降。
 
非要聚合,建议拆分集群,打散业务数据。
 
无限制增加物理机,最后还是不行的。
 
我们1000多台物理机都无法满足几十亿,几百亿数据的实时聚合的。
 
最后拆分成50个小集群。
 
当然了如果基础数据几百亿,几十亿,进行聚合,那是没办法解决的。不行你可以试试看吧。
 

hnj1575565068 - 90后

赞同来自:

如果要做实时聚合可以用druid,ES的话聚合本来就很耗资源

要回复问题请先登录注册