ElasticSearch企业级别性能优化

http.max_context_length的默认值是100mb，意味着你一次document写入时，document的内容不能超过100mb，否则es就会拒绝写入。也许你可以将这个参数设置的更大，从而让你的超大的documdent可以写入es，但是es底层的lucene引擎还是有一个2gb的最大限制。

即使我们不考虑引擎层的限制，超大的document在实际生产环境中是很不好的。超大document会耗费更多的网络资源，内存资源和磁盘资源，甚至对那些不要求获取_source的请求，也是一样，因为es需要从_source中提取_id字段，对于超大document这个获取_id字段的过程的资源开销也是很大的。而将这种超大document写入es也会使用大量的内存，占用内存空间的大小甚至会是documdent本身大小的数倍。近似匹配的搜索，比如phrase query，以及高亮显示，对超大document的资源开销会更大，因为这些操作的性能开销直接跟document的大小成正比。

因此对于超大document，我们需要考虑一下，我们到底需要其中的哪些部分。举例来说，如果我们要对一些书进行搜索，那么我们并不需要将整本书的内容就放入es中吧。我们可以仅仅使用每一篇章或者一个段落作为一个document，然后给一个field标识出来这些document属于哪本书，这样每个document的大小不就变小了么。这就可以避免超大document导致的各种开销，同时可以优化搜索的体验。比如说，如果一个用户要搜索两个单词，foo和bar，如果在两个不同的段落中分别匹配了一个单词，肯定匹配效果要比，一个段落中匹配了两个单词，要差。

3、避免稀疏的数据

lucene的内核结构，跟稠密的数据配合起来，性能会更好，举个例子，什么叫稀疏的数据，什么叫稠密的数据？比如有100个document，每个document都有20个field，20个field都有值，这就是稠密的数据。但是如果100个document，每个document的field都不一样，有的document有2个field，有的document有50个field，这就是稀疏的数据。

原因就是，lucene在内部会通过doc id来唯一标识一个document，这个doc id是integer类型，范围在0到索引中含有的document数量之间。这些doc id是用来在lucene内部的api之间进行通信的，比如说，对一个term用一个match query来进行搜索，就会产生一个doc id集合，然后这些doc id会用来获取对应的norm值，以用来计算每个doc的相关度分数。而根据doc id查找norm的过程，是通过每个document的每个field保留一个字节来进行的一个算法，这个过程叫做norm查找，norm就是每个document的每个field保留的一个字节。对于每个doc id对应的那个norm值，可以通过读取es一个内置索引，叫做doc_id的索引，中的一个字节来获取。这个过程是性能很高的，而且可以帮助lucene快速的定位到每个document的norm值，但是同时这样的话document本身就不需要存储这一个字节的norm值了。

在实际运行过程中，这就意味着，如果一个索引有100个document，对于每个field，就需要100个字节来存储norm值，即使100个document中只有10个document含有某个field，但是对那个field来说，还是要100个字节来存储norm值。这就会对存储产生更大的开销，存储空间被浪费的一个问题，而且也会影响读写性能。

下面有一些避免稀疏数据的办法：

（1）避免将没有任何关联性的数据写入同一个索引

我们必须避免将结构完全不一样的数据写入同一个索引中，因为结构完全不一样的数据，field是完全不一样的，会导致index数据非常稀疏。最好将这种数据写入不同的索引中，如果这种索引数据量比较少，那么可以考虑给其很少的primary shard，比如1个，避免资源浪费。

（2）对document的结构进行规范化/标准化

即使我们真的要将不同类型的document写入相同的索引中，还是有办法可以避免稀疏性，那就是对不同类型的document进行标准化。比如说，如果所有的document都有一个时间戳field，不过有的叫做timestamp，有的叫做creation_date，那么可以将不同document的这个field重命名为相同的字段，尽量让documment的结构相同。另外一个，就是比如有的document有一个字段，叫做goods_type，但是有的document没有这个字段，此时可以对没有这个字段的document，补充一个goods_type给一个默认值，比如default。

（3）避免使用多个types存储不一样结构的document

