全文検索のLucene5.0がリリースされました。1ヶ月近く前の話しですが……
[ANNOUNCE] Apache Lucene 5.0.0 released
SolrやElasticSearchでも利用されているなど、現在使われている多くの検索システムの基板になっているLuceneですが、メジャーバージョンアップは2年半振りになります。いつものようにSolr5.0も同時リリースされています。
主な更新情報から一部を抜粋してみました。
Stronger index safety
（Indexをより安全に取り扱えるようにしたよ）
* All file access now uses Java’s NIO.2 APIs which give Lucene stronger index safety in terms of better error handling and safer commits.
（ファイルアクセスをJava NIO2にしたよ。エラーハンドリングがより細かくできるようになったので、コミットとか安全にできるよ）
* Every Lucene segment now stores a unique id per-segment and per-commit to aid in accurate replication of index files.
（セグメントとコミット単位でユニークなID1を持つようにしたので、インデックスのレプリケーションをより正確にできるよ）
* During merging, IndexWriter now always checks the incoming segments for corruption before merging.
（マージする際に、IndexWriterがセグメントの競合をチェックするようになったよ）
Reduced heap usage
（ヒープサイズを減らしたよ）Lucene now supports random-writable and advance-able sparse bitsets (RoaringDocIdSet and SparseFixedBitSet), so the heap required is in proportion to how many bits are set, not how many total documents exist in the index.
（random-writableでadvance-ableな疎なbitsetを使うようになったよ。これでドキュメント数ではなくbitがsetされてる数にヒープが依存するようになったよ）
Heap usage during IndexWriter merging is also much lower with the new Lucene50Codec, since doc values and norms for the segments being merged are no longer fully loaded into heap for all fields; now they are loaded for the one field currently being merged, and then dropped.
（IndexWriterをマージする時のヒープサイズがだいぶ減ると思うよ。これまで全フィールドを読んでいたのを、1フィールド毎にマージするようにしたから）
The default norms format now uses sparse encoding when appropriate, so indices that enable norms for many sparse fields will see a large reduction in required heap at search time.
（デフォルトのNormでも場合によって疎なencodingを使うようにしたよ。これで検索する時に必要になるヒープが減るよ）
5.0 has a new API to print a tree structure showing a recursive breakdown of which parts are using how much heap.
（どこでどれくらいヒープを使っているかを表示するAPIを作ったよ）
ということで、Index周りをより安全に操作できるようにしたのと（2系使ってた頃はIndexが破損して読めなくなるとかよくあったなぁ）、疎行列を使うシーンを増やしてヒープの使用量を減らしたのが大きな変更になるようです。
その他にもいろいろ変更点はありますが、個人的に面白そうだと思ったのはこのあたり。
ConcurrentMergeScheduler detects whether the index is on SSD or not and does a better job defaulting its settings. This only works on Linux for now; other OS's will continue to use the previous defaults (tuned for spinning disks).
（マージスケジューラーはストレージがSSDかどうかを確認して、デフォルトのジョブの設定を変更するよ。これはまだLinuxのみ対応で、他のOSでは今まで通りの挙動になるよ）
巨大なインデックスやストアされたデータがある場合、マージの時はかなりのディスクアクセスが発生するので、SSDかHDDかで最適な処理が変わってくるようですね。
当該チケットを見てると、SSDを判定するのは簡単ではないというのは伝わってきます。
マージはLuceneが行っている処理の中でもかなり重いもので（PostgreSQLにとってのvacuumのような存在とでも言えば良いだろうか）、その他の更新点でもマージスケジューラーに関する変更が目立っていました。
