関口宏司のLuceneブログ

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

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

| スポンサードリンク | - | | - | - |
Ludiaパフォーマンスチューニングセミナー
先週の金曜日に「第1回 Ludiaパフォーマンスチューニングセミナー」に出席した。

http://d.hatena.ne.jp/ludia/20080326

定員10名のところ、私も含め4名の出席者であった。この内容で19,800円なのでもっと多くてもよいと思った。

有償のセミナーなのでここでそのテクニックを紹介するわけにはいかないが、PostgreSQLのチューニングをよく知らない人はもちろん、ある程度知っている人にもお勧めである。

チューニングというのは手探りでしていると自分が正しい道に進んでいるかわからないので、どこで止めていいのか判断できない。

しかしセミナーで「このような症状で遅いときは、EXPLAINでここを見る。XXXという理由で遅くなっているので、YYYパラメータをいじって解消できる」という理屈から教えてもらえるので、効率のよいチューニングができるようになる。

演習問題も7問もあり、それぞれ違った角度からのチューニング方法(パラメータ設定)を解説するものとなっていて、Ludia開発者には大変お勧めのセミナーであろう。

私にとってはどうだったかというと、ludia.max_n_sort_resultパラメータの意味を少し誤解していてこれを検索リクエストのセッションごとに正しく設定すると格段に速くなる、ということを学んだ。

これまではこのパラメータの意味を「order byをする前の結果セットの最大行数」であると解釈し、そのために200万件のレコードがあるなら200万とセットしなければ正しい検索結果を得られないと思い込んでいた。そうではなく、このパラメータには検索結果一覧表示に必要な件数をセットすればよい、と認識を正すことができた。

たとえば、検索結果ページに1〜10件目を表示する検索リクエストセッションでは:



demo=# set ludia.max_n_sort_result to 10;



とやれば十分である。このあとにselectの全文検索リクエストをスコアのorder byつきで実行すれば、スコア上位10件のものが取得できる。

さらに、11〜20件目を表示する検索リクエストセッションでは:



demo=# set ludia.max_n_sort_result to 20;



とする必要がある。そして「order by スコア offset 10 limit 10」で全文検索を実行する。

以上により、単純な検索では200万行でも同時100ユーザの負荷をかけて動作するようになった。この結果はいずれSolrとの比較資料として公開したいと思っている。=> 公開しました。

問題は、ファセットカウントの取得と絞り込み検索である。これは未だ速くなっていない。

ファセットカウントというのは、ユーザに絞り込み用のナビゲーションリンクを表示するときにリンクの脇に"()"をつけて絞り込み後の件数を表示するために使用される数値情報のことである。

ファセットカウントの例としては、このブログの検索メインページやその検索結果ページのリンクを参照していただきたい。ちなみにこれはSolrで実現しているものである。

さて、Ludiaではファセットカウントを取得するのに、私は次のように実行している:



demo=# select count(*) from auction_item where description @@ '*D+ 音楽 ビデオ' and price <= 9999;



これは「音楽 ビデオ」というキーワードを含むもののうち、価格帯が1円〜9999円のものの件数を取得しようとしているクエリである。この場合は、全文検索以外の条件が使われているため、カウントの取得に際してpgs2getnhits()は使用できない。

ちなみに、auction_itemテーブルは:



demo=# ¥d auction_item
Table "public.auction_item"
Column | Type | Modifiers
---------------+-----------------------------+-----------
auction_id | character varying(16) | not null
category_id | character varying(16) |
category_path | character varying(256) |
title | character varying(128) | not null
url | character varying(128) |
seller_id | character varying(24) |
image1_url | character varying(256) |
image2_url | character varying(256) |
image3_url | character varying(256) |
init_price | integer | not null
price | integer |
bids | integer |
start_time | timestamp without time zone |
end_time | timestamp without time zone |
description | character varying(8192) |
price_group | integer |
date_group | integer |
Indexes:
"auction_item_pkey" PRIMARY KEY, btree (auction_id)
"fidx" fulltext ((description::text))
"idx_date" btree (end_time)
"idx_date_group" btree (date_group)
"idx_price" btree (price)
"idx_price_group" btree (price_group)
demo=#



となっており、上記のクエリのEXPLAINの実行結果は:



