Q:有两个人掉到陷阱里了,死的人叫死人,活人叫什么?

集群18T数据,138亿条,994个索引,全索引全字段下搜索某名字,查询时间为4-10S,可以从哪些角度去优化

Elasticsearch | 作者 wudingmei1024 | 发布于2018年10月25日 | 阅读数:3406

ES版本6.1.3
5台256G机器集群, 安装了4个节点,每个节点5个实例,每个节点内存均配置为31G内存
集群下有18T数据,994个索引,每个索引的数据大小不均衡,有2T的,有几百G的不等
索引设置的分词器为:ik_max_word 
索引已关闭:_all
每个索引分片大小不超过20G
 
对全索引,全字段进行某个中文名字的全文检索:如下所示
{
“query”:{
         "query_string":{
             "query":"张三"
        }
  }
 “size”:10
}
 
第一次搜索时耗时29S,后来进行后台索引段合并。搜索时间缩减到4-10S
开启慢查询日志后,发现不同的索引查询时间差距很大,有些1-2S,有些100ms左右。
 
请问一下,还有那些可以优化的方向,可以提供参考
已邀请:

kennywu76 - Wood

赞同来自: juin wudingmei1024 Dapor

听起来像是将数据库里的表作为索引一对一导入到了ES,才会需要同时查询这么多的索引和字段。  这样做是快不了的,因为一次搜索,同时查询的shard数量太多,会有非常多的随机磁盘IO产生。    问题根源是数据模型缺乏设计, 应该根据查询的需要,对数据做抽取,转换,然后写入到同一个索引里。  如果是全字段查询,应该利用内置的"_all"字段,将所有字段的内容合并到"_all"这个统一索引,搜索的时候直接对"_all"字段检索会快很多。

wudingmei1024 - ES菜鸟

赞同来自:

我想到了一个解决思路,将所有的索引合并成一个新的索引,这种方案是否可行

zqc0512 - andy zhou

赞同来自:

900多SHARD。全部查询,用scroll吧。
感觉整体设计有问题……
 

要回复问题请先登录注册