2017.12.15 Friday
スポンサーサイト
一定期間更新がないため広告を表示しています
| スポンサードリンク | - | | - | - |
関口宏司のLuceneブログOSS検索ライブラリのLuceneおよびそのサブプロジェクト(Solr/Tika/Mahoutなど)について
2009.12.31 Thursday
THIS IS IT
"THIS IS IT"といえばマイケル・ジャクソンの映画として有名だが、我々検索業界関係者の間では「ストップワードだけからなる文書」として2009年にたびたびとりあげられた格好のサンプルデータとなったものである。
ところで映画/DVDなどのタイトルには、このようにストップワードが重要な要素となっているものが少なくなく、単純にStopFilterを適用するわけにはいかない場合がある。そんなときはStopFilterをとりあえず適用しないという手もあるが、そうすると"the", "a", "it"などを含む文書は数が多く、そこから今度はユーザクエリのフレーズにマッチしない文書を取り除くのにコストがかかってしまう。 このような場合に便利なのがShingleFilterである。"shingle"とはワード単位のN-gramのことで、"THIS IS IT"に2-gramのShingleFilterを適用すると、"THIS IS", "IS IT"というトークンを出力してくれるため、単独のトークンよりもdocFreqが小さく抑えられ、性能を維持しつつタイトルを検索できるようになる。 2009.12.30 Wednesday
IndexableBinaryStringTools (2.9)
Luceneは当初からバイナリデータをインデックスに登録できたが、それは単にバイナリデータを出し入れするだけであり、バイナリデータを検索の対象にするものではなかった。
Lucene 2.9で追加されたIndexableBinaryStringToolsクラスを使うとバイナリデータ(byte[])をソートオーダーを維持したまま、インデックスに索引付けできるStringに変換できる。これにより、バイナリデータも検索できるようになった。もっともこのクラスが導入された動機は、ロケールに依存したトークンのソートを行うためにCollatorを使った場合、さらにソートの高速化のためにCollationKeyによって変換されたバイナリデータを索引付けしたいがためのものである。 関連JIRA: IndexableBinaryStringToolsクラスの導入 https://issues.apache.org/jira/browse/LUCENE-1434 トークンをCollationKeyで変換、IndexableBinaryStringToolsでエンコードするCollationKeyFilterの導入 https://issues.apache.org/jira/browse/LUCENE-1435 Lucene 2.9ではCollationKeyFilterはcontrib/collationの下にJDKのCollatorを使った実装と、ICUのものを使った実装が同居していたが、現在開発中のLucene 3.1ではJDKのものをLucene coreに移動し、ICUライブラリに依存する実装はcontrib/icuというディレクトリが新設されてそこに移動された。これにともない、contrib/collationディレクトリは廃止された: https://issues.apache.org/jira/browse/LUCENE-2124 このような背景のIndexableBinaryStringToolsではあるが、あえてバイナリデータを登録(索引付け)し、検索してみると、次のようなプログラムになる: public class TestIndexableBinaryStringTools { static Directory dir = new RAMDirectory(); static Analyzer analyzer = new WhitespaceAnalyzer(); public static void main(String[] args) throws IOException { makeIndex(); searchIndex(); } static void makeIndex() throws IOException { IndexWriter writer = new IndexWriter( dir, analyzer, true, MaxFieldLength.LIMITED ); for( int i = 0; i < 3; i++ ){ Document doc = new Document(); doc.add( new Field( "id", Integer.toString( i ), Store.YES, Index.ANALYZED ) ); doc.add( new Field( "data", bytes2String( new byte[]{ (byte)i } ), Store.YES, Index.NOT_ANALYZED ) ); writer.addDocument( doc ); } writer.close(); } static String bytes2String( byte[] data ){ CharBuffer charBuffer = IndexableBinaryStringTools.encode( ByteBuffer.wrap( data ) ); return new String( charBuffer.array() ); } static void searchIndex() throws IOException { IndexSearcher searcher = new IndexSearcher( dir ); Query query = new TermQuery( new Term( "data", bytes2String( new byte[]{ 2 }) ) ); TopDocs docs = searcher.search( query, 10 ); for( ScoreDoc scoreDoc : docs.scoreDocs ){ Document doc = searcher.doc( scoreDoc.doc ); System.out.println( "id = " + doc.get( "id" ) ); System.out.println( "data = " + string2Bytes( doc.get( "data" ) )[0] ); } searcher.close(); } static byte[] string2Bytes( String s ){ ByteBuffer byteBuffer = IndexableBinaryStringTools.decode( CharBuffer.wrap( s.toCharArray() ) ); return byteBuffer.array(); } } 2009.12.07 Monday
(検索)APIの後方互換性チェックテストコード
Luceneのテストコードは通常JUnitを使って書かれた単体テストになっているが、検索パッケージには"JustCompile"というファイル名で始まる「APIの後方互換性をチェックするためだけの実行されないテストコード」がある:
$ find . -name JustCompile¥*.java ./test/org/apache/lucene/search/function/JustCompileSearchSpans.java ./test/org/apache/lucene/search/JustCompileSearch.java ./test/org/apache/lucene/search/spans/JustCompileSearchSpans.java "JustCompile"テストコードはそれぞれのパッケージのpublicインタフェースおよび抽象クラスをimplementsまたはextendsした具象クラスを用意している。このしくみにより、将来、インタフェースに新しいメソッドや抽象クラスに新しい抽象メソッドがうっかり加えられると、コンパイルエラーになることで警告できるようにしている。 2009.12.04 Friday
クラウド化するSolr 1.5
SolrプロジェクトのリーダーYonik Seeley氏がSolr開発者メーリングリストの中で、「Solr 1.5はクラウド対応をしようぜ!」と宣言し盛り上がりを見せ始めている:
http://old.nabble.com/Solr-1.5---The-Cloud-Edition!-td26635459.html 以下に本日現在のSolrクラウド専用ページhttp://wiki.apache.org/solr/SolrCloudの拙訳を掲載する: ハイレベルな設計目標 SolrCloudの長期目標を示す。ここに掲げる特徴の多くは最初のバージョンから提供されるものではないが、長期的な目標を掲げて設計を行う。 高可用性と耐障害性 ロードバランサーを不要とする。単一障害点を排除する(つまり、後述のZooKeeperスキーマのようなしくみを最小限の変更だけであとからこの特徴を追加できるようなデザインを出発点としたい)。 クラスターのリサイズとリバランス クラスターを拡張したり、ホットスポットをリバランスさせるためにシャードはリサイズできなければならない。既存のシャードは分割したり新しいサーバを割り当てたりできる。 クライアントはクラスターのレイアウトを知らなくとも良いこと ブラウザのようなシンプルなクライアントはクラスター内のどのSolr検索サーバにもリクエストを送ることができる。そしてその検索サーバはクラスター全体に対して分散検索が実行できなくてはならない。これにはクライアントに結果を返すためのロードバランシングとフェイルオーバーも含む。 オープンなAPI ZooKeeperスキーマはマスターノード以外の他のソフトウェアコンポーネントからも、ZooKeeperを通じてクラスターを調査したり変更したりできるような設計がなされるべきである。他のSolrサーバと通信することなくZooKeeper内に正しいznode/ファイルを作成することで、新しいコレクションを作成するようなタスクを最終的に達成する。 いろいろなレベルのカスタムクラスターをサポート ユーザ管理とSolr管理の間の自由度を大きくする。ZooKeeper内の一組のサーバを定義されたインデックス(シャードまたは完全なコピー)とともに管理し、クライアントの検索用途だけに使うこともできるし、一方で昔ながらのマスター/スレーブ構成を使うことも可能とする。 ユーザ定義のパーティショニングをサポート 地理的、時間、ユーザ、・・・などにドキュメントを分割することにより、クラスタの一部だけを検索可能にすることで、検索性能を向上させることができる。これは高度なオペレーション(自動によるドキュメント=>シャード割り当て(おそらくユーザ定義のハッシュ関数により行われる)、インデックスリバランシング、単一障害点の排除など)によりもたらされる一例に過ぎない。 ZooKeeperでモデル化/登録したいエンティティ ホスト
ノード
コレクション
シャード
コア
ロール
ネットワークトポロジ
ZooKeeperスキーマ モデルと状態 ZooKeeperに含ませたい論理的に異なる2つのタイプのデータがある: 「モデル」:クラスタとシステムのゴール/ターゲットを表現する。 「状態」:それを包含するクラスタとシステムの現在の実際の状態を表現する。 マネージャはよく定義されたモデルの変更を作成できる。サーバはそのモデルに適合する場合に自身の状態を応答する。 複数のSolrクラスター 単一のSolrクラスターは既存のZooKeeperクラスターを利用できなければならない。そして複数のSolrクラスターは単一のZooKeeperクラスターと共存できなければならない。 ひとつのアイディア:ZooKeeperクラスターを指し任意のプレフィックスを含む設定URLを使えば簡単にできそう。 シャード識別 シャードを識別するための2つの方法が必要である。 将来的に複雑なクラスターの機能として、Solrは特定のドキュメントがどこにあるか知る必要がある。シャードに含まれるドキュメントはIDの範囲により特定される。ここでのIDとは、ユニークキーフィールドではなくなにかのハッシュコードやユーザ提供によるものとする。 ほとんどの基本的なケースでは、クラスターの外でインデックスを作ることになるだろう。この場合、我々はどのドキュメントがどのシャードにあるかを関知しない。しかし、ひとつのシャードが他のシャードの単純なレプリカであるという事実を識別する方法が我々には必要である。 レイアウト ZooKeeper内の仮想ファイルシステム(スキーマなど)がどのようなものかについてのブレインストーミング: mycluster/hosts * 192.168.0.10 # どのようにホストを識別するか?ホスト名?IP?ホストは1つ以上のIPを持つ。複数を扱うべきか? mycluster/configs/collection1_config/v1/ * solrconfig.xml, schema.xml, stopwords.txt,など。 collections/collection1/ * config=collection1_config # 複数のコレクションが同じ設定を利用できるよう明示する # コレクションは直接シャードのURLを指すべきか?(方法その1) /collections/collection1/shards * localhost:8983/solr/collection1=shardX,shardY,shardZ * localhost:7574/solr/collection1=shardX,shardZ # またはおそらくノードIDを単に指定する(このような形式:localhost:8983? localhost:8983/solr?) # そして"collection1"のようにしてコレクション名であることを暗黙の了解とする? # それはおそらくある制限をもたらしてしまう。フェデレーション検索をしたい場合どうなる? # コレクションに属するノードをリストアップする、各ノードが保持するシャード込みで?(方法その2) /collections/collection1/nodes/localhost:8983/ * shards/ # ノードlocalhost:8983が現在属するこのコレクションのシャード * X=/solr/collection1 # ノードIDからの関連URL * Y=/solr/collection1 * Z=/solr/collection1 # インデックス(シャード)のバージョン(最後のアップデート日時など)を記録できなければならない。 # 方法その3は各ノードをリストアップするシャードをノード自身のモデルに移動できる。 その他疑問点 コレクションごとに単一のマスター(クラスターマネージャのこと、Solrマスターではない)が存在するか、またはクラスター内のすべてのコレクションにひとつのマスターか? 参考文献 http://sourceforge.net/mailarchive/forum.php?forum_name=bailey-developers (関口:Baileyについては以前記事を書きました) http://www.allthingsdistributed.com/2007/10/amazons_dynamo.html |
+ 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 |