搜索引擎(大数据检索)论述[elasticsearch原理相关]

这篇具有很好参考价值的文章主要介绍了搜索引擎(大数据检索)论述[elasticsearch原理相关]。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

首先需要大致知道搜索引擎有大致几类:1.全文搜索引擎 2.垂直搜索引擎 3.类目搜索引擎等。

1.全文搜索引擎:是全文本覆盖的,百度,google等都是全文本搜索,就是我搜一个词项“方圆”,那么这个词项可以是数字平方的概念,可以是一个人名,可以是一首歌等,所有的相关分类的概念都会被检索到。检索范围是全覆盖的,也就是中间涉及到语义的概念。

2.垂直检索引擎:就是检索一个词项,在一个语义范围内检索,检索范围在一个语义内的。

3.类目检索引擎:一般就是我们所见到互联网公司建设的搜索引擎,比如电商,一个词项检索就是检索自己所有的商品类目,或者汽车之家,就是检索所有的汽车类目。

建设搜索引擎,肯定在数据量上都是海量数据,而且要求数据检索返回速率很快,一般都是秒级返回(通常衡量检索引擎的指标有1.准确率 BM25/TF-IDF 2.召回率)。我们都知道一个数据库的表要是表中的数据几十亿条数据,我们select where 条件具有索引,时间也远不止一秒。所以检索引擎不是单单索引的建立那么简单。而且检索引擎的概念是select *  like;是模糊匹配,不是固定匹配,所以检索更是范围巨大,远不是数据库索引检索那么简单。

搜索引擎在原理上很关键的几点,想到大家也会想到,1.数据结构的设计 2.索引结构的设计 3.数据存储方面的数据压缩机制(压缩之后检索更加高效)。首先我们先了解传统上数据的索引的数据结构B-Tree和B+tree.

搜索引擎(大数据检索)论述[elasticsearch原理相关]

这是B树,但是需要普及一个知识点,不然大家不知道树存储到磁盘,在读取的时候涉及到的IO次数。我们磁盘最小的单元是一个扇区(512B),操作系统最小的读取单位是一簇4KB(8个扇区),那么我们在设置每一个树的节点也最小是4KB(在mysql中数据文件存储是16KB为一页,数据叶是最小存储单位)。那么B树每一个节点也要存储数据,如果数据部分很大,那么每一个节点上存储的分支个数就少了,那么树的深度自然要加大,那么在便利数据的时候,就需要遍历到一定深度的树才会检索到数据。每一次检索一个节点就是要读一个全新的数据叶,就是一次的IO磁盘读;那么这样检索上就需要很多次IO,效率很有限,因此引入了B+树:

搜索引擎(大数据检索)论述[elasticsearch原理相关]

B+树呢,每一个节点不存储数据,数据都存储在叶子节点上,而且叶子节点是一个双向的链表进行每一个叶子块链接。这样每一个节点数据块上可以存储的节点 分支就会多达几十,那么树的深度实现大幅度的缩小,遍历起来也非常快。

对于检索引擎,一方面我们肯定把所有的资源信息完整存储,然后根据资源提取所有的“词项”信息,然后搜索引擎会把所有的出现的词项进行存储,词项数据多达千亿级别,词项提出越多,搜索引擎检索准确率也就越高。

