《ElasticSearch易筋经》

一、合理使用ES灾备策略

1.明确数据副本数：这关系到在机器故障场景数据是否会丢失。如果只保留一份数据，服务器故障会导致部分数据丢失；如果您的ES中数据不能丢失，需要至少保留2份数据。数据副本数可以在创建索引时通过参数number_of_replicas=1进行设置（保留2份数据）。

2.核心业务建议双流：ES故障恢复慢，核心业务建议申请两个ES集群作为主备集群，通过双写方式进行数据同步。当主集群发生可用性故障且无法快速恢复时，业务可以切换到备用集群，迅速恢复服务可用性。如果未采用主备集群双写方式，需要有降级预案，避免ES故障严重影响您的业务。



二、控制集群规模、集群数据量

1.选择合适的存储介质，控制单节点数据量：如果您的应用对ES性能要求高，建议使用本地磁盘，且单节点数据量控制在500G以内；日志、归档类的大数据量业务场景，建议使用云盘，单节点数据量控制在2T以内。

2.控制ES集群的节点数量、索引数量、分片数量：一个ES集群最多支持99个数据节点、1000个索引和10000个分片；超过这些限制会导致ES集群不稳定。

3.控制ES集群索引、索引分片的数据量：单个索引的数据量不超过500G，索引的一个分片数据量不超过50G（单分片文档数超过21亿会导致服务异常）。



三、合理的使用索引，避免流量倾斜

1.索引需要提前48小时创建好：新建的索引分片在不同数据节点间分布并不均衡，索引创建之后立刻使用可能会有流量倾斜。索引需要提前48小时创建好，ES会自动将新索引分片调度到不同的数据节点。

2.创建索引需要明确指定每个节点的分片数量：建议 单节点分片数量=索引总分片数 / 数据节点数 + 2，这可让您的索引的分片均衡的调度到不同的数据节点，您可以通过设置index.routing.allocation.total_shards_per_node参数来进行控制。



四、合理的使用ES查询和写入能力

1.避免过度复杂的查询：请避免使用多层聚合(aggs)查询、嵌套查询、父子查询、“from xx to null”和使用通配符的全量查询等，以确保查询的执行效率和性能

2.避免大批量更新：请避免使用 "updateByQuery" 和 "deleteByQuery" 单次处理超过1万条的数据，大批量的更新会对整个集群性能造成影响

3.控制写入文档大小：限制写入的文档在1M以内，大文档在写入、更新和读取时都会导致性能下降，尤其是在频繁并发更新大文档时，容易引起内存垃圾回收频繁和内存溢出的问题

4.配置合理的超时：ES有强大的查询能力，但是复杂查询会消耗磁盘、CPU资源，不同查询线程直接会相互影响，请配置合理的超时，准备降级预案，避免ES性能变差严重影响您的业务。

5. 写入和更新时不要调用refresh：业务在执行bulk、update、delete、updateByQuery和deleteByQuery时，不要设置refresh=true，大促上游泄洪时会导致ES性能严重下降，导致上游数据堆积。

6. 使用合适的字段类型：数字用数值类型存储还是用字符串类型存储好。数值类型在范围查询时可以加速查询提高性能。如果只有Term查询而没有范围查询的需求, 那么数字可以使用字符串类型keyword/text存储提升查询性能。



五、ES不适合的场景

1.不推荐ES用在高性能场景：ES不能保证低延迟，面向C端用户对实时性要求较高的业务，不建议使用ES；这些场景可以考虑使用缓存、数据库等产品承载业务流量。

2.不推荐将ES当数据库使用：ES产品定位是检索引擎，不能保障事务的ACID特性、默认不开启定时备份，如果您对数据的一致性、持久性有严格要求，建议使用云RDS、JED等关系型数据库。



隐隐一股暖流汇入小腹下丹田处...... 神清气爽...倍感舒适... 气血+100，内功+100，根骨+100， 身法+100，悟性+100，运气+100