天津建设网站安全员考试成绩查询,互联网十大企业,大良营销网站建设平台,阐述建站流程1.难点解答
收集到几个问题#xff1a;
elasticsearch是单独建一个项目#xff0c;作为全文搜索使用#xff0c;还是直接在项目中直接用#xff1f; ES 服务器是要单独部署的#xff0c;你可以把 ES 理解为 Redis。 新增数据时#xff0c;插入到mysql中#xff0c;需不…1.难点解答
收集到几个问题
elasticsearch是单独建一个项目作为全文搜索使用还是直接在项目中直接用 ES 服务器是要单独部署的你可以把 ES 理解为 Redis。 新增数据时插入到mysql中需不需要同时插入到es中 一般情况下新增数据的时候很少有采取双写的方案同时写入 MySQL 和 ES 中的。主流的技术方案都是通过 Canal 或 DataBus 监听 MySQL 的 binlog来把数据同步到 ES 中的。 搜索时直接返回es搜索的结果还是需要根据es的结果中的id回mysql中重新查一遍如果不用回mysql中查那么mysql还有什么用直接存es中查也使用esmysql难道只是做备份的吗 一般情况下能直接通过 ES 返回搜索结果的不会再去 MySQL 重新查一遍。MySQL 存在的意义在于其关系型数据存储、简单查询的实时性以及其具备事务特性。 更多知识原理内容见
https://blog.csdn.net/sinat_39620217/article/details/134011021
更多项目实战见
搜索推荐系统专栏简介搜索推荐全流程讲解召回粗排精排重排混排、系统架构、常见问题、算法项目实战总结、技术细节以及项目实战含码源
2.面试常见问题模拟对白
面试官说说你对 ElasticSearch 的理解这应该是一个非常高频的面试问题。
面试场景一 我“请说下你对 ES 的理解。” 候选人“ES 的性能非常好我们的订单中心的订单数据就会往 ES 中同步一份。然后所有的查询请求都走 ES。” 我“对实时性要求很高的 by id 查询也走 ES 吗” 候选人有些慌“这个。。。呵呵我觉得都可以吧。” 我“为什么 ES 叫近实时搜索引擎请问‘近实时’三个字如何体现的” 候选人“这个。。。” 面试场景二 我“请说下你对 ES 的理解。” 候选人口若悬河“ES 是一个基 Lucene 的 Java 开发的搜索引擎是一个分布式、可扩展、实时的搜索与数据分析引擎可以解决项目中的多维搜索问题。” 我“那可以说说ES 不适合做什么吗” 候选人“这个。。。” 面试场景三 我“刚才你说的你们系统线上环境的峰值 QPS 是 3000那如果 QPS 再增加十倍你打算如何优化” 候选人“现在系统中主要用的 MySQL 和 Redis如果 QPS 高了可以再增加 ES。” 我“为什么用 ES 就可以顶住更高的 QPS你分析过你系统请求的类型吗” 候选人“这个。。。” 形象比喻热水化然后我在想ES 对于很多经验尚浅的同学来说是不是有点儿渣男语录中的 “热水化”。 肚子疼多喝热水 —— QPS 高用 ES玩累了多喝热水 —— 性能不好用 ES心情不好多喝热水 —— 数据量大用 ES感冒了多喝热水 —— 懒得分表用 ES
其实摆脱热水化接近事实真相并不困难。下面我们还是通过现象倒推本质去深入浅出地理解一下 ES。
3.应用场景
目前在互联网和电商方向有很多同学都是用 ES 为 MySQL 去补齐短板的。最最典型的是两个应用场景全文检索 和 复杂查询
尤其是复杂查询因为 MySQL 的底层是通过 B Tree 实现的索引如果把每个搜索项都建上索引会非常影响 MySQL 的写入操作的性能。
如果业务主表的数据量过于庞大MySQL 不得已做了分库分表方案的话那会对 MySQL 的查询产生进一步的影响。因为查询条件里面如果不将分库分表键带入的话就只能将 MySQL 已分的全部库表全部查询一遍才会获取全部数据结果。基本上在互联网或电商领域引入 ES80% 都是为了解决这种场景的问题。 那么为什么 ES 处理这种场景就游刃有余呢四个字 —— 倒排索引。
4.倒排索引
索引的初衷是为了从一个海量数据集中快速找出某个字段等于确定值所对应的记录索引分为正排索引和倒排索引两种。
正排索引也叫正向索引Forward Index是通过文档 ID 去查找关键词文档内容。倒排索引也叫反向索引Inverted Index是通过关键词查找文档 ID。 如果通过正排索引查找关键词 elasticsearch 时需要遍历所有文档查找出这个关键词所在的文档。如果文档数量非常庞大的话正排索引的弊端就是查询效率太低。
而倒排索引的玩法就完全不一样了通过倒排索引获得 “elasticsearch” 对应的文档 id 列表 1再通过正排索引查询 1 所对应的文档这样就可以了。
倒排索引包括两部分词典Term Dictionary 倒排列表Posting List。
单词词典Term Dictionary记录了所有文档的单词与倒排列表的关联关系单词词典会比较大一般通过 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
}
}7. 搜索类型SearchType
示例如下
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 和 filter
ElasticSearch 中的 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
此文档与此查询子句的匹配程度如何以及 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 自动缓存以提高性能。只确定是否包括结果中不需要考虑得分。
更多推荐
更多知识原理内容见
https://blog.csdn.net/sinat_39620217/article/details/134011021
更多项目实战见
搜索推荐系统专栏简介搜索推荐全流程讲解召回粗排精排重排混排、系统架构、常见问题、算法项目实战总结、技术细节以及项目实战含码源
