関口宏司のLuceneブログ

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

弊社は Apache Solr に関する教育/コンサルティング/サポートの各サービスを提供しているが、業務を通じてユーザーによる Solr の残念な使い方に遭遇することもたびたびある。ここではそれを「Solr あるある」と総称して紹介してみよう。なお、大抵の話は Apache Lucene にも当てはまるがここでは簡単に「Solr あるある」と記載することにする。



前方一致検索、中間一致検索

フィールド f1 が abc で始まるものを検索するのに q=f1:abc* としたり、abc がフィールド f1 内に現れるものを検索するのに q=f1:*abc* とするのは誤りである。一般的に前者は前方一致検索、後者は中間一致検索などと呼ばれるが、転置インデックス方式の検索エンジンでは検索対象の最小単位が単語となり、単語の完全一致が基本となる。したがって、「前方一致検索」「中間一致検索」というような概念がない。検索対象フィールドが単語の場合は完全一致検索となるし、2単語以上のフィールドであれば中間一致検索となる。したがって、中間一致検索(単語の完全一致)をしたいのであれば、q=f1:*abc* とはせずに q=f1:abc とすればよろしい。q=f1:*abc* で検索できているように見えているのは、いろいろなパターンが考えられるが、文字列解析の過程で * が落とされて結果的に abc という単語検索になっている、などが考えられる。


では前方一致はどうだろう。前方一致検索をしたい場合は、転置インデックスの作り方を工夫する。具体的には EdgeNGramTokenizer(場面によっては EdgeNGramTokenFilter)を使ってインデックスを作成する。これを使うと、abcdefg というフィールド文字列は次のように単語分割され、インデックスが作られる。


a ab abc abcd abcde abcdef abcdefg

このフィールドに対し、abc という文字列で前方一致検索をしたければ、クエリ側はトークナイズせず、つまり KeywordTokenizer を使って(場合によっては LowerCaseFilter を組み合わせてもよい。その場合はインデックス側にも適用する。以下同じ)次のように検索する。

q=f1:abc

単語の完全一致検索が基本の検索エンジンで従来型の「前方一致検索」「中間一致検索」をしたい場合、* を使う検索は Solr あるあるであるが、気持ちはわかるが間違いである。これは次で述べる後方一致検索でも同様である。



後方一致検索

同じく、フィールド値が abc で終わる文書を探すという意味を込めて後方一致検索をしたいというので q=f1:*abc というクエリを発行するのも Solr あるあるであるが、誤りである。Lucene の転置インデックスは単語がソートされた状態で格納されていることを利用して二分探索される。したがって、単語の末尾が一致しているかどうかを確認するには、転置インデックス上の単語を総なめしなければならなくなってしまう。そのため、高速検索を信条とするLuceneにはそのような検索は用意されていない(APIを使って総なめすることは可能)。では Lucene/Solr で後方一致検索はできないのかというとそんなことはなく、「文字列を逆転させて前方一致にする」というテクニックを使う。具体的にはインデックス側、クエリ側双方で ReverseStringFilter を適用する。


インデックス側では、KeywordTokenizer+ReverseStringFilter+EdgeNGramTokenFilter を用いる。すると、abcdefg という文字列は、次のようにインデックス中に展開される。


g gf gfe gfed gfedc gfedcb gfedcba

クエリ側は KeywordTokenizer+ReverseStringFilter を適用する。すると、efg という文字列の後方一致検索は、q=f1:efg と投げればよい。すると当該フィールドで文字列が逆転された上で検索されることで、gfe がヒットする。



ファセットによる絞り込み検索で fq を使わない

ファセットによる絞り込み検索で fq を使わず、q パラメータに AND で絞り込み条件を追加していくのもよく見る Solr あるあるであるが、これも誤りである。fq による検索結果の絞り込みも、AND 条件追加による検索の絞り込みも、返される文書集合は同じである。しかし文書の順番(ランキング)を見てみれば両者は異なることがわかる。メインのクエリ(q パラメータ)に AND で絞り込み条件を追加してしまうと、それはスコア計算の対象になってしまうので、AND を使う方法だと絞り込むたびにランキングが異なってしまう。つまりユーザーから見ると、ファセットのリンクをクリックするたびに文書の表示順が異なってしまう。これではユーザーが混乱するだろう。また、filterCache がうまく使われない、という別の問題もはらんでいる。