搜索引擎(大数据检索)论述[elasticsearch原理相关]

 这是基本的词项存储列表,词项在存储的时候,是根据id进行k-v Map形式存储,而且存储也是分布式的,根据id hash计算处对应存储的key,然后知道对应存储的卡槽和卡槽所在的计算机节点(redis和kafka的类似思维的结合)。然后呢,搜索引擎还根据词项字典建立了对应的词项字典索引,加快map块的遍历。上述的词项属性中有一个词项的资源列表的概念,这里是一个倒序排列的出现该词项的所有的资源id的列表(int 列表),为了能很好检索出来词项对应的资源,对应的资源列表信息肯定需要存储的,这是必不可少的存储的数据单元。普通来说资源数据量在千亿级以上,那么出现该词项的条件假如有100万条,那么100万 int列表就是400万B=4MB.千亿级资源至少也有其百倍的词项,就是100*千亿=10w亿,那仅仅词项的倒排资源列表就是巨大的,甚至达到不可有效存储的概念。所以搜索引擎中的压缩算法是必不可少的,根据压缩后的逻辑遍历数据,从而使得检索更快。搜索引擎通常使用的压缩算法有FOR(Frame of Reference),Boaring BitMap算法,至少elasticSearch(lucence引擎)使用该压缩算法。

1.FOR(Frame of Reference)算法,很简单就是对数据列表取差值,存储初始值和所有的差值即可。比如 一列数据,10000,10001,10002,10003...... 1000101;取完差值(第一个值保留原值)列表就是10000,1,1,1,1,1......;我们使用几个bit存储所有的差值即可(这里差值是1),之前存储所有的数据是靠整型存储,现在依靠bit存储差值。实现很好的压缩,对于该类压缩还经常使用到文本信息压缩,尤其全英文的或者全中文文字压缩,因为存储的都是ASCII码,范围在一个区间内(比较紧凑),那记录差值很简单。FOR压缩很紧凑的数据效率很好。

2.Boaring BitMap算法(位图算法),对于非紧凑的数据序列使用FOR压缩就不行了,如1,30,200,400,750,900,1030,... 差值和原值没有大幅度缩小,所以使用BM算法。一个bit列 1000100001...每一个位就是一个bit,每一个位对应的位置号就是1,2,3,4,5,6....;那么在对应的位置上的bit要是1就代表有该序号的数值存在。.........00101010..... 假如这是一列数前面有10000bit位省略了,那么第一个位置代表一万零一,这一串bit代表就是存储了1万零三,1万零五,1万零七三个数据,所以可以见的一串bit的位置是记录的数据大小,所以存储的数据列一定是不可以重复的,不重复的数据这样记录存储可以极大的压缩,要是资源id在几万几十万区间内或者上亿区间内,那么这样就是1百bit存储一百个大小一亿以上的数据(大小:4B*100)数据,同时我们记录设置初始位置记为1亿(就是bit列第一位置就是1亿)100bit=12.5B存储了400B,实现了几百倍上千倍的压缩。

对于关键词(Term)字典结构的存储,采用复用的思想;就是关键词都是由多个字符组成的,(中文是双字节的字符)那么在整个字典结构保存的时候,采用保存一个个的字符,字符之间通过有向的索引来进行串联起来。这就是前缀树结构,Trie-树结构(如下图所示,数字标记的圆就是一个字符节点)。

搜索引擎(大数据检索)论述[elasticsearch原理相关]

那为什么采用这个复用的思想呢?直接通过散列映射k-v,hashMap结构把所有的关键词都存储起来,遍历也十分迅速,为什么采用这种复用的结构呢?一般搜索服务里面包含几十亿上百亿的资源,然后后台的服务会将这些资源文件中的文本进行解析,提取其中的关键词(或者关键句),一般一个资源文件中包含的关键词有几十到几百,考虑到关键词的重复,那么所有资源包含的关键词 也有百亿甚至更大的数量级别。那么将这些关键词(关键句)存储起来将是非常大的空间,大致计算下,加入平均每一个关键词是8个字符,那么百亿关键词就是100GB的大小的字典结构(这还是很保守的估算)。如果通过字符共用+有向拼接的思想,实现这个结构千倍、万倍的压缩,那么直接可以将这个字典结构放在内存中,那么就不需要每次检索去IO文件,性能表现也完全不一样。

