技术交流群中有小伙伴提及:“es 节点默认1000 个分片的限制”?这引发了我对Elasticsearch 默认值的关注。
我一搜不要紧:聊天记录中涉及“默认”关键词的讨论接近 400 多处。
这些默认值对于架构选型、开发实战、运维排查性能问题等都有很好的借鉴价值,虽官方文档都有详细论述,但散落在各个角度。
处于本能的好奇心,我认为非常有必要结合自己的实战经历梳理出 Elasticsearch 最常用的默认值的适用场景、参数、默认值大小、静态/动态参数类型、实战建议等知识点。
没别的,让更多人提前建立全局(相对)认知、少走弯路。
参数类型分为:集群级别参数、索引级别、Maping级别参数等。
前缀是:cluster.*,修改针对集群生效。
需要在: elasticsearch.yml 配置文件中设置,重启 ES 生效。
index.number_of_shards 是静态参数。
index.number_of_replicas 是动态参数。
以下内容分别从:集群层面、索引层面、映射层面、其他常用逐步展开讲解。
https://www.elastic.co/guide/en/elasticsearch/reference/current/search-settings.html
1)每个节点可以存储的分片数和可用的堆内存大小成正比关系。
2)Elastic 官方博客文章建议:堆内存和分片的配置比例为1:20,举例:30GB堆内存,最多可有600个分片。
https://www.elastic.co/guide/en/elasticsearch/reference/7.0/misc-cluster.html#cluster-shard-limit
https://github.com/elastic/kibana/issues/35529
(2)不合理分配可能问题:
1)分片数量过多,写入放大,导致 bulk queue打满,拒绝率上升;
2)一定数据量级后,分片数量过少,无法充分利用多节点资源,机器资源不均衡。
(1) indices.memory.index_buffer_size
(2) indices.memory.min_index_buffer_size
(3) indices.memory.max_index_buffer_size
(1)indices.memory.index_buffer_size: 10%
(2)indices.memory.min_index_buffer_size : 48 Mb
(1)必须在集群中的每个数据节点上进行配置。
(2)写入优化中首选的优化参数之一,有助于提高写入性能和稳定性。
https://www.elastic.co/guide/en/elasticsearch/reference/current/indexing-buffer.html
(1)cluster.routing.allocation.disk.watermark.low:85%
(2)cluster.routing.allocation.disk.watermark.high:90%
(3)cluster.routing.allocation.disk.watermark.flood_stage:95%
(1)85%:禁止写入;90%:索引分片迁移到其他可用节点;95%:索引只读。
(2)磁盘使用率也是监控的一个核心指标之一。
-XX:+UseConcMarkSweepGC
-XX:CMSInitiatingOccupancyFraction=75
-XX:+UseCMSInitiatingOccupancyOnly
(1)官方建议:
目前,我们仍然认为CMS垃圾收集器是大多数部署的最佳选择,但是自ES 6.5.0(如果在JDK 11或更高版本上运行)以来,我们现在也支持G1GC。
https://github.com/elastic/elasticsearch/issues/44321
(2)配置位置:jvm.options, 优化参考 wood 大叔建议:更改为
-XX:+UseG1GC
-XX:MaxGCPauseMillis=50
其中 -XX:MaxGCPauseMillis 是控制预期的最高GC时长,默认值为 200ms ,如果线上业务特性对于GC停顿非常敏感,可以适当设置低一些。但是 这个值如果设置过小,可能会带来比较高的cpu消耗。
G1 对于集群正常运作的情况下减轻 G1 停顿对服务时延的影响还是很有效的,但是如果是 GC 导致集群卡死,那么很有可能换G1 也无法根本上解决问题。通常都是集群的数据模型或者 Query 需要优化。
https://elasticsearch.cn/question/4589
(1)只能在创建索引时设置此值。
(2)单索引1024个最大分片数的限制是一项安全限制,可防止因资源分配问题导致集群不稳定。
(3)可通过在每个节点上指定export ES_JAVA_OPTS =“-Des.index.max_number_of_shards = 128”系统属性来修改此限制。
(1)可以将其设置为best_compression,它使用DEFLATE以获得更高的压缩率,但代价是存储字段的性能较慢。
(2)不追求压缩效率,追求磁盘占用比低的用户推荐 best_compression 压缩。
根据业务需要合理设置副本,基于数据安全性考虑,建议副本至少设置1。
(1)深度翻页的机制,决定了越往后越慢。除非特殊业务需求,不建议修改默认值,可以参考百度和google的实现。
(2)全部数据遍历推荐scroll API。仅支持向后翻页推荐:Search After API。
(1)结合实际业务需要,一些基础需要ETL的功能建议加上。
(2)如果不加index.default_pipeline也可以,update_by_query + 自定义 pipeline 结合也能实现。不过(1)是更周全、简练的方案。
(1)index.mapping.nested_fields.limit
一个索引最大支持的nested类型个数
(2)index.mapping.nested_objects.limit
一个nested类型支持的最大对象数
(1)index.mapping.nested_fields.limit : 50
(2)index.mapping.nested_objects.limit : 10000
(1)nested 的可能的性能问题不容小觑。
nested本质:每个嵌套对象都被索引为一个单独的Lucene文档。如果我们为包含100个用户对象的单个文档建立索引,则将创建101个Lucene文档。
(2) nested 较 父子文档不同之处:
如果子文档频繁更新,建议使用父子文档。
如果子文档不频繁更新,查询频繁建议 nested类型。
{
"my_index_0001" : {
"mappings" : {
"properties" : {
"cont" : {
"type" : "text",
"fields" : {
"keyword" : {
"type" : "keyword",
"ignore_above" : 256
}
}
}
}
}
}
}
1)ES5.X版本以后,keyword支持的最大长度为32766个UTF-8字符,text对字符长度没有限制。
2)设置ignore_above后,超过给定长度后的数据将不被索引,无法通过term精确匹配检索返回结果。
https://blog.csdn.net/laoyang360/article/details/78207980
一句话概括:别名可以零停机改造(经典技巧,无缝切换)。https://www.elastic.co/guide/en/elasticsearch/reference/6.8/indices-aliases.html
https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-node.html
https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-node.html
POST /_analyze
{
"text": "屹立在东方之林",
"analyzer": "standard"
}
切分结果:
屹
立
在
东
方
之
林
GET my_index/_search?size=0
{
"aggs": {
"by_day": {
"date_histogram": {
"field": "date",
"calendar_interval": "day",
"time_zone": "+08:00"
}
}
}
}
7.0 版本。7.0 版本之后开始默认捆绑了 JDK(安装包里自带JDK),因此我们可以不单独安装 JDK。
没有别的,我就是好奇!
大而全的建议参考官方文档,上述25个默认值都是死磕Elasticsearch交流群中提到的实战问题。
您的实战中有遇到默认值的困惑,欢迎留言交流。
索引(动态/静态)设置参考:
https://www.elastic.co/guide/en/elasticsearch/reference/current/index-modules.html
本文分享自 铭毅天下Elasticsearch 微信公众号,前往查看
如有侵权,请联系 cloudcommunity@tencent.com 删除。
本文参与 腾讯云自媒体同步曝光计划 ,欢迎热爱写作的你一起参与!