ファセットによる絞り込み検索では、AND を使わず fq を使う、と覚えておこう。



スコアによる足切り

「スコアが0.5未満の文書は足切りして返却されないようにしたい」などといった要望も Solr あるあるであるが、これもナンセンスであり、実施しようとして奮闘すること自体、時間の無駄である。


スコア関数のパラメーターはそれがベクトル空間モデルベースの TFIDFSimilarity であれ、確率モデルベースの BM25Similarity であれ、クエリと各文書である。スコアはクエリを固定したときに、各文書に付与される当該クエリとの関連度合いを表現したものであるから、クエリが変わってしまうと相互に比較することに意味がない。クエリ A でスコア 0.4 を獲得した文書がクエリ A に非常に関連しているが、クエリ B でスコア 0.6 を獲得した文書がクエリ B にたいして関連しているとは見えない、ということがおおいにありえる。



自前のハイライト

ハイライト機能(検索キーワードを含む文書スニペットを切り出し、キーワードを太字など目立つように表示する機能)について、Solr が持っているハイライト機能を使わずに、Webアプリケーション(JavaScript含む)でがんばってしまう、というのもたまに見る Solr あるあるである。Solr にハイライト機能があることを知らずに自前で実装してしまうパターン、Solrにハイライト機能があることは知っているが、自前の方がよいと信じて自前で実装してしまうパターンがあるようだ。前者は知らなかったということでお気の毒という他ない。後者は、なぜそのような発想になるのかよくわからない。Solr のハイライト機能はそれほどよくできている。自前で頑張る方式のメリットをあえて上げるならば、たとえば、サーバ側のCPU負荷を下げるため、ユーザーのブラウザにてJavaScriptでハイライトする場合、が考えられるかもしれない。しかしそのメリットの裏で、次の機能を備える Solr の非常によくできたハイライト機能を使わないデメリットをアプリケーションに実装してしまっていることに気づいているだろうか。


  • 検索キーワードがなるべく多く含まれる任意長のスニペットを、任意の個数得ることができる。Solr ではスニペットにもスコアがつけられ、スコアの高いスニペットから返される。同じ機能をアプリケーションで頑張ろうとすると、スニペットを作成するデータソースをすべて転送してこなければならない。その転送元は Solr かもしれないし、RDB かもしれないが、Solr のハイライト機能で作成したスニペットよりも大きなサイズになることが多く、ネットワーク負荷の原因となる。
  • Solr では表記揺れを考慮した検索が可能であるが、ハイライトでも同じ表記揺れを考慮した上でハイライト表示が可能である。アプリケーションで頑張る場合は、同じ表記揺れ対応をしなければ検索にヒットしてもハイライト表示ができない場合が出てきてしまう。また対応する表記揺れルールが変わった場合、Solr でやっていれば設定ファイルの変更で検索もハイライトもどちらも対応できてしまうが、アプリケーションで頑張る方式の場合は、Solr の設定変更がアプリケーションの方に影響してしまうため管理が煩雑になる。
  • Solr のスニペットは単語境界区切りなど、自然な単位でスニペット生成ができるようになっている。さらに、Solr では検索キーワードがフレーズの場合、フレーズが一致している場合のみハイライトさせたり、単語単独でハイライトさせたりといった細かな制御が可能である。同様のことをアプリケーションでやらせようとすれば、簡易であれNLP的機能をアプリケーションに持たせなければならない。
  • Solr ではスニペットが作れない場合の代替表示を指定することができる(大抵はハイライト表示しようとする当該フィールドの先頭100文字など)。

ということで、Solr のハイライト機能は検索アプリケーションのことをよく考慮して用意されており、大変よくできている。自前で用意するというのはたいていの場合誤っていると断言できる。