为了实现前缀复用树(字典)结构能根据有向链接输出想要查询的Term(关键词),需要标记具体节点的状态,例如是不是某一个要查询的Term最后一个字符,某一个节点有几个输出的子节点、子结点个数、是否是最后的子节点(子节点的个数记为某一个节点的出度,有些文章把输出子节点直接叫成出度,这纯属概念混淆)等。既然节点有状态,且通过有向链接,那么就是有限状态机的概念(Finit state Machine  FSM)。如下图:

搜索引擎(大数据检索)论述[elasticsearch原理相关]

由此可见有限有序状态机其实是一个图结构,只是每一个节点有标记状态的数据。那么存储Term(关键词)字典结构肯定也是一个有向图结构,而且还是节点状态标记的图结构。只是每一次节点存储的是字符和节点状态等信息,而且Term存储结构还加入了起始点和终止节点,目的就是在遍历的时候单向有限,而且要求尽量去复用节点,这就是FSA(Finit state Accepter 有限状态接收器)的概念。如下图:

搜索引擎(大数据检索)论述[elasticsearch原理相关]

上图中0是起始节点,7是终止节点 ;而且在有向路线上尽量复用节点。那么如何实现复用呢?这是最为核心的算法,也是关键词存储和检索的核心算法。很多博客上或者视频讲解中只是提到FSA具备线路输出值(或者权重)特征,有点类似哈夫曼树(也叫霍夫曼),尽量使得所有线路的权重值求和结果最小,而且一般要求FSA中相同的始末节点线路输出值是一致的(heap和area中a->e的线路输出值一致)。那么在所有字典节点确认好了之后,来检查线路输出值,相同的要进行合并,这样就容易达到公用线路的算法。如下图:

搜索引擎(大数据检索)论述[elasticsearch原理相关]

线路遍历之后,合并线路:

搜索引擎(大数据检索)论述[elasticsearch原理相关]

在FSA的建立之后,我们还需要对term存储的字典结构中存储每一个term的value,term字符串就是key,还需要像hashmap那样存储对应的value.所以我们又创造了每一个term结束字符节点的时候输出一个value,记为outputValue.这就是FST finit state transsioner.对于一系列的term,需要构造FST结构存储,事先就确定了每一个term的value,构建FST数据结构的一系列算法的集合 叫做FST构造器。构造器的构造过程如下:

搜索引擎(大数据检索)论述[elasticsearch原理相关]

所有的关键词term字符节点都被放置在一个叫做frontier的列表里面,去构建FST的时候,首先创造uncomplied[] 存储即将构建的term的字符,然后创建一个初始节点entry,然后 依次从uncomplied[](也叫做current[])中获取每一个term的起始节点,然后按照每一个term将其他的节点依次挂进去,并记为pendingEntry。如果一个节点挂载的pendingEntry较多的时候,就会合并在一起形成pendingblock,并将该队列中最后一个entry的线路值作为pendingblock的线路值。如果形成的pendingblock持续增长,长度达到一个条件,就会转换成两个floorblock挂载在该block下面,形成层级结构,每一个floorblock的第一个entry节点的线路值作为floorblock的线路输出值。这样就形成了组织架构,这样也是为了方便将term的字典树结构搭建起来,然后所有的term节点挂载完成之后,然后根据term最后的节点来链接到终止节点,接着根据终止节点来倒着扫描末尾节点的状态和输出线路值。逐个的将floorblock和pendingblock中的entry逐个的确定和隔离开来,形成确定的节点参数信息和线路值。

Arc:描述FST构建的重要类型,其中我们要着重理解的包括label、output、target和flags四个属性,其他属性我这里都已经做了详细的中文注释,这里我们来把刚才说的四个属性重点讲解一下。

label:描述当前输入词项中的一个字符,FST最终存储的是label对应字符的ASCLL的二进制。

output:存储Arc对象的附加值或者叫做输出值,output和finalOutput都属于output。

target:如果当前的祖父不是输入值的最后一个字符,target会存储当前字符的下一个字符在current数组中的flag值在current数组中的index即索引值。

