sphinx索引文件进一步说明——最好是结合lucene一起看,直觉告诉我二者本质无异

摘自:http://blog.csdn.net/cangyingzhijia/article/details/8592441

Sphinx使用的文件包括 “sph”, “spa”, “spi”, “spd”, “spp”, “spm” ,还有锁文件。其中sph是系统的配置文件。其它则为索引文件。

.Spi 文件:保存WordId及指向此WordId对应的文档信息在spd文件的指针。Spi文件在检索程序启动时完全加载入内存。Spi文件是分块的,块内排序,块之间也排序。分块的目的应该是为了快速检索到WordId,因为Spi中的WordId是变长压缩的,索引需要先在块级别做二分定位,再在快内解压缩查找。——这种做法,lucene里是FST,用trie来进行单词和doc ids文件位置存储!
文件结构,每块中结构,wordId实际存储的是差值
WordId | SpdFilePointer | DocNum | HitNum

.Spd文件:文件结构
DocID | [DocInfo] | HitFilePointer | FieldNum | HitNum

.Spp文件: 文件结构
HitPos

.Spa文件:存储DocInfo的文件,检索程序启动时会把此文件加载如内存,sphinx可以指定DocInfo的存储方式,
① 存储到spd文件中(InLine)
②. 另外单独存储。指定此,就会生成spa文件
文件结构:
DocId | DocInfo

.Spm文件:在DocInfo中,有一种特殊的属性,叫MVA,多值属性。Sphinx对此属性特殊处理,需要存储在spm文件中。检索程序启动时会把此文件加载如内存。此(MVA)属性在DocInfo对应位置存储其在此文件中的字节偏移量。
文件结构:
DocId | Anum,A1,A2,…,An | Bnum,B1,B2,…,Bn | …

由于在第一趟扫描过程中会出现WordID相同的不同Hits(不同文档或者不同位置不同字段),二趟前会根据WordID排序,WordID相同的Hits会连续出现并合并(合并到第一次出现的相同WordID中)

 

下文摘自:http://mysql.taobao.org/monthly/2016/11/05/

sphinx索引文件的简单介绍.

  • 然后我们来看索引的种类以及格式,在sphinx中,每一个索引都包含了下面几个文件:
    • sph文件 保存了索引的头文件,主要是一些索引元信息
      • 实现在WriteHeader/LoadHeader中。
    • spi文件 保存了wordlist,也就是索引文件中最核心的一个文件。
      • 也就是通过spi文件可以迅速的从一个keywords(word)映射到一堆document list。下面就是spi文件的格式(dict=keywords):
byte dummy = 0x01
keyword[] keyword_blocks
keyword is:
	byte keyword_editcode
	byte[] keyword_delta
	if keyword_editcode == 0:
		assert keyword_delta = { 0 }
		return block_end
	zint doclist_offset
	zint num_docs
	zint num_hits
	if num_docs >= DOCLIST_HINT_THRESH:
		byte doclist_sizehint
	if ver >= 31 and num_docs > SKIPLIST_BLOCK:
		zint skiplist_pos
		zint skiplist_len

if min_infix_len > 0:
	tag "infix-entries"
	infix_entry[] infix_hash_entries

checkpoint[] checkpoints
checkpoint is:
	dword keyword_len
	byte[] keyword [ keyword_len ]
	qword dict_offset

if min_infix_len > 0:
	tag "infix-blocks"
	infix_block[] infix_hash_blocks

tag "dict-header"
zint num_checkpoints
zint checkpoints_offset
zint infix_codepoint_bytes
zint infix_blocks_offset
  • 文件生成是在cidxHit中。
  • spa文件 保存了attribute
  • sps文件 单独保存string类型的attribute值
  • spd文件 保存了document list
    • 所有的document id都保存在这个这个文件中,也就是通过spi文件得到document list的信息后,可以迅速在spd文件中定位document list。
  • spe文件 保存了skip list
  • spk文件 保存了 kill list
  • spm文件 保存了MVA 值
  • spp文件 保存了hit list。
    • 保存了一个word在document中的所有出现的位置。也就是给定一个document 和一个keywords,这个文件将会返回所有的匹配位置(在当前的document中).

其中spp/spi/spd/spa/spe文件的生成都在RtIndex_t::SaveDiskDataImpl中实现。

 

转自:http://www.xuebuyuan.com/1160253.html

sphinx的倒排索引采用了紧凑的磁盘存储方式,由于应用环境的特 殊,docid是非连续的,其使用过程中我们对它的速度并不满意,其并发和单次查询时间在倒排列表较大的情况下,无论使用进程模式或是线程模式,都不能满 足要求,为此才产生了修改其所索引结构的想法。   

 sphinx的倒排列表存放于spd文件,docid以增量压缩的方式存储,在源码分析过程中,可以看到为了对查询树进行query_node(查询词) 间的"与"、"或"运算,sphinx采用了多层调用,多路归并的方法来完成,这个过程中,为了找到符合某属性条件的docid,会进行 docid->属性之间的二分查找(查询spa文件的hash索引,该索引在系统启动时创建),当查询节点较多,要求返回结果较大的情况下,二分查 找带来的时间消耗是“巨大”的。

  spa文件粗略来说是docid+属性,docid采用递增方式存储,ATTR_NUM0(docid+属性) + ATTR_NUM1(...)  + ....,我们注意到spd中每个词的docid倒排列表,也是使用增量方式存储的,二者存在着共性,因此产生了以ATTR_NUMx来替代docid的 思路,由于spa文件的每个docid属性节点大小固定,因此在系统启动时被加载到固定大小的数组中。在查询时,取得ATTR_NUMx就意味着直接取到 了属性字段,省去了二分查找带来的巨大时间消耗。













本文转自张昺华-sky博客园博客,原文链接:http://www.cnblogs.com/bonelee/p/6249445.html,如需转载请自行联系原作者

上一篇:lucene索引文件格式


下一篇:Sql之datediff的用法