なお、検索結果一覧表示時にハイライトスニペットを作成せず、ユーザーのクリックにより当該文書表示時に検索キーワードを太字など目立つように表示する機能は、ここでいうハイライト機能とは異なる。ここでいうハイライト機能は、検索結果一覧表示時に、ユーザーに適切な文書をすばやく選択してもらうためのアシスト機能に相当する。ユーザーはハイライトスニペットを、文書をクリックするかどうかの参考にするため、Solr のハイライト機能はぜひ積極的に利用しよう(ただし、商品の写真を検索結果一覧に表示するようなECサイトの検索アプリのようなものは除く)。



ここで上げた以外にも、RDB の正規化されたテーブルをそのまま Solr のインデックススキーマにマッピングし Solr の JOIN を使うあるあるや、親子階層のファセットを自前で頑張るあるある、クエリを投げる際に常にダブルクォーテーションでくくってしまうあるあるなどもある。



Solr は OSS になって10年を超えるソフトウェアとなった。機能も十分豊富で、やりたいことの多くはすでに Solr が持っていることも多い。アプリケーションで頑張る前にぜひマニュアルや書籍等で該当する機能がないか、使い方がアーキテクチャに沿ったものになっているか、今一度考えてみることをお勧めしたい。



さて、今年はおそらく本記事が最後となるでしょう。更新頻度が少なくなったのにもかかわらず、本年もご愛読いただきありがとうございました。皆様、よいお年をお迎えください!

| 関口宏司 | Solr | 18:56 | comments(0) | trackbacks(0) |
Heliosearch/Solrオフヒープフィルタ

筆者のYonikの許可を得て翻訳した。原文はこちら

Solrのパフォーマンスを一段高めるHeliosearchという新しいオープンソースプロジェクトに真っ先に追加された機能がオフヒープNativeフィルタだ。

大容量JVMヒープの潜在的問題

JVMは大きいヒープの処理が決してうまくなかった。ヒープが大きいとガーベッジコレクション作業が難しくなり、GCポーズによって長時間システムが停止し、ほかの処理が一切できなくなる場合も多い。そのためクエリ/リクエストタイムアウトが発生したり、SolrCloudモードでzookeeperセッションのタイムアウトまでも発生する可能性がある。

オフヒープフィルタ

非常に高度なフィルタキャッシング機能を用意しているHeliosearch/Solrだが、アプリケーションによっては膨大なメモリを使用する可能性がある。大きく存続期間の長いオブジェクトの方が、JVMヒープから取り出して明示的に管理するメリットを得られる。オフヒープメモリはガーベッジコレクタから見えないのだ。

Heliosearchフィルタ(Solr DocSetオブジェクト)はオフヒープでアロケートされるようになっており、不要になればすぐに解放できるよう参照がカウントされるようになった。また、JVM GCはこのようなメモリブロックのコピー処理で時間を無駄にする必要がなくなった。このことはGCの長時間ポーズを排除し、リクエストスループットを改善するのに役立っている。

テスト設定

各方面から報告のあった長時間のGCポーズを再現するにはかなりいろいろなことを試す必要があると考えていたが、何と1回目でいきなりこれが再現されてしまった。ヒープサイズは報告のように大きなものではなく現状は小さく収まっている。ヒープが大きいとGCポーズも延びるようだ。

テストの詳細

  • Ubuntu Linuxサーバ(RAM 8Gバイト、CPU 4コア、Java 1.7 64ビット)
  • クライアント:8スレッドそれぞれが1つのIDのクエリを任意のフィルタ(500種類)で処理
  • filterCache:size=1000(すべてのフィルタをエビクションせず保持するのに十分な大きさ)
  • インデックス:3.8Gバイト、5000万件

Apache Solrコマンドライン:

$ java -jar -Xmx4G start.jar
Heliosearch/Solrコマンドライン:
$ java -jar start.jar

