Lucene 缺点汇总

1.倒排中以docid排序,这样做的好处是多关键词查询时,merge算法自然,高效.支持phrasequery;indexmerge阶段,处理简单.文件定位快速,倒排压缩高效.但是,它的一个致命的缺陷在于:当某个term的倒排很长时,在处理一次search时,系统需要对倒排所有元素都进行处理.这样的代价是不可接受的.这就注定了lucene不适合海量数据的检索(当然Localpartition的分布式索引可以缓解这样的问题).大量的文献建议采用与query无关的ranking项进行排序.这样一方面可以对倒排剪枝,另一方面加速search.但这样的方法也有诸如:多关键词结果merge时的低效,索引merge的算法复杂,建立索引的代价大等缺点.克服这些不足,需要对这两者的优缺点进行相互的扬弃.目前考虑的是采用block的方法,即倒排中以block为基本单位,block之间是ranking降序,而block内采用docid排序.具体细节这里不详细展开.

2.频繁update的数据将使lucene对diskio影响巨大.lucene的增量索引是通过它的merge算法来实现的.而该merge算法导致频繁的disk操作.一个新的数据的update,可能导致一部分根本没有变化的索引被重写很多次,并且可能导致很多的小的indexsegment,造成了search的性能下降,当然,用户可以通过调节几个参数来缓解这个问题.我们可以,兼顾索引效率和检索效率,来重新设计merge算法(中科院的firtex进行了部分尝试,不过缺点依然明显),可以设计Merge算法对于小的索引可以”越级”与大索引块进行合并,来减少diskio.根据倒排block设计的思路,我们可以根据某些经验的统计量为每个block预留一定空间,每个单元有标记.这样,我们可以在一定程度上进行update而根本不需要重写部分索引,从而大大减少diskio.当有大量数据update时候,再采用segment合并的算法进行合并.同时每个block都应该有blockhead,保留Block的一些统计信息,以便在search的时候及早剪枝.

3.再挑挑刺,Lucene结构很清爽。但唯独一个docid排序,这个假设,遍布与整个代码。惨不忍睹。

4.incrementalfetch。lucene不支持从中间取索引。例如:用户取第十页,lucene需要把前面所有的内容都要检索出,然后所有的排序,过滤掉前面的然后返回。虽然说,这个从用户行为来说(因为大多数用户还是看前面的,不会跳着来),不是什么大问题。但是,这个毕竟可以解决。

5.lucene用java写。但是clucene为了保持与javalucene一致,用了很多难看的写法。并且更新不及时。

6.scorer和weight写的比较难看。:slight_smile:

7.doc-partition的模式,当然这个不是lucene本身的问题。doc-partition的方法有着很多不足,诸如全局统计量不准确,diskaccess大等等,但是大部分文章在综合了系统构架的简单性,网络负载和负载均衡还是普遍认为doc-partition比较优秀(google就是这种架构),当然针对doc模式的种种不足,也有很多的paper提出了改进的方法。我比较关注的是collectionselectionfunction,querylog-basedpartition和hybridarchitecture。