这就是搜索引擎读书笔记-day2-4.索引压缩

简介: 词典压缩技术、倒排列表压缩算法、文档ID重排序技术(无损压缩算法)、静态索引裁剪(有损压缩算法)

1.词典压缩

-词典会加载到内存中,压缩目的是为了较小占用内存

image.png

前面介绍了词典组织方式:hash表+链表 / B树字典,上图为b树字典


问题:文档频率信息和倒排指针各使用4个字节标识,但是单词可长可短,不能用固定单词长度来保持(造成空间浪费)

优化思路:

将单词存储部分调整为 连续存储+单词头部地址 就行

image.png

进一步优化:单词字典块切分+连续存储+块头部地址

image.png

这样可以在原有基础上节省一些单词地址的空间占用


2.倒排列表压缩算法

-倒排列表记录:文档编号、词频、单词位置序列信息。文档编号和单词位置序列是依次递增,所以会存储差值而非原值。这也是压缩算法的处理对象


2.1 评价索引压缩算法的指标

-压缩率、压缩速度、解压速度


2.2 一元编码(Unary Cide)与二进制编码(Binary Code)

-不论压缩算法逻辑思路是怎样的,最终都以这两种格式对数据进行表示。

  • 一元编码

对于正式X,采用X-1哥二进制数字1和末尾一个数字0来表示,这对于大的证书编码表示明显很不经济

image.png

  • 二进制编码方式

不同的比特宽度代表不同的数据表示范围

image.png


2.3 倒排列表算法—Elias Gamma算法与 Elias Delta算法

  • Elias Gamma算法

image.png

  1. 被压缩数字x由上述分解函数拆解为:e、d 两个分解因子
  2. 一元编码表示e+1
  3. 二进制编码表示d

et. x = 9 : e=3 and d = 1 因此编码结果:1110:001(比特宽度为3的二进制编码)


  • Elia Delta算法
  1. x利用Elias Gamma算法拆解为e和d
  2. e+1利用Elias Gamma算法拆解为e和d

最终结果由三个因子组成了:e:d1:d2


2.4 Golomb算法与Rice算法

-思路与上述算法类似,区别在于需要编码的因子不一样了:

image.png

  • 一元编码:因子1+1
  • 二进制编码:因子2(因为因子2在[0,b-1],比特宽度上限可以设置为log(b))


二者区别:常数b的计算逻辑不一样,

golomb算法 : b = 0.69*AVG (AVG:带压缩数据序列的平均值, 0.69是经验参数)

rice算法:b = 2^n 且 b

参数b计算适用范围:局部(不同单词对应倒排列表采用不同的值)、全局(所有单词对应倒排列表都采用同一值)

image.png


2.5 变长字节算法(Variable Byte)

-以字节为基本存储单位,字节与字节间通过最高位(0)标识是否为标识数字的最后一个字节

image.png

image.png

2.6 SimpleX系列算法

-利用32个比特位作为一个压缩单位,划分两部分:4个比特管理数据存储区(知识哦后续数据存储区类型),28个比特存储压缩数据存储区,压缩数据存储区使用情况划分为若干种布局类型。

image.png

解释:b为2 说明数据存储区基本构成单元比特宽度为2,分为14个存储单元,每个存储单元存数: 0-3。以此类推

压缩思路:

  1. 读取压缩数据队列后续的28个数字,若发现28个数字都是0或1,可利用B=1布局进行存储
  2. 若发现有大于1的 就读取后续14个 判定是否为 0、1、2、3 ...
  3. 同上

解压缩思路:

  1. 一次性读取4字节,根据前四个比特位判定后续数据存储区的布局方式
  2. 按照这种方式利用掩码获取对应数字



2.7 PForDelta 算法

-将待编码的连续k个数值中,找出10%大数剔除,剩下90%按照等长比特宽度压缩存储

思路:

1.找到异常大数,剔除,单独存储(倒叙存储)

2.原异常大数所在位置串成链表,下图总第一个异常大数中的3代表当前大数往后隔3个数得到第二个异常大数

3.剩下的带压缩数据块确定压缩采取的比特宽度(最大值)

4.所有数值快速压缩

image.png

3.文档编号重排序(DocID Reordering)

-重排编排文档编号。使得某单词倒排列表中相邻两个文档的文档编号尽可能相近。

思路:

1.爬取网页,赋予随机文档编号

2.文本聚类