Apache Solr実行時はOOM例外を回避するためにヒープサイズを4Gバイトに設定する必要があった。搭載可能なRAMは最大8Gだったため、残りのメモリはインデックスファイルのキャッシング用としてOSに残しておきたかった(そうしないと速度が大幅に落ちてしまう)。

GCの結果

2万クエリリクエストを行ったGCの実行結果を以下のグラフに示す。 グレーの棒はGCに要した時間、赤線はヒープの実サイズ、そして青線はヒープの実使用量を示している。

Solr

Solrでの長時間ポーズをテスト中に外から見るのはさらに容易だった。ログが有効になっていたためリクエストがすべてログメッセージを残し、ターミナルでは高速スクロールが発生した。そして、GCの大規模なコンパクションが発生するとターミナルのスクロールは突然停止した。 hs_140120-solr_gc.png

Heliosearch

ガーベッジコレクションの処理が短時間ですむためにHeliosearch GCグラフの方が完了は早い。長時間の完全なGCポーズがほとんど発生しておらず、ほかのGCポーズも大幅に減少していることに注目したい。 hs_140120-heliosearch_gc.png

クエリの待ち時間

このグラフは、2万クエリを実行したときの後半の1万クエリ(ホットスポットとキャッシュが落ち着いたタイミングを見計らうため)の待ち時間をパーセントで示している。
hs_140120-query_latency.png

Query Throughput

hs_140120-query_throughput.png
Query Throughputグラフはオフヒープデータ構造によって解放できるガーベッジコレクションに必要なCPU処理時間を示している。もちろん、これは極端な結果だ。大量のガーベッジコレクションが頻繁に発生している場合はデータ構造をオフヒープにすることで実現するスループット向上の方が適当だろう。

メモリ使用量

プロセス(トップ経由で外部から監視)の常駐メモリ最大使用量は5回にわたって計測した。

Apache SolrHeliosearch
最小3.8GB3.6GB
最大4.3GB3.7GB
オフヒープフィルタを用意するHeliosearchの方がメモリプロファイルが安定し、メモリ使用量も平均的に少なかった。そのため、OSがインデックスファイルをキャッシュするための空きメモリも増えるが、これは高いパフォーマンスを実現するためにきわめて重要なことだ。

結論

今回の簡単なテストにより、オフヒープフィルタが大きな異常値を減らして全体のクエリスループットを高め、長時間のGCポーズを排除してリクエストの予測を容易にすることが判明した。

ご自身でお試しいただきHeliosearchForumで感想をお聞かせいただきたい。



SolrMahoutのトレーニングコース、ただいま2月の受講者を募集中です!

| 関口宏司 | Solr | 12:42 | comments(0) | trackbacks(0) |
Solr新機能:ツッコミ検索とは?
最近はこちらのブログ投稿がご無沙汰である。なぜならJAISTに入学し、Twitterも始めたせいもある。

Twitterは長い文章を考えなくていいから楽だ。しかし、これから述べようと思っているまとまった文章などは量的にTwitterでは無理なので、必然的にブログということになる。何を述べるかというと、最近いわゆる「もしかして検索」という機能を実装し、そこでいろいろ思い巡らせたことについてである。もしかして検索というのは、ユーザがたとえば「パートな湿布」というキーボードを打ち損じた(または変換し損ねた)キーワードで検索したときに、検索結果画面で「もしかして:パートナーシップ」などと正解と思われるキーワードを表示する機能である。そしてただ単に正解と思われるキーワードを表示するだけではなくて、キーワードにリンクを貼って、もしそれが本当に正解キーワードであったならユーザがクリックするだけで正解キーワードですぐさま再検索できるようにする、大変優れた機能である:

[プレスリリース] パートな湿布?いいえ、パートナーシップでした 。〜もしかして検索が可能なSolrサブスクリプションの新版を発表

(詳細記事)日本語「もしかして」検索について

