百度一面问了 3 个 ES 问题,直接干懵了!
Java技术栈
共 8776字,需浏览 18分钟
·
2024-04-03 07:11
先自上而下,后自底向上的介绍ElasticSearch的底层工作原理,试图回答以下问题:
-
为什么我的搜索 foo-bar 无法匹配 _foo-bar_ ? -
为什么增加更多的文件会压缩索引(Index)? 为什么ElasticSearch占用很多内存?
图解ElasticSearch
云上的集群
集群里的盒子
节点之间
索引里的小方块
Shard=Lucene Index
图解Lucene
Mini索引——segment
Segment内部
-
Inverted Index -
Stored Fields -
Document Values -
Cache
最最重要的Inverted Index
-
一个有序的数据字典Dictionary(包括单词Term和它出现的频率)。 -
与单词Term对应的Postings(即存在这个单词的文件)。
查询“the fury”
自动补全(AutoCompletion-Prefix)
昂贵的查找
在此种情况下,如果想要做优化,那么我们面对的问题是如何生成合适的Term。
问题的转化
-
suffix -> xiffus
如果我们想以后缀作为搜索条件,可以为Term做反向处理。 -
(60.6384, 6.5017) -> u4u8gyykk
对于GEO位置信息,可以将它转换为GEO Hash。 -
123 -> {1-hundreds, 12-tens, 123}
解决拼写错误
Stored Field字段查找
Fields来解决这个问题。本质上,Stored Fields是一个简单的键值对key-
value。默认情况下,ElasticSearch会存储整个文件的JSON source。
Document Values为了排序,聚合
所以,另一种数据结构解决了此种问题:Document Values。这种结构本质上就是一个列式的存储,它高度优化了具有相同类型的数据的存储结构。
搜索发生时
Lucene的一些特性使得这个过程非常重要:
-
Segments是不可变的(immutable) -
Delete? 当删除发生时,Lucene做的只是将其标志位置为删除,但是文件还是会在它原来的地方,不会发生改变 -
Update? 所以对于更新来说,本质上它做的工作是:先 删除 ,然后 重新索引(Re-index) -
随处可见的压缩
Lucene非常擅长压缩数据,基本上所有教科书上的压缩方式,都能在Lucene中找到。 -
缓存所有的所有
缓存的故事
举个栗子
以上场景经常在Lucene Index内部发生的。
在Shard中搜索
需要注意的是:
对于日志文件的处理
当我们想要删除旧的数据时也非常方便,只需删除老的索引即可。
如何Scale
节点分配与Shard优化
-
为更重要的数据索引节点,分配性能更好的机器 -
确保每个shard都有副本信息replica
路由Routing
一个真实的请求
Query
Aggregation
请求分发
上帝节点
-
根据索引信息,判断请求会被路由到哪个核心节点 -
以及哪个副本是可用的 -
等等
路由
在真实搜索之前
-
filters可以在任何时候使用 -
query只有在需要score的时候才使用
返回
来源:cnblogs.com/richaaaard/p/5226334.html
评论