容量规划

• 一个集群总共需要多少节点？一个索引需要设置几个分片？
• 规划上保留一定的余量，当负载出现波动，节点出现丢失时，还能正常运行；

做容量规划一定要考虑的因素

• 机器的软硬件配置；
• 单条文档的尺寸 / 文档的总数量 / 索引的总数量（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%）；