ES优化方案
ES优化&联合HBASE：
【Elasticsearch】优秀实践-ES+Hbase的实现_少加点香菜的博客-CSDN博客_sc+es+hbase
ES写入性能优化方案
ElasticSearch 调优笔记_index.refresh_interval_六月·飞雪的博客-CSDN博客
es如何提升写入性能_婲落ヽ紅顏誶的博客-CSDN博客_es写入性能为什么慢
ElasticSearch三：ES如何优化查询的性能_Coding Now的博客-CSDN博客_es查询性能
1.增加filesystem cahce能缓存的数据条数：
写入es的doc数据，得是那些会被索引到的字段，而不要全部都写到es，其他不用来检索的数据放hbase里，或者mysql。
仅仅只是写入es中要用来检索的少数几个字段就可以了，比如说，就写入es id name age三个字段就可以了，然后你可以把其他的字段数据存在mysql里面，我们一般是建议用es + hbase的这么一个架构。
2.字段存储
当前es主要有doc_values，fielddata，storefield三种类型，大部分情况下，并不需要三种类型都存储，可根据实际场景进行调整：
-
当前用得最多的就是doc_values，列存储，对于不需要进行分词的字段，都可以开启doc_values来进行存储（且只保留keyword字段），节约内存，当然，开启doc_values会对查询性能有一定的影响，但是，这个性能损耗是比较小的，而且是值得的；
-
fielddata构建和管理 100% 在内存中，常驻于 JVM 内存堆，所以可用于快速查询，但是这也意味着它本质上是不可扩展的，有很多边缘情况下要提防，如果对于字段没有分析需求，可以关闭fielddata；
-
storefield主要用于_source字段，默认情况下，数据在写入es的时候，es会将doc数据存储为_source字段，查询时可以通过_source字段快速获取doc的原始结构，如果没有update，reindex等需求，可以将_source字段disable；
-
_all，ES在6.x以前的版本，默认将写入的字段拼接成一个大的字符串，并对该字段进行分词，用于支持整个doc的全文检索，在知道doc字段名称的情况下，建议关闭掉该字段，节约存储空间，也避免不带字段key的全文检索；
-
norms：搜索时进行评分，日志场景一般不需要评分，建议关闭。
3.增加refresh间隔
默认的refresh间隔是1s，用index.refresh_interval参数可以设置，这样会其强迫es每秒中都将内存中的数据写入磁盘中，创建一个新的segment file。正是这个间隔，让我们每次写入数据后，1s以后才能看到。但是如果我们将这个间隔调大，比如30s，可以接受写入的数据30s后才看到，那么我们就可以获取更大的写入吞吐量，因为30s内都是写内存的，每隔30s才会创建一个segment file。
4.禁止refresh和replia
如果我们要一次性加载大批量的数据进es，可以先禁止refresh和replia复制，将index.refresh_interval设置为-1，将index.number_of_replicas设置为0即可。这可能会导致我们的数据丢失，因为没有refresh和replica机制了。但是不需要创建segment file，也不需要将数据replica复制到其他的replica shasrd上面去。此时写入的速度会非常快，一旦写完之后，可以将refresh和replica修改回正常的状态。
5.给filesystem cache更多的内存
filesystem cache被用来执行更多的IO操作，如果我们能给filesystemcache更多的内存资源，那么es的写入性能会好很多。
6.segment merge
段合并的计算量庞大， 而且还要吃掉大量磁盘 I/O。合并在后台定期操作，因为他们可能要很长时间才能完成，尤其是比较大的段。
这个通常来说都没问题，因为大规模段合并的概率是很小的。如果发现merge占用了大量的资源，可以设置：index.merge.scheduler.max_thread_count：1
特别是机械磁盘在并发 I/O 支持方面比较差，所以我们需要降低每个索引并发访问磁盘的线程数。这个设置允许 max_thread_count + 2 个线程同时进行磁盘操作，也就是设置为 1 允许三个线程。
对于 SSD，你可以忽略这个设置，默认是 Math.min(3, Runtime.getRuntime().availableProcessors() / 2) ，对 SSD 来说运行的很好。
业务低峰期通过force_merge强制合并segment，降低segment的数量，减小内存消耗；关闭冷索引，业务需要的时候再进行开启，如果一直不使用的索引，可以定期删除，或者备份到hadoop集群。
7.index buffer
indexing buffer 在为doc建立索引时使用，当缓冲满时会刷入磁盘，生成一个新的segment,这是除了refresh_interval 刷新索引外，另一个生成新segment的机会。每个shard有自己的indexing buffer,下面的这个buffer大小的配置需要除以这个节点上索引shard的数量：
indices.memory.index_buffer_size
默认是整个堆空间的10%
indices.memory.min_index_buffer_size
默认48MB
indices.memory.max_index_buffer_size
默认无限制
在执行大量的索引操作时，indices.memory.index_buffer_size的默认设置可能不够，这和可用堆内存，单节点上的shard数量相关，可以考虑适当增大该值。
8.数据预热：刷到filesystem cache里去。
电商，你可以将平时查看最多的一些商品，比如说iphone 8，热数据提前后台搞个程序，每隔1分钟自己主动访问一次，刷到filesystem cache里去。
对于那些你觉得比较热的，经常会有人访问的数据，最好做一个专门的缓存预热子系统，就是对热数据，每隔一段时间，你就提前访问一下，让数据进入filesystem cache里面去。这样期待下次别人访问的时候，一定性能会好一些。
9.冷热分离
es可以做类似于mysql的水平拆分，就是说将大量的访问很少，频率很低的数据，单独写一个索引，然后将访问很频繁的热数据单独写一个索引
你最好是将冷数据写入一个索引中，然后热数据写入另外一个索引中，这样可以确保热数据在被预热之后，尽量都让他们留在filesystem os cache里，别让冷数据给冲刷掉。
10.document模型设计
document模型设计是非常重要的，很多操作，不要在搜索的时候才想去执行各种复杂的乱七八糟的操作。es能支持的操作就是那么多，不要考虑用es做一些它不好操作的事情。如果真的有那种操作，尽量在document模型设计的时候，写入的时候就完成。另外对于一些太复杂的操作，比如join，nested，parent-child搜索都要尽量避免，性能都很差的。
两个思路，在搜索/查询的时候，要执行一些业务强相关的特别复杂的操作：
1）在写入数据的时候，就设计好模型，加几个字段，把处理好的数据写入加的字段里面
2）自己用java程序封装，es能做的，用es来做，搜索出来的数据，在java程序里面去做，比如说我们，基于es，用java封装一些特别复杂的操作
11.分页性能优化
es的分页是较坑的，为啥呢？举个例子吧，假如你每页是10条数据，你现在要查询第100页，实际上是会把每个shard上存储的前1000条数据都查到一个协调节点上，如果你有个5个shard，那么就有5000条数据，接着协调节点对这5000条数据进行一些合并、处理，再获取到最终第100页的10条数据。
分布式的，你要查第100页的10条数据，你是不可能说从5个shard，每个shard就查2条数据？最后到协调节点合并成10条数据？你必须得从每个shard都查1000条数据过来，然后根据你的需求进行排序、筛选等等操作，最后再次分页，拿到里面第100页的数据。
你翻页的时候，翻的越深，每个shard返回的数据就越多，而且协调节点处理的时间越长。非常坑爹。所以用es做分页的时候，你会发现越翻到后面，就越是慢。
12禁止动态mapping
动态mapping的坏处：
-
造成集群元数据一直变更，导致集群不稳定；
-
可能造成数据类型与实际类型不一致；
-
对于一些异常字段或者是扫描类的字段，也会频繁的修改mapping，导致业务不可控。
动态mapping配置的可选值及含义如下：
-
true：支持动态扩展，新增数据有新的字段属性时，自动添加对于的mapping，数据写入成功；
-
false：不支持动态扩展，新增数据有新的字段属性时，直接忽略，数据写入成功 ；
-
strict：不支持动态扩展，新增数据有新的字段时，报错，数据写入失败。
1）不允许深度分页/默认深度分页性能很惨
2）用scroll api：类似于app里的推荐商品不断下拉出来一页一页的
【Elasticsearch】ES查询优化—Scroll API 滚动查询_小雨青年的博客-CSDN博客_es api scroll
操作优化
1.routing
对于数据量较大的业务查询场景，ES侧一般会创建多个shard，并将shard分配到集群中的多个实例来分摊压力，正常情况下，一个查询会遍历查询所有的shard，然后将查询到的结果进行merge之后，再返回给查询端。
此时，写入的时候设置routing，可以避免每次查询都遍历全量shard，而是查询的时候也指定对应的routingkey，这种情况下，ES会只去查询对应的shard，可以大幅度降低合并数据和调度全量shard的开销。
2.使用alias
生产提供服务的索引，切记使用别名提供服务，而不是直接暴露索引名称，避免后续因为业务变更或者索引数据需要reindex等情况造成业务中断。
3 避免宽表
在索引中定义太多字段是一种可能导致映射爆炸的情况，这可能导致内存不足错误和难以恢复的情况，这个问题可能比预期更常见，index.mapping.total_fields.limit ，默认值是1000。
4 二级自动生成_id
当写入端使用特定的id将数据写入ES时，ES会去检查对应的index下是否存在相同的id，这个操作会随着文档数量的增加而消耗越来越大，所以如果业务上没有强需求，建议使用ES自动生成的id，加快写入速率。
5.使用多线程 + bulk批量写入
bulk批量写入的性能比你一条一条写入大量的document的性能要好很多。但是要注意bulk请求得整体字节数不要太大，太大可能给集群带来内存压力，因此每个请求最好避免超过几十MB，即使较大得请求看上去执行可能更好。
索引建立过程属于CPU密集型任务，应该使用固定大小的线程池，来不及处理的任务放入队列。这样可以减少上下文的切换带来的性能消耗，队列大小要适当，过大的队列导致较高的GC压力，并可能导致FGC频繁发生。
bulk写请求是一个长任务，为了给系统增加足够的写入 压力，写入过程应该多个客户端，多个线程冰箱执行。