TODO

[H] [TODO] mylog的编译坑爹不报警
[L] [DONE] merger执行时对各个indexer进行判空，避免空merge
[M] [DONE] disk_indexer中加入对index_block的缓存(没有内置的cache库)
[H] [DONE] query服务实现
[H] [DONE] bitmet实现
[H] [DONE] ID映射
[H] [TODO] 整理系统的限制说明:
    [DONE] -1- diskv的最大文档长度是32M，postinglist和detail不得超过这个长度
    [DONE] -2- hash的冲突率(最好用实际的文本term测试)
    [TODO] -3- 当拉链超长时，merge的问题
    [TODO] -4- 当postinglist_cell的长度超过mem_link_t时。。
[H] [DONE] NLP集成
[H] [DONE] 灵活索引的实现
[H] [TODO] 灵活查询的实现 + 对postinglist的灵活过滤，如只搜标题
    [TODO] 变长索引的实现
    [DONE] 索引中，第一个INT默认是ID，第二个INT中分配默认值，存放分词算法支持的属性和后面变长的offset信息
[H] [DONE] 过滤算法集成
[H] [DONE] 调权算法集成(attr/term/offset)
[H] [DONE] 增加index_group的快速建库模式
[H] [DONE] 计算mem_indexer撑爆的时间和disk_indexer持久化的时间，这是参数配置的前提
           -1- 磁盘写入速度在9M/s，30G的索引需要1个小时左右写完(更大的文件速度会好一些，达到20M左右)
           -2- mem_indexer中的headlistsize为200万时，需要2分钟写满(最坏情况)
[H] [DONE] 通过判断每次day索引merge的时间来判断是否需要dump到day/2中，这就提供了自动调整his索引的merge周期
[H] [DONE] 测试seek_message(file_no, block_id)的正确性
[H] [DONE] 需要考虑异常情况，当dump到day时，如果进行中进程终止，那么启动之后判断
           -1- 没有2级索引，则清空索引
           -2- 如果2级索引不完整，则清空索引
[H] [TODO] OFFSET算法
    假定有3条offset拉链，用a[0]-a[2]表示，拉链的元素是从小到大排序的。
    最终目的是找到这样的i,j,k，使得|a[0][i]-a[1][j]| + |a[1][j]-a[2][k]|最小。
    全局最优解的动态规划做法为：
    用s[i][j]，表示0-i的拉链中，以a[i][j]结尾的最优解。显然，获得s数组后，只要穷举最后一条链的j,就能得到最优解。
    递推式子为：s[i][j]=min( min (s[i-1][x] + a[i-1][x]-a[i][j]), min (s[i-1][x] + a[i][j]-a[i-1][x]))
                                a[i-1][x]>a[i][j], 0<=x<链i-1的长度  a[i-1][x]<=a[i][j], 0<=x<链i-1的长度
    下面说明如何扫一遍所有拉链，就得到s数组。简单起见，只说明左边的a[i-1][x]>a[i][j]部分。
    假定我们要算的是：s[i][j]=min (s[i-1][x] + a[i-1][x]-a[i][j]) a[i-1][x]>a[i][j], 0<=x<链i-1的长度
    令b[i][j]=s[i][j]+a[i][j], 则 s[i][j]=min(b[i-1][x]-a[i][j])=min(b[i-1][x])-a[i][j]，a[i-1][x]>a[i] [j]的限制，
    在加上拉链递增的条件，使得我们可以从大到小枚举j，记录过程中的b[i-1][x]最小值。显然每次可以利用上一次的结果，
    因此b数组也只要扫一次。
    容易看出，只要拉链长度之和复杂度的运算，就能得到最优解。
[H] [TODO] 停用词，一般限制标点
[M] [TODO] 其实可以把mod和del这些数据与brief放在一起的，这样过滤起来多带劲
[H] [DONE] 输出用bson
[H] [DONE] 通用的groupby算法