用Golang写一个搜索引擎(0x06)--- 索引构建

不知不觉写到第六篇了,按这个节奏,估计得写到15到20篇左右才能写完,希望自己能坚持下去,之前写代码的时候很多东西并没有想得那么细致,现在每写一篇文章还要查一些资料,确保文章的准确性,也相当于自己复习了一下吧,呵呵。

先说一下,关于倒排文件,其实还有很多东西没有讲,到后面再统一补充一下吧,主要是倒排文件的压缩技术,这一部分因为目前的存储空间不管是硬盘还是内存都是很大的,所以压缩技术用得不是很多了。

今天我们来讲讲倒排索引的构建。

之前,我们了解到了,倒排索引在系统中是存成下图这个样子

bt6.png

上面的B+树是一个文件,下面的倒排链是一个文件,那么,如何来构建这两个文件呢,本章我会说说一般的常规构建方法,然后说一下我是怎么构建的。

一般情况下,搜索引擎默认会认为索引是不会有太大的变化的,所以把索引分为全量索引和增量索引两部分,全量索引一般是以天甚至是周,月为单位构建的,构建完了以后就导入到引擎中进行检索,而增量索引是实时的进入搜索引擎的,很多就是保存在内存中,搜索的时候分别从全量索引和增量索引中检索数据,然后把两部分数据合并起来返回给请求方,所以增量索引不是我们这一篇的主要内容,在最后我的索引构建部分我会说一下我的增量索引构建方式。现在先看看全量索引。

全量索引构建一般有以下两种方式

一次性构建索引

一种是一次性的构建索引,这种构建方法是全量扫描所有文档,然后把所有的索引存储到内存中,直到所有文档扫描完毕,索引在内存中就构建完了,这时再一次性的写入硬盘中。大概步骤如下:

  • 初始化一个空map ,map的key用来保存term,map的value是一个链表,用来保存docid链
  • 设置docid的值为0
  • 读取一个文档内容,将文档编号设置成docid
  • 对文档进行切词操作,得到这个文档的所有term(t1,t2,t3...)
  • 将所有的<term,docid>键值对的term插入到map的key中,docid追加到map的value中
  • docid加1
  • 如果还有文档未读取,返回第三步,否则继续
  • 遍历map中的<key,value>,将value写入倒排文件中,并记录此value在文件中的偏移offset,然后将<key,offset>写入B+树中
  • 索引构建完毕

用图来表示就是下面几个步骤

idx0.png

如果用伪代码来表示的话就是这样

//初始化ivt的map 和 docid编号
var ivt map[string][]int
var docid int = 0
//依次读取文件的每一行数据
for content := range DocumentsFileContents{
  terms := segmenter.Cut(content) // 切词
  for _,term := range terms{
    if _,ok:=ivt[term];!ok{
       ivt[term]=[]int{docid}
    }else{
       ivt[term]=append(ivt[term],docid)
    }
    docid++
}

//初始化一棵B+树,字典
bt:=InitBTree("./index.dic")
//初始化一个倒排文件
ivtFile := InitFile("./index.ivt")
//依次遍历字典
for k,v := range ivt{
  //将value追加到倒排文件中,并得到文件偏移[写文件]
  offset := ivtFile.Append(v)
  //将term和文件偏移写入到B+树中[写文件]
  bt.Add(term,offset)
}

ivtFile.Close()
bt.Close()
  
}

如此一来,倒排文件就构建好了,这里我直接使用了map这样的描述,只是为了让大家更加直观的了解到一个倒排文件的构建,在实际中可能不是用这种数据结构。

分批构建,依次合并

一次性构建的方式,由于是把所以文档都加载到内存,如果机器的内存空间不够大的话,会导致构建失败,所以一般情况下不采用那种形式,很多索引构建的方式都用这种分批构建,依次合并的方式,这种方式主要按以下方式进行

  • 申请一块固定大小的内存空间,用来存放字典数据文档数据

  • 在固定内存中初始化一个可排序的字典(可以是树,也可以是跳跃表,也可以是链表,能排序就行)

  • 设置docid的值为0

  • 读取一个文档内容,将文档编号设置成docid
  • 对文档进行切词操作,得到这个文档的所有term(t1,t2,t3...)
  • 将term按顺序插入到字典中,并且在内存中生成多个个<term,docid>的键值对<t1,docid>,<t2,docid>,并且将这些键值对存入到内存的文档数据中,同时保证键值对按照term进行排序
  • docid加1
  • 如果内存空间用完了,将文档数据写入到磁盘上,清空内存中的文档数据
  • 如果还有文档未读取,返回第三步,否则继续
  • 由于各个磁盘文件中的键值对是按照term的顺序排列的,通过多路归并算法将各个磁盘文件进行合并操作,合并的过程中生成每一个term的倒排链,追加的写一次倒排文件,并配合词典生成这个term的文件偏移,直到所有文件合并完成,词典也跟着构建完成了。
  • 索引构建完毕