demo=# explain select count(*) from auction_item where description @@ '*D+ 音楽 ビデオ' and price <= 9999;
QUERY PLAN

--------------------------------------------------------------------------------

Aggregate (cost=3760.76..3760.77 rows=1 width=0)
-> Bitmap Heap Scan on auction_item (cost=11.95..3758.76 rows=797 width=0)
Recheck Cond: ((description)::text @@ '*D+ 音楽 ビデオ'::text)
Filter: (price <= 9999)
-> Bitmap Index Scan on fidx (cost=0.00..11.75 rows=1000 width=0)
Index Cond: ((description)::text @@ '*D+ 音楽 ビデオ'::text)
(6 rows)
demo=#



となっている。

ファセットカウントを取得するときは、当然価格帯が1円〜9999円以外のものも必要となってくるので、前述のselect count(*)を必要なだけpriceの条件を変えながら複数回実行することが必要となってくる。負荷がけマシンから1ユーザでも大変重いクエリとなってしまった。

なお、複数回のselectを実行するときは、"SET TRANSACTION ISOLATION LEVEL SERIALIZABLE"を実行している。

ファセットカウントを取得する別の方法として、価格帯ごとに単純な数値を割り当て、別に作成したカラムにその数値をセットして、複数回のselect count(*)を実行する代わりにgroup byで一度に取得できるようにする、という方法がある。そうすると、次のように実行できる:



demo=# select price_group,count(*) from auction_item where description @@ '*D+ 音楽 ビデオ' group by price_group;
price_group | count
-------------+-------
5 | 338
1 | 122
4 | 235
3 | 282
2 | 390
(5 rows)
demo=#



このときのクエリプランは次のようになる:



demo=# explain select price_group,count(*) from auction_item where description @@ '*D+ 音楽 ビデオ' group by price_group;
QUERY PLAN

--------------------------------------------------------------------------------
-
HashAggregate (cost=3761.31..3761.33 rows=1 width=4)
-> Bitmap Heap Scan on auction_item (cost=12.00..3756.31 rows=1000 width=4)

Recheck Cond: ((description)::text @@ '*D+ 音楽 ビデオ'::text)
-> Bitmap Index Scan on fidx (cost=0.00..11.75 rows=1000 width=0)
Index Cond: ((description)::text @@ '*D+ 音楽 ビデオ'::text)
(5 rows)
demo=#



しかし、このgroup byの方法でも速くならなかった。PostgreSQLのプロンプトから使っている分にはそれほど遅く感じないが、負荷がけマシンから検索語を変えながら連続して実行すると、重さが際立ってくるのであった。

主なパラメータは次のようになっている:



demo=# select * from pgs2getoption();
-[ RECORD 1 ]------+--------
max_n_sort_result | 1000000
enable_seqscan | off
seqscan_flags | 1
sen_index_flags | 31
max_n_index_cache | 16
initial_n_segments | 512

demo=# show work_mem;
-[ RECORD 1 ]--
work_mem | 10MB

demo=# show shared_buffers;
-[ RECORD 1 ]--+-----
shared_buffers | 32MB

demo=#



Ludiaに詳しい方でもしも他にいじったほうがよさそうなパラメータやその他のチューニング箇所をご存知でしたら、コメントに書いていただけますと助かります。
| 関口宏司 | その他のOSS検索エンジン | 14:24 | comments(0) | trackbacks(0) |
リクルートのSolr事例発表@LinuxWorld Expo/Tokyo 2008
リクルートの中野さんと共同で「リクルートにおける検索エンジンSolrの活用」というタイトルで事例発表を行うことになった。

LinuxWorld Expo/Tokyo 2008 東京ビッグサイト
5月29日(木)A-25 14:00〜14:45
リクルートにおける検索エンジンSolrの活用
http://www.idg.co.jp/expo/lw/lw2008/details/index.html#a25

検索エンジン導入を検討中の方、商用検索エンジンからの乗換えを検討している企業、他のOSS検索エンジンを使用中で不満のある方も満足している方も、聴講すればきっと得るものがあるはず。事前登録へGO!
| 関口宏司 | Luceneセミナー | 10:39 | comments(0) | trackbacks(0) |
CHANGES.txtがChanges.htmlにチェンジ!?
Luceneリリースの変更履歴が記録されているファイルCHANGES.txtが(縦に)長くなってきて読みにくくなってきたという意見があり、読みやすくしたChanges.htmlファイルというのが提供されるようになった。

