上一篇具体讲了怎么做的, 后来又一直在想如何提高.
因为不太明白如何提高效率,我又做了一些无谓的尝试,比如把同前缀的写到一个小文件里,例如8K,如果数据量小,多个前缀的数据都写在一块里,猜想从路径直接定位到文件会快很多。结果尝试了一下,结果和原来的方法一样的结果甚至更慢….
我们可以知道每一块其实只要找到前缀一致的那批long, 这可以转变为一个key-value查找的问题了。采用一些高效的kv数据库,例如berkeleyDB, Tokyo cabinet,之类的可能在读取数据方面比自己写的文件随机读取要好。
于是我又用了lucene来做,(berkeleyDB收费,TC在windows上没法测)用lucene是因为可以直接利用取docid的方法来获取出结果。 这样写数据的时候把所有同前缀的都聚一块,吧long[] 根据规则转换成byte[] ,在Document上加入一个field只保存这个byte[], 前缀的值的顺序加入到indexwriter中。获取结果的时候直接indexsearcher.doc(前缀值) 得到Document 后得到byte[] 。根据不完全的测试,速度好像快了一些,但是依然是随机查询硬盘的消耗,而且索引比常规的大一倍多,而且数据生成慢了很多。后来又试了压缩byte[],结果大小没变多少,巨慢。如果有的KV数据库比如thuirdb这种只读不写的,估计就爽了。
经过一番折腾,懒得再搞了,就当作系统会帮你把查询过的值做缓存。如上篇的评论说的,其实如果数据量不大,放内存更合适, 当然要看参数的具体值再决定好.
加了lucene的代码在这:http://download.csdn.net/source/3375075