Mdrill项目在lucene的改进上的10点心得

Mdrill项目在lucene的改进上的10点心得

 

 

原始文档下载：https://github.com/alibaba/mdrill/blob/master/doc/Mdrill%E9%A1%B9%E7%9B%AE%E5%9C%A8lucene%E7%9A%84%E6%94%B9%E8%BF%9B%E4%B8%8A%E7%9A%8410%E7%82%B9%E5%BF%83%E5%BE%97.docx?raw=true

 

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，而是仅仅在当前的索引中做了一个标记ÿ