実際にはCHANGES.txtを読み込んでHTMLを生成するPerlスクリプトが提供されるようになった。

現在はSubversionからLuceneをダウンロードして、次のようにAntを実行してChanges.htmlを生成しなければならない:



$ ant changes-to-html



出力されたHTMLはCHANGES.txtの階層をなしている項目(大項目>中項目>小項目)の各タイトルがクリックできるようになっており、クリックするとその項目が折りたたまれたり展開されたりして、「今、変更履歴のどの辺を読んでいるか」というのが把握しやすくなっている。
| 関口宏司 | Luceneツール | 14:43 | comments(0) | trackbacks(1) |
「Lucene on WANDisco」でニュービジネス!?
昨晩David Richardsとビールをしこたま飲んだ。少し飲みすぎたため、もう夕方だというのにいまいち気分がすぐれない。

DavidはWANDiscoの社長で、飲み会のメンバーにはもうひとり、WANDisco(社名でもあり製品名でもある)を日本で展開する事業を行っているH3 Partners社の谷川さんがいた。谷川さんは私のBEA時代の同僚である。その後私がDavidが設立したInsevoという会社の日本事務所立ち上げ時にBEAを退職したとき、谷川さんが少し遅れてにInsevoのメンバーとなった。3人はそのとき以来の知り合いということになる。

Insevo当時、Davidはミーティングにはダイエットコークと水を必要とする小太りなCEOであった。DavidがInsevoの日本代理店を開拓するために来日すると、ダイエットコークなど日本では常備している会社などないので、私はパシリとなってダイエットコークを求め捜し歩いたことは2度くらいある。「今でも会議中にダイエットコークと水を飲むのか」と聞いたところ、もう飲んでいない、とのこと。改めて彼をよく見ると、少しスリムになったようだ。どうやらダイエットに成功したらしい。

WANDiscoは当初CVSのレポジトリを機能強化するミドルウェア的(?)な製品で、その後SubversionやJIRAなど対応できる製品が広がったもののようだ。WANDiscoを使えばレポジトリをグローバルに分散させたりローカルでクラスタリングを組んだりできるようである。日本ではAccess Controlのために導入を検討している企業があるらしい。私は詳しいわけではないので、WANDiscoのページを参照していただきたい。

最近WANDiscoはJIRAを開発しているAtlassianという会社とパートナーシップ契約を結んだ。JIRAといえばLuceneやSolrのトラッキングシステムとしていつもお世話になっているツールである。私はAtlassianは20代の若者数人で立ち上げたオーストラリアの会社で今では11,000もの顧客を持ち、100万ドルを1週間で売り上げることもある急成長中の会社ということを昨晩初めて知った(一部はDavidのブログにも書いてある)。Davidは今回日本に来る前にオーストラリアに寄ってきたとのこと。

Insevoのころに出会ったDavidは、会社を立ち上げては売り払い、別の新しい会社を立ち上げるという、あきっぽく落ち着かないやつ、という印象を勝手に持っていた。事実、私がInsevoに入社して最初にUSに出張したとき、会社が売却されるらしいと聞き、翌日には本当に買い手側のCEOがInsevoのオフィスに来て社員を集めて説明会を開いていた。私は寝耳に水でマスオさんのようにただ驚く以外に方法がなかった。WANDiscoはどうかというと「成長しているエキサイティングな会社で、これが自分の最後の会社だ」とのことである。

そんなWANDiscoは、Davidの住むSan Ramon(カリフォルニア)で彼の子供が通う小学校のPTAにて、Dr. Aahladと出会ったのがきっかけで生まれたという。そのPTAはITベンチャーのCEOやベンチャーキャピタルの社長やエンジェルや大学教授が集うものすごい集会であるらしい。そこでWANDiscoの基礎となっているDConEテクノロジーを発明したDr. Aahladと出会ってWANDiscoという製品と会社が生まれた。DConEテクノロジーは20ページもの数学で埋め尽くされた論文で説明されており、「WANDisco社では(Dr. Aahlad以外に)論文を理解しているものはいない」とのことだ。

