関口宏司のLuceneブログ

OSS検索ライブラリのLuceneおよびそのサブプロジェクト(Solr/Tika/Mahoutなど)について
スポンサーサイト

一定期間更新がないため広告を表示しています

| スポンサードリンク | - | | - | - |
(メモ)Grantさんの著書
http://www.manning.com/ingersoll/
| 関口宏司 | その他(分類不能) | 10:15 | comments(0) | trackbacks(0) |
(メモ) XTF - 高速ハイライトツール?
Lucene MLに流れていた情報。未確認。

http://xtf.wiki.sourceforge.net/underHood_Documents#tocunderHood_Documents5
| 関口宏司 | Luceneツール | 20:20 | comments(0) | trackbacks(0) |
(アイディア)逆ページランク
経済アナリスト 森永 卓郎氏のコラム「役所のマインドコントロールから脱け出せ!」を読んだ。これによると財務省のホームページでは、同省の都合の悪い記述は脚注などで小さい文字で表示されているらしい。

そこで思いついたのがタイトルのアイディアだ。私はかねてより官公庁や自治体などのホームページを横断検索するデモを作りたいと思って(2年以上経つがなかなか着手できないでいるのだが、それはこの際どうでもよい)いる。そのサイトで「小さい文字ほど重要である」「階層が深いほど重要である」「被リンクが少ないほど重要である」とみなす、その名も「逆ページランク」というのを実装してみてはどうだろう。

官公庁のホームページでは国民に知らせたくない重要な情報ほど文字を小さくしているようなので、この冗談のようなアイディアは案外いいセン行くのではないか。

この方法によると、<H1>よりも<H4>が、<B>よりも通常文字列が、通常文字列よりも<font size="-1">がより国民にとって重要になってくるのであり、高いスコアを与えて検索結果の上位にランキングさせるのである。なんじゃそりゃ。
| 関口宏司 | Luceneスコアリング | 22:17 | comments(3) | trackbacks(0) |
Lucene 2.4.0 のリリース
Lucene 2.4.0がリリースされた。以下、リリースアナウンスメールをそのまま掲載するが、新機能などすでにこのブログで紹介したものはブログ記事へのリンクを張ってある。紹介していないものは、今後取り上げていこうと思う。

なお、最後に書いてあるとおり次のLuceneはバージョン2.9となり、2.xの最後のバージョンとなる。その次は3.0となって2.9までのdeprecatedなAPIはすべて削除される。そしてLucene 3.0からはJRE 1.5以上を必要とする。


Release 2.4.0 of Lucene is now available!

With 2.4.0 we have relaxed the backwards compatibility policy of the
Fieldable interface
: we now allow changes on a case by case basis.
This means any custom classes that implement Fieldable will need to be
updated. This was done to accommodate the new omitTf() method (to do
pure boolean searching).

Many new features, fixes and optimizations have happened since 2.3,
including:

* New InstantiatedIndex (contrib/instantiated): RAM-based index that
enables much faster searching than RAMDirectory.

* New IndexWriter constructors now default autoCommit to false.

* New commit() method in IndexWriter lets you control when changes
are made visible and permanent in the index.

* A machine or OS crash, or power loss, while IndexWriter is writing
to an index will no longer corrupt the index.


* TimeLimitedCollector adds timeout to searches.

* Delete documents by Query in IndexWriter.

* Pure boolean indexing (no frequency, positions nor payloads are
indexed) using Field.setOmitTf().


* A new Directory implementation, NIOFSDirectory, using java.nio's
APIs to allow multiple threads to read from the same open file
without locking.

* IndexWriter.expungeDeletes() reclaims disk space from deleted
documents by merging away segments that have deletions.

* All filters now return a DocIdSet instead of java.util.BitSet,
making filters more efficient and flexible.

* Searching with a Filter is more efficient: now the filter is
applied to a document before scoring is done.

* IndexReader can be opened with new readOnly=true mode, which gives
better performance in a multi-threaded environment.


The detailed changes are here:

http://lucene.apache.org/java/2_4_0/changes/Changes.html

