Kouhei Sutou
kou****@clear*****
2010年 11月 17日 (水) 11:59:25 JST
須藤です。 In <16757****@nifty*****> "Re: [groonga-dev,00402] Re: rroonga を使って、リモートの groonga を利用する方法について" on Wed, 17 Nov 2010 00:40:18 +0900 (JST), yfa02****@nifty***** wrote: >> そうですよね、したいですよね。。。 > > な、、なるほど。。そうでしたか。。 > プロダクションで利用する際は、複数サーバー構成が前提になってくるので、 > リモートアクセスをしたいなと考えておりました。 はい、妥当だと思います。 いくつかgroongaベースで運用している検索サービスがあるのですが、 そこでもgroongaサーバをたてて、Webインターフェイスからは groongaサーバにHTTPやgqtp（groonga独自プロトコル）でアクセス して検索するような構成になっています。 >> なのですが、現在はselectコマンド(*)のみを実験的にサポートし >> ている段階です。 >> groonga_context.select("users", >> :match_columns => "name", >> :query => "taro", >> :limit => 10) > > ありがとうございます。 > なるほど、でも、ある意味この方が直感的でわかりやすい気もしてきました。 > 明日、早速試してみたいと思います。 まだAPIが固まっていないので、使ってみて気になるところがあっ たら教えてもらえるとうれしいです！ > となると、indexerなどの更新クエリはローカルで実施するか、 > send、receiveを生で利用するかな感じでしょうか。 小さなものだとselectの--filterで更新するのがよいと思います。 （フラグの値を変更するなど） 例えば、有効期限が切れたユーザを無効にするならこんな感じのコ マンドを実行します。 （注意: 試していないのでsyntax errorになるかもしれません！） select users --filter 'expire_date <= "2010-11-17 11:16:00"' --scorer 'enabled = false' あと、キャッシュ絡みのことも考えると上記のような方法で更新し た方がよいです。groongaサーバはselectの結果をキャッシュしてい るのですが、--scorerを使うと古いキャッシュを無効にしてくれま す。 しかし、大量のデータを追加するなどの場合はサーバ経由ではなく、 ローカルで実施するのがよいと思います。これは速度の問題です。 ローカルで実施する場合は以下の2種類のどちらかを選ぶのが現実 的だと思います。 1. rroongaが提供するAPI（groongaでいうDB API）を使って ローカルのデータベースに更新する 2. 追加・更新したいデータをJSONに変換してloadコマンドで読 み込む 複雑な処理（他のカラムの値を見ながら新しい値を計算するなど） がある場合は1.がよいと思います。そうでない場合は2.がよいと思 います。ただし、1.の場合は前述のキャッシュに不整合が起こる問 題があります。rroongaにはまだ古いキャッシュを無効にする機能 がないので、1.が終わった後に load '[]' users などとして古いキャッシュを無効にする必要があります。 > そういう意味ですと、もしかしたら自分的にはQL APIの記述方法の方が > 直感的でわかりやすいので、もしかしたら上述のselectコマンド経由で > 利用するのも悪くないかもせん。 gqtpでQL APIを利用する場合はgroongaのgqtp通信機能を使わないと いけない（独自で実装してもいいけど面倒）のですが、HTTPで利用 する場合はgroongaの機能は必要はなく、一般的なHTTPクライアン トの機能だけが必要となります。なので、rroongaとは別にgroonga に依存しないライブラリを作る方がいいのかも、と思っていたりし ます。 （groongaのHTTPインターフェイス専用ライブラリでrroongaに依存 しない。HTTPクライアントライブラリのラッパーみたいなイメー ジ。） > ところで、 > > http://groonga.rubyforge.org/groonga/text/TUTORIAL_ja_rdoc.html > http://groonga.rubyforge.org/rroonga/text/TUTORIAL_ja_rdoc.html > > の2つのページがありますが、 > Ruby/groongaとrroongaの二種類があるのでしょうか？ あ、Ruby/groongaはrroongaに名前が変わったのです。 /groonga/に行ったら/rroonga/へリダイレクトするようにしました。 > #ラングバ、ぐるんが、るるんが、らくんがとたまに混乱します（笑） そうだと思います！ 「全文検索エンジンgroongaを囲む夕べ #1」(*)の時までには、そ こらへんをまとめたものを用意したいと思っています。 (*) http://atnd.org/events/9234 -- 須藤 功平 <kou****@clear*****> 株式会社クリアコード <http://www.clear-code.com/> (03-6231-7270) プログラミングが好きなソフトウェア開発者を募集中: http://www.clear-code.com/recruitment/ In <16757****@nifty*****> "Re: [groonga-dev,00402] Re: rroonga を使って、リモートの groonga を利用する方法について" on Wed, 17 Nov 2010 00:40:18 +0900 (JST), yfa02****@nifty***** wrote: > さとうです > > お返事いただきありがとうございました。 > >> そうですよね、したいですよね。。。 > > な、、なるほど。。そうでしたか。。 > プロダクションで利用する際は、複数サーバー構成が前提になってくるので、 > リモートアクセスをしたいなと考えておりました。 > > >> なのですが、現在はselectコマンド(*)のみを実験的にサポートし >> ている段階です。 >> groonga_context.select("users", >> :match_columns => "name", >> :query => "taro", >> :limit => 10) > > ありがとうございます。 > なるほど、でも、ある意味この方が直感的でわかりやすい気もしてきました。 > 明日、早速試してみたいと思います。 > > > となると、indexerなどの更新クエリはローカルで実施するか、 > send、receiveを生で利用するかな感じでしょうか。 > > >> 余談ですが、背景を少し説明しておきます。 > > あ、なるほど、このメールを読んだ後に、READMEを読み直してようやく理解が深まりま > した。 > rroongaのAPIはDB-APIなのですね。 > > 本家groongaのチュートリアルに書いてるクエリの説明、記述方式と > ちょっと違うかな？？と違和感を感じていた理由がようやくわかりました。 > > そういう意味ですと、もしかしたら自分的にはQL APIの記述方法の方が > 直感的でわかりやすいので、もしかしたら上述のselectコマンド経由で > 利用するのも悪くないかもせん。 > > > とはいえ、更新系の処理も行わなければいけないので、 > そのあたりを含めて、もう少し検討をしてみたいと思います。 > > お忙しいところありがとうございました。 > 大変助かりました。 > > ところで、 > > http://groonga.rubyforge.org/groonga/text/TUTORIAL_ja_rdoc.html > http://groonga.rubyforge.org/rroonga/text/TUTORIAL_ja_rdoc.html > > の2つのページがありますが、 > Ruby/groongaとrroongaの二種類があるのでしょうか？ > > #ラングバ、ぐるんが、るるんが、らくんがとたまに混乱します（笑） >
