Hiroyuki Sato
hiroy****@gmail*****
2015年 8月 15日 (土) 01:42:22 JST
須藤様 佐藤です。 ご連絡をありがとうございます。 インラインでコメントしました。 よろしくお願いします。 2015年8月13日 23:47 Kouhei Sutou <kou****@clear*****>: > 須藤です。 > > In <CA+Tq-RpHssEDa55t-Li-9=-j53T****@mail*****> > "[groonga-dev,03411] 日付データと、highlight_htmlのことについて押してください。" on Thu, 13 Aug 2015 23:01:53 +0900, > Hiroyuki Sato <hiroy****@gmail*****> wrote: > >> 日付データと、highlight_htmlのことについて押してください。 >> >> >> | isbn | title | 発売日 | >> |--------------|-------------------|----------| >> | 49-1234-7890 | Haskell入門 | 2015/1/1 | >> | 49-1234-7891 | Groonga入門 | 2015/2/1 | >> | 49-1234-7892 | できるErlang | 2015/3/1 | >> | 49-1234-7893 | Go言語入門 | 2015/4/1 | >> | 49-1234-7894 | 三日でできるScala | 2015/5/1 | > >> 確認事項 >> 1, 発売日でソートする場合 >> ・インデックスは必須でしょうか？ > > 必須ではありません。 > >> ・インデックスをつけることで、ソートが速くなりますか？ > > 速くなります。 > > ただし、速くなるのは--sortbyのキーがpublished_dateだけで、条 > 件が指定されていない（--queryも--filterも指定されていない） > ときだけです。 > > --sortbyのキーが複数だったり、条件が指定されているとインデッ > クスがあってもなくても速度は変わりません。 ありがとうございます。今使っているのは複数のqueryを使っているでソートは速くならいですね。 > >> 2, 発売日で絞り込みをする場合(queryに日付を指定する場合) >> ・インデックスは必須でしょうか？ > > 必須ではありません。 > >> ・インデックスをつけることで、ソートが速くなりますか？ > > ソートは速くなりませんが、検索は速くなります。 > ソートのときのような制限はありません。 失礼しました。ソートではなく検索です。 > >> 3, 発売日と、titleでインデックスを作る場合 >> >> ・どちらもOKでしょうか？ >> ・同じテーブルの異なるカラムでインデックスを作る >> column_create --table Terms --name published_idx --flags >> COLUMN_INDEX --type Book --source published_date > > これは動きません。 > > インデクスをどのテーブルに作るかを考えるときは、 > 語彙表（＝インデックスのテーブル、↑だとTerms）のキーの型と > 値の型が同じか、ということを気にするとよいです。 > （厳密に言うと、値をトークナイズしたトークンの型が同じか、な > んですが、よくわからないうちはあまり気にしなくてよいです。） > > ↑では、Termsが語彙表でそのキーの方はShortTextです。 > 一方、published_dateの型はTimeです。 なるほど、ありがとうございます。 ちなみに、二つのカラムが同じ型(ex ShortText)である場合 インデックス用のテーブルを別々にしたほうが良いケースはありますでしょうか？ 例えば http://groonga.org/ja/docs/tutorial/match_columns.html?highlight=複数%20カラム%20インデックス こちらのtitle,messageのような場合 titleはTitleIndexテーブル、messageはMessageIndexとするようなケースです。 それぞれで異なるトークナイズの方法が違う場合はそれぞれ別にテーブルを作る必要がある という理解で良いでしょうか？ > > 型が違うのでこの定義は動きません。 > （動いたとしてもたまたまです。） > >> ・別々のテーブルを作りインデックスを作る >> table_create --name PublishDate --flags >> TABLE_PAT_KEY|KEY_NORMALIZE --key_type ShortText --default_tokenizer >> TokenBigram > > 別のテーブルを作るのが正しいのですが、この定義では動きません。 > > まず、型を揃えます。つまり、Timeにします。 > > table_create \ > --name PublishDate \ > --flags TABLE_PAT_KEY \ > --key_type Time 了解しました。 > > --default_tokenizerを指定するのは全文検索したいときだけ、と > 考えてください。全文検索するときは部分文字列で検索したいので > 元の値を分割（＝トークナイズ）する必要があります。 > 今回は日付の値そのもので検索したいのでトークナイズする必要は > ありません。 > > よって、--default_tokenizerを指定する必要はありません。 了解しました。 > また、KEY_NORMALIZEはキーの型がShortTextの場合のみに有用です。 > よって、指定する必要はありません。 > > なお、KEY_NORMALIZEは非推奨になっているので、使うときは代わ > りに--normalizer NormalizerAutoを指定してください。 > > 以上から、テーブル定義は↑でよいです。 > >> column_create --table PublishDate --name published_idx --flags >> COLUMN_INDEX --type Book --source published_date > > インデックスカラムの定義はこれでOKです。 > >> 4, 指定した発売日の中で、条件に合致したものだけハイライト表示 >> >> ・こういう検索の仕方は大丈夫でしょうか？ >> (一応動いているので大丈夫そうなんですが..念のための確認です。) >> 1430406000: 2015/5/1 >> select --table Book \ >> --query '(go OR erlang OR haskell) OR ( published_date:>0 >> published_date:<1430406000)' \ >> --output_columns 'highlight_html(title)' --match_columns title >> --command_version 2 > > 大丈夫です。 > > なお、 > > published_date:<1430406000 > > は > > published_date:<"2015/5/1 00:00:00" > > というように文字列でも指定できます。 > ありがとうございます。 > > -- > 須藤 功平 <kou****@clear*****> > 株式会社クリアコード <http://www.clear-code.com/> > > Groongaベースの全文検索システムを総合サポート: > http://groonga.org/ja/support/ > パッチ採用 - プログラミングが楽しい人向けの採用プロセス: > http://www.clear-code.com/recruitment/ > コードリーダー育成支援 - 自然とリーダブルコードを書くチームへ: > http://www.clear-code.com/services/code-reader/ > > _______________________________________________ > groonga-dev mailing list > groon****@lists***** > http://lists.osdn.me/mailman/listinfo/groonga-dev -- Hiroyuki Sato
