美文网首页中台建设
ElasticSearch | 集群容量规划

ElasticSearch | 集群容量规划

作者: 乌鲁木齐001号程序员 | 来源:发表于2020-06-01 19:52 被阅读0次

    容量规划

    • 一个集群总共需要多少节点?一个索引需要设置几个分片?
    • 规划上保留一定的余量,当负载出现波动,节点出现丢失时,还能正常运行;
    做容量规划一定要考虑的因素
    • 机器的软硬件配置;
    • 单条文档的尺寸 / 文档的总数量 / 索引的总数量(Time Base 数据保留的时间)/ 副本分片数;
    • 文档是如何写入的(Bulk 的尺寸);
    • 文档的复杂度,文档是如何进行读取的(怎样的查询和聚合);

    评估业务的性能需求

    数据吞吐 & 性能需求
    • 数据写入的吞吐量,每秒要求写入多少数据;
    • 查询的吞吐量;
    • 单条查询可接收的最大返回时间;
    了解你的数据
    • 数据的格式和数据的 Mapping;
    • 实际的查询和聚合长的什么样子;

    ElasticSearch 的常见应用类型

    搜索应用 | 固定大小的数据集
    • 搜索的数据集增长相对比较缓慢;
    日志应用 | 基于时间序列的数据
    • 使用 ElasticSearch 存放日志和性能指标,数据每天不断写入,增长速度较快;
    • 结合 Warm Node 做数据的老化处理;

    硬件配置

    • 选择合理的硬件,数据节点尽量使用 SSD;
    • 搜索等性能要求高的场景,建议使用 SSD ,按照 1:10 的比例,配置内存和磁盘;
    • 日志类和查询并发低的场景,可以考虑使用机械硬盘存储,按照 1:50 的比例分配内存和磁盘;
    • 单节点数据建议控制在 2TB 以内,最大不建议超过 5TB ;
    • JVM 配置机器内存的一半,JVM 内存配置建议不超过 32 GB;

    部署方式

    • 如果需要考虑可靠性高可用,建议部署 3 台 Dedicated 的 Master 节点;
    • 如果有复杂的查询和聚合,建议设置 Coordinating Node ;

    容量规划案例 | 固定大小的数据集

    一些案例

    唱片信息库 / 产品信息库

    一些特性
    • 被搜索的数据集很大,但是增长相对比较慢(不会有大量的写入),更关心搜索和聚合的读取性能;
    • 数据的重要性和时间范围无关,关注的是搜索的相关度;
    估算索引的数据量,然后确定分片的大小
    • 单个分片的数据量不要超过 20GB;
    • 可以通过增加副本分片,提高查询的吞吐量;

    拆分索引

    • 如果业务上有大量的查询是基于一个字段进行 Filter,该字段又是一个数量有限的枚举值,比如订单所在的地区;可以把索引按地区分成多个索引,分散在更多的分片上,提升查询的性能;
    • 如果在单个索引上有大量的数据,可以考虑将索引拆分成多个索引,提高查询的性能;
    • 如果要对多个索引进行查询,还可以在查询中指定多个索引得以实现;
    • 如果业务上有大量的查询是基于一个字段进行 Filter,该字段数值并不固定,可以启用 Routing 功能,按照 Filter 字段的值分布到集群中的不同 Shard,降低查询时相关的 Shard 数,提高 CPU 利用率;

    容量规划案例 | 基于时间序列的数据

    相关案例
    • 日志、指标、安全相关的 Evenets;
    • 舆情分析;
    一些特性
    • 每条数据都有时间戳,文档基本不会被更新(日志和指标数据);
    • 用户更多的会查询近期的数据,对旧的数据查询相对较少;
    • 对数据的写入性能要求比较高;
    创建基于时间序列的索引

    创建 time-based 索引

    • 在索引的名字中增加时间信息;
    • 按照每天、每周、每月的方式进行划分;

    带来的好处

    • 更加合理的组织索引,例如随着时间的推移,便于对索引做老化处理;
      • 利用 Hot & Warm 架构;
      • 备份和删除的速度快,删除索引的速度远快于 Delete By Query 的速度,Delete By Query 在底层不会立即释放空间,而 Merge 时又很消耗资源;
    写入时间序列的数据:基于 Date Math 的方式
    • 优点:易于使用;
    • 缺点:如果时间发生变化,需要重新部署代码;

    比如现在的时间是:2019-08-01 T00:00:00,不同的格式,输出的时间的样子

    <logs-{now/d}> logs-2019.08.01
    <logs-{now{YYYY.MM}}> logs-2019.08
    <logs-{nowYYYY/w}> logs-2019..7.29 当周的第一天

    注意转义:
    POST /<logs-{now/d}/_search 要转义成 POST /%3Clogs-%7Bnow%2Fd%7D%3E/_search

    写入时间序列的数据:基于 Index Alias
    • 每天都更新 logs_write 的指向;
    POST _aliases
    {
      "actions": [
        {
          "add": {
            "index": "logs_2019-06-27",
            "alias": "logs_write"
          }
        },
        {
          "remove": {
            "index": "logs_2019-06-26",
            "alias": "logs_write"
          }
        }
      ]
    }
    

    集群扩容

    解决 CPU 和内存开销的问题
    • 增加 Coordinating Node 和 Ingest Node;
    解决存储容量的问题
    • 增加数据节点;
    • 为避免分片分布不均的问题,要提前监控磁盘空间,提前清理数据或增加节点(70%);

    相关文章

      网友评论

        本文标题:ElasticSearch | 集群容量规划

        本文链接:https://www.haomeiwen.com/subject/bowszhtx.html