elasticsearch中文官网,将数据化管理落地的四个关键课后测试
墨初 知识笔记 81阅读
前向索引，也叫前向索引，是通过文档ID查找关键词文档的内容。倒排索引，也叫倒排索引，就是通过关键词找到文档ID。如果在通过正交索引搜索关键字面试场景一时，需要遍历所有文档以找到关键字所在的文档。面试场景二.倒排索引则完全不同。可以通过倒排索引得到“elasticsearch”对应的文档id列表1，然后通过正交索引查询1对应的文档。倒排索引包括两个部分：面试场景三词典$ TERM词典全文检索
列表的关联关系单词词典会比较大一般通过 B 树来实现以满足高性能的插入与查询。
倒排列表Posting List记录了单词对应的文档结合由倒排索引项组成包括 文档 ID等同于数据库主键词频Term Frequency该单词在文档中出现的次数主要是用于打分位置Positon单词在文档中分词的位置用于语句搜索偏移Offset记录单词的的位置 默认情况下ES 的 JSON 文档中的每个字段都有自己的倒排索引这也其在复杂查询上优于 MySQL 的原因。
5.分词器是的说到倒排索引就不得不提分词器。因为没有分词器的话就没有词典也就构建不了倒排索引了。
分词器的主要工作是把用户输入的一段文本按照一定的逻辑转换成一系列单词。
当然仅仅这些还不够因为单词中肯定是有重复的接下来要做事情就是去重以及去重之后的排序这样便于搜索。
整体步骤如下
分词器一般由三个部分组成
字符过滤器Character Filters对原始文本进行处理最常见的就是第一种 分词器Tokenizer将原始文本按照特定的规则切分为单词默认的是 Standard Tokenizer Token 过滤器Token Filter将切分的单词进行加工如大小写转换去掉停用词加入同义词等等。三者顺序为
讲完倒排索引和分词基本上大家对 ES 的运行机制有了一个宏观的了解知道它为什么适合于进行全文检索关键字和多维复杂查询的场景了。
6. 准实时搜索这块知识点是在面试中高频出现的问题。随着按段per-segment搜索的发展 一个新的文档从索引到可被搜索的延迟显著降低了。新文档可做到在几分钟之内即可被检索但这样依然不够快不能满足于所有场景需求。
磁盘在这里成为了瓶颈。因为提交Commiting一个新的段Segment到磁盘需要一个 fsync 来确保段被物理性地写入磁盘这样在断电的时候就不会丢失数据。 但是如果每次索引一个文档都去执行一次 fsync 的话会造成很大的性能问题。
我们需要的是一个更轻量的方式来使一个文档可被搜索在 ES 和磁盘之间是文件系统缓存。在内存索引缓冲区中的文档会被写入到一个新的段中这里新段会被先写入到文件系统缓存这一步代价会比较低稍后再被刷新到磁盘这一步代价比较高。不过只要文件已经在缓存中 就可以像其它文件一样被打开和读取了。
我们都知道ES 的底层实现是 Lucene。而 Lucene 允许新段被写入和打开使其包含的文档在未进行一次完整提交时便对搜索可见。这种方式比进行一次提交代价要小得多并且在不影响性能的前提下可以被频繁地执行。
通过如上实现方式可将 ES 可被检索的时长从分钟级别优化到了秒级别。
默认情况下每个分片会每秒自动刷新refresh一次。这就是为什么我们说 ES 是近实时搜索。文档的变化并不是立即对搜索可见但会在一秒之内变为可见。
refresh的相关 API 如下
1刷新Refresh所有的索引POST /_refresh2只刷新Refreshblogs 索引POST /blogs/_refresh3每 30 秒刷新 my_index 索引PUT my_index/_settings { index : { refresh_interval : 30s } }另外refresh_interval 可以在既存索引上进行动态更新。 在生产环境中当你正在建立一个大的新索引时可以先关闭自动刷新待开始使用该索引时再把它们调回来。
4关闭自动刷新 my_index 索引当内存缓冲区满了才进行 refresh 操作PUT my_index/_settings { index : { refresh_interval : -1 } }示例如下
GET /_search?search_typequery_then_fetch共有四种搜索类型包括query and fetch、query then fetch默认、DFS query and fetch 和 DFS query then fetch。
7.1 query and fetch本地向索引的所有分片shard都发出查询请求各分片返回的时候把元素文档document和计算后的排名分值一起返回。
优点快。缺点排名不准确每个分片计算后的分值进行排序同时各个 shard 返回的结果的数量之和可能是用户要求的 size 的 n 倍。数据量不准确 7.2 query then fetch默认本地先向所有的 shard发出请求各分片只返回文档 id(注意不包括文档 document和排名分值基于自己分片然后按照各分片返回的文档的分数进行重新排名取前 size 个文档。
根据文档 id 去相关的 shard 取 document这种方式返回的 document 数量与用户要求的大小是相等的。
优点返回的数据量是准确的。缺点性能一般并且数据排名不准确。 7.3 DFS query and fetch全局这种方式比第一种方式多了一个 DFS 步骤有这一步可以更精确控制搜索打分和排名。也就是在进行查询之前先对所有分片发送请求把所有分片中的词频率和文档频率等打分依据全部汇总到一块再执行后面的操作。
优点数据排名准确。缺点性能一般返回的数据量不准确 可能返回 (N * 分片数量) 的数据。DFS query then fetch全局
比第 2 种方式多了一个 DFS 步骤。也就是在进行查询之前先对所有分片发送请求把所有分片中的词频率和文档频率等打分依据全部汇总到一块再执行后面的操作。
优点返回的数据量是准确的数据排名准确。缺点性能最差DFS 是一个什么样的过程?
多了一个初始化散发(initial scatter) 步骤在进行真正的查询之前先把各个分片的词频率和文档频率排名信息收集一下然后进行词搜索的时候各分片依据全局的词频率和文档频率进行搜索和排名。
检索词的频率检索词 honeymoon在这个文档的 tweet 字段中出现的次数。
反向文档频率检索词 honeymoon 在索引上所有文档的 tweet 字段中出现的次数。
在每一个分片上查询符合要求的数据并根据全局的 Term 和 Document 的频率信息计算相关性得分构建一个优先级队列存储查询结果包含分页、排序等等把查询结果的 metadata 返回给查询节点。
注意真正的文档此时还并没有返回返回的只是得分数据。
8. query 和 filterElasticSearch 中的 search 操作包括两种查询query和过滤filter。
从使用场景的角度来看全文检索以及任何使用相关性评分的场景使用 query 查询除此之外的使用 filter 过滤器进行过滤。
示例如下
GET /_search{ query: { bool: { must: [ { match: { title: Search }}, { match: { content: Elasticsearch }} ], filter: [ { term: { status: published }}, { range: { publish_date: { gte: 2015-01-01 }}} ] } }}此文档与此查询子句的匹配程度如何以及 query 上下文的条件是用来给文档打分的匹配越好 _score 越高。
即全文搜索评分排序无法缓存性能低。
filter此文档和查询子句匹配吗以及 filter 的条件只产生两种结果符合与不符合后者被过滤掉。
即精确查询是非过滤可缓存性能高。
Query 检索细化关注点
**是否包含**确定文档是否应该成为结果的一部分。
**相关度得分**除了确定文档是否匹配外查询子句还计算了表示文档与其他文档相比匹配程度的_score。得分越高相关度越高。更相关的文件在搜索排名更高。
典型应用场景
1全文检索——这种相关性的概念非常适合全文搜索因为很少有完全正确的答案。
如文档中存在字段
hotel_name“上海浦东香格里拉酒店”实际分词结果为上海浦上海浦东香格里拉格里里拉酒店。也就是说搜索以上关键词都能搜到hotel_name“上海浦东香格里拉酒店”的酒店。这些都是
“相关” 的。
2包含单词 “run” 但也匹配 “runs”, “running”, “jog” 或者 “sprint”。都是奔跑的意思
filter 过滤细化关注点
**是否包含**确定是否包含在检索结果中回答只有 “是” 或“否”。
**不涉及评分**在搜索中没有额外的相关度排名。
**针对结构化数据**适用于完全精确匹配范围检索。
典型应用场景
1时间戳 timestamp 是否在 2015 至 2016 年范围内
2状态字段 status 是否设置为 “published”
为什么 filter 比 query 更快
因为经常使用的过滤器将被 ES 自动缓存以提高性能。只确定是否包括结果中不需要考虑得分。
更多推荐 更多知识原理内容见更多项目实战见
搜索推荐系统专栏简介搜索推荐全流程讲解召回粗排精排重排混排、系统架构、常见问题、算法项目实战总结、技术细节以及项目实战含码源