笔记五十五：如何对集群进行容量规划
42 / 0 / 创建于 4年前 /
CrazyZard 的个人博客
容量规划
- 一个集群总共需要多少个节点？ 一个索引需要设置几个分片？
- 规划上需要保持一定的余量，当负载出现波动，节点出现丢失时，还能正常运行
- 做容量规划时，一些需要考虑的因素
- 机器的软硬件配置
- 单条文档的尺寸 / 文档的总数据量 / 索引的总数据量（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 Architecture
- 备份和删除以及删除的效率高。（ Delete By Query 执行速度慢，底层不也不会立刻释放空间，而 Merge 时又很消 耗资源）
- 更加合理的组织索引，例如随着时间推移，便于对索引做的老化处理
写入时间序列的数据：基于 Date Math 的方式
- 容易使用
- 如果时间发生变化，需要重新部署代码
# POST /<logs-{now/d}/_search
POST /%3Clogs-%7Bnow%2Fd%7D%3E/_search写入时间序列的数据 – 基于 Index Alias
- Time-based 索引
- 创建索引，每天 / 每周 / 每月
- 在索引的名字中增加时间信息
集群扩容
- 增加 Coordinating / Ingest Node
- 解决 CPU 和 内存开销的问题
- 增加数据节点
- 解决存储的容量的问题
- 为避免分片分布不均的问题，要提前监控磁盘空间，提前清理数据或增加节点（70%）
本作品采用《CC 协议》，转载必须注明作者和本文链接
关于 LearnKu
粤公网安备 44030502004330号