很多人会很喜欢在一个index中放很多个types来存储不同类型的数据。但是其实不是这样的，最好不要这么干，如果你在一个index中有多个type，但是这些type的数据结构不太一样，那么这些type实际上底层都是写到这个索引中的，还是会导致稀疏性。如果多个type的结构不太一样，最好放入不同的索引中，不要写入一个索引中。

（4）对稀疏的field禁用norms和doc_values

如果上面的步骤都没法做，那么只能对那种稀疏的field，禁止norms和doc_values字段，因为这两个字段的存储机制类似，都是每个field有一个全量的存储，对存储浪费很大。如果一个field不需要考虑其相关度分数，那么可以禁用norms，如果不需要对一个field进行排序或者聚合，那么可以禁用doc_values字段。

磁盘读写性能优化

优化磁盘空间的占用，减少磁盘空间的占用，更多的数据可以进入filesystem cache

比如说你原来，磁盘空间占用一共是1T，内存只有512G，现在优化了磁盘空间占用之后，减少了数据量，可能数据量就只有512G了，那么就可以全部进入内存

1、禁用不需要的功能

聚合，搜索，评分，近似匹配

聚合：doc values
搜索：倒排索引，index
评分：norms
近似匹配：index_options（freqs）

任何一个功能不需要，就把对应的存储的数据给干掉，这样可以节约磁盘空间的占用，也可以优化磁盘的读写性能

默认情况下，es在写入document到索引的时候，都会给大多数的field增加一份doc values，就是正排索引，用来进行聚合或者排序的。比如说，如果我们有一个叫做foo的数字类型field，我们要对这个字段运行histograms aggr聚合操作，但是可能我们并不需要对这个字段进行搜索，那么就可以禁止为这个字段生成倒排索引，只需要doc value正排索引即可。禁用倒排索引：

PUT index
{
  "mappings": {
    "type": {
      "properties": {
        "foo": {
          "type": "integer",
          "index": false
        }
      }
    }
  }
}

text类型的field会存储norm值，用来计算doc的相关度分数，如果我们需要对一个text field进行搜索，但是不关心这个field的分数，那么可以禁用norm值

PUT index
{
  "mappings": {
    "type": {
      "properties": {
        "foo": {
          "type": "text",
          "norms": false
        }
      }
    }
  }
}

text field还会存储出现频率以及位置，出现频率也是用来计算相关度分数的，位置是用来进行phrase query这种近似匹配操作的，如果我们不需要执行phrase query近似匹配，那么可以禁用位置这个属性：

PUT index
{
  "mappings": {
    "type": {
      "properties": {
        "foo": {
          "type": "text",
          "index_options": "freqs"
        }
      }
    }
  }
}

此外，如果我们不关心相关度频分，我们可以配置es仅仅为每个term索引对应的document，我们可以对这个field进行搜索，但是phrase query这种近似匹配会报错，而且相关度评分会不准确：

PUT index
{
  "mappings": {
    "type": {
      "properties": {
        "foo": {
          "type": "text",
          "norms": false,
          "index_options": "freqs"
        }
      }
    }
  }
}

2、不要用默认的动态string类型映射

默认的动态string类型映射会将string类型的field同时映射为text类型以及keyword类型，这会浪费磁盘空间，因为我们不一定两种都需要。通常来说，id field这种字段可能只需要keyword映射，而body field可能只需要text field。

映射一个content，content: text，content.内置字段: keyword

可以通过手动设置mappings映射来避免字符串类型的field被自动映射为text和keyword：

PUT index
{
  "mappings": {
    "type": {
      "dynamic_templates": [
        {
          "strings": {
            "match_mapping_type": "string",
            "mapping": {
              "type": "keyword"
            }
          }
        }
      ]
    }
  }
}

3、禁止_all field

_all field会将document中所有field的值都合并在一起进行索引，很耗费空空间，如果不需要一次性对所有的field都进行搜索，那么最好禁用_all field。

4、使用best_compression