ところで「もしかして検索」というのはGoogleで表示される文言「もしかして○○」からとって命名したものであるが、(上記2つめの記事にもあるように)Yahoo!では「○○ではありませんか?」となり、もしこちらから命名するとなると「ではありませんか?検索」となる。ただ、私の記憶が正しければ、この種の機能はGoogleが早かったような気がするので、以降ではGoogleに敬意を表して「もしかして検索」あるいは省略して「もしかして」と呼ぶことにする。

そして私がまず気がつくのは、Googleの姿勢の低さだ。あのGoogleが「もしかして」である。本当はかなりの確信を持ってリンクを提示しているはずなのだが、あくまでも低姿勢に「もしかして」である。しかし、低姿勢さはYahoo!も負けてはいない。「ではありませんか?」だ。「もしかして」よりも謙虚さを感じる。そこまで自信がないのなら提示しなければいいのに、あくまでもYahoo!はいうのだった。「ではありませんか?」と。

しかし、両社の低姿勢ぶりは私は実はうなずけるところでもある。なぜならこれは確率の問題だからだ(最近私は確率の勉強をしているのだった)。なので絶対ということはなく、「もしかして」ということになる。やろうと思えばおそらく、「何パーセントの確率で○○です」と提示できるはずである。

ロンウイットのもしかしての方法はどうかというと、確率ではなくSolrのSpellCheckComponentを使っているので、もう少し原始的だ。しかしインデックス内の正解データを使っているので、こちらも高い精度が得られている。しかし私も日頃から謙虚でありたいと考える人間であり、ロンウイットはGoogleやYahoo!の足元にも及ばない会社なので、検索結果画面に表示する文言は両社よりももっと謙虚であってしかるべきである。

たとえば、こんなのはどうだろう:

「まちがってたら申し訳ないんですが、ひょっとしたら○○ではありませんか」

相当自信がなさそうなのだった。これくらいであればもし間違っていたとしてもユーザから文句は出ないだろう。しかし、これでもまだ心配な場合は、どうすればいいか。

究極の方法は「あえて何も言わない」だ。ユーザが間違ったキーワードで検索を行う。しかし、こちらも絶対の自信がないのであえて何も言わない。つまりこうだ:

「・・・・・・」

するとユーザは検索結果一覧画面を見て、自らキーワードの打ち損じに気がつく。そして今度は落ち着いて正しいキーワードで検索し直すだろう。すると、Solrはようやく先ほどの自身がはじきだした正解キーワードと、ユーザが2回目に入れた正しいキーワードが等しいことを確認し、100%の確信を持って今度こそ検索結果画面に次のような文言を表示するのだった:

「ですよね〜。私もそう思ったんですけど、違うかもしれないので黙ってたんですけど、やっぱり打ち損じでしたね〜」

しかしこれでは意味がわからないし、CPUの無駄遣いであり、ユーザから別の文句も出そうだ。

逆はどうだろう。ロンウイットはこれでも一応ベンチャーの気概を忘れてはいない。そこであえて100%、いや、120%の確信を持って正解と思われるキーワードを提示したいと考えるのだった。つまりこうだ:

「○○だろ!」

相当な自信がうかがえる。間違っていたとしても、この勢いがあればユーザはクリックしてしまうのではないか。また私は別のことにも気がついたのだった。これはある意味、ユーザのボケ(キーワードの打ち損じ)に対するSolrのツッコミといってもよいだろう。私はこれを「ツッコミ検索」と呼ぶことにしたい。はずれても笑いがとれればそれでいい。日本のお笑いの精神がそこには垣間見えるのだった。

しかし、まじめな話、デモデータ(歴代の内閣総理大臣の所信表明演説のテキストデータを利用)を使った次の実例を見れば、相当イイセンいっていると、読者は納得してくれるに違いない:

ボケツッコミ
笑止高齢化「少子高齢化」だろ!
いんたーねっt「インターネット」だろ!
しゃ皆保険「社会保険」だろ!
滑稽銀「国会議員」だろ!
partner湿布「パートナーシップ」だろ!
滅入るマガジン リーマン「メールマガジン サラリーマン」だろ!


