ElasticSearch底层原理简析

2024-09-08 07:18

本文主要是介绍ElasticSearch底层原理简析,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

1.ElasticSearch简述
ElastiaSearch(以下简称ES)是一个基于Lucene的搜索服务器,它提供了一个分布式多用户能力的全文搜索引擎,支持RESTful web接口。Elasticsearch是用Java开发的,并作为Apache许可条款下的开放源码发布,是当前流行的企业级搜索引擎。ES设计用于云计算中,能够进行实时搜索,支持PB级搜索,具有稳定,可靠,快速,安装使用方便等优点。从2016年开始,使用量已经超越solr。目前京东互联网医院对医院、医生、问诊单的搜索;京东多药城b2c处方药订单的搜索等均已依赖ES进行。
本文从倒排索引、相关度分数计算、分布式架构、JavaAPI常见用法等几个方面简要解析ES底层原理及基本用法,希望给读者提供有益帮助。

2.倒排索引
2.1理解倒排索引
ES使用倒排索引的结构进行全文快速搜索,一个倒排索引由文档中所有不重复的列表构成,对于每一个单词,有一个包含他的文档列表。本小节主要以京东互联网医院医院信息为例介绍倒排索引的存储方式及数据存储标准化规则。
如下表所示,假设文档集合中包含5个文档,左边对应文档编号,右边文档内容,我们的任务就是对这个文档集合建立倒排索引。
文档编号 文档内容
1 {“hospitalName”:”北京大学第三附属医院”}
2 {“hospitalName”:”北京协和医院”}
3 {“hospitalName”:”解放军总医院第一附属医院”}
4 {“hospitalName”:”Peking University Third Hospital”}
5 {“hospitalName”:”Peking Union Medical College Hospital”}

(1)首先利用中、英文分词器从所有文档中提取不重复的单词,每一个单词对应有一个ID和含有这个单词的文档ID,这样可以很清晰的看出单词及对应的文档,如下表所示。
单词ID 单词 文档id
1 医院 1、2、3
2 北京 1、2
3 北京大学 1
4 第三 1
5 附属 1、3
6 协和 2
7 解放军 3
8 第一 3
9 总 3

(2)索引系统还可以记录除此之外的很多信息,下图还记录了单词频率信息(TF),即单词在每个文档中出现的次数。这个信息是用户为词条信息在搜索时,计算查询和文档相似程度(相关度分数)是一个很重要的计算因子。
单词ID 单词 文档Id:出现次数
1 医院 (1:1)、(2:1)、(3:2)
2 北京 (1:1)、(2:1)
3 北京大学 (1:1)
4 第三 (1:1)
5 附属 (1:1)、(3:1)
6 协和 (2:1)
7 解放军 (3:1)
8 第一 (3:1)
9 总 (3:1)

(3)还可以记录单词在文档中出现的位置
例如:(1,<8>,1)代表“医院”这个单词在ID为1、位置为8的文档中的出现了1次。
单词ID 单词 文档id,<位置>,出现次数
1 医院 (1,<8>,1)、(2<5>1)、(3<5,11>2)
… … …

显然,利用倒排索引,我们可以很快定位到文档,从而提高用户对词条的检索速度。
2.2标准化规则(normalization)
为解决词条检索时词条命中率问题,ES在建立倒排索引时运用标准化规则即针对存储的索引词条进行一些相关预处理再作为索引进行存储。
为了便于理解,此部分利用英文文档解释倒排索引的标准化规则。
例如:通常情况下,在搜索“Third”、“Hospital”这两个单词时候,文档4两个单词都出现了,计数为2;文档5只有“Hospital”这个单词出现了,计数为1,所以文档4命中率高,排名靠前。
Term Doc_4 Doc_5
Third 1 0
Hospital 1 1
Peking 1 1
Total 3 2

但是这样搜索就会存在下列问题:
(1)”Third”与”third” 用户认为是相同单词,但是首字母小写可能搜不到内容。
(2)“hospitals”与”hospital”有相同的词根,如果存储了”hospitals”,那么”hospital”可能检索不到 。
(3)“piking”与”beijing”为相同意思的词,”beijing”可能检索不到。
基于以上问题,ES在建立倒排索引时,会对拆分的各个单词进行相应

这篇关于ElasticSearch底层原理简析的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/1147477

相关文章

基于MySQL Binlog的Elasticsearch数据同步实践

