唯一性索引优化实践（讲得好细哦）

原文出处：搜索技术博客-淘宝

Unique索引，有时也称Primary Key索引，顾名思义就是对于这个索引字段每个doc的值都是唯一的，如各种id字段：product id，customer id, campaign id和bidword id等。这种类型的索引一般用来进行高效的查询，最典型的应用场景就是进行附表join查询，即对主表中查到的每一个doc，都在附表中查询其对应的附表doc信息。所以，对这种类型的索引进行优化会对整体查询性能有很好的提升，特别是在主表查询的结果很多的情况下。本文主要总结一下对于这种类型索引的优化实践，包括全量和实时增量的情况。

我们知道，在全量建索引时，在内存中一般用开链的哈希表来存储Token的Hash值及其倒排链的信息。假设有N个不同的tokens，那么这个hash数组的大小一般是取第一个大于N*(5/3)的质数P。结构如下图所示：

当一个段的索引建完以后，这个内存中的Hash表里面的tokens的哈希值及包含其倒排链和occ链等元信息的keyword terms一般被转成如下的三种数据结构之一存在文件中：

这几种数据结构的目的都是为了在查询时先mmap了这些文件以后，能对于一个给定的query keyword，快速根据其哈希值找到其对应的keyword term，进而定位到相应的倒排链和occ链等信息。不同的数据结构在不同的场景（数据特点）下对于内存空间的使用以及查询性能的影响也是不同的。下面先简要分析一下以上这几种常用数据结构的特点，然后再谈谈对于Unique类型的索引所采用的优化数据结构。

为了便于分析，假设我们有100万个不同的Tokens，每个Token的Hash值需用8个bytes表示(uint64_t)。Tokens对应的keyword terms 100万个，同时在一般情况下，每个keyword term的第一个元素就是其对应的token的hash值。在内存中建索引的时候,这个开链hash表数组的大小P取大于N*(5/3)的第一个质数，即3145739。

Closed Hash Table(闭链哈希表)

提到哈希表，不少人想到就是快，时间复杂度为O(1), 其实未必如此，这个在后面的优化讨论中再深入。对于闭链hash,其大小一般也是取第一个大于N*(5/3)的质数P来申请空间，所以空间占用一般会比较大。对于以上例子，即N=100万，那么这个Hash数组大小为P，为原始keyword terms大小的3.15倍。闭链Hash表事实上就是环形数组，如下图所示：

当查询一个token倒排链等信息的时候，首先计算其hash值，比如H，然后用H模P得到一个值作为下标，然后看这个闭链hash数组在这个下标下的元素是否是空值，如果为空（对于上图来说，就是元素的hash值为0），则直接返回表示没有查到；若不为空，则看看这个元素的hash值是否和查询值相等，若相等则找到返回，若不等则继续跟这个元素的后面元素依次进行比较，最后要么找到，要么碰到一个空元素说明没有查找到。

Skip List(跳表)

跳表，顾名思义，是能在查找的时候能快速跳过很多元素，然后在一个相对小的范围内搜索给定的一个query keyword的hash值对应的keyword term信息。跳表的实现原理是：

所以一个跳表的结构如下图所示：

在查询的时候，执行如下步骤：

注意由于按Hash值的值域进行分段跳跃，所以每个哈希值区间里面的元素个数是很可能是分布不均的，故每次二分查找的区间大小是不固定的。

Tiered Dictionary(分层词典)

Tiered dictionary的思路是分层查询定位。即，先二分查找一个小词典定位到一个大致的小范围，然后再在小范围内再继续搜索keyword term。实现的原理是：

所以，序列化好的tiered dictionary结构图如下：

那么对于任一个查询词，假设hash值为H，查找其对应的keyword term就比较简单了：

相对于skip list，tiered dictionary的查询比较稳定，因为它可以保证第二次搜索总是在一个元素较少的block中查询，而skip list无法做到这一点，这个前面提到过；但是skip list有时候可以在第一步查skip list小数组的时候就可以确定这个元素不存在，而tiered dictionary一般情况下做不到这点。

全量Unique索引优化

像很多数据结构的算法一样，在内存空间使用和查找时间之间往往需要一个权衡，Unique索引的优化也是这样，当然我们的目标还是在尽可能的在占用较少内存的情况下，使得查询速度更快。

不同于一般的字段索引，一次查询只查询一次，用在附表Join时候的Unique索引在一次查询中可能会被查询上万次(每个主表的doc结果都需要进行一次附表Unique索引查询)，这就决定了查询速度是Unique索引实现的第一目标。我们看到，不管是skip list还是tiered dictionary，大部分时候都需要二分查找，特别是有时候对于不在里面的元素，二分查找比较的次数反而更多，这就决定了对于Unique索引如用这两种数据结构，在线查询的性能是很不高的，虽然它们俩是比较省内存的。

当然，我们最想达到的目标就是只比较一次，或者很有限几次就能确定一个hash值是否在一个段的某个unique索引中。我们很显然会想到哈希表，比如实现简单的闭链哈希表。的确，有些搜索引擎的索引也是这么做的。但是，对于闭链哈希表的实现，这里面有一个大坑！