「WANDiscoでLuceneインデックスをリプリケーションできるかもね」という話になり、技術的に可能であれば新しいビジネスに発展するかもしれない。

昨夜は5年ぶりの再会だったのだが、彼が待ち合わせに指定した場所はなんと浜松町の「ポケモンセンター」だった。私はよく知らなかったが、どうやらPOKEMONは海外でも人気らしく、David以外にも子供に持たされたのか、メモを持って右往左往する外人さんがたくさんいた。
| 関口宏司 | Luceneツール | 20:01 | comments(0) | trackbacks(0) |
NRI OpenStandia発行メルマガにコラム連載開始
NRI OpenStandiaグループが毎月発行するメルマガにLucene/Solr関連ののコラムを連載することになった。第1回は明日発行される。

こんにちは、はじめまして。(株)ロンウイットの関口と申します。弊社は、
OSSの全文検索エンジンLucene(ルシーン)と Solr(ソーラー)の導入コンサ
ルティングサービスやサポートサービスを企業向けに提供する会社として 2年
前に設立されました。今回NRI様よりコラム執筆の機会を頂戴しましたので、
数回に分けてLuceneとSolrの紹介をさせていただきます。

◇ なぜLucene/Solrなの? ◇
ところで、弊社はなぜLuceneやSolrを使ったサービスを提供しているのでしょ
うか。OSSの検索エンジンがいくつかある中でなぜLucene/Solrをお勧めしてい
るのでしょうか。 ロンウイットを設立する直前、私は米系CRM製品ベンダの日
本法人に勤務し、製品サポートを担当していました。ある日、米国本社が日本
市場からの撤退を決定し、サポート担当である私以外の全日本法人従業員を解
雇しました。元来のんびり屋の私は、一人残されるというこのめったに遭遇で
きない状況を楽しみましたが、さすがに3ヶ月が限度でした。日本のCRMユーザ
をサポートする日々を送りつつ、「このままではまずい!」という気持ちから
「次」を模索する作業が始まったのでした。2004年ころのことです。
(続きは明日発行されるNRIメルマガで!)

メルマガ購読のための登録方法は、現在専用フォームがないために、次のような手続きが必要なようだ:


メルマガ用登録フォームの作成に時間がかかるため、ブログ読者の方には下記のようにご案内いただければと思います。

1.OSSユーザコミュニティサイトにユーザ登録していただく
  http://openstandia.org
2.「ossc@nri.co.jp」にメルマガ希望のメールを送信いただく
| 関口宏司 | その他(分類不能) | 14:48 | comments(0) | trackbacks(0) |
Luceneバージョン間の互換性について
Luceneのバージョン間の後方互換性はそのバージョン番号を見るとわかるようになっている。

http://wiki.apache.org/lucene-java/BackwardsCompatibility

API

マイナーバージョンは常にAPIの完全な後方互換性があります。つまり、X.0を使って開発されたアプリケーションは変更なくすべてのX.Nリリースでも動作し続けます。

メジャーリリースは非互換のAPIが導入される可能性があります。移行計画は新しいAPIがリリースX.Nに導入され、そのときに古いAPIがdeprecatedになります。そしてリリースX+1.0が出た時点で全てのdeprecatedのAPIが削除されます。

インデックスファイルフォーマット

ファイルフォーマットはメジャーバージョン間で後方互換性があります。バージョンX.NはバージョンX-1.0を含むバージョンX-1の全リリースが生成したインデックスを読める必要があります。しかし、X-2.Nは読めない可能性があります。

注意:古いリリースは新しいリリースのLuceneが生成したインデックスを読めるとは保証できません。読めない場合はわかりやすいエラーメッセージが表示されます。

実行時動作の変更

ときどきLucene開発者は、既存のLuceneの実行時の振る舞いよりよりよいあるいはより正しいと考えられるときは、結果として実行時のデフォルト動作を変えてしまうような特定の不具合改修や機能強化を決定することがあります。これらの変更は古いバージョンの振る舞いに依存しているあるいは期待しているLuceneクライアントに対しての後方互換性を考慮しません。

もしリリースに実行時の振る舞いの変更がある場合はCHANGES.txtに明示されます。

もし実行時の振る舞いの変更がマイナーリリースに含まれる場合(X.NからX.N+1移行時に含まれる場合)、古い振る舞いを強制させる方法が2通りあります:

