搜索引擎的文件格式

树脂可以分析，索引和存储文档，并具有对术语，模糊和前缀的查询支持。 这是支持其索引，查询和文档存储功能所需的六个不同文件，并说明了布局。

文件地址

[index_version] .da

文档存储在doc文件中。 要在文件中找到一个文件，必须首先在文件中查找其起始位置并找出其长度。 da文件包含文档的地址及其大小，每个记录按文档ID排序，该整数从零开始递增，并在每个upsert会话中分配给每个文档。

每个upsert会话一个da文件。

文件地址的大小： sizeof（long）+ sizeof（int）

文件资料

[index_version] .doc

长度可变的文档沿边存储，没有定界符。 默认情况下，快速模式下使用QuickLZ压缩，通过提供压缩标志来使用gzip。

每个upsert会话一个doc文件。

文档大小： sizeof（int）+可变大小的字符串* numOfFields

索引信息

[index_version] .ix

包含文档计数和压缩标志。

每个upsert会话一次。

大小： sizeof（int）+ sizeof（byte）

主键

[index_name] .pk

包含每个文档的主键的哈希值，以及指示该文档是删除还是活动的标志。 编写索引时，仅当您需要通过该键删除或更新时才需要提供主键。 没有主键的文档只能按条款删除，并且永远无法更新。

每个upsert会话一个文件。

文档记录的大小： sizeof（UInt64）+ sizeof（byte）

贴子

[index_version] .pos

过帐是术语计数和对文档的引用。 过帐按术语分组。

每个upsert会话一个发布文件。

发布大小： 2 * sizeof（int）

搜索树

[index_version]-[field_hash] .tri

在每个搜索引擎的核心（大脑？）处，搜索树（这里以双链前缀树的形式）是trie和二进制搜索树之间的完美结合。 够树了。

每个特里节点，其char值及其元数据都存储在文件中。

元数据

布尔EndOfWord
布尔哈斯儿童
布尔哈斯兄弟
短深度*
int权重（numOfChildren + numOfSiblings +1）
PostingsAddress地址（仅适用于EndOfWord，与文档地址相同的大小）

它有很多信息，但需要能够从磁盘扫描文件，就像它是内存中存在的左子右兄弟搜索树一样。

需要一个节点的权重，以便确定一旦扫描已达到死胡同，但需要继续前进到下一个分支，就可以跳过多少个节点。

在每个EndOfWord上找到的发布地址都有一个大小，并指向发布文件中的某个位置，该位置标记与该特定术语相关联的发布列表的开始。

每个upsert会话的每个文档字段一个trie文件。

节点大小： sizeof（char）+ 3 * sizeof（字节）+ sizeof（int）+ sizeof（short）+ SizeOfPostingsAddress（）
单词节点结尾的大小： SizeOfNode（）+ SizeOfPostingsAddress（）

文件更新

由于版本控制方案可在查询时检测哪些文件是活动的，哪些文件是无效的，因此不需要文件更新。

结论

如果这些是Resin，Lucene以及Google以一种或多种形式需要的文件，那么，它们在Google那里所做的一切与火箭科学相去甚远。

干杯!

From: https://hackernoon.com/file-formats-of-a-search-engine-2c7a2396f1eb