如何实现ElasticSearch优化，针对这个问题，本文详细介绍了相应的分析和解答，希望能帮助更多想要解决这个问题的小伙伴找到更简单更容易的方法。
尽量不要将不同数据结构的数据放在同一个索引中，考虑从数据较少的集合中创建碎片较少的存储。当然，数据之间有父子关系的情况除外。毕竟，父子关系的数据不能存储在不同的索引中。
00-1010 1.尽量使用批量索引。
2.客户端应该尝试使用多线程批处理索引。
3.添加刷新机制的间隔默认为1s -1，表示从数据索引到查询的整个过程被禁用，默认为1s，由index.refresh_interval参数控制。如果对数据的实时性要求不高，可以将参数适当调整到业务系统可接受的范围内。在此间隔期间，es将强制创建一个新的段。区间越大，创建的段越大，也减少了后续字段合并段的压力(lucene底部的数据结构其实可以详细查询lucene和段的关系)。
4.当数据最初被索引时，禁用刷新和复制机制。如果有大量数据需要索引(前提条件)，由于刷新和复制机制对数据索引性能影响很大，可以将index.refresh_interval设置为-1，将index . number _ of _ Replicator设置为0，禁用这两种机制。这两个参数将不会被调整到合理的值，直到这次完成所有数据索引。但是，应该理解，性能和数据安全性不能同时满足，这取决于业务数据的重要性。
5.禁止内存交换。
暂时禁用开关sudo swapoff-a
永久禁用它需要编辑/etc/fstab文件，并注释掉所有包含该单词的换行符。
6.文件系统缓存的内存不应少于服务器内存的一半。文件系统缓存将用于缓冲输入/输出操作，这对es非常重要。要求内存不小于服务器内存的一半，也就是说，es的jvm堆的值设置应该小于服务器内存的一半。
7.尽量使用es自动生成的id作为es的文档id。应该知道，它的作用首先是确定文档的唯一性，其次，默认情况下，id用作路由值来计算文档应该分配给哪个分片，它也是生成uid的成员。如果在索引时设置了id，会先检查其唯一性，成本很高，而且随着索引文档数量的增加，消耗会越来越大。如果没有业务需要，最好使用自动生成的id(检查过程将被跳过)。
9.索引缓存的大小
10.字符串类型字段不分段。
设置精细的全文字段：默认情况下会对字符串字段进行分段，这样不仅会占用额外的资源，还会影响创建索引的速度。因此，将不需要分词的字段设置为not_analyzed。
11.设置段合并的线程数：
curl-XPUT ' your-es-host :9200/nginx _ log-2018-03-20/_ settings '-d ' { 0 }
index . merge . scheduler . max _ thread _ count ' : 1
}'
12.不需要打开http服务。按如下方式设置配置参数：http.enabled: false。
13.官方弹性文档建议节点中的索引应该不超过三个碎片。配置total_shards_per_node参数，以限制分配给每个索引中每个节点的最大发布数。
14.分片：一个索引将存储在多个分片中，建立索引后分片数量不能改变。建议[碎片数*副本数=簇数]。
14.分段和合并弹性搜索的默认设置在这里是保守的：您不希望搜索性能受到背景合并的影响。但是，有时候(尤其是SSD，或者日志场景)限流阈值太低。
默认值为20 MB/s，这对于机械磁盘来说应该是一个不错的设置。如果您使用固态硬盘，请考虑将其提高到100200兆字节/秒。请验证哪个值适合您的系统：
PUT/_集群/设置
{
持久' : {
indexs . store . throttle . max _ bytes _ per _ sec ' : ' 100 MB '
}
}
您可以增加index . trans log . flush _ threshold _ size参数，该参数默认为200M，例如可以增加到1GB。
增加此参数可以允许translog在刷新之前存储更大的段；较大片段的创建将降低刷新频率，
此外，较大数据段的合并越小，磁盘IO越小，索引性能越高。
二、查询速度1、查询缓存
查询缓存的主要目的是缓存聚合、提示和命中(返回的文档不会被缓存)。
如果您想要打开主控索引的查询缓存，您可以执行如下操作。
PUT/mastering/_设置
{ ' index . requests . cache . enable ' : true }
2.默认情况下，查询缓存使用节点堆栈的1%内存，可以通过以下方式设置：
indexs . requests . cache . size : 2%
关于如何实现弹性搜索优化的问题，我希望在这里分享。
内容来源网络，如有侵权，联系删除，本文地址：https://www.230890.com/zhan/148962.html
