用shrink和rollover api 高效管理基于时间的索引
创建索引时要先定义分片的数量， 在索引创建完之后将无法增加或减少分片的数量
分片越多，索引吞吐量越大，查询速度越慢，需要的资源越多
随着数据的增长，扩容将成为必须，上面这两个问题就会成为集群的性能和管理的超级障碍
假设每天都要为日志创建一个包含5个分片的索引，那这个行为每年都会创建出 1825 个分片来。 而且，假如不会再查询旧索引，那么在集群中保存那么多分片就没有意义了。
shrink API
shrink API 可以让用户将一个现有索引的朱分片减少，最终生成一个 新索引
收缩的过程
首先创建一个与源索引有相同定义的目标索引，但是主分片数会更少
然后创建硬连接，将源索引中的段连接到目标索引 （如果文件系统不支持硬连接，就把所有段拷贝到新索引中，这样的过程当然会更耗时）
最后对目标索引执行恢复流程，就好像它是一个已经关闭了的索引，现在刚刚被再次打开一样
多匹配类型
best_fields 从多字段中，找一个评分最高的
most_fields 为每一个字段评分，把所有评分综合考虑
cross_fields 把所有字段当做一个大字段考虑
phrase 匹配词组
phrase_prefix1.最佳字段(Best fields):
指的就是搜索结果中应该返回某一个字段匹配到了最多的关键词的文档。
2.多数字段(Most fields):
一个用来调优相关度的常用技术是将相同的数据索引到多个字段中。它用来尽可能多地匹配文档。
ES会为每个字段生成一个match查询，然后将它们包含在一个bool查询中。
指的就是搜索结果应该返回匹配了更多的字段的document优先返回回来。
most_fields 会告诉 Elasticsearch 合并所有匹配字段的评分：
most_fields 方式的问题
用 most_fields 这种方式搜索也存在某些问题，这些问题并不会马上显现：
- 它是为多数字段匹配 任意 词设计的，而不是在 所有字段 中找到最匹配的。
- 它不能使用
operator或minimum_should_match参数来降低次相关结果造成的长尾效应。 - 词频对于每个字段是不一样的，而且它们之间的相互影响会导致不好的排序结果。
3.跨字段(Cross fields):
对于一些实体，标识信息会在多个字段中出现，每个字段中只含有一部分信息：
- Person:
first_name和last_name - Book:
title,author, 和description - Address:
street,city,country, 和postcode
此时，我们希望在任意字段中找到尽可能多的单词。我们需要在多个字段中进行查询，就好像这些字段是一个字段那样。
指的是一个唯一标识，跨域了多个字段，它将所有的字段视为一个大的字段，然后在任一字段中搜索每个词条
match_phrase
比如，有如下查询
{
“match”: {
“content”: “java spark”
}
}
match query，只能搜索到包含java和spark的document，但是不知道java和spark是不是离的很近。
如果希望搜索java spark，中间不能插入任何其他的字符，那这个时候match去做全文检索是无法做到的，此时需要使用match_phrase
slop
要经过几次移动才能与一个document的field中的匹配，这个移动的次数，就是slop
match_phrase_prefix
原理跟match_phrase类似，唯一的区别，就是把最后一个term作为前缀去搜索
hello就是去进行match，搜索对应的doc
w，会作为前缀，去扫描整个倒排索引，找到所有w开头的doc
然后找到所有doc中，即包含hello，又包含w开头的字符的doc
Elasticsearch 中的数据建模方法
要想让查询速度更快，让更新更容易而且代价更小，定义数据结构是要解决的关键问题之一。
扁平式结构
在扁平式结构中，用简单的键值对索引文档，有时候也用简单对象的形式，这些最简单最快。
数据存储成这种格式就可以 索引更快，也可以查询更快。
但是这样索引文档会导致难以维护不同实体之间的关系，因为Elasticsearch并不知道实体时间应该是怎样的关系。
使用扁平结构之后，就经常要在应用程序中做关联，以发现文档之间的关系。
数据反范式化
即把其他文档内的相关字段多复制一份，目的只是为了维护实体之间的关系。
这种方法可以用来维护扁平式结构，也可以通过在没分文档中多保存一到多个字段来维护它们之间的关系，但是会占用大量空间
嵌套与父子关系
这些关系是 Elasticsearch 为管理关系型数据而自带的解决方案
