业务数据量与ES集群规模及配置的对应关系大致是怎样?

作为一个ES小白,没有实战经验,对数据量与ES的集群规划没有啥概念,希望有实战过的兄弟不吝赐教。
我们现在线上ES的情况为:
数据量1TB左右,文档数20亿左右,线上3个ES节点(阿里云的8核32G配SSD云盘),划分了4个索引,每个索引10个主分片(副本数1,每个分片差不多10几G),采用父子文档结构。另外集群上还有一些文档数较小的索引(百万级左右)。目前那4个大索引每天请求数也就几十次吧(写比较频繁,50~500/s),小索引的查询频次在10~40次/s
360截图20180612210754049.jpg

 
遇到的问题:
现在大索引的查询请求都很慢(用户反映经常刷不出来,每次一查,load average就涨到10以上,集群跑一段时间后内存就会涨上去,老年代GC回收变得频繁),而且会影响到小索引的查询请求。
360截图.jpg

 
疑问:
(1)是不是该加节点了(3个会不会太少),3个节点纵向升级两回了,运维出于成本考虑,都不太愿意给加机器。本人也没有实战经验,这样的数据规模大概ES集群的硬件配置应该是怎样的?
(2)截止目前,最近线上集群已经崩掉两回了,每次都是主节点先挂掉。是否有必要将主节点与数据节点独立划分出来(之前是混在一起的)
(3)目前业务上还没有到做数据冷热分离的地步。对于现有的数据量,我的索引及分片划分方式是不是不合理?应该如何更好地划分。
已邀请:

kennywu76 - wood@Ctrip

赞同来自: laoyang360 strglee zyb1994111

根据你的描述,集群的QPS并不高,那么这个数据量级对应这个硬件配置应该还算好。主要问题在于每天几十个大索引的查询会引起集群负载很高,通常是数据模型可能做得不够优化,或者Query写得不够好。 需要结合大索引的shard数量,doc数量,mapping,以及Query DSL本身做了那些过滤,查询,聚合来分析系统开销在哪里。
 
从你贴的监控图标看,10:00 - 14:00那段时间, old gc非常频繁,但是GC过后,heap占用率并没有下降,并且一直呈缓慢上升趋势,说明有不能被回收的对象一直在增加。 直到接近16:00的时候,监控曲线断开(应该是有结点内存OOM了导致监控数据缺失)。  如果这个是你所说的每次都是“主结点”挂掉的情况,我凭经验推断,比较大的可能性是集群有大量的状态更新任务在堆积,耗尽了主结点的内存。  你可以用 /_cat/pending_tasks 确认一下。
 
如果是我推测的这种情况,那么看下这些是什么任务,找出产生这些任务的根源,对症下药。
 
 

kennywu76 - wood@Ctrip

赞同来自: the_best

@the_best  根据profile的输出看,问题应该主要出在parent-child Query上。  你这个数据里parent的数量是否非常多? parent-child之间的关系链接要依靠一种叫做global ordinals的数据结构,这种数据结构默认是在查询阶段,实时构造,放在内存里,用于加速parent id和child id之间join。   如果parent的数量非常多,这个内存消耗是非常显著的。
这块的内存消耗可以用下面的方法查看:
# Per-index
GET _stats/fielddata?human&fields=my_join_field#question

# Per-node per-index
GET _nodes/stats/indices/fielddata?human&fields=my_join_field#question

parent-child适用的场景是少数parent对很多child, 如果你的数据特性是很多的parent,然后每个parent的child不是很多,那么查询的开销会非常高。 
 
相关资料参考: https://www.elastic.co/guide/e ... .html
 
另外status字段应该设置为keyword, 原因参考:https://elasticsearch.cn/article/446 。 不过相对来说,主要的问题还是上面说的parent-child连接。

the_best

赞同来自:

现在简单的查询都很慢。以下简单查询之前十几秒才能出来,现在把这些大索引的写任务停掉了,查询变快了一些(7s左右)
{
  "from": 0,
  "size": 50,
  "query": {
    "bool": {
      "must": [
        {
          "bool": {
            "must": [
              {
                "bool": {
                  "must": [
                    {
                      "query_string": {
                        "query": "5",
                        "fields": [
                          "status^1.0"
                        ],
                        "use_dis_max": true,
                        "tie_breaker": 0.0,
                        "default_operator": "or",
                        "auto_generate_phrase_queries": false,
                        "max_determinized_states": 10000,
                        "enable_position_increments": true,
                        "fuzziness": "AUTO",
                        "fuzzy_prefix_length": 0,
                        "fuzzy_max_expansions": 50,
                        "phrase_slop": 0,
                        "escape": false,
                        "split_on_whitespace": true,
                        "boost": 1.0
                      }
                    },
                    {
                      "has_child": {
                        "query": {
                          "bool": {
                            "must": [
                              {
                                "query_string": {
                                  "query": "152836522601000003",
                                  "fields": [
                                    "signer_user_id^1.0"
                                  ],
                                  "use_dis_max": true,
                                  "tie_breaker": 0.0,
                                  "default_operator": "or",
                                  "auto_generate_phrase_queries": false,
                                  "max_determinized_states": 10000,
                                  "enable_position_increments": true,
                                  "fuzziness": "AUTO",
                                  "fuzzy_prefix_length": 0,
                                  "fuzzy_max_expansions": 50,
                                  "phrase_slop": 0,
                                  "escape": false,
                                  "split_on_whitespace": true,
                                  "boost": 1.0
                                }
                              }
                            ],
                            "disable_coord": false,
                            "adjust_pure_negative": true,
                            "boost": 1.0
                          }
                        },
                        "type": "contract_signer",
                        "score_mode": "none",
                        "min_children": 0,
                        "max_children": 2147483647,
                        "ignore_unmapped": false,
                        "boost": 1.0
                      }
                    }
                  ],
                  "disable_coord": false,
                  "adjust_pure_negative": true,
                  "boost": 1.0
                }
              }
            ],
            "disable_coord": false,
            "adjust_pure_negative": true,
            "boost": 1.0
          }
        }
      ],
      "disable_coord": false,
      "adjust_pure_negative": true,
      "boost": 1.0
    }
  },
  "sort": [
    {
      "utime": {
        "order": "desc"
      }
    }
  ],
  "highlight": {
    
  }
}
profile API的耗时分析如下:

profile1.jpg


profile2.jpg

感觉分片耗时都消耗在build_scorer阶段或next_doc阶段。
 

yang009ww

赞同来自:

兄弟,请问你这个profile api图形可视化是用的什么工具呀?求告知,谢谢!

要回复问题请先登录注册