flags:通用最小化算法要求任何对数据的压缩都要可以逆向运算,即数据可编码解码,因此在对于FST进行压缩的时候,flags的作用是以最小的代价标记若干个状态值,这里采用了一种位移算法,以实现其通用最小化的目的。这里label和output都很容易理解,但是target和flags相对难以理解。target的含义我们在FST的写入过程中给大家做详细介绍,但是这flags的含义我们有必要在这里展开来详细的讲解一下。

lastFrozenNode:当节点从frontier[]数组中摘下来的时候,节点和它包含的Arcs信息会被写入到current[]数组中,lastFrozenNode会记录当前被处理的节点的第一个Arc在current数组中的起始坐标,即flag的坐标。如果当前节点是终止节点,因为终止节点没有出度Arc,因此lastFrozenNode会输出-1。当lastFrozenNode的值和当前处理的Arc指向的target node在current数组的起始坐标不相同并且当前处理的Arc的target node不是Stop node(因为没有出度Arc)的时候,也就意味着最终构建的FST对象存储的current[]数组在读取的时候,当前Arc对应的label在数组中的下一个Arc不是当前term的下一个label,就需要记录当前Arc的下一个Arc在current数组中的坐标,此时flag就不会标记BIT_TARGET_NEXT值。

把该末尾节点输出线路值记为一个合理的数值out1,该term对应的数值是value,往前所有的线路输出值总和为value-out1;如果out1值被之前扫描到的term线路已经赋值了,那么:1.如果out1<=value;则其向前线路和为value-out1; 2.如果out1>value;则令out1=value;记temp=out1-value;temp的数值可能需要被其他term向前的其他线路作为补偿值,且该term向前的线路暂不输出值(不输出值标记为0)。这样倒向逐个确定节点的线路输出值,然后最后相同的线路进行扫描合并,确定每一个节点的出度和状态参数信息,从而达到固化的目的。然后再倒序扫描固化的节点,执行freezeTail加固话的节点信息存储到compiled array数组中,依次从数组的最前面开始放置。这样放置完成之后,发现数组最后的位置存储的term字典树的开始位置节点信息,类似一个栈结构;这也是为什么叫做倒排索引的原因

flags在FST结构读取的时候起着关键作用,flags是有几种有限的固定值的。

搜索引擎(大数据检索)论述[elasticsearch原理相关]

flags是这几种状态值的和,1,2,4,8,16,32者六种数值的几种组合,所以我们可以很轻松从flag的数值推断出来是哪几种状态值的累加。根据flag,我们在读取的时候很容易知道该节点在FST中的状态和位置。 

按照网上给的一个例子,图中红框内是term和对应的value数值,也就是k-v列表信息:

搜索引擎(大数据检索)论述[elasticsearch原理相关]

然后图中左边部分是要计算每一个节点的flags,和右边确定的FST节点的拓扑结构信息,可以动手大家画一下,很容易就可以画出来的。下面是输出的最终FST数组结构:

搜索引擎(大数据检索)论述[elasticsearch原理相关]文章来源地址https://www.toymoban.com/news/detail-402964.html

