上一篇具體講了怎麼做的, 後來又一直在想如何提高.
因爲不太明白如何提高效率，我又做了一些無謂的嘗試，比如把同前綴的寫到一個小文件裏，例如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