1.JVMシステムプロパティを用いる
2.staticメソッドの提供

Contribパッケージ

contribパッケージの互換性はパッケージごとの成熟度や利用目的により異なります。各contribはそれぞれのREADME.txtファイルで互換性に対するアプローチを明示すべきでしょう。もし互換性についての言及がない場合は、ユーザはあらゆる互換性について期待すべきではありません。
| 関口宏司 | Luceneリリース | 22:29 | comments(0) | trackbacks(0) |
EndecaやFASTを検討し、最終的にSolrに行き着いて満足した人
EndecaやFASTといった商用検索エンジンをはじめ多くの検索エンジンを検討し、最終的にSolrを採用して満足している人からのMLへの投稿:
http://www.nabble.com/Zappos%27s-new-Solr-Site-td16637873.html
| 関口宏司 | Luceneとは? | 09:50 | comments(0) | trackbacks(0) |
類義語検索とオントロジー
LuceneやSolrを使った類義語検索では類義語辞書が必要となるが、弊社がコンサルする場合、これは今のところ顧客自身に用意してもらっている。会社名など(「松下電器産業」と「パナソニック」など)汎用的なものもあるが、それよりも顧客の事業ドメイン独特の専門用語とその略語などをサポートすることが重要な場合が多く、広くカバーされた汎用的な類義語辞書が強く求められる場面にはあまり遭遇しない。企業内検索では社内・部内専門用語の略語で検索したとき、その用語の(略語ではなく)正式名称を含むWordファイルがヒットしてその部分がハイライトされようものなら、それだけで結構喜んでもらえるものだ。

類義語検索を発展させたものとして、オントロジーを使った検索というものがある。類義語辞書では登録された用語はフラットであるが、オントロジーでは用語の概念を考慮した階層構造を形成する。たとえば、「動物」「爬虫類」「哺乳類」「犬」「猫」という用語をオントロジー辞書に登録するとした場合、次のようになる:



動物
|
+------------------+
| |
哺乳類 爬虫類
|
+-------------+
| |
犬 猫



そうしておいて「犬」で検索されたときに適当な条件に符合した場合は「哺乳類」や「動物」などにキーワードを拡大して検索したり、場合によってはその兄弟の「猫」というキーワードを使って検索する、ということをおこなう。

オントロジーを使った検索はそれなりに可能性を感じさせるが、類義語辞書を作るよりもコストが高くなるのが難点だ。その割りに効果が定量的にわかりにくい(費用対効果がはっきりしない)。

類義語のソリューションはオントロジーほどエレガントではないものの、その効果は非常に大きい。

たとえば不動産屋のサイトで、「ペット可」「犬猫可」というような用語を含む賃貸物件の説明文が文書に含まれているとする。オントロジー辞書では「ペット」の下に「犬」と「猫」を配置することになるだろう。類義語ではもっと単純で:



ペット, 犬, 猫



と定義する。こうしておいて犬を飼える賃貸物件を探しているサイト訪問者が「犬」というキーワードで検索すると、「犬」の他「ペット」を含む物件が検索でき、「ペット」がハイライト表示される。もちろん、「猫」もハイライト表示されてしまうが、なにしろここは不動産屋の物件情報サイトだ。目くじらを立てて怒るユーザはいないだろう。これがペットショップのサイトや動物図鑑のサイトならまずいかもしれないが。しかしそもそもペットショップや動物図鑑サイトなら上記のような類義語定義はありえないだろう。

類義語機能は類義語を「展開」するだけでなく片方向にマッピングする「正規化」もある。こういった機能をうまく組み合わせれば案件ごとになんとか抜け道も見つけられるものだ。

類義語検索機能を導入することで、ユーザは似た用語を自分で捻出しながら何度も検索を繰り返すことなく探している文書にたどり着くことができるようになり、利便性が増してユーザのサイトへの信頼感を高める効果がある。まだ導入していないサイトは導入を検討してみるとよいだろう。
| 関口宏司 | その他(分類不能) | 15:11 | comments(7) | trackbacks(0) |
+ Solrによるブログ内検索
+ PROFILE
  12345
6789101112
13141516171819
20212223242526
27282930   
<< April 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