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.使用多线程 + bulk批量写入

        bulk批量写入的性能比你一条一条写入大量的document的性能要好很多。但是要注意bulk请求得整体字节数不要太大，太大可能给集群带来内存压力，因此每个请求最好避免超过几十MB，即使较大得请求看上去执行可能更好。

索引建立过程属于CPU密集型任务，应该使用固定大小的线程池，来不及处理的任务放入队列。这样可以减少上下文的切换带来的性能消耗，队列大小要适当，过大的队列导致较高的GC压力，并可能导致FGC频繁发生。

bulk写请求是一个长任务，为了给系统增加足够的写入 压力，写入过程应该多个客户端，多个线程冰箱执行。

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.使用自动生成的id

如果我们要手动给es document设置一个id，那么es需要每次都去确认一下那个id是否存在，这个过程是比较耗费时间的。如果我们使用自动生成的id，那么es就可以跳过这个步骤，写入性能会更好。对于你的业务中的表id，可以作为es document的一个field。

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做分页的时候，你会发现越翻到后面，就越是慢。

1）不允许深度分页/默认深度分页性能很惨

2）用scroll api：类似于app里的推荐商品不断下拉出来一页一页的

【Elasticsearch】ES查询优化—Scroll API 滚动查询_小雨青年的博客-CSDN博客_es api scroll