Lucene 2.4.0 includes index format changes that are not readable by older
versions of Lucene. Lucene 2.4.0 can both read and update older Lucene
indexes. Adding to an index with an older format will cause it to be
converted to the newer format.

Binary and source distributions are available at
http://www.apache.org/dyn/closer.cgi/lucene/java/

Lucene artifacts are also available in the Maven2 repository at
http://repo1.maven.org/maven2/org/apache/lucene/


NEXT RELEASE

The next release will be 2.9. After that will be 3.0, which will
remove all deprecated APIs from 2.9 and will be the first release of
Lucene to require JRE 1.5. The timing on these two releases is not
yet known.

Mike
| 関口宏司 | Luceneリリース | 02:28 | comments(0) | trackbacks(0) |
未確認情報
Powerset(現マイクロソフト)のJim Kellerman氏がHBaseのコミッターに就任?!
| 関口宏司 | その他(分類不能) | 00:40 | comments(0) | trackbacks(0) |
突然の電源断にも壊れないLuceneのインデックス(2.4)
まもなくリリースされるLucene 2.4では、インデックスの書き込み中における突然の電源断やOSのクラッシュにもインデックスが壊れないことが保証される(新しいインデックスを作成しきるか、もしくは失敗して古いインデックスが残るようになる)。

インデックス作成中のクラッシュの単体テストコードもある。テストの仕方は次のとおり:



$ ant -emacs test -Dtestcase=TestCrash
:
Testsuite: org.apache.lucene.index.TestCrash
Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 2.845 sec


| 関口宏司 | Luceneクラス解説 | 17:02 | comments(0) | trackbacks(0) |
IndexMergeTool
IndexMergeToolはディスク上の複数のLuceneインデックスをマージして1つの新しいインデックスを作成するコマンドラインツールである。contrib/miscellaneous/にあるIndexMergeToolは実質20行程度の短いプログラムで、addIndexes()メソッドの使い方の簡単なサンプルにもなっている:


public class IndexMergeTool {
public static void main(String[] args) throws IOException {
if (args.length < 3) {
System.err.println("Usage: IndexMergeTool [index3] ...");
System.exit(1);
}
File mergedIndex = new File(args[0]);

IndexWriter writer = new IndexWriter(mergedIndex, new SimpleAnalyzer(), true, IndexWriter.MaxFieldLength.LIMITED);

Directory[] indexes = new Directory[args.length - 1];
for (int i = 1; i < args.length; i++) {
indexes[i - 1] = FSDirectory.getDirectory(args[i], false);
}

System.out.println("Merging...");
writer.addIndexes(indexes);

System.out.println("Optimizing...");
writer.optimize();
writer.close();
System.out.println("Done.");
}
}


もっとも現在(まだでていないLucene 2.4)は、addIndexes()ではなく、addIndexesNoOptimize()の利用が推奨されている。
| 関口宏司 | Luceneツール | 08:52 | comments(0) | trackbacks(0) |
RMI関連のコードがcontribに移動の可能性(3.0)
https://issues.apache.org/jira/browse/LUCENE-1407

Android(!)でLuceneアプリを開発している人から、IndexSearcherなどがjava.rmi.Remoteを実装しており、RMIが使えないAndroid上でLuceneの検索アプリが動かないという指摘が発端。

そこでLucene 2.9でdeprecatedとし、3.0ではRMIに関する部分はcoreからcontribに移動しましょう、という提案がされている。
| 関口宏司 | Luceneクラス解説 | 00:30 | comments(0) | trackbacks(0) |
Solrにできて、Googleでできないこと
前回の記事は、読みようによっては、「Solrでできることは、すべてGoogleでもできる」ととられてしまう可能性もあるので、ここで「Googleではできないが、Solrでできること」もある、ということを具体例で示しておこう。

ここでいうGoogleはGoogleアプライアンスをとりあげる。Googleアプライアンスはブラックボックスであるがゆえに楽なことも多いが、インテグレータにとってはカスタマイズできない箱だということが、使用経験のあるインテグレータの間では有名な話だ。よって、Lucene/Solrで得意とするところの検索結果のランキングのカスタマイズが、Googleを採用すると一切できない。

