导言
ES 是在系统架构设计时常用到的数据搜索与存储系统，对于输入的数据，ES会按照预先定义好的设置（如果没有预先设置好，可以设置动态映射）进行分词，建立倒排索引和Doc_values，以方便搜索查询。ES本身具备对索引进行分片和备份的功能，使用者可以在索引建立时进行设置。ES 底层使用了Luence对数据进行管理，对宿主机的内存和磁盘IO有较高的要求，这使得每个ES的节点成本会比较高，因此在规划阶段需要对要使用的ES节点数目进行评估，以了解后续的成本状况。
节点
不考虑使用MachineLearning的情况，ES 的节点角色设置有以下几种：
-
Master（主节点）
集群的主节点，负责集群的编排。对应节点配置中的node.master设为true
-
Data（数据节点）
数据节点，负责数据的搜索与写入。对应节点配置中的node.data设为true
-
Ingest（ingest节点）
负责进行请求的预处理（pipeline）。对应节点配置中的node.ingest设为true
-
coordinate（协调节点）
接收外部请求，并将请求分配到相应应的节点，并对节点返回的数据进行合并处理。当前三个角色的配置都是false的情况下，该节点会承担专门协调的角色。实际情况下，所有节点都具备coordinator请求的能力。
对于小规模的集群，由于设备有限，往往node.master，node.data，node.ingest都设置为true，方便管理。对于较大规模的集群，由于这几个角色对计算资源的要求不同，往往分配单独角色节点以最优化资源利用。
同时，考虑到冷热数据不同的索引需求，一般会将数据节点再按冷热温（Hot，Warm，Cold）进行划分，同时结合索引的生命周期管理（ILM）模块进行搭配使用。（ILM参考：https://www.jianshu.com/p/9f7f39efeda3)
-
Hot节点
处理当前最新数据的写入和查询，一般会配置大内存和固态硬盘，具有较高的磁盘IO，SSD一般会具备200，000到400，000的IOPS，如果以存储量来算，单块SSD能够达到1-2GBps。
相对而言，普通HDD的顺序写入速度大概约240MBps，如果是随机写入则速度更低，可以通过配置Raid0来提示HDD的性能。由于ES本身在逻辑成本实现了高可用，因此不需要再通过搭建raid5的方式提供磁盘的高可用。
-
Warm节点
一般用来存储非最新数据，不会有实时写入的请求，有时候会处理一些查询，索引处于只读状态。一般会使用HDD配合中等配置的内存。
-
Cold节点
Cold节点用来存放归档的数据，以满足一些法律法规。如果数据并没有留存的需求，一般超过一定的时限就会删除相关的索引。Cold节点需要廉价的大容量存储，索引处于关闭状态，没有实时的查询需求。
ES的数据节点往往有较大的负载压力，一般建议节点不要共用硬件设备，一防止因为硬件原因导致多个节点同时离线。
由于Java压缩指针的原因，分配给节点JVM的堆内存不建议超过32GB，一般推荐分配一般的内存给JVM，另外一般内存用来做page cache。节点的swap需要禁止，其原因在于如果不禁止swap，节点就可能交换JVM的堆内存而不是page cache，这会导致更长的系统响应时间。
业务场景
对于数据来说，对应操作包括，增（index)，删（delete），改（update），查（search/query）。对于ES来说，比较重要的两个场景为新增（数据写入）和查询。
数据写入
如下图所示，数据的写入有以下流程：
- coordinator节点接收到外界的写入请求。
- 如果集群有配置ingest pipeline，coordinator节点会将请求发放到ingest节点进行预处理。
- 如果没有配置pipeline或者在预处理结束后，相应节点会根据routing规则决定该请求需要写入到哪个分片（shard）（一般会根据_id值做hash。shard_id = hash(routing) % number_of_shard），并且请求分配到对应节点。
- shard对应节点处理写入请求。
- 写入请求完成后，向副本分片所在节点发出replication请求。
- 副本分片所在节点处理副本写入请求。
数据搜索
对数据进行搜索时，会有不同于写入时的处理流程。不会进行pipeline处理。相关流程为：
- coordinator节点接收到查询请求。
- 在本地找到需要查询的分片后，coordinator节点将请求分配到相关shard所在节点。
- 各shard处理完搜索后，将结果返回给coordinator节点。
- coordinator节点会将各shard返回来的结果进行合并。
- coordinator节点将合并好的结果返回给请求客户端。
资源
可以看出coordinator节点负责处理外界的request，并将相应的操作指派到相应节点上去。在搜索或者聚合的情况下，还要合并从各个节点返回的结果，再将结果返回给客户端。因此可以看出，coordinator节点对于网络带宽，CPU，和内存的要求都较高。对于大规模集群来说，coordinator节点本身负载压力就比较大，不适合在担任其他角色。
ingest节点负责在文档写入之前对数据进行预处理，功能比较单一，主要是CPU和内存。
数据节点负责具体的写入和搜索逻辑，对内存要求比较高，数据节点的CPU能力决定了其可以承载的并发数。同时数据节点也承担了数据的存储职能，对磁盘IO有一定的要求。由于数据在做replication时，会有n倍的流量在集群内部备份节点之间发生，因此数据节点对网络也有一定的要求，这取决于数据的副本数。
下表是各种角色的节点对资源的依赖情况下，仅代表个人观点。
| 角色 | CPU | 内存 | IO | 网络 |
|---|---|---|---|---|
| coordinator | 高 | 高 | 一般 | 高 |
| ingest | 一般 | 一般 | 一般 | 一般 |
| data | 一般 | 高 | 高 | 高 |
| master | 一般 | 取决于集群大小 | 一般 | 一般 |
对数据量进行估算
在规划ES集群之前，我们需要问自己几个问题：
- 我的数据是什么样的。
- 每天会有多少新增数据？
- 这些数据需要保留多少天？
- 给这些数据设置几个副本？
- 原始数据在写入ES后大小会有所变化，比如，要建立倒排索引。keyword字段和其他结构化字段会构建doc_values正排索引，这些都会导致落盘后的数据发生变化。
- 我的资源是怎么样的
- 数据节点有多少堆内存
- 我需要留出部分磁盘空间给系统和后台，按5%计算。
- ES默认的磁盘low.watermark是85%，超过该阈值后，将不允许向该节点分配shard。
- 考虑到系统的高可用，需要考虑在一个或多个节点下线的情况下，离线的分片可以得到重新分配。
获得了这些数据后，我们就可以进行计算了。
- 总数据量 = 每天新增原始数据量 * 保留天数 * （副本数+1）*膨胀系数
- 磁盘空间 = 总数据量 / (1-15%-5%) = 总数据量 * 1.25
- 所需节点数 = 磁盘空间 / (节点内存/内存磁盘比)
- 一个经验数字是，使用SSD的Hot类型节点（内存/磁盘）为1/30。使用HDD的Warm类型节点（内存/磁盘）比为1/160。而用来归档，使用廉价硬盘存储的Cold类型节点（内存/磁盘）为1/1000。
- 一个经验数字，所需的磁盘空间一般为原始数据大小的3.38倍。仅供参考，具体使用的磁盘空间。
使用多个类型（Hot，Warm，Cold）分片时，需要按照每个阶段分别进行计算。
对分片数进行估算
在进行分片估计时，我们需要先准备以下数据：
- 有多少个索引
- 每个索引设置多少个shard以及几个replication
- 每个索引保留多长时间
- 每个数据节点有多少内存
现在我们有以下一些经验数据：
- 每1GB堆内存最多包含20个分片（每个分片50MB，是一个非常小的值，建议按情况适当提高该数值）
- 每个分片不超过50GB。（一般30-40GB）
可以计算得到：
- 总分片数 = 索引数量 * shard数 * （副本数 + 1）
- 所需节点 = 总分片数 / (节点堆内存[GB]/每GB堆内存承载分片数 )
ES权威指南里提到了一种通过实践的评估方式，可以参考：https://www.elastic.co/guide/cn/elasticsearch/guide/cn/capacity-planning.html
根据搜索量进行估算
我们需要预先假设几个数据：
- 峰值每秒请求数。
- 平均请求延时。
我们预先知道每个节点的线程池大小，搜索线程池大小一般配为:
线程池大小 = int（核数 * 3/2） + 1，该公式来源于https://www.elastic.co/guide/cn/elasticsearch/guide/current/dont-touch-these-settings.html
先计算：
- 每线程每秒处理请求数 = 1s/平均请求延时
- 处理峰值请求所需的并发数 = 峰值每秒请求数/每线程每秒处理请求数
- 所需节点数 = 峰值并发数/每节点线程池大小。
