YUKI Hiroshi
yuki****@clear*****
2017年 2月 24日 (金) 14:35:12 JST
クリアコードの結城です。 すみません、先の回答の内容に誤りがありました。 > b. インデックスを使った全文検索でヒット件数が0だった場合、自動的に > インデックスを使わないシーケンシャルサーチに切り替わる。 この点は、「インデックスを使わないシーケンシャルサーチに切り替わる」では なく「インデックスを使ってもう少し条件の緩い検索を行う」でした。 （Groongaが自動的に行うクエリ最適化によって、今回のようなケースではイン デックスを使用できるため、シーケンシャルサーチにはならずインデックスを 使った緩い検索になります。） なので、 > bの仕様により自動的にGroongaがインデックスを使わない検索に > fallbackして、シーケンシャルに全レコードを舐めていった結果が検索結果と > して返されています。 この部分の説明も、シーケンシャルサーチではなくインデックスを使った緩い検 索ということになります。 YUKI Hiroshi wrote: > クリアコードの結城です。 > > > 前方一致、中間一致、後方一致に関して以下のような想定でしたが、 > > 数字の前方一致に関してはSQLの結果から検索に該当する場合と該当しない場 > 合があり、 > > ばらつきがあるように見受けられますのでお手数ですが仕様をご教示願えま > すでしょうか。 > > これはGroongaの以下の仕様による現象です。 > > a. TokenBigram＋NormalizerAutoでは、連続するASCII文字は > 空白区切りでトークナイズされる。 > - http://groonga.org/ja/docs/reference/tokenizers.html#tokenbigram > b. インデックスを使った全文検索でヒット件数が0だった場合、自動的に > インデックスを使わないシーケンシャルサーチに切り替わる。 > - > http://groonga.org/ja/docs/reference/commands/select.html#match-escalation-threshold > - http://groonga.org/ja/docs/spec/search.html#id6 > > これらの点を踏まえて見ていくと、 > > > INSERT INTO memos VALUES (1, '123'); > > INSERT INTO memos VALUES (2, '12345'); > > INSERT INTO memos VALUES (3, '1234567890'); > > この3パターンの文字列はいずれもASCII文字のみの連続なので、aの仕様により > 空白区切りでトークナイズされます。 > > > 1.contentを1で検索→id1、2、3が検索に該当 > > 2.contentを12で検索→id1、2、3が検索に該当 > > 3.contentを123で検索→id1が検索に該当 > > 4.contentを1234で検索→id2、3が検索に該当 > > 5.contentを12345で検索→id2が検索に該当 > > 6.contentを123456で検索→id3が検索に該当 > > ※以下1234567890まで桁を増やしていく場合もid3が検索に該当 > > この各パターンでは、3と5の場合のみインデックスから検索結果を見付ける事が > でき、その結果が返されています。 > 3と5以外のパターンではインデックスベースでの検索では結果が0件ということ > になり、bの仕様により自動的にGroongaがインデックスを使わない検索に > fallbackして、シーケンシャルに全レコードを舐めていった結果が検索結果とし > て返されています。 > > > 連続するASCII文字でも前方一致検索を使う機会が多いようでしたら、上記のaの > 特殊動作が行われないトークナイザーとして、入力をすべて厳密にBigramでトー > クナイズする「TokenBigramSplitSymbolAlphaDigit」を使うのがおすすめです。 > > http://groonga.org/ja/docs/reference/tokenizers.html#tokenbigramsplitsymbolalphadigit > > > > tak_kaz24****@yahoo***** wrote: >> お世話になっています。高橋と申します。 >> 先ほどのメールがWEB上文字化けしていたので念のため再送します >> PGroongaのWindows版を使用して全文検索システムを構築すべく動作検証をしております。 >> 数字形式の前方一致検索について以下のような事象が発生していますので、 >> お手数ですが回答願えますでしょうか。 >> >> ■環境 >> Windows Server 2008 R2 Standard SP1（64bit） >> PostgreSQL9.5.5-1（Windowsインストーラ版使用） >> pgroonga1.1.9（Windowsバイナリ版使用） >> >> ■事象 >> 数字形式のデータをテーブルに格納しSQLを発行したところ、 >> 前方一致で該当する場合と該当しない場合があります。 >> 特にPostgreSQLやpgroongaのログにエラーは出力されていません。 >> >> ■実際のテーブル、データ >> CREATE TABLE memos ( >> id integer, >> content text >> ); >> >> CREATE INDEX pgroonga_content_index ON memos USING pgroonga (content); >> ※デフォルトのTokenBigram、NormalizerAutoの環境 >> >> INSERT INTO memos VALUES (1, '123'); >> INSERT INTO memos VALUES (2, '12345'); >> INSERT INTO memos VALUES (3, '1234567890'); >> >> ■SQL実行時の結果 >> 以下のようなSQLで1から6のようなパターンで検索を実施 >> >> SELECT id FROM memos WHERE content %% '123' >> >> 1.contentを1で検索→id1、2、3が検索に該当 >> 2.contentを12で検索→id1、2、3が検索に該当 >> 3.contentを123で検索→id1が検索に該当 >> 4.contentを1234で検索→id2、3が検索に該当 >> 5.contentを12345で検索→id2が検索に該当 >> 6.contentを123456で検索→id3が検索に該当 >> ※以下1234567890まで桁を増やしていく場合もid3が検索に該当 >> >> ■想定結果 >> 以下のような検索結果になる想定でした。 >> >> 3.contentを123で検索→id1、2、3が検索に該当 >> 5.contentを12345で検索→id2、3が検索に該当 >> >> 前方一致、中間一致、後方一致に関して以下のような想定でしたが、 >> 数字の前方一致に関してはSQLの結果から検索に該当する場合と該当しない場合があり、 >> ばらつきがあるように見受けられますのでお手数ですが仕様をご教示願えますでしょうか。 >> >> ・英字、数字：前方一致のみ可能で中間一致、後方一致は出来ない >> ・ひらがな、カタカナ、漢字、記号：前方一致、中間一致、後方一致可能 >> >> _______________________________________________ >> groonga-dev mailing list >> groon****@lists***** >> http://lists.osdn.me/mailman/listinfo/groonga-dev >> > -- 結城 洋志 <YUKI Hiroshi> E-mail: yuki****@clear***** 株式会社クリアコード 〒170-0005 東京都豊島区南大塚3-29-9 中野ビル3階 TEL : 03-5927-9440 FAX : 03-5927-9441 WWW : http://www.clear-code.com/
