一，写优化

  1. 批量提交。每次提交的数据量为多大能力达到最优，受文件大小，数据类型，网络状况，集群状态等因素影响，一般来说一次批处理的数据大小应从5M-15M开始逐步减少直到没有性能提花为止。
  2. 优化存储设置。尽量应用固态硬盘(solid state disk)
  3. 正当应用段合并。段合并的计算宏大，会耗费大量的I/O，为了避免因段合并影响搜寻性能，咱们须要管制正当的合并速度，可通过参考进行配置
  4. 缩小refresh次数。这个须要依据理论状况来看，如果咱们对搜寻的时效性不高，则能够减少提早refresh的工夫，这样还能够缩小段合并的数量。
  5. 缩小flush的次数。这个同样须要结合实际状况来看，当translog的数量达到512M或30分钟时，会触发一次flush，磁盘长久化比拟耗资源，咱们能够通过参考设置正当的值
  6. 缩小正本数。ES正本数能够保障集群可用性，也能够减少搜寻的并发数，但却会重大升高写索引的效率，因为在写索引时须要把整个文档的内容都发给正本节点，而所有的正本节点都须要把索引过程反复进行一遍。所以正本数不可过多。

二，读优化

  1. 防止大后果集和深翻页。如果有N个分片，协同节点须要收集每个分片的前from+size条数据，而后将收集到的Nx(from+size)条数据合并后再进行一次排序，最初从from+1开始返回size条数据。只有N,from,size其中有个值很大，这样的查问会耗费很多CPU，效率低下。为解决这类问题，ES提供了scroll和scroll-scan这两种形式。
    1) scroll形式。 与search申请每次返回一页数据不同，scroll是为检索大量的后果（甚至所有的后果）而设计的，比方，咱们有一个批量查问的需要，要查问1～100页的数据，每页有100条数据，如果用search查问，则每次都要在每个分片上查问得分最高的from+size条数据，而后协同节点把收集到的n×（from+size）条数据合并起来再进行一次排序。接着从from+1开始返回size条数据，并且要反复100次，随着from的增大，查问的速度越来越慢。
    但scroll的思路是：在各个分片上一次查问10000条数据，协同节点收集n×10000条数据，而后合并、排序，将排名前10000的后果以快照模式存储，最初应用相似数据库游标的模式逐次取得局部数据。这种做法的益处是缩小了查问和排序的次数。scroll在第一次查问时除了返回查问到的后果外，还会返回一个scroll_id，它是下次申请的参数。scroll也分query,fetch两个阶段，第一阶段query先将所有符合条件的doc_id查问并暂存；第二阶段fetch依据doc_id与scroll_id以游标的形式获取文档。须要留神的是scroll会应用快照的模式暂存数据，后续一段时间内数据如果有批改是感知不到的，所以它不适宜实时性要求高的场景
    2) scroll-scan形式。scroll在首次查问时须要进行文本类似度计算和排序，这个过程也比拟耗时，scroll-scan则敞开了这一过程。scroll-scan的特点是不做文本类似度计算；不反对聚合
  2. 抉择适合路由
    在多分片的ES集群下，查问大抵分如下两种。
    1) 查问条件中蕴含了routing信息。查问时能够依据routing间接定位到其中的一个分片，而不须要查问所有分片，再通过协调节点二次排序。
    2) 如果查问条件不蕴含routing，整个查问过程就分scatter与gather两个过程。
    scatter（散发）：在申请达到协调节点后，协调节点将查问申请散发到每个分片上
    gather（聚合）：协调节点收集在每个分片上实现的搜寻后果，再将收集的后果集进行从新排序，返回给用户。

三，堆大小的设置

ES默认的堆内存大小是1GB，因为ES是比拟耗内存的利用，咱们能够将这个值调大一点。-Xms与-Xmx设置一样。内存调配还有两个准则：

  1. 最好不要超过物理内存的50%。ES底层是lucene实现的，因为lucene段的不变性，所以咱们不必思考数据的变动，这对缓存十分敌对，操作系统能够将这些文件缓存在操作系统的文件缓存零碎(filesystem cache)中而非堆内存中，如果超过物理内存过多，则留给文件缓存零碎就不多了
  2. 堆内存最好不要超过32G。这是因为在64位操作系统中，指针自身会变大，会有更大的空间节约在指针自身上。

性能调优就写到这里，上面看下ES里的一些个性，比方主节点选举，如何防止脑裂。

  1. 角色隔离
    因为节点默认的是node.master和node.data都为true，所以咱们往往会让Master节点也担当了Data节点的角色。Elasticsearch集群中的Data节点负责对数据进行增、删、改、查和聚合等操作，所以对CPU、内存和I/O的耗费很大，有可能会对Master节点造成影响，从而影响整个集群的状态。

在搭建集群时，特地是比拟大的集群时，咱们应该对Elasticsearch集群中的节点做角色上的划分和隔离。咱们通常应用几个配置比拟低的虚拟机来搭建一个专门的Master集群。在集群中做角色隔离是一件非常简单的事件，只需在节点的配置文件中增加如下配置信息即可。

候选主节点：

node.master =truenode.data=false

数据节点：

node.master =falsenode.data=true
  1. master选举
    前提条件：
    1) 只有是候选主节点(master:true)的节点能力成为主节点
    2) 最小主节点数(min_master_nodes)的目标是避免脑裂
    ES的选举是ZenDiscovery模块负责的，次要蕴含Ping（节点之间通过这个RPC来发现彼此）和 Unicast（单播模块蕴含一个主机列表以管制哪些节点须要 ping 通）这两局部。选举流程大抵如下：
    第一步：确认候选主节点数是否达标
    第二步：对所有候选主节点依据nodeId字典排序，每次选举每个节点都将本人所晓得节点排一秩序，而后选出第一个(第0位)节点，暂且认为它是master节点
    第三步：如果对某个节点的投票数达到肯定的值（候选主节点数/2+1）并且节点本人也选举本人，那这个节点就是master。否则从新进行直到满足下面条件。
  2. 防止脑裂
    脑裂是因为网络起因导致在集群中选举出了多个master，最初导致一个集群被决裂为多个集群。了为避免脑裂，咱们须要在在Master集群节点的配置文件中增加参数discovery.zen.minimum_master_nodes，该参数示意在选举主节点时须要参加选举的候选主节点的节点数（默认值是1）。咱们通常应该把这个值设置成（master_ eligible_nodes/2）+1，其中master_eligible_nodes为Master集群中的节点数。这样做既能避免脑裂的景象呈现，也能最大限度地晋升集群的高可用性，因为只有不少于discovery.zen.minimum_ master_nodes个候选节点存活，选举工作就能够顺利进行。

参考文章：elasticsearch scroll查问的原理没太懂
Elasticsearch之SearchScroll原理分析和性能及稳定性优化