线上ES集群提高读写能力的大致方案

问题背景：

业务在使用ES集群读取ES数据，如果同时向ES集群写任务时，会遇到RT涨的情况，会出现一些抖动，尤其是在计算框架大量增加并发度像ES集群写的情况下会出现抖动，目前的话是大数据计算集群减少并发写。以后还是期望增加并发度，加快写入速度，预期会对ES集群读性能带来挑战

目前现状：

目前线上是采用的 5台 64C 128G 1THDD，机器配置比较高，使用比较稳定，在集群同时大量读写时出现一些抖动，没有发生过 FGC等状况，平均延迟都在毫秒级。集群索引所占据的数据量大概为300-500G。集群的搭建使用的是默认配置，没有对ES节点角色进行区分，也就是5个节点可以同时承担Master / Data / Ingest / Coordinating / Machine Learning 的职责，随着数据和业务量的增加未来估计会遇到挑战。

据目前监控数据ES整体比较稳定，是否扩容及部署架构调整具体还是要根据业务使用和集群性能监控数据作出综合评估。

如下图数据监控数据：

图：过去7天数据云查询响应时间

数据访问监控数据P99响应时间大多在30ms以内，极个别情况会出现超过100ms情况，结合ES集群监控数据（具体可查看最后参考链接及数据）可暂时保持现有集群架构，后期持续观察监控数据对集群进行角色拆分及扩容。

ES集群部署：

基础知识

通常ES集群中有以下角色的节点类型 Master / Data / Ingest / Coordinating / Machine Learning

各个角色的作用如下：

Master 节点，负责分片管理、集群管理，集群状态的管理，如果单独出节点Master，从高可用和避免脑裂的角度出发，一般在生产环节中配置三台，集群自动会选择1台作为主节点。
Data Node 节点：这个节点主要负责数据的存储，在数据扩展上起到了至关重要的作用。读写数据都会找到相应的 Data Node 节点。
Coordinating Node 节点：协调节点主要负责协调客户端的请求，将接收到的请求分发给合适的节点，并把结果汇集到一起。比如客户端请求查询某个索引的数据，协调节点将会把请求分发给保存相关的数据的 DataNode 节点，找到相应的分片，并把查询到的结果都汇集返回。并且每个节点都默认起到了 Coordinating Node 的职责。
Ingest Node: Ingest node 专门对索引的文档做预处理,发生在对真实文档建立索引之前，起到数据处理的作用。

一个节点在默认情况会下同时扮演这些角色，在开发环境通常数据量不大通常部署一个节点的ES集群。生产环境下就需要根据数据量，写入和查询的吞吐量，选择合适的部署方式，通常资源足够的话最佳的实践方式是设置单一角色的节点，如下图所示：

节点参数配置

角色配置建议

角色	cpu	内存	磁盘
Master	低配置	低配置	低配置
Data Node	高配置	高配置	高配置
ingest	高配置	中等配置	低配置
Coordinating	中/高配置	中/高配置	低配置

未来方案：

单独分出几个节点部署成ingest 角色前面挂个LB主要承担部分数据接入操作，独立几个coordinatiing 节点前面挂个LB主要做数据处理查询聚合读的操作，当系统中有大量的复杂查询及聚合时候，增加 Coordinating 节点，便于增加查询的性能。

总结

随着业务量和数据量上升，当前ES集群使用的是默认配置，没有对ES节点角色进行区分的使用方式，在未来估计会受到一定的压力和挑战，当前根据监控数据和ES集群监控，暂时满足业务需求，后续集群架构需要进行一定的调整，进行角色职责的拆分。一些节点混合部署，或者完全独立，当数据量过大，磁盘容量无法满足需求，可以增加数据节点，当系统中有大量的复杂查询及聚合时候，增加 Coordinating 节点，增加查询的性能，同时可以对Coordinating和ingest、Data节点进行拆分，进一步减小节点承担的压力。