提问:布和纸怕什么?

es 查询效率下降到10s,有知道什么原因么?

Elasticsearch | 作者 cjwang | 发布于2017年07月17日 | 阅读数:8383

我们目前的使用es版本是5.1.1,在centos上部署的,内存是128G, 是做垂直领域的搜索,有9个node,现在部署一个索引,索引分配了20个shard,2个备份
目前segment有5000+,20个shard目前有4.6T的大小,算上备份目前13.8T多,每个shard的大小达到了200G+
但是目前查询性能太差,基本都是10s+ 差的会到分钟级别;我们已经使用了路由功能。

想问问可能造成查询慢的原因?还有使用profile后,参考官方文档,还不知道怎么调优,希望指导下

在小数据量时,搜索很快的?

这个是查询语句
GET /index-xxxx/type-myshare/_search?routing=xxxxx
{
  "_source" : {
    "excludes": ["timestamp", "content", "title","userId"]
  },
  "from" : "0",
  "size" : "30",
  "query": {
    "bool": {
      "must": [
        {
          "term": {
            "userId": "xxxxx"
          }
        },
        {
          "query_string": {
            "query": "微信",
            "analyze_wildcard" : "true",
            "fields": ["title^2", "name^2", "content", "author", "tags"]
          }
        }
      ],
      "filter": [
        {
          "range": {
            "createTime": {
              "gte": "0",
              "lte": "2147483647"
            }
          }
        },
        {
          "range": {
            "modifyTime": {
              "gte": "0",
              "lte": "2147483647"
            }
          }
        }
      ]
    }
  },
  "sort" : [
    {"createTime" : { "order": "asc"}}
  ]
}
 
把排序 去掉之后依旧很慢
已邀请:

laududu

赞同来自: cjwang newairisme laoyang360

依我之见,将这么大的数据量放入一个索引,本身就是很不科学的规划,风险很高,效率低下。为什么不利用小索引+别名来处理?每个shards分配5G左右,每个索引100G,分50个索引。这样对于维护数据的更新周期很方便的,我们处理PB级的索引就是这么做的,做好分词,效果秒级效应。

imp

赞同来自:

查询条件复杂不  输两三个词查跟输两百个词去查也是有区别的啊

kepmoving - 90后

赞同来自:

我猜是排序,或者script导致的

wyntergreg

赞同来自:

节点heap分31G,不要32G

chendaoqiu - 90后IT

赞同来自:

优化之后,结果如何

xin_wei5

赞同来自:

设置成NIOFS类型,应该就降下来了。要重建索引

要回复问题请先登录注册