T

全文検索エンジンgroongaを囲む夕べ 3 @groonga

というわけで「全文検索エンジンgroongaを囲む夕べ 3 @groonga」に参加してきました。毎年「いい肉の日」に合わせて開催されるイベントですが、今回が初参加です。最近とあるサイトの改修に関わっていて、そこで使われていたSolrの置き換えとしてGroongaを選択したところだったので、ちょうどよかったと顔を出してみた次第です。たぶん、後ほどこのあたりで詳しい発表内容が掲載されると思います。

これまで個人用途でFerretを使ったり、またそれ以前はLudia + PostgreSQLを使ったことはあったのですが、Groongaを使うのは初めてでした。Solrは悪いプロダクトでは決してないのですが、今回適用したサイトでは利用するサーバの環境にマッチしていなかったこと、検索結果を調べたら正直なところちゃんと使いこなせていなかったことなどを勘案して、デモを作成したところ問題なく動作しそうだったGroongaに乗り換えました。

しかし、いかんせんGroongaはそんなに人気のあるものではないので、導入実績が少なく、ベストプラクティスのようなものもありません。幸い、たいした負担にもならない程度のアクセスしか見込めなかったので、レプリケーションなど負荷分散などには現時点であまり気を使うこともないのですが、それでも導入に際してはいろいろと困ったことがありました。まず最初に行き当たった壁は、システム構成を考えるにあたっての選択肢が多すぎる問題です。例えばGroongaには様々な関連プロジェクトがあり、使い方もいろいろ揃っています。MySQLやPostgreSQLのようなRDBMSと組み合わせて使ったり、あるいはhttpまたはmemcacheのバイナリプロトコルで通信する、Perl、NodeJS、Rubyのバインディングを通じてやり取りする、などなど、とにかくメニューは豊富です。しかし、ではどれが自分の使い方に向いているのか選択するとなると、ちょっとメニューが多すぎて困ってしまいます。実際、導入に際して手元の環境にインストールして調査がてらに叩いているときはgroonga実行ファイルからクエリと発行していたのですが、PHPで動かしているシステムと連携するにあたってはプロセスを別に上げてシステムコマンドを実行しない限りはこのときと同じクエリは利用できません。MySQLのバインディングもあるのですが、MySQLに密結合となるのは経験上避けた方がいいのはわかっていたので、結局楽そうだからとhttpで通信するやり方を選んだところ、GETのパラメータとして送信するやり方がgroongaの実行ファイル経由でクエリを送信するのとかなり違うので戸惑いました。今となってみればgroongaのhttpサーバではなく途中で簡単なRubyのサーバでも動かしてrroonga経由で使う方が楽な気がするのですが、そういったことも含めて、検討するポイントが多すぎるのも贅沢な悩みではあります。

また、どの言語/RDBMSのバインディングを利用するかによってアクセスできる機能が異なるのも困った問題です。現在のところ、groonga実行ファイルを直接叩くのは別として、rroongaが最も低レベルのAPIまでいじることができるようですが、その辺りの資料が見当たらず試行錯誤しました。お陰でhttp経由ではまだ使えないスニペットを使うと仕様を決めてしまい、自分で言い出した手前なんとかしないといけないと独自実装するはめになりました。そういった個々の実装の違いについては、プレゼンでいい資料があったので、公開されたら紹介します。

しかし、いったん導入してしまえば、スコアの調整や実際の検索部分については素晴らしく動作してくれます。いろいろな利用例を拝見したのですが、一人でああでもないこうでもないとやっていた結果がそんなに的外れではなかったこと、場合によっては結構いい線いっているらしいことが実感できました。まだまだ調整の余地はありますが、経験値が溜まってきたらいろいろここでも発表していきたいと思います。

と、そんな感じでしたが、当日はみなさんありがとうございました。楽しかったです。またいろいろ情報を追いかけていきます。特にfluentdを使ったレプリケーションとか胸熱でした。