レポート

モーショノロジー2012 #1「検索はシステムを救う」実施レポート

この記事を読むのに必要な時間:およそ 5.5 分

rroongaによる検索サービスの実装

株式会社クリアコードの須藤さんより,Rubyとgroongaを一緒に使った検索サービスの作り方について説明がありました。

画像

rroongaはgroongaのRubyライブラリで,プロセス内(アプリケーション内)にDBを持つのが特徴で,groongaをライブラリとして使う場合,以下のようなメリットがあります。

  • 通信コストがないため,小さいコストで細かくデータを読み書きできる
  • 低レベルのAPIから高レベルのAPIまで使えるため柔軟に演算を組み合わせた検索ができる

この中で「柔軟に演算を組み合わせた例」として,⁠多段ドリルダウン」を実現する説明,用途などを紹介しました。このような機能は,たとえユーザが意識しなくても,システム的には絞り込み条件が途中で変更される場合,キーやそれまでの結果を効率よく引き継ぐことができ,継続検索を可能にします。

また今回のお話では「デメリットはスケールアウトする標準的な仕組みがないことです。そのため,レプリケーションの仕組みを自分で作り込む必要があります」と,デメリットにも言及されました。

開発事例として,テレビ番組横断検索&共有サービス「テレコ!」の紹介がありました。ここでは,たとえば番組説明から出演者を抽出する場合のような,メタデータ抽出にはドリルダウンが有効であること。またコンテンツベースの候補の精度がいいなど,メリットを効果的に適用する事ができます。

その他,groonga本体が持ってる機能。ローマ字,かな。補完,補正,提案,学習などのサジェスト機能なども利用することができるので,要件次第では非常に相性が良いとのお話を頂きました。

その他,当日の発表内容につきましては,同社のブログでご紹介いただいております。

モーショノロジー2012 #1: rroongaによる検索サービスの実装
URL:http://www.clear-code.com/blog/2012/1/26.html

ぐるなびサービスにおける,groongaの位置情報検索関連について。

株式会社ぐるなびの塩畑さんには,groongaを利用した位置情報を利用したレストラン検索についてお話しいただきました。⁠ぐるなび」といえば,レストラン,居酒屋などの検索でおなじみではないでしょうか? 今回は,これらの店舗について,どうやって位置を特定しているのかといった実装についてのお話です。

画像

groongaを利用したきっかけは,それまで利用していたパッケージの提供が終了となったことです。新たなパッケージ選定を検討した結果,groongaに決定し,2010年に移行を完了したそうです。位置検索の一般的な方法は,飲食店などの店舗を緯度経度検索し,結果を地図で表示するもので,地図に関しては日本測地系と世界測地系があるとのこと。groongaの場合は両方ともサポートされているそうです。

実際の検索方法としては,ある場所を基準点として,そこから矩形と円形による範囲検索を提供。また,基準点(座標)から,各データ(店舗など)までの距離を,方形近似,球面近似,楕円体(ヒュベニ)で算出し,結果に反映しているそうです。

距離算出に関しては,そこまでサポートする必要があるのかなどと質問もありましたが,⁠誤差に関しては地域によって差が生じる(実際に最大数メートル誤差が生じる所もある⁠⁠」ことと,⁠たとえば隣の店舗を指してしまったらしたら契約店舗に迷惑がかかる」などを考慮したとのことで,この点に関しては,絶対的なプロ意識を持って対応している点が伺えました。

また,店舗名や補足説明などに関しては,MeCabを利用した全文検索を採用しているとのことでした。

当日のレポートはこちらでも公開されています。また,スライドは以下で公開されていますのでぜひご覧ください。

groongaの位置情報検索について(PDF)

Solrを使ったレシピ検索のプロトタイピング

クックパッド株式会社からは,レシピ検索担当の兼山さんより,実際にクックパッドで利用されているSolrを使ったレシピ検索のプロトタイピングについてお話し頂きました。

画像

クックパッドでは,開発サイクルとして,まず細かいプロトタイプを作成し,本番環境へデプロイし,ユーザの反応を見て展開を検討します。このためにRailsのchankoライブラリを開発。複数の環境をデプロイする仕組みを構築し,数十バージョンの本番を平行で展開したり,ABテストなどにも活用するなどの恩恵を受ける事ができるようになりました。

一見,本番環境でプロトタイプというと,エンドユーザを使ってデバッグしているイメージを受けるかもしれませんが,この場合はどれも真剣勝負の本番環境で,インターフェースやデータ抽出方法などの最適など,ユーザの反応が必要な部分を中心にプロトタイプ展開しているイメージでした。

検索システムに関しては,MySQL(Tritonn⁠⁠→Solrに全面移行したそうです。Apache+Javaの環境があれば手軽にSolrを利用する事が可能とはいえ,MySQLからの移行は大規模なソースコードの修正を必要とし,その点では苦労されたとのことでした。

従来利用していたTritonnで抱えていた問題は以下になります。⁠スライドより)

  • パフォーマンス悪い
  • フィールド追加が辛い
  • レプリがステートメントベース(本番でテーブル定義を変えにくい)

Solrへの移行メリットは以下の点です。

  • パフォーマンス良い
  • フィールド追加が簡単
  • レプリ→ファイルベース(本番でテーブル定義を変えやすい)

このように移行前の問題点をほぼ改善したので,プロトタイピングがしやすい環境を構築する目的を達成できたとのことでした。

その他,HTTPを利用するため並列化のメリットなどがある反面,JavaベースのためGC実行時にロックがかかる場合があるなど,いくつか問題点もあるとのことでしたが,varnishなどを前段に置きキャッシュさせるなど,より安全に運用するべく施策を検証しているとのことでした。

その他にもいろいろとお話しいただきました。当日のスライドは以下に提供いただいています。

Solrを使ったレシピ検索のプロトタイピング
URL:http://d.hatena.ne.jp/code46/20120127/p1

まとめと次回予告

今回,非常に有名なサイトで実際に利用されている検索が,どのようなコンセプトで何を使って実装されているか,実際に開発に携わる方々にお話しいただくことができ,非常に有意義な時間だったかと思います。また,ふだんプロダクト別に開催される事が多い印象のあった検索系の勉強会ですが,開発者,ユーザ,プロダクト関係なく一同にお話しいただく機会を開催する事ができて,本当に良かったと思っています。

次回は,⁠ネイティブアプリケーション」vs「Webアプリケーション⁠⁠』と題しまして,開発手法,技術,デザインなどさまざまな観点からお話できる会を予定しておりますので,ぜひとも参加いただければと思います。

著者プロフィール

高岡将(たかおかすすむ)

大手金融,独立系SIerにて気がつけば計18年以上のキャリアを重ねる。バランス感覚に長け,インフラ/アプリ,プレイヤ/マネージャなど関係なくこなし,「いそうだけどいないタイプ」と評価される。

仕事以外では,自転車,ジョギング,サックス等を趣味にし,密かに「エンジニアと健康」についてダイエット成功論の連載を企む。