elasticsearch 其他优化

字段类型优化

• 数值类型 ：选择适用的最小类型，能用 byte 就不要用 short，能用 short 就不要用 integer。对索引、检索、存储都有好处。 Which type should I use?

• nested类型 ：索引一个有100个 nested 类型字段的文档，实际上会有101个文档被索引，因为每个 nested 类型都被单独作为一个文档索引，所以应当避免使用 nested 类型。 Limiting the number of nested fields](https://www.elastic.co/guide/en/elasticsearch/reference/5.5/nested.html#limit-number-nested-fields)

元字段优化

• _all field ：_all 字段是一个特殊的字段，内容是其他字段的值使用空格分割，拼接为一个大字符串，然后再进行分词、索引，但是不存储。因此只能搜索，不能检出。可以这个字段是一个 text 类型的字段，不论其他字段是什么类型，拼接时都会作为字符串拼接。所以如果不需要，可以将其禁用，因为在写入时会占用CPU和存储资源。

Mapping 参数优化

• copy_to ：可以用来将一些字段值拷贝到另一个字段中，没有特殊需求不要使用
• fielddata ： 避免使用 text 类型的字段，做排序、聚合及脚本中使用，可以考虑使用 fields 机制完成

默认情况下，大部分的字段都会被索引，这使得他们可以被搜索。但是在搜索里的排序、聚合和脚本中访问字段值时，使用的是另外一种文档数据的访问机制。

搜索需要解决的问题是文档中是否包含这个词，但排序和聚合解决的却是文档中的字段值是什么。

大部分的字段都可以使用索引文档时，存在磁盘上的 [doc_values 作为数据访问机制，但是 text 类型不支持 doc_values。

因此如果要使用 text 类型的字段进行排序、聚合等，就需要使用一种内存数据结构——fielddata，这个机制默认是禁用的。构建 fielddata 结构时，会从磁盘上的所有的分段上读取所有的倒排索引，然后再JVM堆内存构建 fielddata 结构，所以使用fielddata的成本很高。

• store ：默认情况 下，字段的值都是会被索引的，字段可以被搜索，但是字段的值没有存储。也就是说如果要得到字段的值，还需要从 _source 中检出。

例如，索引的数据是博客，有字段 title、content，content 是一个超大的文本字段，如果我们只需要查询出 title 字段，如果从 _source 中解析可能就会很慢，使用 store 可以不用通过 _source。

可以对比 MySQL 的非聚簇索引。