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就意味着直接取到 了属性字段，省去了二分查找带来的巨大时间消耗。