图解 ElasticSearch 搜索原理
程序员的成长之路
共 6978字,需浏览 14分钟
·
2024-05-22 00:00
阅读本文大概需要 5 分钟。
来自:www.cnblogs.com/richaaaard/p/5226334.html
摘要
-
为什么我的搜索 *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)
昂贵的查找
问题的转化
-
* suffix -> xiffus *
如果我们想以后缀作为搜索条件,可以为Term做反向处理。
-
(60.6384, 6.5017) -> u4u8gyykk
对于GEO位置信息,可以将它转换为GEO Hash。
-
123 -> {1-hundreds, 12-tens, 123}
对于简单的数字,可以为它生成多重形式的Term。
解决拼写错误
Stored Field字段查找
Document Values为了排序,聚合
搜索发生时
-
Segments是不可变的(immutable)
-
-
Delete? 当删除发生时,Lucene做的只是将其标志位置为删除,但是文件还是会在它原来的地方,不会发生改变 -
Update? 所以对于更新来说,本质上它做的工作是:先删除 ,然后重新索引(Re-index) -
随处可见的压缩
Lucene非常擅长压缩数据,基本上所有教科书上的压缩方式,都能在Lucene中找到。
-
缓存所有的所有
Lucene也会将所有的信息做缓存,这大大提高了它的查询效率。
缓存的故事
举个栗子
在Shard中搜索
对于日志文件的处理
如何Scale
节点分配与Shard优化
-
为更重要的数据索引节点,分配性能更好的机器 -
确保每个shard都有副本信息replica
路由Routing
一个真实的请求
Query
Aggregation
请求分发
上帝节点
-
根据索引信息,判断请求会被路由到哪个核心节点 -
以及哪个副本是可用的 -
等等
路由
在真实搜索之前
-
filters可以在任何时候使用 -
query只有在需要score的时候才使用
返回
《云服务器限时免费领取》 轻量级服务器-2核4G5M 1个月 云服务器-2核4G3M 1个月 ⬇戳阅读原文领取 朕已阅
评论