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

Elasticsearch | 作者 the_best | 发布于2018年06月12日 | 阅读数：9837

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

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

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

4 个回复

kennywu76 - Wood

赞同来自: 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

赞同来自: 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的耗时分析如下：