Naoya Murakami
visio****@gmail*****
2013年 12月 20日 (金) 14:27:50 JST
お世話になっております。村上です。 詳細な解説ありがとうございます！ テーブル定義に問題ない旨、了解しました。 件数が非常に多い時にドリルダウンに結構時間がかかってしまうのは、 性能の限界として、運用でなんとか手心を加えて対応します！ なんかRroongaとかを使えれば、件数に応じて、ドリルダウンの有無 とか細やかに挙動を変えれて便利そうだなぁとか思いました。 また、時間があるときに勉強してみようと思います！ 以上、よろしくお願いします。 2013年12月20日 14:05 Kouhei Sutou <kou****@clear*****>: > 須藤です。 > > 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 > > _______________________________________________ > groonga-dev mailing list > groon****@lists***** > http://lists.sourceforge.jp/mailman/listinfo/groonga-dev >
