(」・ω・)」うー!(/・ω・)/にゃー!

Groonga を囲む夕べ 2にいってきた

| Comments

全文検索エンジンgroongaを囲む夕べ 2にいってきたので、そのさいのメモ。 運営の皆様、会場提供してくださったVoyage Group様、素敵なイベントをありがとうございますm( )m

というわけで以下内容のメモ。

groonga村

Overview

もう使っていいの？

  • 今日事例発表あるよ！
  • 仕事で使ってたら教えて！

groongaの利点

  • 即時更新
  • データを一元管理できる
  • SQLで使える

groongaと他との違い

gronnga

  • 全文検索エンジンライブラリ
  • 組み込んで使う前提

  • 自前のストレージもある

  • DB API

    • これを経由して各種から利用する
    • rroonga
      • rubyから使うライブラリ
    • mroonga
      • MySQLから利用するプラグイン
      • 今日はベンチマークもあり

  • クエリAPI

    • groongaに直接クエリ発行
    • groongaコマンド
      • CLIとか。
    • nroonga
      • node.js経由でクエリAPIを使う。HTTP経由で使う。

  • groonga \w PostgreSQL

groonga 新年と収穫のお祭り

これまでの開発経緯

  • 2005年にSennaリリース
  • 2ch検索のために開発
  • 即時検索可能に。。。というのを目的にしていたので、当初から動的構築ひとすじ
    • その後groongaに解明。カラムストア機能をつけた。　

索引の動的構築とは

  • 登録した文書を索引に即時反映

    • 当時としては斜め上の考え方
    • 転地インデックスの動的構築は煩雑

  • 静的構築

    • 構築完了した時点で検索完了
    • 小さい作業領域で高速に検索可能

  • 動的更新

    • 常に検索可能
    • ランダムI/Oを押さえたり、ロックしないようにするなどの工夫が必要

現在

  • カラムストア機能を追加

    • トランザクションは苦手だが、集計や圧縮に向いている。

  • 最近は静的構築も進めている。

    • オフラインで作るには性能的に有利
    • 静的構築もできた方がいいよね。

  • 静的構築のアプローチ

    • 転地索引構築の2pass化

今後

  • から無ストアの性能強化

    • キャッシュを考慮したデータ構造
    • 高速なファセット検索

  • 索引の圧縮方式の拡充

  • 類似文字列検索

    • 編集距離・コサイン類似度

  • 頻出パターン抽出

  • ストリーム処理機能
    • 時間窓内での頻出パターン・最大・最小値計算
  • スキーマレス化

最後に

開発者募集中！

mroongaの紹介

mroongaとは

  • MySQLのストレージエンジン

    • 他のストレージエンジンに存在しない全文検索エンジンを追加する事が可能

  • MyISAMと異なり、ロックする事なく参照・更新する事ができる。

    • 最近位置情報をサポート
    • ただし、現在は点のみ。

  • ラッパーモード

    • 基本的には、全文インデックスの部分のみmroongaが提供し、その他の部分は既存のストレージエンジンのものを利用する
      • NULLの制限(groongaがNULLを扱えない)の回避等もできる。
    • mroongaストレージエンジンが、裏から他のストレージエンジンを利用するイメージ

新バージョン

  • auto_incrrementの追加
  • ラッパーモードの追加
  • マルチカラムインデックス追加　
    • ただし、MySQL以外からもgroongaを利用するようなタンデム構成では整合性を保てなくなるので注意
  • 位置情報検索index追加
    • 現時点では点のみ
  • 全文検索パーサーをカスタマイズできるように。
  • rename / alter table対応

Spiderとの連携

  • 全文検索対応
  • 位置情報検索index対応
    • shardingしていてもできる。

今後

  • MariaDBにバンドルされる。

まとめ

  • 更新と参照が混在する用途に強い
  • Spiderと組み合わせてスケールアウトすることができる

Geographical Searching

groongaとの歩み

  • 2008から検索エンジン再構築プロジェクト開始
    • 当時senna
  • 2010 からgroongaを採用
    • レストラン検索
    • 地図検索
    • 駅検索
    • GPS検索

緯度経度情報検索

  • groongaでは矩形と円形の検索
    • 矩形(範囲)検索
    • 円形(距離)検索

距離計算の実現方法

  • 方形検索
  • 球面近似
  • ヒュベニ
    • 楕円退場で距離を算出する