一、为什么要做 随着马蜂窝的逐渐发展,我们的业务数据越来越多,单纯使用 MySQL 已经不能满足我们的数据查询需求,例如对于商品、订单等数据的多维度检索。 使用 Elasticsearch 存储业务数据可以很好的解决我们业务中的搜索需求。而数据进行异构存储后,随之而来的就是数据同步的问题。 二、现有方法及问题 对于数据同步,我们目前的解决方案是建立数据中间表。把需要检索的业务数据,统一放到一张M

深入探索协同过滤:从原理到推荐模块案例

文章目录 前言一、协同过滤1. 基于用户的协同过滤(UserCF)2. 基于物品的协同过滤(ItemCF)3. 相似度计算方法 二、相似度计算方法1. 欧氏距离2. 皮尔逊相关系数3. 杰卡德相似系数4. 余弦相似度 三、推荐模块案例1.基于文章的协同过滤推荐功能2.基于用户的协同过滤推荐功能 前言     在信息过载的时代,推荐系统成为连接用户与内容的桥梁。本文聚焦于

hdu4407(容斥原理)

题意:给一串数字1,2,......n,两个操作:1、修改第k个数字,2、查询区间[l,r]中与n互质的数之和。 解题思路:咱一看,像线段树,但是如果用线段树做,那么每个区间一定要记录所有的素因子,这样会超内存。然后我就做不来了。后来看了题解,原来是用容斥原理来做的。还记得这道题目吗?求区间[1,r]中与p互质的数的个数,如果不会的话就先去做那题吧。现在这题是求区间[l,r]中与n互质的数的和

【编程底层思考】垃圾收集机制,GC算法,垃圾收集器类型概述

Java的垃圾收集(Garbage Collection,GC)机制是Java语言的一大特色,它负责自动管理内存的回收,释放不再使用的对象所占用的内存。以下是对Java垃圾收集机制的详细介绍: 一、垃圾收集机制概述: 对象存活判断:垃圾收集器定期检查堆内存中的对象,判断哪些对象是“垃圾”,即不再被任何引用链直接或间接引用的对象。内存回收:将判断为垃圾的对象占用的内存进行回收,以便重新使用。

hdu4407容斥原理

题意: 有一个元素为 1~n 的数列{An},有2种操作(1000次): 1、求某段区间 [a,b] 中与 p 互质的数的和。 2、将数列中某个位置元素的值改变。 import java.io.BufferedInputStream;import java.io.BufferedReader;import java.io.IOException;import java.io.Inpu

hdu4059容斥原理

求1-n中与n互质的数的4次方之和 import java.io.BufferedInputStream;import java.io.BufferedReader;import java.io.IOException;import java.io.InputStream;import java.io.InputStreamReader;import java.io.PrintWrit

哈希表的底层实现(1)---C++版

目录 哈希表的基本原理 哈希表的优点 哈希表的缺点 应用场景 闭散列法 开散列法 开放定值法Open Addressing——线性探测的模拟实现 超大重点部分评析 链地址法Separate Chaining——哈希桶的模拟实现 哈希表(Hash Table)是一种数据结构,它通过将键(Key)映射到值(Value)的方式来实现快速的数据存储与查找。哈希表的核心概念是哈希

寻迹模块TCRT5000的应用原理和功能实现(基于STM32)

目录 概述 1 认识TCRT5000 1.1 模块介绍 1.2 电气特性 2 系统应用 2.1 系统架构 2.2 STM32Cube创建工程 3 功能实现 3.1 代码实现 3.2 源代码文件 4 功能测试 4.1 检测黑线状态 4.2 未检测黑线状态 概述 本文主要介绍TCRT5000模块的使用原理,包括该模块的硬件实现方式,电路实现原理,还使用STM32类

TL-Tomcat中长连接的底层源码原理实现

长连接:浏览器告诉tomcat不要将请求关掉。  如果不是长连接,tomcat响应后会告诉浏览器把这个连接关掉。    tomcat中有一个缓冲区  如果发送大批量数据后 又不处理  那么会堆积缓冲区 后面的请求会越来越慢。

PHP原理之内存管理中难懂的几个点

PHP的内存管理, 分为俩大部分, 第一部分是PHP自身的内存管理, 这部分主要的内容就是引用计数, 写时复制, 等等面向应用的层面的管理. 而第二部分就是今天我要介绍的, zend_alloc中描写的关于PHP自身的内存管理, 包括它是如何管理可用内存, 如何分配内存等. 另外, 为什么要写这个呢, 因为之前并没有任何资料来介绍PHP内存管理中使用的策略, 数据结构, 或者算法. 而在我们