惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

N
News and Events Feed by Topic
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
月光博客
月光博客
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
大猫的无限游戏
大猫的无限游戏
T
Tailwind CSS Blog
S
SegmentFault 最新的问题
V
V2EX
阮一峰的网络日志
阮一峰的网络日志
C
Cisco Blogs
博客园 - 叶小钗
P
Privacy International News Feed
Jina AI
Jina AI
Apple Machine Learning Research
Apple Machine Learning Research
T
Threatpost
IT之家
IT之家
博客园 - 聂微东
Know Your Adversary
Know Your Adversary
Help Net Security
Help Net Security
罗磊的独立博客
I
Intezer
S
Schneier on Security
博客园_首页
C
CERT Recently Published Vulnerability Notes
雷峰网
雷峰网
Cisco Talos Blog
Cisco Talos Blog
宝玉的分享
宝玉的分享
cs.CV updates on arXiv.org
cs.CV updates on arXiv.org
Webroot Blog
Webroot Blog
TaoSecurity Blog
TaoSecurity Blog
MyScale Blog
MyScale Blog
P
Privacy & Cybersecurity Law Blog
T
The Exploit Database - CXSecurity.com
PCI Perspectives
PCI Perspectives
Security Latest
Security Latest
H
Heimdal Security Blog
S
Secure Thoughts
Hacker News: Ask HN
Hacker News: Ask HN
Y
Y Combinator Blog
cs.CL updates on arXiv.org
cs.CL updates on arXiv.org
Microsoft Security Blog
Microsoft Security Blog
cs.AI updates on arXiv.org
cs.AI updates on arXiv.org
SecWiki News
SecWiki News
The GitHub Blog
The GitHub Blog
A
Arctic Wolf
A
About on SuperTechFans
aimingoo的专栏
aimingoo的专栏
T
Threat Research - Cisco Blogs
Engineering at Meta
Engineering at Meta
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC

博客园 - 软件心理学工程师

SPIFFE/SPIRE 的身份哲学与技术实现 后量子密码学(post-quantum cryptography):为什么重要以及如何使用 密钥管理碎碎念 SpringBoot集成resilience4j进行熔断和一个响应式编程的问题 凤凰项目&DevOps实践指南 OAuth2和OpenID API横向越权问题的分析和解决 初识RAG 基于AWS的密钥管理系统 加密算法的使用场景 Linux透明大页(Transparent Huge Pages)对ES性能对影响 《java8 in action》读书笔记 ES索引的一些长度限制 初识redis Elasticsearch慢查询故障诊断 Elasticsearch搜索调优 elasticsearch.yml 常用参数说明 linux log rotate elasticsearch local debug环境搭建 CAP碎碎念 彻底删除kafka topic步骤
elasticsearch基础知识杂记
软件心理学工程师 · 2019-10-21 · via 博客园 - 软件心理学工程师

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