日常工作中用到的ES相关基础知识和总结。不足之处请指正，会持续更新。
1.集群的健康状况为 yellow 则表示全部主分片都正常运行（集群可以正常服务所有请求），但是 副本 分片没有全部处在正常状态。
2.主分片的数目在索引创建时就已经确定了下来。但是，读操作——搜索和返回数据——可以同时被主分片 或 副本分片所处理，所以当你拥有越多的副本分片时，也将拥有越高的吞吐量。不过要小心副本分片太多，对内存对占用太多，可能会降低查询效率。
3.elasticsearch乐观并发控制，利用_version号来确保应用中相互冲突的变更不会导致数据丢失。如果旧版本的文档在新版本之后到达，它可以被简单的忽略。
4.文档路由到分片：shard = hash(id) % number_of_primary_shards。可以自己指定一个或多个字段做路由，会大大降低查询耗时。
5.新建、索引和删除文档等写操作，必须在主分片上完成之后才能被复制到相关的副本分片。
6.检索一个文档，可以从主分片或者任意副本分片检索。
7.插入，修改或删除一个文档，只能从主分片操作。
8.轻量搜索：GET /index/type/_search?q=last_name:Smith , 对字段last_name进行query-string搜索。
9.查询表达式搜索：比轻量搜索更丰富灵活，支持全文搜索，短语搜索，过滤，排序等。参看DSL查询语法。
10.评分查询：计算score和排序。指定一个固定的score: constant_score。不计算score：filter。
11.搜索执行：query_and_fetch, query_then_fetdch。
12.存储优化：SSD和普通机械硬盘。按hot-warm标签进行分类。
13. index sort采用中断查询，加快查询速度。不过存储性能大打折扣。
13.倒排索引：你只能搜索在索引中出现的词条，索引文本和查询字符串必须标准化为相同的格式。
14.相关性：TF-IDF + 字段长度。查询结果中的_score字段，查看如何具体计算用explain参数。如果用filter或constant_score查询，可以不计算score。
15._source字段和_all字段：_source字段存储整个json文档体。_all字段把其他字段值当做一个大字符串来索引。
16.store是在 _source之外再对指定store的字段存一份，通常用于某字段文本很长，不想放在_source里面，或者该字段经常需要做reindex。
17.refresh和flush:refresh把数据从内存刷到文件系统缓存（lucene flush），并追加translog，这时便可以被search到。flush把数据从缓存刷到磁盘并清空translog，持久化数据到磁盘(lucene commit)。
18.inner_hits:用于把父子文档或者嵌套文档中子文档命中的部分展示出来，相当于在父子之间做了join返回。不用inner_hits的话，父子文档只返回符合条件的父文档，不展示命中的子文档。
19. parent-child:父子文档在一个索引中，处在独立的Lucene文件中,主要作用是允许把一个type的文档和另外一个type的文档关联起来，一个父文档，对应一到多个子文档。
与nested相比，parent-child关系的主要优势有：
- 更新父文档时，不会重新索引子文档。而更新nested文档会重新索引主文档和所有nested文档。
- 创建，修改或删除子文档时，不会影响父文档或者其他子文档。
- 父文档的id用于子文档的routing依据。因为，查找子文档时要指明父文档Id。
20.Global Ordinals:某个字段的值，在shard级别映射成的编号。比如字段status的value有IDEL, RUNNING, SUCCESS, FAILED，分别映射成1,2,3,4，可降低agg阶段的资源开销，还能提前加载。
21.High Cardinality:是指某个字段有很多unqiue value。
- High Cardinality会导致构建Global Ordinals过程变慢，从而导致聚合查询变慢、内存使用过高。
- High Cardinality会导致压缩比率降低，从而导致存储空间增加，特别是像hash值这样完全随机的字符串。
- 对High Cardinality字段执行Cardinality聚合查询时，会受到精度控制从而导致结果不精确。
22.rescore:对查询出来的结果中的topN进行重新打分和排序。rescore query里如果再有sort会报错。window_size:topN的取值。query_weight:默认值为1，原查询的打分会先乘以该值，然后再与rescore的得分相加。rescore_query_weight:rescore的打分会先乘以该值，然后在与原查询的得分相加。rescore_mode: total，max， min, avg, multiply。
23.Ingest Node:预处理节点, pipeline中的processor做预处理。pipeline = processors的集合。用_simulate API测试pipeline的效果。
24.script: doc只可以在search, agg中访问到;GET操作用params._source取值;POST操作通过ctx._source取值。doc['first.keyword']`这样的写法是因为doc[]返回有可能是分词之后的value，所以你想要某个field的完整值时，请使用keyword。
25.function_score：允许为每个与主查询匹配的文档应用一个函数，以达到改变甚至完全替换原始查询评分"_score"的目的。将检索与希望重点关注的因素结合起来。weight: 设置权重，finalscore = _score*weight。field_value_factor:使用这个值来修改_score，如将某些字段作为考虑因素。random_score: 为每个用户都使用一个不同的随机评分对结果排序，但对某一具体用户来说，看到的属性始终一致。script_score:用自定义脚本控制评分。
26.Analyzer: 包含3个部分：1. Character Filters:字符过滤。2. Tokenzier:词项划分。3. Token Filters：词项过滤。可以采用 **_analyze** API检验分词器的效果。
27.配置优先级：Transient settings > Persistent settings > command-line settings > config file settings
28.Doc value:存储文档Id与字段内容的对应关系，存储于磁盘加载到文件系统缓存, 通常也被叫做正排索引。text字段没有doc value，可以把该类字段再存一个keyword。keyword类型的字段默认存doc value，如果不想存doc value可以显示禁止。
29. FieldData: 基于内存，针对text字段。Fielddata 和 doc_value的比较。
相同点:
- 都要创建正排索引，数据结构类似于列式存储
- 都是为了可以聚合，排序之类的操作
不同点：
- fielddata: 内存存储；doc_values: OS Cache+磁盘存储
- fielddata: 对应的字段类型是text; doc_values：对应的字段类型是keyword
- field_data主要针对的是分词字段；doc_values针对大是不分词字段
- fielddata默认不开启；doc_values默认是开启
30. query cache:缓存filter/range/must_not的最终结果。segment的文档数量小于10000或者小于总index数量的3%时，查询是不会缓存的。
31. request cache：缓存shard级别的查询结果。不缓存size>0的结果，比如具体的hits。缓存hits.total, aggregations, suggestions.
32. cache policy：LRU。缓存的结果会随着segment merge或者shard refresh而无效。cache key是request的json body。如果json body发生变化，则不能利用缓存。即使同一个请求，但是条件的顺序不同，也不行。cache会刷掉，每次refresh或者segment merge会刷cache。保存cache又比较耗时。
33. Data Frames：用于提升agg的performance。提前从A索引根据字段和agg条件做好aggreation存入B索引，方便查找和展示。
34. Minimal Snapshot：只snapshot索引的name, _source和metadata，restore的时候通过reindex重做索引。节约snapshot的存储空间，但索引restore的时间会变长。
35. Suggester:将输入的文本切分成token，然后在索引的字典里查找相似的term并返回。