MySQLとPostgreSQLと日本語全文検索 参加レポート
昨日は肉の日でしたね!
肉の日にはIT系イベント、ということで、「MySQLとPostgreSQLと日本語全文検索」というものに参加してきました。
参加レポートというほどではありませんが、メモがてら残しておきます。
MySQLとPostgreSQLと日本語全文検索
- 開催日時: 2016-02-09(火)20:00 - 22:00
- 会場: DMM.comラボ
- イベントページ: https://groonga.doorkeeper.jp/events/35295
MySQL 5.7 InnoDB 日本語全文検索
発表資料
http://www.slideshare.net/yoyamasaki/20160209-inno-dbftsjp- 5.6でInnoDBに対応
- 5.7でCJK対応
- 5.7ではN-gramとMeCabに対応している
- 事前準備
- インストール
- my.cnfに設定して起動
- 接頭辞
loose-
を付けないとMySQL起動時にエラーになる
- 接頭辞
- INSTALL PLUGIN コマンドでインストール
- my.cnfに設定して起動
- インデックスの作成
- FULLTEXT INDEX指定で作成
- WITH PARSER mecab などでパーサ指定
- AND検索、OR検索、スコアリングができる
- 構文はMroongaと同じだった
- 今後
- パフォーマンスの改善
- ディスク容量の軽減
- あいまい検索
等
- メイン担当者が日本人じゃないらしい
PostgreSQLでpg_bigmを使って日本語全文検索(仮)
@sawada_masahiko(PostgreSQL・pg_bigmの開発者)
発表資料
http://www.slideshare.net/hadoopxnttdata/postgresqlpgbigm-mysqlpostgresql1/7にPostgreSQL 9.5がリリースされた
- モジュールを使うことで全文検索が可能になる
- 形態素解析をする場合は以下
- textsearch_ja
- メンテナンスされていないので、ソースを修正しないと動かない
- pgroonga
- textsearch_groonga
- textsearch_ja
- N-gramの場合は
- pg_bigm
- NTT DATAが作ってる
- pg_trgm
- unigram
- 追加モジュールが不要
- textsearch_senna
- pg_bigm
- 全文検索インデックスが必要/不要な検索
- 不要な場合
- テーブルのサイズが小さければ、中間一致で検索すればよい
- 前方一致ならBtreeで
- 後方一致ならBtree式で
- 必要な場合
- テーブルのサイズが大きい場合
- 中間一致も使いたい場合
- 不要な場合
- pg_trgm
- インデックスはPostgreSQLが管理する
- 日本語に弱い
- 1,2文字の検索が上手くできない
- PostgreSQLがシーケンシャルスキャンに切り替えるので、そこまで低速にはならないはず
- pg_bigm
- インデックスはPostgreSQLが管理する
- 日本語に強い
- 1,2文字の検索に対応
- GINインデックスを使う
- オススメはPostgreSQL9.4以降
- GINインデックスの性能やサイズが向上したらしい
- 圧縮機能が入った
- 検索性能も向上している
- 検索文字列が長いほど速くなるよう検索ロジックが直された
- GINインデックスの性能やサイズが向上したらしい
- 正規化して検索してくれる
- 全角-半角
ludia_funcs
を使うことで可能- NTT DATAが作ってる
MySQL・PostgreSQLでGroonga(Mroonga・PGroonga)を使って日本語全文検索
@ktou(Groonga・Mroonga・PGroongaの開発者)
- 発表資料
http://slide.rabbit-shocker.org/authors/kou/mysql-and-postgresql-and-japanese-full-text-search/
是非とも以下をTwitterでつぶやいてください!!!
HerokuのPostgreSQLでPGroongaを使えるならHerokuを使いたい! #herokujp #mypgft
- ベンチマークは人のは参考程度に
- 必ず自分の使う環境に沿った状態で行いましょう
- 検索性能はInnoDB ngramが安定して遅い
- データロードは大差ない
- インデックスの作成が圧倒的に速い
- 他が数時間かかっているが、xroongaは1時間かからない
- PGroongaはデータ量が少ない。次にpg_bigmが少ない。
- インデックスサイズはMroongaが少ない。InnoDB mecabと同じ。
- PGroongaは元データをコピーしたものも持つらしい。だからサイズが大きくなる。
- Groongaはマルチスレッド/マルチプロセスに対応している
- MySQLはマルチスレッド
- PostgreSQLはマルチプロセス
DMM.comラボでの日本語全文検索の利用事例紹介
オンライゲームで使ってる
- コミュニティで使った
- トピック検索
- 友達検索
- FAQも結構多い
質疑応答
- MySQLでパーサによる速度の差は?
- インデックスの量でMeCabのほうが少ないので高速になることが多い
- 転置インデックスは遅い?
- PostgreSQL
- 実際は遅いが、体感が速くなるように仕組みを入れている
- Mroonga/PGroonga
- インデックスの更新タイミングは制御できない
- とにかく速い
- PostgreSQL
- Master InnoDB, Slave Mroongaできるらしい