Elasticsearch
分片设定及管理
单个分片
- 7.0 开始，新创建一个索引时，默认只有一个主分片
- 单个分片，查询算分，聚合不准的问题都可以得以避免
- 单个索引， 单个分片时候，集群无法实现水平扩展
- 即使增加新的节点，无法实现水平扩展
两个分片
- 集群增加一个节点后， Elasticsearch会自动进行分片的移动，也叫Shard Rebalancing
如何设计分片数
- 当分片数 >节点数时
- 一旦集群中有新的数据节点加入，分片就可以自动进行分配
- 分片 在重新分配时，系统不会有downtime
- 多 分片的好处:一个索引如果分布在不同的节点，多个节点可以并行执行
- 查询可以并行执行
- 数据写入可以分散到多个机器
一些例子
- 案例1
- 每天1 GB的数据，一个索引一个主分片，一个副本分片
- 需保留半年的数据，接近360 GB的数据量，
- 案例2
- 5个不同的日志，每天创建-一个日志索引。每个日志索引创建10个主分片
- 保留半年的数据
- 51030*6=9000个分片
分片过多所带来的副作用
- Shard 是Elasticsearch 实现集群水平扩展的最小单位
- 过多设置分片数会带来–些潜在的问题
- 每个分片是一个Lucene 的索引，会使用机器的资源。过多的分片会导致额外的性能开销
- Lucene Indices / File descriptors / RAM / CPU
- 每次搜索的请求，需要从每个分片上获取数据
- 分片的Meta 信息由Master 节点维护。过多，会增加管理的负担。经验值，控制分片总数在10 W以内
如何确定主分片数
- 从存储的物理角度看
- 日志类应用， 单个分片不要大于50 GB
- 搜索类应用， 单个分片不要超过20 GB
- 为什么要控制分片存储大小.
- 提高Update 的性能
- Merge时，减少所需的资源
- 丢失节点后， 具备更快的恢复速度/便于分片在集群内Rebalancing
如何确定副本分片数
- 副本是主分 片的拷贝
- 提高系统可用性: 相应查询请求，防止数据丢失
- 需要占用和主分片一样的资源
- 对性能的影响
- 副本会降低数据的索引速度:有几份副本就会有几倍的CPU资源消耗在索引.上
- 会减缓对主分片的查询压力，但是会消耗同样的内存资源
- 如果机器资源充分，提高副本数，可以提高整体的查询QPS
调整分片总数设定，避免分配不均衡
如何对集群进行容量规划
容量规划
- 一个集群总共需要多少个节点?一个索引需要设置几个分片?
- 规划上需要保持- -定的余量，当负载出现波动，节点出现丢失时，还能正常运行
- 做容量规 划时，一些需要考虑的因素
- 机器的软硬件配置
- 单条文档的尺寸/文档的总数据量/索引的总数据量(Time base数据保留的时间) /副本分片数
- 文档是如何写入的(Bulk的尺寸)
- 文档的复杂度，文档是如何进行读取的(怎么样的查询和聚合)
评估业务的性能需求
- 数据 吞吐及性能需求
- 数据写入的吞吐量，每秒要求写入多少数据?
- 查询的吞吐量?
- 单条查询可接受的最大返回时间?
- 了解你的数据
- 数据的格式和数据的Mapping
- 实际的查询 和聚合长的是什么样的
常见用例
- 搜索: 固定大小的数据集
- 搜索 的数据集增长相对比较缓慢
- 日志: 基于时间序列的数据
- 使用ES存放日志与性能指标。数据每天不断写入，增长速度较快
- 结合Warm Node做数据的老化处理
硬件配置
- 选择合理的硬件， 数据节点尽可能使用SSD
- 搜索等性能要求高的场景，建议SSD
- 按照1:10的比例配置内存和硬盘
- 日志类和查询并发低的场景，可以考虑使用机械硬盘存储
- 按照1:50的比例配置内存和硬盘
- 单节点数据建议控制在2 TB以内，最大不建议超过5 TB
- JVM配置机器内存的一半，JVM 内存配置不建议超过32 G
部署方式
- 按需选择合理的部署方式
- 如果需要考虑可靠性高可用， 建议部署3台dedicated的Master 节点
- 如果有复杂的查询和聚合，建议设置Coordinating 节点
容量规划案例1:固定大小的数据集
- 一些案例:唱片信息库/产品信息
- 一些特性
- 被搜索的数据集很大， 但是增长相对比较慢(不会有大量的写入)。更关心搜索和聚合的读取性能
- 数据的重要性与时间范围无关。关注的是搜索的相关度
- 估算索引的的数据量，然后确定分片的大小
- 单个分片的数据不要超过 20 GB
- 可以通过增加副本分片，提高查询的吞吐量
拆分索引
- 如果业务 上有大量的查询是基于一个字段进行Filter, 该字段又是一个数量有限的枚举值
- 例如订 单所在的地区
- 如果在单个索引有大量的数据，可以考虑将索引拆分成多个索引
- 查询性能可以得到提高
- 如果要对多个索引进行查询，还是可以在查询中指定多个索引得以实现
- 如果业务 上有大量的查询是基于-一个字段进行Filter, 该字段数值并不固定
- 可以启用Routing 功能，按照filter 字段的值分布到集群中不同的shard, 降低查询时相关的shard,提高CPU利用率
容量规划案例2:基于时间序列的数据
- 相关的用案
- 日志/指标/安全相关的Events
- 舆情分析
- 一些特性
- 每条数据都有时间戳;文档基本不会被更新(日志和指标数据)
- 用户更多的会查询近期的数据;对旧的数据查询相对较少
- 对数据的写入性能要求比较高
创建基于时间序列的索引
- 创建time-based 索引
- 在索引的名字中增加时间信息
- 按照 每天/每周/每月的方式进行划分
- 带来的好处
- 更加合理的组织索引，例如随着时间推移，便于对索引做的老化处理
- 利用Hot & Warm Archi tecture
- 备份和删除以及删除的效率高。( Delete By Query 执行速度慢，底层不也不会立刻释放空间，而Merge 时又很消耗资源) .
写入时间序列的数据:基于Date Math的方式
- 容易使用
- 如果时间发生变化，需要重新部署代码
写入时间序列的数据-基于Index Alias
集群扩容
- 增加 Coordinating / Ingest Node
- 解决CPU和内存开销的问题
- 增加数据节点
- 解决存储的容量的问题
- 为避免分片分布不均的问题，要提前监控磁盘空间，提前清理数据或增加节点(70%)
本节知识点
- 根据ES的使用场景，建议将搜索类和日志类的应用部署在不同的ES群上
- 可以针对写入和读取做优化
- 根据场景选择合适的部署方式
- 硬件配置， 数据节点推荐使用SSD
- 对于日志类的应用，可以选择使用冷热架构
- 索引的设计，分片的设计也至关重要
- 时间序列的索引/单个分片的尺寸，搜索类保持在20G以内，日志类保持在50 G以内
demoAPI
PUT logs_2019-06-27
PUT logs_2019-06-26
POST _aliases
{
"actions": [
{
"add": {
"index": "logs_2019-06-27",
"alias": "logs_write"
}
},
{
"remove": {
"index": "logs_2019-06-26",
"alias": "logs_write"
}
}
]
}
# POST /<logs-{now/d}/_search
POST /%3Clogs-%7Bnow%2Fd%7D%3E/_search
# POST /<logs-{now/w}/_search
POST /%3Clogs-%7Bnow%2Fw%7D%3E/_search
本文章为转载内容，我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题，欢迎原作者联系我们进行内容更正或删除文章。
