全文检索之sphinx源码分析--优化（二）

        对上一篇的优化部分简要解释一下代码的变动，由于还是涉及一些工作上的业务，所以不会原模原样的写下来，不过解释一下逻辑则具体的代码实现也不会太难的

        searchd

        1、通过文件名排除不需要检索的索引文件，在RunSubset函数中通过对m_dQueries.m_dFilters.m_sAttrName.cstr（）进行操作可以取得之前提到的where条件里的YYY的值范围，通过这个范围卡一下每一个m_dLocal中的索引文件的文件名代表的时间范围，对检索时间范围明确的查询有非常好的效果

        2、在RunLocalSearches函数里进行过滤，sphinx需要用户指定一个检索返回条数的值maxmatches，不指定就默认20条，我们以默认值举例：倒排一下索引文件m_dLocal.RSort()，于是最新的索引文件在最前面（索引文件名代表时间范围），此时假定第一个索引文件就检索够了20条，那么剩下的999个索引文件还需要检索么？答案是还是要看一下具体情况的，如果每个索引文件之间没有时间交集（如第一个索引文件维护17080102~17080103而第二个索引文件维护17080104~17080105）那么后面的999个索引文件的sph完全不需要解压看一下，反之如果有时间交集则还是要看一下有交集的索引文件的。这步优化对命中量大的关键字有非常好的效果，经常能将10分钟以上的检索时间减小到秒级

        3、n叉树的优化难度在于对这部分代码需要比较深入的去看，如果不用一些gdb这样的调试工具去追很难发现具体的点。在sphParseExtendedQuery函数生成第一个n叉树的时候，这部分只有match关键字相关的处理，我们可以在这里得知哪些节点是第一层的与操作的叶子节点，但是sph文件没有打开我们不能从其中得知哪些关键字命中为0，而如果我们推后到n叉转二叉的时候我们可以知道哪些关键字命中为0（通过sph文件）但是又没有办法判断哪些关键字是第一层的与操作子节点。因此我在XQNode_t类中加入一个新的变量need_to_check，在sphParseExtendedQuery函数生成n叉树的时候检查节点类型，将第一层的与操作的叶子节点的该值置为1，这样推后到转二叉树的时候ExtNode_i::Create函数中我们通过判断 if(pChild->need_to_check ==1 && pTerm->GetDocsCount() == 0)就可以直接返回NULL而不继续对这个索引文件进行检索了。

        indexer

        1、封装二进制文件读取数据实现伪流式处理逻辑，这里有两个思路，一个是类似xml文件生成索引的类，从CSphSource_Document类继承来，另一种是从CSphSource_SQL类继承，从CSphSource_Document类走则需要重新实现遍历doc的函数、遍历hit的函数，虽然从设计的角度来说是更为合理的，但是实现难度也更大，我在这里权衡了代码复杂度以后选择了从CSphSource_SQL类继承，这样虽然是利用的SQL类实现的文件流处理比较有违和感，但是实际上实现难度反而更小，代码改动加上测试基本在三五个小时就可以解决。需要实现的类函数主要是：

        具体实现就不一一列举了，从函数名也可以较容易的知道如何做，这里多说一下最好在disconnect函数里把建完索引的文件删掉以免内存盘撑爆。

        2、在创建索引时直接从文件夹里去看是否有需要建索引的文件，然后自己生成conf文件给自己用，而不是在调用参数里传conf文件把一切都固定死，同时给indexer各种模式参数可以保证在低数据量的情况下一次建立所以就退出和高数据量情况下积累一定的数据量在落地成索引文件。大数据量积累数据则需要在Build函数里循环source取数据这部分再在外部加上一个while，具体的方案也很好实现，就不在这里多说了。