3.文档重排序,相同类型文档赋予接近文档编号

image.png

重排序结果:

image.png

另外对于海量文案数据聚类速度难以满足实际需求的情况,可以采用启发规则改善,李二:将页面URL相似的网页聚合在一起



4.静态索引裁剪(Static Index Pruing)

-对计算网页和用户查询最终相关性得分贡献不同,保留重要索引项,剔除不重要索引,并尽可能保证搜索质量。

4.1 以单词为中心的索引裁剪

-利用相似计算函数计算 单词-文档相关性,并依据相关性阈值淘汰部分索引项

image.png

思路:

  1. 根据相关性函数计算每个倒排列表项中 单词与文档 相关性
  2. 每个单词设置至少保留k个索引项
  3. 小于k个都保留,多于k个。保留k个分数高的索引项
  4. 设置一些富裕项目,既阈值乘上一个折扣因子a

image.png




4.2 以文档未中心的索引裁剪

-构建索引过程中进行裁剪,判断文档包含单词的重要性,经过评分计算,保留重要单词。

思路:

  1. 文档缩水(剔除相关性低的单词)
  2. 再构筑索引

image.png

缺点:

某些极端情况的停用词(的)会被裁减掉。导致索引项为空。




相关文章
|
7月前
|
搜索推荐 算法 数据库
正排索引 vs 倒排索引 - 搜索引擎具体原理
正排索引 vs 倒排索引 - 搜索引擎具体原理
180 4
|
7月前
|
关系型数据库 MySQL
Mysql基础第二十一天,全文本搜索
Mysql基础第二十一天,全文本搜索
53 0
|
搜索推荐 中间件 Linux
一个基于EntityFrameworkCore+Lucene实现的全文搜索引擎库
这是一个仅70KB的、轻量级的全文检索搜索引擎、基于Lucene实现的。
160 0
一个基于EntityFrameworkCore+Lucene实现的全文搜索引擎库
|
运维 搜索推荐 数据可视化
几百行代码完成百度搜索引擎,真的可以吗?(下)
Hello 大家好,我是鸭血粉丝,大家都叫我阿粉,搜索引擎想必大家一定不会默认,我们项目中经常使用的 ElasticSearch 就是一种搜索引擎,在我们的日志系统中必不可少,ELK 作为一个整体,基本上是运维标配了,另外目前的搜索引擎底层都是基于 Lucene 来实现的。
几百行代码完成百度搜索引擎,真的可以吗?(下)
|
运维 搜索推荐 数据可视化
几百行代码完成百度搜索引擎,真的可以吗?(上)
Hello 大家好,我是鸭血粉丝,大家都叫我阿粉,搜索引擎想必大家一定不会默认,我们项目中经常使用的 ElasticSearch 就是一种搜索引擎,在我们的日志系统中必不可少,ELK 作为一个整体,基本上是运维标配了,另外目前的搜索引擎底层都是基于 Lucene 来实现的。
几百行代码完成百度搜索引擎,真的可以吗?(上)
|
存储 缓存 安全
【图文结合】全网最全的MySQL索引讲解,万字长文由浅入深带你认识索引
【图文结合】全网最全的MySQL索引讲解,万字长文由浅入深带你认识索引
255 0
【图文结合】全网最全的MySQL索引讲解,万字长文由浅入深带你认识索引
|
机器学习/深度学习 搜索推荐 数据处理
这就是搜索引擎读书笔记-day3-5.检索模型与搜索排序
搜索结果排序融合了上百种排序因子,而重要两因素是:用户查询和网页内容相关性 及 网页链接情况。本节介绍内容相关性介绍网页排序
这就是搜索引擎读书笔记-day3-5.检索模型与搜索排序
|
存储 自然语言处理 搜索推荐
|
存储 自然语言处理 运维
搜索lucene概念扫盲
假期重新把之前在新浪博客里面的文字梳理了下,搬到这里。本篇回归基础,从概念介绍起。
141 0
|
自然语言处理 搜索推荐 算法
深入搜索引擎原理
之前几段工作经历都与搜索有关,现在也有业务在用搜索,对搜索引擎做一个原理性的分享,包括搜索的一系列核心数据结构和算法,尽量覆盖搜索引擎的核心原理,但不涉及数据挖掘、NLP等。文章有点长,多多指点~~ # 一、搜索引擎引题 ## 搜索引擎是什么? 这里有个概念需要提一下。
7884 1