共计 3934 个字符,预计需要花费 10 分钟才能阅读完成。
作者:京东物流 李洪吉
提到 ES,大多数爱好者想到的都是搜索引擎,然而明确一点,ES 不等同于搜索引擎。不论是谷歌、百度、必应、搜狗为代表的自然语言解决(NLP)、爬虫、网页解决、大数据处理的全文搜索引擎,还是有明确搜寻目标的搜寻行为,如各大电商网站、OA、站内搜索、视频网站的垂直搜索引擎,他们或多或少都应用到了 ES。
作为搜索引擎的一部分,ES 天然具备速度快、后果精确、后果丰盛等特点,那么 ES 是如何达到“搜索引擎”级别的查问效率呢?首先是索引,其次是压缩算法,接下来咱们就一起理解下 ES 的索引构造和压缩算法
1 构造
1.1 Mysql
Mysql 下的 data 目录寄存的文件就是 mysql 相干数据,mysql 文件夹对应的就是数据库 mysql。
其中表 columns\_priv 对应了 3 个文件:columns\_priv.frm、columns\_priv.MYD、columns\_priv.MYI。
.frm:表构造;.MYD:myisam 存储引擎原数据;.MYI:myisam 存储引擎索引;.ibd:innodb 存储引擎数据
1.2 Elasticsearch
cfe 为索引文,cfs 为数据文件,cfe 文件保留 Lucene 各文件在.cfs 文件的地位信息
cfs、cfe 在 segment 还很小的时候,将 segment 的所有文件都存在在 cfs 中,在 cfs 逐步变大时,大小超过 shard 的 10%,则会拆分为其余文件,如 tim、dvd、fdt 等文件
1.3 存储构造
倒排索引构造分为倒排表、词项字典、词项索引
倒排表蕴含某个词项的所有 id 的数据存储了在.doc 文件中
词项字典蕴含了 index field 的所有通过解决之后的词项数据,最终存储在.tim 文件中
1.4 构造比照
咱们以某商城的手机为例,左侧为 es 倒排索引构造,右侧为原始数据。左侧图示只是为了展现倒排索引构造,并不是说 es 中倒排表就是简略的数组
以下面构造比照示例图为例,如果共有 10 亿条数据须要存储在 ES 中 (上图右),分词后存储的倒排表(上图左) 大略蕴含分词 term 以及对应的 id 数组等,在 10 亿条数据中,分词“小米”相干的数据有 100 万条,也就是说分词“小米”对应的数组 Posting List 长度是 100 万
id 是 int 类型的有序主键,分词“小米”在数组 Posting List 中 100 万 int 类型数字总长度 =100 万✖每个 int 占 4 字节 =400 万 Byte≈4MB。1 个分词占 4MB 空间, 如果 10 亿条数据有 500 万个分词,总空间 =4MB✖500 万 = 2 千万 MB,磁盘空间间接爆炸
2 算法
分词对应的数组 Posting List 理论就是一个个有序数组,而有序数值数组是比拟容易进行压缩解决的,而且一般来说压缩效益也不错,如果能对其进行压缩是可能大大节约空间资源的
ES 中倒排索引的压缩算法次要有 FOR 算法 (Frame Of Reference) 和 RBM 算法(RoaringBitMap)
2.1 FOR
FOR 算法的核心思想是用减法来削减数值大小,从而达到升高空间存储。假如 V(n)示意数组中第 n 个字段的值,那么通过 FOR 算法压缩的数值 V(n)=V(n)-V(n-1)。也就是说存储的是后一位减去前一位的差值。存储是也不再依照 int 来计算了,而是看这个数组的最大值须要占用多少 bit 来计算
咱们依照差值计算的形式来保留数据,初始值为 1,2 与 1 的差值为 1,3 与 2 的差值为 1……最终咱们就将原始 Posting List 数据转化为 100 万个 1,每个 1 咱们能够用 1bit 来记录,总空间 =1bit✖100 万 =100 万 bit,相比原有 400 万 Byte=3200bit,空间压缩了 32 倍
在理论生产中,不可能呈现一个 term 的 Posting List 是这种差值均为 1 的状况,所以咱们以通用示例举例。如果原数据为[73,300,302,332,343,372], 数组中 6 个数字占据总空间为 24 字节。依照差值形式记录,数组转化为[73,227,2,30,11,29], 最大数字为 227,大于 2 的 7 次方 128,小于 2 的 8 次方 256,所以每个数字能够应用 8bit 即 1Byte 来保留,占据总空间为 1Byte*6 + 1Byte=7Byte
在此基础上,咱们将差值数组依照密集度划分为 [73,227] 和[2,30,11,29],其中 [73,227] 中最大值 227 介于 2 的 7 次方和 2 的 8 次方之间,所以用 8bit=1Byte 作为切割分段,[2,30,11,29]中最大数 30 介于 2 的 4 次方和 2 的 5 次方之间,所以用 5bit 作为切割分段。
数组 [73,227] 占据总空间为 8bit✖2 个 =16bit=2Byte
数组 [2,30,11,29] 占据总空间为 5bit✖4 个 =20bit=3Byte
为什么 20bit=3Byte 呢?因为 8bit=1Byte,小于 8bit 也会占据 1 个字节空间,所以 17bit 到 24bit 均为 3Byte
所以,最终占据总空间 =1+2+1+3=7Byte
疑难一:既然原数组 [73,300,302,332,343,372] 要依照密集度拆分为 [73,227] 和[2,30,11,29]两个数组,那为什么不持续往下拆分,间接拆分到每个数字是一个数组,这样应用 bit 记录时占据总空间会更少?
答:如果持续拆分数组,空间的确会应用更少,然而,之前咱们提到搜索引擎速度快的形式有两种:高效的压缩算法和疾速的编码解码速度,单个数字存储的确压缩了空间,然而咱们无奈再通过解码的形式将源数据还原
疑难二:为什么源数据应用差值记录占据 6Byte,拆分数组后占据 7Byte,拆分后占据空间不变,有时候甚至会变大,为什么?
答:数据量小的状况下的确会呈现该状况,因为咱们须要拆分数组并记录拆分数组的长度(如下面示例中的 8bit 和 5bit),在原数据存储空间根底上还要存储拆分长度,所以数据量小的状况下会呈现比间接存储占据空间大的状况。然而不论是搜索引擎还是 Elasticsearch 更多解决的是海量数据,数据量越多,差值数组拆分的形式节俭空间越显著
2.2 RBM
咱们曾经理解了 FOR 压缩算法,算法外围是将 PostingList 依照差值密集度转化成两个差值数组。在这里咱们要思考一种状况就是:在大数据中,10 亿条数据分词 500 万个,如果分词“小米”所在 PostList 比拟扩散且差值很大,此时应用 FOR 算法成果就会大打折扣。所以稠密的数组,不适宜应用 FOR 算法
在这里咱们以 [1000,62101,131385,132052,191173,196658] 为例,如果依照 FOR 算法,转化成的差值数组为 [1000,61101,69284,667,59121,5485] 密集度很低。咱们采纳 RBM 算法
源数据 PostingList 是由 int 类型组成的数组,int 类型 =4Byte=32bit,最大值 = 2 的 32 次方 -1=4294967295≈43 亿。当数据较大且稠密时,咱们将 32bit 拆分为 16bit 和 16bit,16bit 最大值 =65535,前 16bit 寄存 商,后 16bit 寄存 余数,所以商和余数都不会超过 65535. 咱们将源数组的值除以 65536,失去的商和余数别离寄存在前 16bit 和后 16bit。
以数字 196658 为例,转化为 2 进制,前 16 位 =3,后 16 位 =50
失去的后果以 K - V 寄存。Key 最大值为 16bit,所以以 short[]数组寄存,Value 以 Container 寄存。
因为源数组为有序数组,所以依照高下 16 位转化后,商和余数都是从小到大排列
通过看 Container 源码,咱们能够看到 Container 有 3 种:ArrayContainer、BitmapContainer、RunContainer。
- ArrayContainer 实质为汇合,所以随着数组中数量越多,占用空间越多,呈正向增长。
当数组种数量为 4096 时,占据总空间 =4096 个✖16bit(即 2Byte)➗1024=8KB
当数组种数量为 65536 时,占据总空间 =65536 个✖16bit(即 2Byte)➗1024=128KB
- BitmapContainer 位图,外围就是将原有存储数值转化成该数值在哪个地位上存在
因为余数最大值为 65535,所以咱们须要 65536 位位图,数值是多少,在位图上对应的地位就是多少。数值等于 4096,则位图上 4096 位值为 1;数值等于 65535,则位图上 65535 位值为 1。每个地位上的数都占用 8KB 空间(8KB=65536bit)
- RunContainer 用法绝对狭窄,这种类型是 Lucene 5 之后新增的类型,次要利用在间断数字的存储商,比方倒排表中存储的数组为 [1,2,3…100W] 这样的间断数组,如果应用 RunContainer,只需存储结尾和结尾两个数字:1 和 100W,即占用 8 个字节。这种存储形式的优缺点都很显著,它重大收到数字连续性的影响,间断的数字越多,它存储的效率就越高
- 如果数组是如下模式 [1,2,3,4,5,100,101,102,999,1000,1001] 就会被拆分为三段:[1,5],[100,102],[999,1001]
至于每次存储采纳什么容器,须要进行一下断定,比方 ArrayContainer,当存储的元素少于 4096 个时,他会比 BitmapContainer 占用更少空间,而当大于 4096 个元素时,采纳 ArrayContainer 所须要的空间就会大于 8kb,那么采纳 BitmapContainer 就会占用更少空间
3 总结
ES 在解决海量数据时通过其独到的构造和压缩算法,将索引效率尽可能的晋升。尽管在理论业务解决中咱们极少遇到海量数据处理的状况,然而通过理解 ES 的原理,可能帮咱们宽阔下视线,理解数字之美,算法之美。