到了这里,关于搜索引擎(大数据检索)论述[elasticsearch原理相关]的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 如何高效检索信息:搜索引擎使用小技巧

    本文首发在我的个人博客:追逐日落,欢迎大家前去参观~ 在当今信息爆炸的时代,搜索引擎已经成为我们获取信息的主要途径之一。 平时我们使用搜索引擎,通常是将输入搜索框后回车,然后开始从上到下翻阅有用的信息。其实搜索引擎提供了多种语法,合理使用这

    2024年03月10日
    浏览(65)
  • 基于Elasticsearch与Hbase组合框架的大数据搜索引擎

    本项目为学校大数据工程实训项目,共开发4周,答辩成绩不错。代码仓库放文章尾,写的不好,代码仅供参考。 对于结构化数据 ,因为它们具有特定的结构,所以我们一般都是可以通过关系型数据库(MySQL,Oracle 等)的二维表(Table)的方式存储和搜索,也可以建立索引。

    2024年02月09日
    浏览(65)
  • Elasticsearch(二)kibana数据检索

    有了数据学习使用kibana调用api检索数据,熟练kibana操作后再进一步使用spring data。 term 用于keyword类型数据 精准查询 ,类似mysql match 用于text类型数据 分词查询 ,倒排索引 首先针对keyword文本类型查询学习,类似于Mysql对字段的查询。 文档内容格式参考 结构化搜索 是指对结构

    2024年02月03日
    浏览(44)
  • Elasticsearch (ES) 搜索引擎: 数据类型、动态映射、多类型(子字段)

    原文链接:https://xiets.blog.csdn.net/article/details/132348634 版权声明:原创文章禁止转载 专栏目录:Elasticsearch 专栏(总目录) ES 映射字段的 数据类型 ,官网文档参考:Field data types。 下面是 ES 常用的一些基本数据类型。 字符串 类型: keyword :类型。 text :文本类型。

    2024年03月23日
    浏览(67)
  • 揭秘阿里自研搜索引擎 Havenask 在线检索服务

    作者:谷深 Havenask 是阿里巴巴智能引擎事业部自研的开源高性能搜索引擎,深度支持了包括淘宝、天猫、菜鸟、高德、饿了么在内几乎整个阿里的搜索业务。本文针对性介绍了 Havenask 的在线服务,它具备高可用、高时效、低成本的优势,帮助企业和开发者量身定做适合业务

    2024年02月02日
    浏览(53)
  • 搜索引擎:常用信息检索方式介绍与倒排索引实现(Python)

    (1)线性扫描 计算机对于文档内容检索有多种可能的方式,如直接从头遍历至尾端,根据我们输入的提取内容。 这类检索方式与我们人类阅读的习惯相同,因此实现简单且很容易被接受。 若问你《三国演义》中是否存在’舌战群儒’这一词语,我们常常会选择浏览全文

    2024年02月08日
    浏览(43)
  • Java操作Elasticsearch进行数据检索

    1.安装依赖 (注意版本要和自己安装的es版本对应)          打开发现部分依赖和我们es版本不一致,是因为springboot指定了版本,我们需要更换为自己对应版本。 1.1、改为自己es对应版本  2.编写配置类 3.配置类添加请求选项 4、测试 4.1、存储数据到es  4.2、检索数据  

    2024年02月16日
    浏览(42)
  • 【搜索引擎】Document indexing and retrieval: 文档索引与检索

    作者:禅与计算机程序设计艺术 搜索引擎作为互联网信息获取的一种重要手段之一,无论是在PC、移动端还是电脑上使用,都可以快速找到想要的信息。而对于文档信息的搜索引擎索引构建,则是一个更加复杂的问题。 文档索引与检索(Document Indexing and Retrieval, DIR)的目标是建

    2024年02月08日
    浏览(44)
  • elasticsearch 百亿级数据检索案例与原理

    版权说明: 本文章版权归本人及博客园共同所有,转载请标明原文出处( elasticsearch 百亿级数据检索案例与原理 - mikevictor - 博客园 ),以下内容为个人理解,仅供参考。 一、前言      数据平台已迭代三个版本,从头开始遇到很多常见的难题,终于有片段时间整理一些已完

    2024年02月14日
    浏览(37)
  • Python实战:在搜索引擎开发中的倒排索引与检索算法

    在信息检索领域,搜索引擎是一个至关重要的工具,它可以帮助用户在大量的数据中找到所需的信息。而倒排索引是搜索引擎的核心技术之一,它能够提高检索的效率。 倒排索引是一种数据结构,它将文档的内容和文档的ID关联起来。在倒排索引中,每个词项都有一个列表,

    2024年04月26日
    浏览(33)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包