測地系について

  • 日本測地系
  • 世界測地系

パフォーマンステスト

数字色々細かいので割愛。。。

最初のVerから90%ぐらいのパフォマンスアップ！

groonga with PostgreSQL

PostgreSQLの特徴

  • 拡張性の高さ

    • CでもPL/PGSQLで型も作れたり関数を作れたり。。。
    • indexも定義できる
    • テーブル定義もできるように(SQL/MED)

  • PGXN

    • CPANみたいなもの
    • 探したりインストールしたりするのがずっと楽になる予定

textsearch_groonga

  • PostgreSQLの方には文書データを入れておく。
  • groongaの方でindex関連の情報を持つ

groonga/fdw

  • SQL/MED

  • FDW

    • Forigen Data Wrapper
    • 外部リソースをPostgresのテーブルとして利用できる機能
      • 外部からデータとれる
    • 9.1から
    • 今は読み込みぐらいだが、シンプルに実装できる
      • Oracle
      • MySQL
      • Redis
      • etc..

  • groonga_fdw

    • FDWの機能を使ってgroongaを使う
    • 開発中

どう違う？

  • textsearch_groonga
    • インデックスとしてのみ
    • 持ってるデータに対して全文検索を張りたい
  • groonga_fdw
    • データ自体groongaで持つ感じになる

mroongaベンチマーク

  • MySQL内でのベンチマーク
    • 全文検索機能
    • 位置情報検索
    • 即時更新

全文検索

  • 100万件のtweetに対して１万回のフレーズ検索にかかった時間
    • mroonga だいぶ早いです。。。
    • mroonga + innoDBが割と良い選択肢になりそう

位置情報検索

  • 1100万件の番地データに対して1000回のMBRContains + ORDER BY検索
    • mroongaそこそこ早いけど、InnoDBと組み合わせるとorder byで読みにいく分の重さでちょっと負ける

書き込み

  • mroonga単体だとスループット１オーダーぐらい早い。。
    • ラッパーモードだとInnoDBに引きずられる

動的更新の性能

  • 書き込み量が増加しても、Sphinx等に比べて性能劣化が少ない。

mroongaの未サポート機能

文字コード

  • UTF-8以外のサポート
  • COLLATIONも、NFKC使っていて、MySQLのものをそのまま使えるわけではない。

condition pushdown

  • MySQLが使うと判断したindex以外でも使えるように。
  • groongaのドリルダウンと組み合わせたい。

位置情報

  • 点のみ
  • 0またぎの緯度経度検索ができない

MySQL 5.6から出る正確な位置比較関数

  • MBR~はまだつかえない

ストレージモードでのNULL

  • ラッパーモードのみ

トランザクション

  • mroongaがサポートできていないので、ラッパーモードでInnoDBのトランザクションを使っても、mroongaのindexだけrollbackされなかったりする。

修復ができない

  • 単純にrepaier tableではだめ。
  • 色々手順ふむ

Spiderまわり

  • parallel searchに未対応

groonga 開発予報

grn_datとは

  • 文字列とIDを関連づけるモジュール

  • grn_pat grn_hash

  • grn_pat

    • パトリシアトライ
    • 前方一致

  • grn_hash

    • ハッシュ表
    • 前方一致はサポートしないが高素行

  • grn_dat

    • だぶる配列
    • 前方一致検索をサポートする上に速い

  • いずれも参照ロックフリー

grn_datの特徴

  • 前方一致が可能で参照が速い
    • 更新とかにはあまり強くない

前方一致検索とは

  • Common Prefix Search
    • クエリから索引語への分割
  • Predictive Search

文字列更新とは

  • IDを残して文字列のみを更新
    • grn_patなどでは、削除ー＞別のIDで追加、という仕組みしかなかった

まとめ

  • grn_patの代替

    • メモリ使用量より参照時間を重視するとき

  • 参考：参照ロックフリーなダブル配列

ベンチマーク

  • wikipediaのタイトル(100万件ぐらい

  • ランダムに並べ替えて登録

  • 参照時間はgrn_pat よりはやい

  • 更新は重くなってしまう。
  • メモリ消費量も大きいので、チープなメモリでは使えない。

開発予報

  • 出現頻度の調整
  • 不安定なハッシュ表を調整
    • 小規模な場合にインデックス構築が遅いので、改良の余地あり
  • データをコンパクトに

Comments