对于hash table的实现，我们知道关键是hash function，记做H。好的H(x)的计算结果要分布均匀(uniform distributed)、冲突少(less collisions)。但对于闭链hash table的实现，除了冲突少，H还有一个非常重要的要求，那就是H(x)的结果集要避免簇拥在一起(avoid clustering)，即要避免H(x)计算得到的数组下标是连在一起的，否则会发生非常悲惨的后果。这个其实不难理解，因为对于线性hash函数来说，闭链hash表在查找的时候若发生冲突，是依次向后比较查找，要么找到相应元素，要么碰到空元素没有找到返回。所以如果有大片的结果连在一起，如果查找的元素不在里面，同时又发生了冲突，查找到第一个空元素有时候需要比较很多次。这种情况很容易发生，比如在bidword id很多是相连在一起的情况，同时我们又采用简单取模的方式来计算hash数组存储下标。

当然，我们可以修改哈希函数来避免簇拥，这个我们增量索引优化的时候会采用。对于全量，为了在内存使用和查询效率上取得平衡，我们可以采用开链哈希表的方式来解决，其实实现也不复杂。

最简单的实现，就是将内存中的hash table里面的conflicting hash nodes list一条一条的序列化，内存中的主索引数组的元素分布情况不变，同时将conflicting nodes直接链在原hash主数组的后面。不过，为了链式存储，序列化好的每个keyword item里面会增加一个next指针和是否是每条链的最后一个节点的标记。存储好的结果如下图所示：

显然，有了这样的开链hash表结构，我们就可以保证每次都能在有限比较次数内确定一个hash值是否在索引中，而且最多比较次数就是最长的冲突链的长度。同时，我们知道一般用来建Unique索引的字段值基本上都是以加一的方式递增的，所以当哈希函数取为H(x) = x % P（P是一个较大质数），冲突显然是很少的。此外，在查询没有冲突的情况下，只需要比较一次就可以确定一个hash值是否在索引中；即使在比较查找发现有冲突的时候，大的内存跳跃查找也至多一次，因为除了第一个冲突节点，后面都所有其它的冲突节点都是存储在一起的，所以查询上具有较好的内存访问局部性，对CPU cache利用比较友好，从而查询性能比较好。

测试和线上效果证明，对于P4P广告bidword域的bid_adid Unique索引，当用以上的开链hash表存储结构替代原来的skip list实现时，查询性能提升3倍左右。

此外，在基本保持查询性能优化效果不变的情况下，我们还可以对以上开链hash表存储结构进行优化，从而占用更少的内存空间。

我们发现主hash数组里面的每个空元素也占用了一个keyword item的空间大小，但其实它们唯一的作用就是表明这个位置为空，所以我们可以用一个每个元素大小为32位(uint32_t)的数组来表明hash结果信息，其中1个bit用来表明此位置是否有hash结果，另外31个bit用来表示当有hash结果的时候，对应hash节点链在keyword items数组中的开始下标。这样就可以将整个keyword items按每条hash冲突链存储在一起了，next指针也不需要了，只需要用一个bit来标识其是否是hash冲突链的最后一个节点就可以了，一般这个flag可以从32位的doc id上面取一位来标识。故，改进后的存储结构为：

对于前面提到的那个例子，即有100万个tokens，每个Unique索引的keyword item保存token的哈希值和doc id，且有20万的hash结果是冲突的。那么，上面改进后的索引结构使用的内存空间约是原来的46%，节省了一半以上的内存空间。

【注： (3145739*4 + 1000000*12)/((3145739+200000)*16) = 45.9%; 16是因为原来的keyword item多需要额外4个bytes的next成员】

实时增量Unique索引优化

以上谈论的是对全量Unique索引的优化，实时增量索引是在内存中一条doc一条doc构建起来的，它不可能像全量时那样有一个完整的内存哈希表可以进行序列化存储。但是由于一个segment的总共doc数组数目是固定的，同时又是Unique索引，所以我们一般用闭链哈希表来存储实时增量的unique索引。

但我们前面提到过，闭链哈希表的实现有一点要非常小心，那就是哈希函数H在保存冲突少的同时也应该避免哈希结果的slots簇拥在一起。其实也就是让空元素能够均匀的分布在哈希数组中，这样即使在查询碰到哈希冲突的时候，也能够很快完成比较退出，即要么找到相应元素完成查找，要么很快就能碰到空元素表示查找不到退出。

怎么样才能避免哈希结果集簇拥在一起了呢？一个简单有效的办法为：

所以，修改后的实时增量段的Unique索引的存储结构为：

显然，修改后的算法占用了更多的内存空间。但由于是实时增量段，这些段的doc数据量一般比较小，而且会被定期合并生成和全量时候一样的索引结构，所以多一点内存空间影响不是太大。但对于查询性能的提升是非常大的，据测试和线上效果观测，经过这样的修改，查询性能提升10倍以上。

这篇文章是小编无意间看到的，其实里边大多数的东西我到现在都还没有理解，不过我会继续努力，我能告诉你这曾经是我遇到过的一道面试题么。