Hiroyuki Sato
hiroy****@gmail*****
2015年 6月 27日 (土) 14:24:27 JST
須藤さん 佐藤です。 ご連絡をありがとうございます。 おかげさまでだいぶイメージがつかめました。 gistも直しました。 https://gist.github.com/hiroyuki-sato/276fa18be508a731faed 勉強会参加する方向で検討をしたいと思います。 KEY_NORMALIZEの件は次のようなことでよいでしょうか？ table_create --name Terms --flags TABLE_PAT_KEY|KEY_NORMALIZE --key_type ShortText --default_tokenizer TokenMecab table_create --name Terms --flags TABLE_PAT_KEY --key_type ShortText --default_tokenizer TokenMecab --normalizer NormalizerAuto よろしくお願いします。 2015年6月26日 21:57 Kouhei Sutou <kou****@clear*****>: > 須藤です。 > > In <CA+Tq-Ro9VuhcHkbSn8-OU_5bcv2FLTmsRe3nfm9P_OEELJ****@mail*****> > "[groonga-dev,03310] Re: テーブルの_keyとフラグについて" on Fri, 26 Jun 2015 20:55:00 +0900, > Hiroyuki Sato <hiroy****@gmail*****> wrote: > >>> * 1,2: このような理解で良いでしょうか? > >>> 1, テーブルのキー >>> (1) 一意である >>> 同じキーのエントリを複数件、一つのテーブルに登録することはできない。 > > はい、その通りです。 > >>> 2, データ用のキーのフラグ >>> (1) キーを使って他のテーブルを検索しない場合: TABLE_NO_KEY > > はい、その通りです。 > あとは、できるだけサイズを小さくしたい、速くしたい、ただし、 > いろいろある制約は我慢できるという場合に選びます。 > >>> (2) キーを使って他のテーブルを完全一致でのみ検索する場合: TABLE_HASH_KEY > > はい、その通りです。 > あとは、↓よりも速度が欲しいときに選びます。が、全文検索が入 > ったり、多くのレコード・カラムの出力処理が入ると、全体からみ > てTABLE_HASH_KEYと↓の時間の差はそんなに気にならなくなるので、 > 気にする場合は少ないです。 > >>> (3) キーを使って他のテーブルを全文検索で使う場合: TABLE_PAT_KEY または TABLE_DAT_KEY > > そんなに間違っていないんですが、ほとんどはTABLE_PAT_KEYです。 > TABLE_DAT_KEYはサイズが大きくなりやすい（うえにTABLE_PAT_KEY > はサイズがすごく小さくなる）ので、全文検索用のトークンが多く > なる場合（だいたいそう）はTABLE_PAT_KEYです。 > > では、TABLE_DAT_KEYはどういうときに使うかというと、トークン > 数に上限があって、トークンの前方一致検索もしたいというような > ケースです。（前方一致検索が必要ないならTABLE_HASH_KEYでよ > い。） > > たとえば、タグ検索やWikiのタイトル検索で、タグやタイトルで > 「Groonga/テーブル」みたいに階層構造をつけている場合です。 > > > また、テーブルについて書いてあるドキュメントも参考になると思 > います。 > http://groonga.org/ja/docs/reference/tables.html > > >>> 3, インデックステーブルのキーのフラグ >>> (1) _keyにはどのような値が入るのか？ >>> https://gist.github.com/hiroyuki-sato/8f3e399474ff7cb20ab8 > > これは、「一つのエントリに複数のIDを格納するような場合」の方 > がイメージとしては近くて、こっちの > > [単語, [_id, 単語の出現位置]] > > の「単語」部分が_keyになって、こうなります。 > > _id _key title_idx > 1 Haskell [[1,0]] > 2 Groonga [[2,0]] > 3 Erlang [[3,3]] > 4 Go [[4,0]] > 5 Scala [[5,6]] > 6 入門 [[1,7],[2,7],[4,4]] > 7 できる [[3,0],[5,2]] > 8 言語 [[4,2]] > 9 三日 [[5,0]] > 10 で [[5,2]] > > なので、 > >> https://gist.github.com/hiroyuki-sato/276fa18be508a731faed > > の「lexcon (lx: lexicon id)」の表のところまではあっているん > ですが、「title_idxの内容は、「どのレコード(bXX)」の「何番目 > の文字」かを指定する。」の表は違うんです。 > > _id title_idx 対応する単語 > l6 b1,7 入門 > l7 b2,7 入門 > l8 b4,4 入門 > > というように_idが別々には「振られません」。 > > _id title_idx 対応する単語（←が_key） > l6 [[b1,7],[b2,7],[b4,4]] 入門 > > というように、同じ_id（= 同じ_key）のところに全部入っていま > す。 > > > ベクターカラムのところも、↓と書いているので、もしかしたらイ > メージが違うかもしれません。（データとしてはあっています。） > > _id title > b1 Haskell入門 > b1 Leraning Haskell > > ベクターカラムのときは同じ_idに対して複数の格納場所（複数の > 列）がある、みたいにイメージしているのかと思うんですが、 > > _id title > b1 [Haskell入門, Leraning Haskell] > > というように、列は1つでベクターカラムの中に複数の格納場所が > あるというイメージで考えてください。で、インデックスカラムも > 後者と同じように、列は1つ（_id（= _key）は1つ）で、カラムの > 中に複数の出現位置を格納しているのです。 > > >> 念のため確認をしたいのですが >> インデックスのテーブルのフラグは、TABLE_NO_KEYは指定せず、TABLE_HASH_KEY, TABLE_PAT_KEY, TABLE_DAT_KEY >> のどれかを指定するという理解でよいのでしょうか？ > > はい、その通りです。 > > > 他の全文検索エンジンは語彙表を外に出していなくて（ユーザーは > しなくていい・指定できない）、トークナイザーやノーマライザー > は指定できるんですが、Groongaは語彙表から外に出しているので、 > 検索時の仕組みがわからないと、イメージがつかみにくいかもしれ > ません。わかると理にかなっているなぁと思えるのですが。。。 > > >>> 追伸: 今度の読書会ってこの辺が話題でしょうか？参加しようかな.. > > 次は > > 4.7.3. カラムインデックスによる関連テーブルをまたぐ検索 > http://groonga.org/ja/docs/tutorial/match_columns.html#nested-index-search-among-related-table-by-column-index > > からで、もう少し進んだところですが、参加者がわかっていないと > ころがあれば、ドキュメントに書いていないことでも絵を描きなが > ら説明しているので、理解が進むと思います。なので、ぜひ！ > > あ、だいぶ回が進んでいるので途中参加は敷居が高い…と感じてい > る人がいるかもしれないので補足しておくと、途中参加の人は歓迎 > です。なぜなら、これまで継続して参加している人たちの理解が深 > まる機会が増えるからです。 > > 途中参加の人は当然わからないところがでてきます。そのとき、こ > れまで参加していた人が説明します。これがポイントで、何回も説 > 明することで理解が進みます。もし、うまく説明できなかったら理 > 解できていなかったということなので、他の人が説明します。これ > もやはり理解が進みます。 > > なので、途中参加は歓迎なのです。 > > > > Gistに書いていることの補足なんですが、実は、KEY_NORMALIZEは > deprecatedになっているのです。代わりに > --normalizer NormalizerAutoを指定してください。ドキュメント > でもまだKEY_NORMALIZEを使っているところが多く残っているので > 直さないといけないんですよねぇ。。。 > > > -- > 須藤 功平 <kou****@clear*****> > 株式会社クリアコード <http://www.clear-code.com/> > > Groongaベースの全文検索システムを総合サポート: > http://groonga.org/ja/support/ > パッチ採用 - プログラミングが楽しい人向けの採用プロセス: > http://www.clear-code.com/recruitment/ > > _______________________________________________ > groonga-dev mailing list > groon****@lists***** > http://lists.osdn.me/mailman/listinfo/groonga-dev -- Hiroyuki Sato
