初めてのシステムと日記

全文検索エンジンgroongaを囲む夕べ 2 #groongaに参加してきました。

今回はmroonga(旧groongaストレージエンジン)の話を聞きたくて参加してみました。

※以前groongaストレージエンジンを試した記事はこちら

■groonga村(株式会社クリアコード須藤さん)

今日の勉強会の位置づけやgroongaについての説明でした。

• groonga1.2.8リリース！
• groongaの開発者募集中
  • 興味は少しありますが、まずはソース読めですね。。
• groongaのユーザー増加も募集中
• 安定しているのか？
  • 実績が！！！
    • ぐるなびさん：レストラン検索等(この後位置情報検索で)
    • スカパーJSATさん’番組情報検索
    • buzztter
    • 某転職サイト
  • 公開可能な実績を募集中のようです
• 類似製品との違いって
  • 類似製品一覧
    • Apache Solr/Lucene
    • Sphinx
    • Senna
      • Tritonn
      • textsearch_senna
  • groongaの方がよいところ
    • 即時更新
    • データをDBMSで一元管理 ※DBMS:データベースを構築、運用するための管理ソフトウェア
    • 普通のSQLで使える→既存ノウハウを使える
  • 類似製品の方がよいところ
    • 機能が豊富
    • エコシステムが充実→調べたのですがちょっと理解できなかったです。。
    • 書籍がある→先駆者が多そうなイメージ
• groongaの外観
  • groonga(ぐるんが):全文検索エンジンライブラリ
  • rroonga(るるんが？):Rubyライブラリ
  • mroonga(むるんが？):MySQLストレージエンジン
  • nroonga(呼び方分からない。。):Node.jsライブラリ
  • groonga with PostgreSQL:PostgreSQLでgroongaを使える

■新年と収穫の祭り(有限会社未来検索ブラジル森さん)

Sennaからの開発経緯から、現在、今後開発したいものについての話でした。

• 最初は検索エンジンとして斜め上を行ってた。
• その後世間でも徐々に盛んに
  • twitter、real-time webの影響？→こういうところtwitterはやはりすごいですね。。
• groongaは動的構築一筋
  • 静的構築
    • 構築が完了した時点で検索可能
    • 小さい作業領域で高速構築可能
  • 動的構築
    • 検索可能な状態を維持しながら構築
    • ランダムI/Oを抑えるために工夫が必要
  • 大量の検索と更新を同時にこなしたいので動的構築一筋
  • 静的構築 VS 動的構築について
    • 以下の記事がオススメ
      • 検索エンジンはいかにして動くのか？
• 最近の動向
  • Geographical Searching
  • DBMSとの結合強化
  • 牽引の静的構築→オフラインで索引は静的構築が有利
• 今後開発したいもの
  • カラムストアの性能強化
  • 類似文字列検索→是非！
  • 頻出パターン抽出→これも是非！
  • などなど
• 開発者募集！！開発者募集！！開発者募集！！

■mroongaのご紹介(斯波さん)

文字通り、メジャーリリースされたmroongaの紹介です。wktk。

• 更新が混在しても高速な全文検索が可能
  • 更新時、他の更新、参照をテーブルロックでブロックすることがない
  • 並列性の高い参照、更新が可能
• 更新が混在しても高速な位置情報検索が可能
  • 位置情報インデックスの更新性能が高い特性が加わり、全文検索同様の力を発揮
  • ただし、現在扱える位置情報は点のみ
• 他のストレージエンジンに全文検索機能を追加することが可能
  • ラッパーモード機能(任意のストレージエンジンと連携)→今回の勉強会で一番気になった
  • 全文検索:groonga、それ以外:任意のストレージエンジンが可能→wktk
• 主な追加機能→自分が試したver0.2でちょっと。。と思ったところがほとんど改善されていた！
  • auto_increment
  • ラッパーモード
    • create table文のストレージエンジン:groonga、コメントにCOMMENT='engine"innodb"'を記述
  • マルチカラムインデックス
    • タンデム構成(MySQL以外からもgroongaを利用)ではカラム更新時にインデックスの整合性が取れなくなるので注意
  • create/drop index
  • 位置情報index
  • 全文検索用パーサーカスタマイズ
  • rename/alter table
