Elasticsearch-31.分片设定及管理 he 如何对集群进行容量规划

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