elasticsearch基础知识杂记

日常工作中用到的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并返回。