OSS検索エンジンであるLucene/Solrはいろいろなプラグインが可能であり、ランキングのカスタマイズは「Googleでできないが、Solrでできる」ことの一例である。
| 関口宏司 | Google免罪符 | 19:02 | comments(0) | trackbacks(0) |
分散検索:Google vs Solr
先日、Solr 1.3の分散検索機能を導入しようとしている某客先で、Solrの分散検索の実装を検討しているときに出た話題。

関口「・・・とまあ、こういうわけで、Solrでは分散検索でInteger.MAX_VALUEの21億件を超える検索対象文書数を扱うこと(「40億件ヒットしました」と表示する等)はできますが、21億件を越える部分、たとえば『22億件目から10件分』の検索結果を返すことはできません。」
客「Googleではどうでしょうか?」

という話の流れでGoogleで数十億件もヒットする単語を探そうとするが、そのような単語はなかなか見つからない。

関口「・・・あと、Solrの分散検索の実装では、『次の10件』を繰り返していき、十分大きな開始オフセットを要求されると、処理時間が非常にかかってしまいます。なので、クライアント側で適当な上限を設けてやる必要があります。」
客「Googleではどうでしょうか?」

またもやGoogleの検索窓に適当な単語を入力してみる。今度は、数百万件ヒットするありふれた単語を思い浮かべるのは簡単で、結果を得ることができた。ただ、Googleの検索結果ページ下部の「次の10件」をクリックしていき、開始オフセットを100万件先にまで進めるのは人力では困難である。しかし、URLにオフセットを指定する"start"パラメータを使って"start=1000000"と指定すれば、Googleで簡単に開始オフセットを100万にすることができる。

そこで"start=1000000"を指定して検索すると、なんと、次のように表示されてしまった:

Google - over 1,000 hits

Googleでは1,000件以上先(正確には1,001件以上先?/2008年10月現在)の「検索結果一覧」を要求されても表示しないのだった。これは知りませんでした。

まあ、考えてみれば当然だ。Googleの分散検索のシーケンスはSolrと同じなので(というか、事実はSolrがGoogleのシーケンスをまねているので)Googleでも、検索結果一覧の開始オフセットが大きい場合は処理負荷が相当大きくなるため、開始オフセットが大きい検索リクエストには応じない、という選択をしているのだった。

「じゃあ、我々もせいぜい数万件表示すればいっか」「Googleができないんだから」というところに落ち着いた。

「Googleができないんだから」というセリフは、思えば私は月に1回くらい使っているかもしれない。お客さんも「Googleができないんだったらしょうがないね」と納得してくれる。「GoogleができなくてもSolrではやってくれるよね」というお客さんにはいまだに出会っていない。

「Googleができないんだから」は魔法の言葉だ。私は今日からこれを「Google免罪符」と呼ぶことにしよう。
| 関口宏司 | Google免罪符 | 11:33 | comments(1) | trackbacks(0) |
+ Solrによるブログ内検索
+ PROFILE
   1234
567891011
12131415161718
19202122232425
262728293031 
<< October 2008 >>
+ LINKS
検索エンジン製品 - 比較のポイント
商用検索エンジンを購入した企業担当者は読まないでください。ショックを受けますから・・・
>>製品比較 10のポイント
+ Lucene&Solrデモ
+ ThinkIT記事
+ RECOMMEND
Apache Solr入門 ―オープンソース全文検索エンジン
Apache Solr入門 ―オープンソース全文検索エンジン (JUGEMレビュー »)
関口 宏司,三部 靖夫,武田 光平,中野 猛,大谷 純
+ RECOMMEND
Lucene in Action
Lucene in Action (JUGEMレビュー »)
Erik Hatcher,Otis Gospodnetic,Mike McCandless
FastVectorHighlighterについて解説記事を寄稿しました。
+ RECOMMEND
+ SELECTED ENTRIES
+ RECENT COMMENTS
+ RECENT TRACKBACK
+ CATEGORIES
+ ARCHIVES
+ MOBILE
qrcode
+ SPONSORED LINKS