• 今後の予定
  • MariaDBにバンドルされる→会場で一番盛り上がった印象ですが、盛り上がりについていけなかった。。

■Geographical Searching(株式会社ぐるなび 塩畑さん)

groongaとの歩みから経度緯度検索機能の実現についての話でした。

• groongaとの歩み
  • レストラン検索、地図検索などでgroongaを利用
• 経度緯度検索機能の実現
  • 資料に詳しくまとめていたのでそちらを参考に。。http://groonga.org/ja/publication/presentation/groonga-night-2-geographical-searching.pdf
• パフォーマンスについて
  • 総データ数約54万件
  • 2010年4月Ver:約0.34秒→2010年8月ver:0.03秒
  • 約90%のパフォーマンスアップ！

■groonga with PostgreSQL(フォルシア株式会社 奥野さん)

PostgreSQLのgroonga全文検索拡張や将来像についての話でした。

PostgreSQLは全く触ったことがなく。。話についていけませんでした。。

groongaを利用したライブラリα版を年内にはリリースしたいとのこと。

名前はproonga(ぷるんが)。。ですかね、流れ的に。

■mroongaベンチマーク(株式会社クリアコード須藤さん)

mroongaのベンチマークについての話でした。

ラッパーモードなど魅力的な機能が追加されたのでパフォーマンスも気になるところです。

• 高速な全文検索機能
  • 約100万件のtweetに対して1万回のフレーズ検索にかかった時間
  • tweetは全て英語らしい
  • table構成が不明
  • mroonga > mroonga+InnoDB > MyISAM >>>> InnoDB
  • mroongaの圧勝でラッパーモードでもそんなにパフォーマンス変わらず！
• 高速な位置情報検索機能
  • 約1100万件の番地データに対して1000回のMBRContains+ORDER BY検索にかかった時間
  • 約1100万件の番地データに対して1000回のMBRContains+ORDER BY検索にかかった時間
  • mroonga = MyISAM = mroonga+InnoDB
  • どの検索もパフォーマンスはどれも拮抗
• 即時更新
  • 98万件のtweetが保存された状態で2万件のtweetを追加したときの更新スループット
  • mroonga >>>>> MyISAM > Sphinx >> mroonga+InnoDB = InnoDB
  • 更新に関してはラッパーモードは連携したストレージエンジンに引っ張られるとのこと

以前ver0.2で他テーブルとINNER JOINした時、パフォーマンスが著しく低下していました。

それが今回のラッパーモードによって解消されるのかが気になりました。

何十万件あるデータに紐づくテーブルをJOINすることはありえそうなのですが、、どうなんだろう。

単体テーブルで全文検索してアプリ側でfor文まわして個別に取ってきた方が速いということなのかな。

■mroongaの未サポート機能(斯波さん)

• UTF-8以外の文字コード
• 点以外の空間情報
• 0跨ぎの緯度経度→世界基準だと問題ありそう
• トランザクション→ラッパーモードでも無理らしい
• repair table
• などなど

トランザクションやrepair tableが対応していないのは個人的に怖いと思いました。

復旧が大変そうな印象です。

■groonga開発予報(有限会社未来検索ブラジル矢田さん)

ダブル配列について熱く語られていた印象がw

ダブル配列は更新より参照の方が多い時に有効だそうです。

次の開発予報は対応されたらパフォーマンスがかなり向上しそうでした。

• 開発予報
  • 頻出する索引ごをキャッシュ
  • 不安定なハッシュ表を調整
  • 見る機会の少ないデータを圧縮

今回発表された資料、Ust、Tweetのまとめは下記にあげられています。

http://groonga.org/ja/publication/#groonga-night-2

ラッパーモードは是非検証してみたいです！

ツイートする