字段类型优化
-
数值类型 :选择适用的最小类型,能用 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 参数优化
默认情况下,大部分的字段都会被索引,这使得他们可以被搜索。但是在搜索里的排序、聚合和脚本中访问字段值时,使用的是另外一种文档数据的访问机制。
搜索需要解决的问题是文档中是否包含这个词,但排序和聚合解决的却是文档中的字段值是什么。
大部分的字段都可以使用索引文档时,存在磁盘上的 [doc_values 作为数据访问机制,但是 text 类型不支持 doc_values。
因此如果要使用 text 类型的字段进行排序、聚合等,就需要使用一种内存数据结构——fielddata,这个机制默认是禁用的。构建 fielddata 结构时,会从磁盘上的所有的分段上读取所有的倒排索引,然后再JVM堆内存构建 fielddata 结构,所以使用fielddata的成本很高。
- store :默认情况 下,字段的值都是会被索引的,字段可以被搜索,但是字段的值没有存储。也就是说如果要得到字段的值,还需要从 _source 中检出。
例如,索引的数据是博客,有字段 title、content,content 是一个超大的文本字段,如果我们只需要查询出 title 字段,如果从 _source 中解析可能就会很慢,使用 store 可以不用通过 _source。
可以对比 MySQL 的非聚簇索引。