1、合并请求

bulk批量API，一次发送多篇文档进行索引，也可以一次性发送多条get或search操作

批量索引、更新和删除

• _bulk 节点
• curl -XPOST localhost:9200/get-together/group/_bulk?pretty --data-binary @$REQUEST_FILE

多条搜索和多条获取

• _msearch节点
• _mget节点

2、优化Lucene分段

一旦Elasticsearch接收到了应用所发的文档，它会将其索引到内存中的分段的倒排索引。这些分段会不时地写入磁盘。

刷新和冲刷的阈值

• Elasticsearch保持了某个时间点索引打开的快照，这个快照会按照一定的时间间隔刷新
• 冲刷是将索引的数据从内存写入磁盘，内存缓冲慢了、超过冲刷间隔时间、事务日志到达一定阈值

合并策略

• 为了将分段总数量控制、删除文档，需要进行合并
• 设置分段的数量、每次合并的数量、分段的最大体量

存储限流

• 限制可使用的IO吞吐量

3、充分利用缓存

分片查询缓存与操作系统缓存

过滤器和过滤器缓存

• term、terms、exists/missing、prefix均使用位集合
• 组合不使用位集合的过滤器时，and or not过滤器时更好的选择
• 轻量级的过滤器应该在更耗资源的过滤器之前运行
• 字段缓存，terms、range过滤器中的excution设置为fielddata

分片查询缓存

• 分片查询缓存在分片级别上，维护了整个请求及结果之间的映射
• 分片查询缓存有默认大小设置，JVM堆的1%

JVM堆核操作系统缓存

• 内存不够用，会使得垃圾回收器运行的更加频繁或者运行得更久
• 减小索引缓冲区的大小
• 减少过滤器缓存和分片查询缓存的大小
• 减少搜索和聚集请求中的size参数
• 将堆的大小设置为比常规高出50%

使用预热器让缓存热身

• 可以定义任何类型的搜索请求作为预热器
• 预热器会让Elasticsearch在每次刷新操作之后，运行这个查询

4、其他性能的权衡

大规模索引还是昂贵的搜索

• 模糊查询、前缀查询、通配符都很消耗资源
• 使用N元语法产生分词可以获取类似的模糊查询效果，但是N元语法会使得索引变大，磁盘读写压力大

脚本使用

• 脚本的结果永远不会被缓存，因为Elasticsearch无法理解脚本内的内容
• 访问字段数据比访问文档数据快，doc['xxx']比_source['']快，因为后者要去磁盘上获取

权衡网络开销

• query_and_fetch是获取全部相关文档
• query_then_fetch是两次传输，首次只传必须的元数据，再用过滤后的结果取所有结果
• dfs_query_then_fetch，如果分布得不均匀，可以考虑用这种方式，可以收集各个分片的数据到主节点进行整体的计算，会比较慢

and/then fetch

权衡内存，深度分页

• scan类型搜索，会返回一个滚动id，唯一标示这个请求并会记住哪些页面已被返回