こんにちは、堀本と申します。 通常のトークナイザ(TokenBigram)は数字、英字の区切れでトークナイズし 、数字のみの項目は全体がトークンとしてインデックスに登録されるので、 1つ目のご質問の前半は江上さんのご理解の通りです。 ご質問の後半ですが、インデックスにあるトークンと完全一致しない検索 キーワードの時にインデックスを使って検索をするかどうかは、PostgreSQL のプランナー次第なので、完全一致しないキーワードだからといって、 フルスキャンになるとは限りません。 もし、インデックスを使った検索をPostgreSQLのプランナーが選択した場合は、 以下のような挙動になります。 まず、インデックスに登録されている数字に完全一致する数字を含むレコード がヒットします。 完全一致でヒットしたレコードが存在した場合は、部分一致での検索はしない ため、部分一致しているレコードはヒットしません。 (Groongaの全文検索は基本的に完全一致で検索するためです。) デフォルトの設定では、完全一致でヒットするレコードが無かった場合は、 前方一致検索を実施します。(少し緩めの検索をします) したがって、インデックスを使った検索が選択された場合は、完全一致 -> 前方一致で検索され、完全一致、前方一致しないレコードはヒットしない。 となります。 2つ目のご質問の「TokenBigramSplitSymbolAlphaDigit」を使うことである程度 の高速化が見込めるかどうかなのですが、こちらは状況によるかと思います。 問題のクエリーを EXPLAIN ANALYZE VERBOSE をつけて実行した時に フルスキャンになっていた場合は、「TokenBigramSplitSymbolAlphaDigit」を 使うことでインデックスを使った検索が選択され高速化する可能性があります が、既にインデックスを使って検索していた場合は、どちらもインデックスを 使用した検索なので、高速化は見込めないと思われます。 (インデックスに登録されるトークンが2文字ずつになるので、ヒット数は増える と思います。) したがって、まずは、検索が遅い時の実行計画(EXPLAIN ANALYZE VERBOSEの 結果)を見てインデックスが使われている検索なのかどうかを確認してみると いうのはいかがでしょうか？ 的を外した回答になっていたらすみません。 以上です。失礼いたします。 On 2019/02/20 14:35, 江上 秀樹 wrote: > 以前、別件で質問させていただいた江上と申しますが、その節はありがとうございました。 > > 今回は数字の検索処理時間についてになります。 > > 7桁の数字が入ったjsonデータ800万件の検索対象データと検索キーの組合せで、以下のような検索時間がかかりました。 > > 検索対象 検索キー 検索時間 > 半角 半角 8秒 > 全角 全角 数ミリ秒 > > --- 実行したクエリ ---- > SELECT * FROM table WHERE > order_key_value_json operator(pgroonga.@@) 'paths == "item004"' > > order_key_value_json はjsonカラムで100項目のキーバリュー収容。item004はそのキーの1つ。 > --- > > ●確認なのですが、以下で正しいでしょうか？ > > 通常のトークナイザ(TokenBigram)は数字、英字の区切れでトークナイズするため、上記のような数字のみの項目は全体としてインデックス作成され、部分一致はフルスキャンになる。 > > この場合アルファベットも数字も2文字ずつ区切るトークナイザーである > 「TokenBigramSplitSymbolAlphaDigit」を使うことである程度の高速化が見込めるでしょうか？ > > > _______________________________________________ > groonga-dev mailing list > groon****@lists***** > https://lists.osdn.me/mailman/listinfo/groonga-dev >