日本の検索にもっと笑いを。ガンバレ日本!なんかわからないがオリンピックイヤーなので言ってみた。7期目に突入したロンウイットを、相変わらずこんな感じではありますが、今後ともどうぞよろしくお願い申し上げます。



元ヤフー社員も大満足のロンウイットのSolrトレーニング・・・受講者インタビュー記事
Solr 3.6 6月 トレーニング受講者募集中

| 関口宏司 | Solr | 02:12 | comments(0) | trackbacks(0) |
soleami - Apache Solr のクエリログ可視化サービス
soleami (ソレミ)というSolrのクエリログを可視化するサービスを開始した。

soleami.com

soleamiという名前は、近所の本屋の辞書コーナーを2時間ほどうろついてひねり出したものである。由来はフランス語の“ami du soleil”(太陽の友人)からとった造語である。Solrはいうまでもなくソーラーパネルやソーラーシステムのソーラー、つまり太陽から来ている(Solrのロゴも太陽を模している)。その友達のように常にそばに置いて使ってもらいたい、というところから命名した。ちなみに、"soleil"(ソレイユ)のところは日本でも「シルク・ドゥ・ソレイユ」という名前が有名だ。

なぜフランス語かというと、ロンウイットもフランス語だからだ。ロンウイットはうちの近所の丸八通りから、「丸」も「八」も縁起がいいのでとってきたものであり、「ロン(丸)」「ウイット(八)」である。じゃあなぜロンウイットはフランス語なのか、というのは聞かないで欲しい。こちらも本屋の辞書コーナーを3時間くらいうろついて命名したと思う。あれは今から6年前のことであった。3時間うろつく前には3週間くらい悩んだ記憶がある。苦しんだ様子は以下のスライドに詳しい。

プレ・ロンウイット・ネーミング・ストーリー



さてsoleamiであるが、これはSolrのクエリログを可視化するサービスである。TomcatにSolrをデプロイして運用しているサイトがほとんどだと思うが、Tomcatが出力するcatalina.outファイルをsoleamiにアップロードするだけで検索キーワードのトレンド(季節変動など)やいわゆる「0件ヒット」の発生をビジュアルにみることができる。

世の中Hadoopを使ってアクセスログ(クリックログ)を解析するのがはやっているが、一方でクエリログは置き去りにされていないだろうか。クエリログは検索システムのユーザ(サイト訪問者)のニーズのリストともいえ、サイト管理者・運営会社の立場からみれば、ぜひ分析してサイトの改善に役立てるべきデータである。

しかし大手の会社でもなければ、なかなかクエリログを分析するまで手が回らないのが実情だ。たとえばcatalina.outをExcelやawk/sedなどで処理しようとしても結構大変である。結局、catalina.outはディスク容量を圧迫するので、保存期間を過ぎると捨てられてしまう。これは非常にもったいない話ではないだろうか。

また大手の会社でもアクセスログの解析で手一杯で、クエリログまではまだまだ、というところも多い。またクエリログとなるとどこから手をつけていいかわからない、という意見もある。そういうときは、soleamiに過去(12ヶ月前までさかのぼって可視化できる)から現在のクエリログをアップロードし、おおよその見当をつけるといいだろう。 季節変動を示す検索キーワードを見つけたり、何度も「0件ヒット」を起こしているクエリを特定し、サイトの改善に役立てることができるし、自社でHadoopなどでさらに深掘りして分析する際の方向性のあたりをつけることができる。

Tomcat上でSolrをすでに運用しているサイトはcatalina.outファイルがTomcatのlogsディレクトリにできているだろう。これをsoleamiにアップロードするだけでチャートが表示できる。

soleami-chart-TOP10

soleami-list-TREND1000

TomcatもSolrでさえもまだ・・・という方は、以下の記事でTomcatとSolrをダウンロードする最初のところから解説しているので、読んでクエリログを大いに活用していただきたい。

soleami (ソレミ)の使い方〜Solrの立ち上げからログの可視化まで〜
http://www.rondhuit.com/soleami-howto.html



