2017.12.15 Friday
スポンサーサイト
一定期間更新がないため広告を表示しています
| スポンサードリンク | - | | - | - |
関口宏司のLuceneブログOSS検索ライブラリのLuceneおよびそのサブプロジェクト(Solr/Tika/Mahoutなど)について
2008.10.14 Tuesday
(アイディア)逆ページランク
経済アナリスト 森永 卓郎氏のコラム「役所のマインドコントロールから脱け出せ!」を読んだ。これによると財務省のホームページでは、同省の都合の悪い記述は脚注などで小さい文字で表示されているらしい。
そこで思いついたのがタイトルのアイディアだ。私はかねてより官公庁や自治体などのホームページを横断検索するデモを作りたいと思って(2年以上経つがなかなか着手できないでいるのだが、それはこの際どうでもよい)いる。そのサイトで「小さい文字ほど重要である」「階層が深いほど重要である」「被リンクが少ないほど重要である」とみなす、その名も「逆ページランク」というのを実装してみてはどうだろう。 官公庁のホームページでは国民に知らせたくない重要な情報ほど文字を小さくしているようなので、この冗談のようなアイディアは案外いいセン行くのではないか。 この方法によると、<H1>よりも<H4>が、<B>よりも通常文字列が、通常文字列よりも<font size="-1">がより国民にとって重要になってくるのであり、高いスコアを与えて検索結果の上位にランキングさせるのである。なんじゃそりゃ。 2008.10.12 Sunday
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 2008.10.09 Thursday
突然の電源断にも壊れないLuceneのインデックス(2.4)
まもなくリリースされるLucene 2.4では、インデックスの書き込み中における突然の電源断やOSのクラッシュにもインデックスが壊れないことが保証される(新しいインデックスを作成しきるか、もしくは失敗して古いインデックスが残るようになる)。
インデックス作成中のクラッシュの単体テストコードもある。テストの仕方は次のとおり:
2008.10.07 Tuesday
IndexMergeTool
IndexMergeToolはディスク上の複数のLuceneインデックスをマージして1つの新しいインデックスを作成するコマンドラインツールである。contrib/miscellaneous/にあるIndexMergeToolは実質20行程度の短いプログラムで、addIndexes()メソッドの使い方の簡単なサンプルにもなっている:
もっとも現在(まだでていないLucene 2.4)は、addIndexes()ではなく、addIndexesNoOptimize()の利用が推奨されている。 2008.10.06 Monday
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に移動しましょう、という提案がされている。 2008.10.03 Friday
Solrにできて、Googleでできないこと
前回の記事は、読みようによっては、「Solrでできることは、すべてGoogleでもできる」ととられてしまう可能性もあるので、ここで「Googleではできないが、Solrでできること」もある、ということを具体例で示しておこう。
ここでいうGoogleはGoogleアプライアンスをとりあげる。Googleアプライアンスはブラックボックスであるがゆえに楽なことも多いが、インテグレータにとってはカスタマイズできない箱だということが、使用経験のあるインテグレータの間では有名な話だ。よって、Lucene/Solrで得意とするところの検索結果のランキングのカスタマイズが、Googleを採用すると一切できない。 OSS検索エンジンであるLucene/Solrはいろいろなプラグインが可能であり、ランキングのカスタマイズは「Googleでできないが、Solrでできる」ことの一例である。 2008.10.02 Thursday
分散検索: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では1,000件以上先(正確には1,001件以上先?/2008年10月現在)の「検索結果一覧」を要求されても表示しないのだった。これは知りませんでした。 まあ、考えてみれば当然だ。Googleの分散検索のシーケンスはSolrと同じなので(というか、事実はSolrがGoogleのシーケンスをまねているので)Googleでも、検索結果一覧の開始オフセットが大きい場合は処理負荷が相当大きくなるため、開始オフセットが大きい検索リクエストには応じない、という選択をしているのだった。 「じゃあ、我々もせいぜい数万件表示すればいっか」「Googleができないんだから」というところに落ち着いた。 「Googleができないんだから」というセリフは、思えば私は月に1回くらい使っているかもしれない。お客さんも「Googleができないんだったらしょうがないね」と納得してくれる。「GoogleができなくてもSolrではやってくれるよね」というお客さんにはいまだに出会っていない。 「Googleができないんだから」は魔法の言葉だ。私は今日からこれを「Google免罪符」と呼ぶことにしよう。 |
+ Solrによるブログ内検索
+ PROFILE
+ LINKS
+ Lucene&Solrデモ
+ ThinkIT記事
+ RECOMMEND
+ RECOMMEND
Lucene in Action (JUGEMレビュー »)
Erik Hatcher,Otis Gospodnetic,Mike McCandless FastVectorHighlighterについて解説記事を寄稿しました。
+ RECOMMEND
+ SELECTED ENTRIES
+ RECENT COMMENTS
+ RECENT TRACKBACK
+ CATEGORIES
+ ARCHIVES
+ MOBILE
+ SPONSORED LINKS
|
(C) 2024 ブログ JUGEM Some Rights Reserved.
|
PAGE TOP |