之前为了加速读取solr中的文献(文献有几千万,每个几K),我用c++和thrift实现了一个叫cabinet的服务。其中key是一个32位整数,value是一个string,是一个thrift序列化后的字节数组。支持增加、删除、修改和读取,读取性能要很好。所以实现上就把索引(key为文献id,value为文献在数据文件中的位置)存在内存中,读取时只读取一次硬盘。修改和删除的记录则存在另外两个map中。
今天发现这个工作和hadoop map file的工作完全一样,如果使用map file, io部分的编码完全可以省掉,只需要管理main,del,ins这三个map文件,而且hadoop提供的序列化功能比较全,还方便在上面直接跑mapreduce,就是需要看看真实的性能如何。
有一个问题是:map file如果真是完全排序的,那么插入性能会很糟糕。
成熟的方案是solr + hbase,mapfile做快速索引完全没有问题,MapFileOutputFormat.getReaders,getEntry可以实现,但要scalability,仍要分片。