Mdrill项目在lucene的改进上的10点心得
Mdrill官方:https://github.com/alibaba/mdrill
一、 修改创建索引逻辑,让索引能够基于hdfs中进行创建
目的:
这样就不在需要使用本地硬盘,可以通过mapreduce并发的在hadoop中创建索引,从而解决离线创建索引的速度,而且也同时解决创建索引过程中本地必须要有大硬盘的囧况。
原理:
之所以原先的lucene不能再hdfs中创建索引,是因为lucene中存在随机写,而hdfs 不支持随机写导致,仔细阅读lucene源码发现,lucene使用随机写的场景只有两种,
一种是在文件的头部预留出一个int长度的空间,等待索引创建完毕后,更新这个预留的int位置,标记上该索引一共有多少条记录。
另外一种是存在文件校验crc32,前面预留出一个long类型的空间,在后续写入数据后,得到其crc32的值后,重新写入。
综上所述,这些随机写是可以避免的,我们的处理办法是不在预留这些空间,而是将其值顺序的写到另外一个文件中去。
二、 addIndexesNoOptimize的优化
目的:
该方法了解lucene的人应该知道,是向当前索引中添加一个新的索引,通常来说我们在mapreduce的第一个阶段会通过大并发创建小索引,在第二个阶段会通过addIndexesNoOptimize的方法将这些小的索引合并成一个完整的最终的索引。
目前lucene在这个地方的实现并不是特别好,addIndexesNoOptimize的处理逻辑是先将外部的索引copy到当前索引所在的目录,然后在进行合并,所以这个就多了一个copy的过程
这样做目前有3个缺点
第一、 当数据量特别大的时候,因为有了一次额外的copy,这种copy带来的开销是很大的,而且也是没必要的。
第二、 因为这这种copy将索引都copy到同一个目录上了,也就意味着在同一个磁盘上,那么在合并索引的时候还需要将这些文件重新读取一遍,单个磁盘的读取速度是有限的,不能利用多个磁盘进行合并会影响合并速度。
第三、 很多时候我希望当前索引下的不同的sigments能够分布到不同的硬盘上,这样检索的时候,同一个索引不同的sigments能够使用不同的硬盘进行检索。
原理:
针对上述问题,我们对lucene进行了一次比较小的改进,大家可以将其理解为linux下的文件的软连接,实际的addIndexesNoOptimize方法并不会真正的发生copy,而是仅仅在当前的索引中做了一个标记ÿ