2017.12.27

Mroongaのベクターカラムとかのお話

どうも、福本です。
僕は数年前、当時はMySQL日本語の全文検索を高速に行えなかったことをきっかけにMroongaを使い始めました。

そもそもMroongaMySQL用のストレージエンジンで高速な日本語全文検索が可能になるというもので、
形態素解析機のMeCabとの連携も可能です。

DIIIGに関してもMroongaを使っているのですが、実は他にも理由があります。
今回はそのあたりの使っている機能とメリットデメリットについて僕が体感したことを
紹介させていただこうかと思います。

まずはメリットデメリットですが
ざっと僕が使う際に起きたことを元にするとこんな感じです。

■メリット

  • 全文検索が早い(当時は。今は精度や結果はともかくFullTextIndexで検索は出来る)
  • ベクターカラムという隠れた奥義を持っている(個人の感想です)
  • 公式の人の応答がすごく早い・優しい

■デメリット

  • 迂闊に構造を変更するとあっさりロックして、DBが一切応答しなくなる事がある
  • 公式サイトは親切かつ充実しているが、公式以外での情報は意外と少ない
  • ベクターカラムについての情報が少ない(気がする)
  • ジオメトリ型で取り扱えるデータがPOINTのみ

基本的に横着しなければデメリットはちょっぴり情報が少ない以外は特に無いのかなぁと思っています。
すっごいこまったらTwitterで公式の人に「たすけてー!」ってぶん投げるか
メーリングリストに投げると反応あると思います。

さて、さっきからチラチラでている「ベクターカラム」というキーワードですが
何を隠そう(隠してないが)、これがDIIIGに導入した理由の一つです。

ざっくりいうと

  • 任意のカラムをスペース区切りのデータで入力し、区切った個々のデータに対して高速に検索がかけられる

というもの。
もう少しイメージしやすくすると

  • 複数タグの設定

です。
この手のデータをテーブルのカラム数を気にせず、随時任意に設定できるのは結構嬉しい気がします。
あとからどんな種類のデータが増えるかわからないので

  • 主になる情報にたいして、関連付けたい情報(属性)のIDを複数ベクターカラムで持つ
  • 関連付けした情報(属性)で一気に探したいので、ベクターカラムを対象にIDで検索

とかしたい場合、カラムを増やさずにこういうのが高速にできます。
あと、

  • 1 10 11 101

みたいなスペース区切りのデータがあるとして
通常文字列として部分一致検索したら 10 だと 101 にもヒットしますが
この場合完全一致をめがけて高速に検索できるので重宝しました。

この手の複雑なデータを高速に検索するのは
ElasticSearchとかのほうが得意かもですが、学習コストや仕様変更のコストの面ではMySQLをそのまま使えるMroongaはとても嬉しいです。
※僕はどっちも好きですが。

なお、ベクターカラムを使うには実は別で1つテーブルを定義する必要があるのですが
こちらとの依存関係があり、迂闊にPhpMyAdminとかから消そうものなら一瞬でMySQL動かなくなったりします

そのあたりはお気をつけください。

なお、以前えらい目にあった時に書いたエントリです。