O(1)复杂度的字符串查找算法设计

     Tips：这是为本人所在公司设计的查找子串的算法的文档。“发明”出来之后才发现杯具了……原来这货叫字典树，是早已经有的东西。计算熵倒是自己引入的，但是后面发现很多情况下得不偿失，实际实现中去掉了这个功能。以下为文档最初始的版本，并不跟手上已经实现的玩意完全符合。仅仅希望大家看了之后能有所启发，以下是正文。

   

1 简介

2 测试数据

3 算法原理介绍

  1.1 在数组查找单个字符

  1.2 在树查找字符串

  1.3 计算熵增益 构建决策树查找字符串

4 模糊查找

5 缺陷和优化

 

 

1 简介

本算法的应用场景为，在N个NWord长的字符串集合中，查找一个NWord长的字符串所在位置。 

根据理论预期和实际检验，目前为止基本实现了O（1）时间复杂度的查找。也就是说，无论N为多少，查找时间基本为常数。严格来说，查找时间跟N无关，仅跟字符串长度NWord有关。但是字符串长度大部分情况下不会超过一定范围（比如10-20个汉字），所以可认为：查找时间 = f(  NWord )  = f( 群名长度 ) = 常数。

本算法在设计中参考了两种算法：

1）根据ID3算法计算熵增益构建决策树。

2）参考暴雪游戏公司的哈希查找算法，使用字符串本身的值的一部分作为下标。

2 测试数据

算法Demo使用随机生成的大量字符串作为测试样本。主要变动参数有2个：N，查找的字符串样本集合的数量；NWord，待查找的字符串字节数，同时也是字符串样本集合每个元素的字节数。测试耗时单位为毫秒。查找内容为在有N个目标字符串的集合中进行查找N次查找，带查找字符串也从集合中抽取（即保证待查找字符串一定在字符串集合中）。

比较效率的目标算法为STL的unordered_map和暴雪的同样为O(1)复杂度的hash查找。机器环境为64位windows 7， Intel Core I5 四核CPU。

查询次数	目标字符串集合大小 即N	待查找字符串长度即NWord	stl::unordered_map	blizzard字符串查找算法	原创查找算法—精确模式	原创查找算法—模糊模式
1*10000	1*10000	20	64	9	11	3
2*10000	2*10000	20	137	18	31	5
3*10000	3*10000	20	238	26	48	12
4*10000	4*10000	20	301	34	42	22
5*10000	5*10000	20	340	42	77	21
6*10000	6*10000	20	468	49	88	18
7*10000	7*10000	20	489	58	110	33
8*10000	8*10000	20	556	66	92	34
9*10000	9*10000	20	636	75	117	39
10*10000	10*10000	20	662	85	117	38
1*10000	1*10000	40	60	10	10	3
2*10000	2*10000	40	120	17	20	6
3*10000	3*10000	40	200	25	32	10
4*10000	4*10000	40	290	33	41	13
5*10000	5*10000	40	315	41	58	17
6*10000	6*10000	40	390	49	68	22
7*10000	7*10000	40	432	57	74	27
8*10000	8*10000	40	495	69	87	30
9*10000	9*10000	40	568	75	101	34
10*10000	10*10000	40	636	84	108	39

结论：

当数据量N在1万到10万之间时，无论字符串长度为多少，以下成立：

使用STL内置的unordered_map算法时，每万次查找消耗时间在50~60毫秒左右

使用暴雪blizzard字符串查找算法时，每万次查询时间都稳定在8毫秒左右；

使用自定义算法精确查找时，每万次查询时间都稳定在10毫秒左右；

使用自定义算法模糊查找时，每万次查询时间都稳定在3-4毫秒左右。

3 算法原理介绍

  3.1 在数组查找单个字符

  我们先考虑在一个1维数组中查找NWord为1的字符串，也就是单个字节。如果我们直接把字节的值作为下标，那么O（1）的时间复杂度是很明显的。

3.2 在树查找字符串

考虑多个字节的字符串，就不能再使用1维数组来存储。可以把字符串切割为字节放在树结构之中。每个字节在本层子节点通过该字节的值来进行索引。这样，当需要进行查找时，即不使用深度遍历，也不需要使用广度遍历，只要遍历字符串的每一个字节，不断取字节值作为下标即可。

3.3 计算熵增益 构建决策树查找字符串

3.2中是顺序使用每一个字节的值作为下标。但是每个字符的重要性，或者说代表性，可以使不同的。假设我们在三个样本组成的集合中进行查找，即Hell，Heat，High。如果我们把3个词组织成树，可以根据根节点的选取组织不同的树。

我们考虑三个单词的字节1和字节3。如果我们在决策树中第一步判断的是单词的第3字节（也就是说以第3字节的值构建根节点的下级），那么可以一步到位查找出来，可以不进行后续的判断。如果第一步判断的是第1字节，那么就是在做无用功，还要进行后续判断。

有NWord个字节，就要计算NWord次熵增益。每次计算熵增益的参数为所有字符串中相同位置的字节，即N个字符。 

我们令S为样本集合，A为某个字节，则字节A的熵增益的计算公式如下：

 

其中，是样本内所有N个字符串的总熵，这里取；是S的不同子集，这里就是某个字节取不同值的集合。是不同取值的数量；是总样本数量N。即是。例如第3字节的i，a，g分别是一个集合，其分别是1,1,1。第2字节的e，i分别是一个集合，其分别是2和1。我们根据公式计算二者的熵增益如下：

总熵 = log(2,N) = log(2,3) = 1.584

第三字节的熵增益 = log(2,3) - ( log(2,1)/3 + log(2,1)/3 + log(2,1)/3 ) =log(2,3) = 1.584  

第二字节的熵增益 = log(2,3) - ( log(2,2)/3 + log(2,1)/3) = log(2,3) - 1/3 = 1.251

也就是说，第三字节的“价值”更大，应该取第三字节在更靠近根节点的层次上。进一步地说，第三字节的熵增益等于总熵，也就是说其拥有完全的信息——只要判断第三字节就可以完成查找。

4 模糊查找与精确查找

决策树查找之所以快，在于可以在适当的时机停止下来。参考下面的例子：

就如同第3节所说的，如果我们在树的某i层，对应所有字符串的第j个字节，如果每个字符串的j字节都两两不同，那么查找到该层的适当位置时并且子树数量仅为1时即可停止，因为接下来的必是要查找的字符串。比如例3的第3个字节——l，a，g——两两不同，我们只要判断第三字节即可。

但是如果集合中没有我们要查找的字符串，而查找算法执行到只剩下1个子树时，若此时停止，找到的就不是跟待查找字符串完全匹配的字符串，而仅仅是集合中最接近的。

5  缺陷和优化

     在最新的实现中，首先我去掉了计算熵增益的部分；否则插入时耗时太长。其次，为了应付当保存的字符串长度为60，数量大于等于10万条时内存的爆炸性增长，我把树节点的数据部分设置成动态分配。内存池使用了谷歌的je_malloc，否则大量的内存碎片会使内存回收变成大问题。