あの米Clouderaディレクターも参加したロンウイットのSolrトレーニング・・・受講者インタビュー記事
Solr 3.5 3月 トレーニング受講者募集中

| 関口宏司 | Solr | 01:22 | comments(0) | trackbacks(0) |
SOLR-2911
Packt社より書籍 Apache Solr 3 Enterprise Search Server が出版され、著者が現在Solrのホームページに掲載されている以前同社より出版された同じ著者の1.4の本のリンクを新しくして欲しいと、チケットSOLR-2911をオープンした。

それによると、「リンクを新しくしてくれたら、Packt社は売り上げの5%をApache Software Foundationへ寄付する」と書かれており、面白い提案だなあと感心した。
| 関口宏司 | Solr | 08:52 | comments(1) | trackbacks(0) |
言語判別機能の追加 (Solr 3.5)
次期Solrバージョン3.5には、言語判別機能が追加される予定である。言語判別機能は、インデックス作成時に呼び出され、あるフィールドが何語で書かれているかを自動判別する機能である。

https://issues.apache.org/jira/browse/SOLR-1979

これにより各ドキュメント/フィールド毎に最適なテキスト解析が行えるようになる。日本語以外のドキュメントを多く扱う企業、たとえばグローバルに事業展開を行っている企業の社内検索等に威力を発揮するだろう。

上記のSOLR-1979では言語判別機能としてApache Tikaの機能を使用している。これよりもサポートしている言語数と判別精度がよさそうな、サイボウズshuyoさん作の言語判別をとりこもうという提案がすでに追加でなされている。

language-detection
http://code.google.com/p/language-detection/

add alternative language detection impl
https://issues.apache.org/jira/browse/SOLR-2839

こちらもSolr 3.5におそらく入るのではないかと思われる。
| 関口宏司 | Solr | 12:26 | comments(1) | trackbacks(0) |
関数クエリとソートの面白い組み合わせ
Solr本にも掲載されているQueryElevationComponentは、特定のクエリに反応して特定のドキュメントのランキングを意図的に上位表示することができるが、これは上位表示したいドキュメントのユニークキーをソートで強制的に上位表示することで実現している。

似たような要件で、ある特定のキーワードとの関連度でソートを行い、その後ユーザクエリとの関連度でランキング(ソート)を行いたい場合、つまり:

sort=ある特定のキーワードとの関連度 desc,score desc


としたい。この場合は、QueryElevationComponentは使えない(ある特定のキーワードとの関連度ではないため)が、Solr 3.1から可能になった関数クエリによるソートを使って次のようにすれば可能である:

sort=query({!lucene v='text:solr'}) desc,score desc


query()関数は通常クエリのスコアを返すので、まずそれでソートを行い、次いで通常のスコア値によるソートを行っている。

メーリングリストより引用

関数クエリでお困りでしたら・・・Solr 3.3 9月 トレーニング受講者募集中

Solr トレーニングコースパンフレットダウンロードはこちら
| 関口宏司 | Solr | 11:37 | comments(0) | trackbacks(0) |
Solr SearchComponentの分散検索対応状況
SearchComponent略称対応状況
Query対応
Facet対応(範囲ファセットは3.6/4.0から対応)
MLT未対応
Highlight対応
Stats対応
Debug対応
SpellCheck3.1から対応
Terms3.1から対応
QueryElevation対応
TermVector対応
Clustering3.1から対応
| 関口宏司 | Solr | 00:03 | comments(0) | trackbacks(0) |
Solr runs on Jailbroken iPad
http://imgur.com/tHRh3
| 関口宏司 | Solr | 08:09 | comments(0) | trackbacks(0) |
Solrユーザ sourceforge.net
sourceforge.netはファセット検索でSolrを活用:

http://sourceforge.net/
| 関口宏司 | Solr | 00:16 | comments(0) | trackbacks(0) |
+ Solrによるブログ内検索
+ PROFILE
    123
45678910
11121314151617
18192021222324
25262728   
<< February 2018 >>
+ 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