groongaを囲む夕べ#1

リハビリがてら、六本木のG社で開催されたG勉強会に参加してきました。

全文検索エンジンgroongaを囲む夕べ #1 : ATND

Groonga - An open-source fulltext search engine and column store

groongaの存在はこの勉強会まであまり知らなかったのですが、Sennaの後継として作成された全文検索エンジンとのことでした。
うまく適合できそうであれば今つくろうとしているパーソナルワークのプロジェクトで導入してみたいな、と思います。

以下講演内容の要旨

全文検索エンジンgroongaについて

• senna
  • 名前の由来
    • アイルトン・セナ（未来検索ブラジルだから）
  • アーキテクト
    • 参照ロックフリー
    • データ更新時に検索を阻害しない
  • 特徴
    • 全文検索用の「ライブラリ」
    • 転置インデックスのみを更新し、ドキュメントデータは持たない
      • ドキュメントデータはMySQLに保存
      • Tritonn
        • MySQLの全文検索演算子を乗っ取る
  • 動機
    • 2chの地震速報板をすぐに検索したかったから
  • ウイークポイント
    • インデックス更新が遅い
      • TritonnはMyISAMでしか動かない（全文検索演算子がMyISAMのみ対応）
      • 更新時にテーブルロックがかかる

• groonga
  • 名前の由来
    • 造語（SEO対策）
  • 特徴
    • 文章の情報も管理・保存
    • gronnga単体で全文検索が可能
    • ファセット検索対応
    • geo search対応
      • 地点間の距離計算/２点間の矩形内にあるかどうかの検索、等々
      • 日本測地系/世界測定系 両方に対応
    • サジェスト機能
      • ユーザーにの検索クエリログを一定間隔で収集し解析する
        • 高頻度の共起クエリーの推薦とか
        • スペル補正とか（編集距離で距離を算出し近いものを）
        • 補完とか
    • SQLで使える（外部ストレージとの連携）
      • groongaストレージエンジン（MySQL）
      • textsearch_groonga(PostgreSQL)
    • 複数プロセスで利用可能
      • 更新時にはロック
      • 更新情報が各プロセスにシリアライズ
  • アーキテクト
    • 文章データはカラムごとに保存
      • Key-Value Storeを並列に並べた感じ？
      •  文書IDごとに各カラムのデータを結びつけ＋カラム数分並列に並べる
      • multiValued(value中に配列を入れることが出来る）
      •  テーブルカラム（valueに他テーブルの参照を入れることが出来る）
    • ネットワークサーバとして動作することを想定
      • HTTP GET
      • 独自プロトコル
      • memcached(バイナリプロトコル）
      • msgpack(未実装。内部に定数だけ定義）
    • コマンドラインや各種言語バインディングからも使用可能
    • クエリ言語
      • JavaScriptライクな文法
      • 結果はJSONP/XML/CSVで返却
  • ドキュメント
    • http://groonga.org/docs/
  • 導入事例
    • gronngaデーモン
      • 某サイトでのアイテム検索
    • gronngaライブラリ(Ruby)
      • 番組情報サイトの検索
      • buzztter
  • 注意点
    • 64bit専用
      • OSの仮想メモリ(mmap)を最大限の利用するため
    • ファイルディスクリプタを大量に使う
      • インデックスのカラムごとにファイルが分かれているので
    • 可変長カラムの空間効率は改善の余地があるかも

• 質疑応答
  • 分散構成はspiderストレージエンジンを使えば出来るという話だったがspiderをサポートしているのか？
    • 特に関知してない。使えば出来るんじゃないか。
  • インデックスの複数サーバへの分散はどうすればよい
    • 機能としては出来上がってない。（関知しない）
    • spierをストレージとして使った場合はspider側が勝手にやる
  • groongaが落ちたときの挙動は？いつ落ちても壊れない？
    • いつ落ちても壊れるw。ロックフリーなシステムなので更新時に落ちたら壊れるので諦めてください。
    • データの元本を別に保持して障害時に復旧するようなオペレーションをおすすめします
  • データの整合性のチェックはしている？
    • していない
  • 各言語のバインディング拡張の予定は？
    • 作りたいけど手が回らない（PHPとPython書きたい）
    • よろしければ開発にご参加ください
  • データのオンラインバックアップはできる？
    • Linuxには「cp」という素晴らしいコマンドがありますw。
    • dump機能はある
  • sennaにくらべてファイルサイズは大きくなる？
    • 文書データも保持するのでサイズは大きくなると思う
  • HTTP経由でインデックスの更新は可能か？
    • GETの中にjsonを強引につめれば今でもできる
    • 今後POST対応を検討したい
  • 32bitではビルド出来ない？
    • ビルドは出来るが実用上に問題がある

Ruby/groonga (rroonga/ActiveGroonga/Racknga) について

• ラングバプロジェクト
  • 由来
    • 語感だけ
  • 提供
    • 全文検索システム(ruby+groonga)
    • そのためのコンポーネント
  • 構成要素（文書検索ラングバ）
    • groonga
    • rronnga
    • ChupaText/ChupaRuby（文章抽出）
    • Railsサポート用ライブラリ(ActiveGroonga)
    • Rackサポート用ライブラリ＋α（racknga)

• rroonga
  • groongaのRubyバインディング
  • Rubyらしく書ける事を重視
  • groonga APIレイヤー
    • QL-API : DB操作コマンド、ネットワークアクセス
    • DB-API：データベース、テーブル、カラム型、手続き（tokenizeなど）
    • LOW-Level API:ハッシュテーブル、パトリシアTRIE、配列
      • rroongaはDB-API、QL-API（一部）をサポート
  • スキーマ定義はDSLで(QL-APIの代替）
    • • メソッド経由でカラムアクセス可能
  • groonga<->Rubyの自動型変換
  • 検索条件をRubyの式として記述可

• • 利用シーン
    • インデクサー
      • Rubyで加工しながらデータ追加
    • データベースメンテナンス
    • groongaの動作確認
    • テストデータ投入

• • 導入事例
    • るりまサーチ（rroonga + Rack)

• ChupaText
  • 複数の入力形式を一つの操作方法でサポート
  • mime形式で返却
  • 入力処理をプラグイン化しているので柔軟に拡張可能
    • Cで共有ライブラリを作成
    • Rubyスクリプトを作成

• ChupaRuby
  • ChupaTextのRubyバインディング

• ActiveGroonga
  • Rails3用のgroongaモデル
  • rroonga + ActiveModel
• -
• 質疑応答
  • RubyからCのライブラリを呼び出す時はどうすれば（Ruby側がmallocしてしまう）
    • プロセスを分けましょう。

MySQL + groonga (groongaストレージエンジン) について

• groongaストレージエンジンとは？
  • Tritonnの後継プロダクト
    • まだリプレース可能なほどは洗練されてない・・
    • MySQL Pluggable Storage に対応

• Tritonn
  • MySQLで全文検索を使えるようにしたい
    • MySQL実装では日本語が使えなかった
      • MySQL標準のものは半角スペースでのチャンキングにのみ対応

• groongaストレージエンジン
  • 特徴
    • MySQL5.1以上で全文検索を使えるようにする
      • 現在は5.1対応、5.5非対応
    • Tritonnに比べて柔軟性追加＋高速化
  • アーキテクト
    • groongaストレージエンジンをMySQLのpluggable storageとして追加
    • groongaストレージエンジンからgroongaを呼びだす
    • groongaのデータを共有するので、同じデータをMySQL、rroonga、HTTP、GQLなどから並行呼び出し可能
    • groongaのデータと同期するため仮想化ラムを用意
      • _id：groongaにおけるレコードの識別番号
      • _score：全文検索時のスコア値
    • order by limit のパフォーマンス問題解消
      • Tritonn時：order byの並び替え前に対象レコードを全件読み込む処理が重い
      • limit件数分のみ取得するように実装されている
    • その他
      • カラムの刈りこみ（不要なカラムを読まない）
      • count高速化
      • 大規模分散検索対応
        • Spider Storage Engineと連携

• Spider Storage Engineでのgroongaの分散（イメージ）
  • スコアでのソート時
    • 複数ファイルに並列でアクセスしてマージ
  • レンジパーティショニング条件下でのソート
    • パーティショニングのルール範囲で値を取得
  • パーティションの分割条件に沿った絞り込み
    • 参照先が分割条件と等価なので最低限のアクセスでデータ取得できる

• 質疑応答
  • スコアなしの状態で他のテーブルに移行する際はどうする？
    • dumpしてテーブル定義を書いてリストア
    • ALTER TABLEも今後は対応予定
  • limit句高速化の際に他テーブルとのjoinのしたときの動きは？
    • JOINにはまだ対応していない（通常のMySQLと同じ動きになる）
  • 複数カラムにまたがる全文検索のインデックスは対応予定はあるか？
    • 今のところ対応予定はない
    • groonga本体が対応したらストレージエンジンでも対応する
  • nullを入れたらゼロになったが？
    • 現在groongaがnull値をサポートしていない
    • どうしようか検討中
  • vector カラムのサポート予定は？
    • MySQLのデータ型とのマッピングが難しい。現在はノーアイデア。
  • 複数のカラムに対して重み付けをすることはできるか？
    • Tritonnの場合は複合インデックスを用いて実施していた。
    • 実装するとしたら同様な形になると思うがまずmulti カラムインデックスの対応が必要
  • mroongaという名前は使っている？
    • 今も使っている。開発コード名。

PostgreSQL + groonga (textsearch_groonga) について

※タイムアップにつき退出