索引的分布式存储

一  先不说分布式，先说在磁盘上索引怎么存储。

在内存里，索引肯定是以BST，Trie，Hashtable等形式存在，便于查找。在磁盘上的存储呢？

1）不要想到树的序列化问题，不一样，第一，索引是先在磁盘后load到内存里，第二，树的序列化是说要完全保存树的结构，这里不需要，只需要是一颗平衡树就行。

2）其实就是一个symbol table，词典，key-value 表，在磁盘上时候不需要有序，只要相关数据保存到了就可以了，load的过程就是给定一个词典建一棵Trie树的问题。只需要从一棵空trie开始，(key,value)做一个结点，不断插入入到Trie里（或者 BST ，hash table）。

3）MDS对索引的存储是用xml 把trie的结构也保存了下来，不是为了存储这个树结构本身，而是为了利用Trie的特点，相同前缀只出现一次，公共前缀多的情况下节省存储。当然xml又有overhead，未必真的能节省，但思路是这样。在磁盘上保存树的结构，并不能加速load。

二、分布式下怎么存？

1 按照docId 进行分区（partition）, 即局部索引，一台机器对应docId的一个range, 单独的build index，一个关键词在一台机器上只能查到部分的docId列表，搜索的处理流程是，前端把关键词发给每一个结点，并行的查询，最后聚合docId 列表。 好处：

1）可靠，一个node挂了，只是造成docId列表不完全，只是少部分结果没有返回，不影响全局。

2）并行查找返回结果，loadbalance，避免单机返回所有的docId 列表造成的单机过大网络负载。

2. 按wordId 分区，全局索引

一台机器负责一个wordId range的索引，关键词映射到具体的机器，这台机器包括这个关键词的所有docId。

好处：1）查询只需要访问一台机器，也不需要后续的聚合

2）如果查询的关键词分布均匀，loadbalance比较好。局部索引每次查询都要发给所有机器，每台机器的有可能排队

缺点：可靠性差，如果一台机器挂了，这个机器对应所有关键词的查询都会挂，当然也可以通过replica cluster方案解决可靠性问题。

3 实际系统中一般采用局部索引，因为可靠性比较重要，再者这种按docId 分区的方案比较自然，因为前端的crawler的产出就是doc库，很自然的就是按docId range分区，而且也许crawler本身就是分布式的，每个crawler 维护自己独立的网页库，天然就分区好了。