Naoya Murakami
visio****@gmail*****
2013年 12月 6日 (金) 13:28:58 JST
お世話になっております。村上と申します。 当方は、データサイズ数百GiBぐらい、レコード数600万〜1000万ぐらいの データベースを十以上の項目で絞り込むことを想定した検索システムを 個人で作っています。 MroongaおよびGroongaについて無知だったので（そもそもMySQLも）、 満足できるパフォーマンスがなかなか得られずに何十回もテーブル設計 を見直しました。 全文検索システムは実際に構築して試してみないとパフォーマンスを 検証できないのが難しいですね。 最初は、複雑な絞り込み検索でもインデックスを使ってできるように、 SPIDER + 絞り込み検索する項目にタグ付けしたテキストを格納した カラムの全文インデックスを作って対応しようしていました。 しかしながら、須藤さんにMroongaでベクターカラムが作れるということと、 Groongaでは、ある程度自由に複数インデックスが使えるということを 教えてもらい、更新は、Mroonga、検索は、mroonga_commandを使って、 Groongaのselectコマンドを使うことにしました。 http://sourceforge.jp/projects/groonga/lists/archive/dev/2013-August/001643.html 当方の感想ですが、Groongaのselectを使うと、SQLのSELECTに比べてこんなにうれしいです。 ・Groongaではある程度自由に複数インデックスが使えるので、多数の項目で絞り込み検索を しまくっても、爆速です。むしろ一致件数が減って速くなるケースの方が多いです。 ・カウント結果が同時に返ってくるので、カウントと検索を２回しなくても済みます。 ・ドリルダウンもできます。ドリルダウンは、ほんの+0.数secだけで、この全文検索条件に 一致する項目の数が一瞬で抽出可能です。 ・Groongaのクエリ構文は、Googleライクな検索システムが作り易いように考えられている構文 でアプリ側が作りやすいと感じました。 また、この他に大規模になってくると、転置インデックスの語句の出現回数に応じて、 全文検索性能自体が激しく劣化するということがわかったので、 トークナイズ処理の手当てをして、ようやく満足いく性能が得られたかなというところです。 まぁ、私は個人でやっているのでテーブル再設計が簡単で、Groongaの構文を使うことも 特に問題なかったですが、普通は、開発途中でやり直しは大変そうですね。 ちなみに、MYISAMとかだったらデータファイルが１個しかできないのが PARTITIONでファイルがばらばらになると思うのですが、 Groonga(Mroongaストレージモード)で作られるデータファイルって1Gごとに ばらばらになりますが、インデックスが使われないケースのレコードアクセス での絞り込みやカウント等は、カラムに対応づけられた全ファイルを読んじゃう んですかね？ 以上です。