_source field和其他field都很耗费磁盘空间，最好是对其使用best_compression进行压缩。用elasticsearch.yml中的index.codec来设置，将其设置为best_compression即可。

5、用最小的最合适的数字类型

es支持4种数字类型，byte，short，integer，long。如果最小的类型就合适，那么就用最小的类型。

索引写入性能优化

1和2，适合的是，你的es java client程序，可以采取批量写的场景
3，比较通用的，比较合适的是，你对于写入数据到可以读到能够接受比较大的延迟
4，一次性批量导入数据的场景
5/6/7/8/9，通用型，尽量都去做到
1/2/3/4，都是有各自适用的场景，如果场景合适，就尽量用，因为对性能的提升都是很明显的
5/6/7/8/9，其中通用，尽量去优化你的集群，但是其中最重要的，就是3块，filesystem cache更大的内存，给index buffer最充足的内存，一个是用SSD固态硬盘

1、用bulk批量写入

你如果要往es里面灌入数据的话，那么根据你的业务场景来，如果你的业务场景可以支持，可以做到，让你将一批数据聚合起来，一次性写入es，那么就尽量采用bulk的方式，每次批量写个几百条这样子。

bulk批量写入的性能比你一条一条写入大量的document的性能要好很多。但是如果要知道一个bulk请求最佳的大小，需要对单个es node的单个shard做压测。先bulk写入100个document，然后200个，400个，以此类推，每次都将bulk size加倍一次。如果bulk写入性能开始变平缓的时候，那么这个就是最佳的bulk大小。并不是bulk size越大越好，而是根据你的集群等环境具体要测试出来的，因为越大的bulk size会导致内存压力过大，因此最好一个请求不要发送超过10mb的数据量。

之前有es学员就是在公司里测试这个bulk写入，上来就是多线程并发写bulk，但是这里面就有一个问题，刚开始，你先确定一个是bulk size，此时就尽量是用你的程序，单线程，一个es node，一个shard，测试。看看单线程最多一次性写多少条数据，性能是比较好的。

2、使用多线程将数据写入es

单线程发送bulk请求是无法最大化es集群写入的吞吐量的。如果要利用集群的所有资源，就需要使用多线程并发将数据bulk写入集群中。为了更好的利用集群的资源，这样多线程并发写入，可以减少每次底层磁盘fsync的次数和开销。一样，可以对单个es节点的单个shard做压测，比如说，先是2个线程，然后是4个线程，然后是8个线程，16个，每次线程数量倍增。一旦发现es返回了TOO_MANY_REQUESTS的错误，JavaClient也就是EsRejectedExecutionException，之前有学员就是做多线程的bulk写入的时候，就发生了。此时那么就说明es是说已经到了一个并发写入的最大瓶颈了，此时我们就知道最多只能支撑这么高的并发写入了。

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、禁止swapping交换内存

之前讲解果，可以将swapping禁止掉，有的时候，如果要将es jvm内存交换到磁盘，再交换回内存，大量磁盘IO，性能很差

6、给filesystem cache更多的内存

filesystem cache被用来执行更多的IO操作，如果我们能给filesystem cache更多的内存资源，那么es的写入性能会好很多。

7、使用自动生成的id

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

8、用性能更好的硬件

我们可以给filesystem cache更多的内存，也可以使用SSD替代机械硬盘，避免使用NAS等网络存储，考虑使用RAID 0来条带化存储提升磁盘并行读写效率，等等。

9、index buffer

如果我们要进行非常重的高并发写入操作，那么最好将index buffer调大一些，indices.memory.index_buffer_size，这个可以调节大一些，设置的这个index buffer大小，是所有的shard公用的，但是如果除以shard数量以后，算出来平均每个shard可以使用的内存大小，一般建议，但是对于每个shard来说，最多给512mb，因为再大性能就没什么提升了。es会将这个设置作为每个shard共享的index buffer，那些特别活跃的shard会更多的使用这个buffer。默认这个参数的值是10%，也就是jvm heap的10%，如果我们给jvm heap分配10gb内存，那么这个index buffer就有1gb，对于两个shard共享来说，是足够的了。