Kouhei Sutou
kou****@clear*****
2013年 12月 20日 (金) 14:05:28 JST
須藤です。 In <CANM+****@mail*****> "[groonga-dev,02018] Mroongaにおけるベクターカラムのインデックスについて" on Fri, 20 Dec 2013 13:04:14 +0900, Naoya Murakami <visio****@gmail*****> wrote: > 先日、ベクターカラムのドリルダウンで速度が遅いという > 余談をさせていただきました件について、インデックスが > 使われてないんじゃないかなぁという疑問点が沸きました。 実は、そもそもドリルダウンではインデックスを使っていないので す。では、どうやって高速化しているかというと、カラムの値への アクセスをショートカットして速くしています。 Groongaはカラムストアを採用しているので、特定のカラムに集中 的にアクセスすることがわかっていればアクセスする方法を最適化 できるのです。 > そこで、テーブル定義を見直したのですが、Mroongaにおける > ベクターカラムに対するインデックスの張り方は、 > 以下の(1)Qiitaに示されているような形をとるのでしょうか？ > > Qiitaの記載がなかったころにテーブル定義をつくっていて、 > 以下の(2)のテストケースを参考にして作っていました。 > > Groongaのテーブル構造を見ると、それぞれでインデックス > の作られ方が異なっていました。 > > ひょっとしたら、(2)の張り方にしてて、ドリルダウンで > インデックスが使われてないんじゃないかなぁとか考えました。 ドリルダウンではインデックスを使っていないのでどちらも同じ挙 動になります。ちなみに、どちらも前述の高速にドリルダウンする 処理を使います。 さらにちなむと、(1)はよくありません。これだと、tags用の語彙 表（Bugs-tagsテーブル）のトークナイザーがTokenBigramになって いるので日本語だとタグが細かくなってしまいます。 例えば、「ぐるんが」をtagsにいれると「ぐるんが」というタグで はなく「ぐる」「るん」「んが」「が」と言ったタグが語彙表に入っ てしまいます。 ただし、(1)の方はもとのデータはそのままで正規化できます。(2) の方で正規化しようとすると、Tags._keyの値が正規化されるので、 tagsの値も正規化後のものになってしまいます。 > GroongaのselectコマンドでBugsのtagsをドリルダウンで > 集計するのにインデックスが使われるようにできるケース > があれば教えてください。 ということで、特に何もしなくても大丈夫です！ -- 須藤 功平 <kou****@clear*****> 株式会社クリアコード <http://www.clear-code.com/> (03-6231-7270) Groongaサポート: http://groonga.org/ja/support/ パッチ採用はじめました: http://www.clear-code.com/recruitment/ コミットへのコメントサービスはじめました: http://www.clear-code.com/services/commit-comment.html
