规则匹配引擎——思路3

PS：速度太慢，我自己都受不了了，麻利点儿

上篇说道我们该如何成就“没有重合范围的规则集合”，如何做到？

很简单，与坐标系中的坐标变换异曲同工，我们可以通过重合规则来实现没有重合范围的规则集：

   -------50----75----------------150------
1.         --------------------------------
2.                                 --------
3. --------------
4.         ------------------------
变换为: 
   -------50----75----------------150------
1.         ------
1.               ------------------
1.                                 --------
2.                                 --------
3. --------
3.         ------
4.         ------
4.               ------------------

可以看到，将各个规则中范围的节点的作为范围坐标轴的分割点，形成有限个范围，范围间是不重合的，实现了我们前面所须的假设。每条规则对应一个或者多个范围，此时，对于一个特定的待判定值，通过二分查找确定其所属的范围，范围对应的一个或者多个规则也就随之被抓出来。比如，100所属范围为75-150，因此匹配到的规则为1和4。

其实，这也类似于全文检索中的倒排索引，每个独立的非重合的范围作为每条规则的属性而存在。道理总是相通的。

这一条路终于走出了眉目。

但是，还有两个问题：

１．在思路1中，我们为了分析方便，将多种多样的属性规则简化成了这么一个数字范围的形式，其他的能采用类似的方法么？

当然能。现在我们思路是，对于给定的待判定属性，用二分查找来确定其所属范围，每个范围对应一条或者多条规则。因此，只要理论上任何可以通过排序来确定唯一性的东西我们都能给其划定范围，并采用二分查找。比如，对于字符串，我们可以利用其hash值，将其排序、划定范围、对应规则，只不过，此时的范围可能只对应这唯一的字符串而已，但是方法已经通用了。

２．对于一条待判定数据，其多个属性规则匹配出来的结果规则集是不一样的，如何融合呢？

比如对于{'price': 100, 'location': 'Beijing'}，price属性匹配出来的规则是123， location规则匹配出来的规则是2345，那最终的结果应该是2和3。此时的问题是集合求交集的问题，此时最大的影响因素为所有集合中的最小集的大小。假定L个集合，最小集合为K个元素，那用hash求交所耗费的最大的时间复杂度也不过O（KL）。

总体而言，假定规则总数为m，正常非特别复杂情况下，根据规则产生的范围段应该在>m的差不多的数量级，我们可以暂定为km(k为一个100以内的常数)，同时待定数据有n个属性，那在数据属性定位过程中时间复杂度为nO(log2(km))。匹配结果规则集的求交集依赖于各个属性匹配出来的结果规则集合的最小集，最少情况下为零，最大情况下为m(这意味着有傻冒把m条规则的所有属性全定义为$any，现实情况下不存在这种级别傻冒，但是底线在这里，即便有，他也无法突破)，因此匹配结果规则集的去重时间复杂度为O(0)-O(mn)之间。整体时间复杂度的渐进下限为nO(log2(km))，渐进上限为nO(log2(km))+O(mn)。在一个规则匹配引擎的正常使用情况下，规则条数可能不断扩充，即m为变量，而数据属性维度是固定的，也就是n为一个常数。当把常数都省略掉，渐进上限可以写做O(log2(m))+O(m)，即最差性能。如果理想点，假定数据属性匹配出来的结果规则集都是特定的小数量子集，O(m)貌似也可以被当成一个稍大一点的常数省掉，那时间复杂度就剩O(log2(m))。这依赖于规则配置的实际情况，可这样的可能，已经很美了。

思路到此结束，后面来实现它，实现过程中仍有很多意想不到的问题，On the road。