同样,我们用一个图来表示就是下面这个样子

idx1.png

如果用伪代码表示的话,就是下面这个样子,代码流程也很简单,结合上面的步骤和图仔细看看就能明白

//初始化固定的内存空间,存放字典和数据
dic := new DicMemory()
data := new DataMemory()
var docid int = 0
//依次读取文件的每一行数据
for content := range DocumentsFileContents{
  terms := segmenter.Cut(content) // 切词
  for _,term := range terms{
    //插入字典中
    dic.Add(term)
    //插入到数据文件中
    data.Add(term,docid)
    //如果data满了,写入磁盘并清空内存
    if data.IsFull() {
        data.WriteToDisk()
        data.Empty()
    }
    docid++
}


//初始化一个文件描述符数组
idxFiles := make([]*Fd,0)

//依次读取每一个磁盘文件
for idxFile := range ReadFromDisk {
    //获取每一个磁盘文件的文件描述符,存到一个数组中
    idxFiles.Append(idxFile)
}

//配合词典进行多路归并,并将结果写入到一个新文件中
ivtFile:=InitFile("./index.ivt")
dic.SetFilename("./index.dic")
//多路归并
KWayMerge(idxFiles,ivtFile,dic)

//构建完成
ivtFile.Close()
dic.Close()
  
}

上面就是两种构建全量索引的方法,对于第二种方法,还有一种特殊情况,就是当内存中的词典也很巨大,将内存撑爆了怎么办,这是可以将词典也分步的写到磁盘,然后在进行词典的合并,这里就不说了,感兴趣的可以自己去查一查。

我上面说的这些和一些搜索引擎的书可能说的不太一样,但是基本思想应该差不多,为了让大家更直观的抓到本质,很多特殊一点的情况我并没有详细说明,毕竟这不是一篇纯理论的文章,如果大家真的感兴趣肯定可以找到很多办法来更深入的了解搜索引擎的。

关于上面提到的多路归并,是一个标准的外排序的方法,到处都能找到资料,这里就不详细展开了。

另外,在索引的构建过程中还有一些细节的东西,比如一般的索引构建都是两次扫描文档,第一次用来生成一些统计信息,也就是上一篇说的词的信息,比如TF,DF之类的,第二次扫描才开始真正的构建,这样的话,可以把term的相关性的计算放到构建索引的时候来进行,那么在检索的时候只需要进行排序而不用计算相关性了,可以极大提高检索的效率。

我的构建方法

最后,我来说说我是怎么构建索引的,由于我写的这个搜索引擎,是没有明确的区分全量和增量索引概念的,把这个决定权交到了上层的引擎层来决定,所以在底层构建索引的时候不存在全量增量的概念,所以采用了第一种和第二种方法结合的方式进行索引的构建。

  • 首先设定一个阈值,比如10000篇文档,在这10000篇文档的范围内,按照第一种方式构建索引,生成一个字典文件和一个倒排文件,这一组文件叫做一个段(segment)
  • 每10000篇文档生成一个段(segment),直到所有文档构建完成,从而生成了多个段,并且在搜索引擎启动以后,增量数据也按这个方法进行构建,所以段会越来越多
  • 每一个段就是索引的一部分,他有倒排索引的全部东西(词典,倒排表),可以进行一次正常的检索操作,每次检索的时候依次搜索各个段,然后把结果合并起来就是最终结果了
  • 如果段的数量过多,按照第二种方式的思想,对多个段的词典和倒排文件进行多路合并操作,由于词典是有序的,所以可以按照term的顺序进行归并操作,每次归并的时候把倒排全拉出来,然后生成一个新的词典和新的倒排文件,当合并完了以后把老的都删掉。

上面的合并操作策略完全交给上层的引擎层甚至业务层来完成,有些场景下增量索引少,那么第一次构建完索引以后就可以把各个段合并到一起,增量索引每隔一定的时间合并一次,有些场景下数据一直不停的进入系统中,那么可以通过一些策略,不停的在系统空闲时合并一部分索引,来保证检索的效率。

OK,上面就是索引构建的方法,到这一篇完成,倒排索引的数据结构,构建方式都说完了,但是还是有很多零碎的东西没有说,后面会统一的把一些没提及到的地方整理一篇文章说一下,接下来,我会用一到两篇的文章说一下正排索引,然后就可以跨到检索层去了。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 203,456评论 5 477
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,370评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 150,337评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,583评论 1 273
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,596评论 5 365
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,572评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,936评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,595评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,850评论 1 297
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,601评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,685评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,371评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,951评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,934评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,167评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 43,636评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,411评论 2 342

推荐阅读更多精彩内容