Elasticsearch クエリのイノベーション: ワイルドカード型の効率的なファジーマッチング戦略の検討

1. 背景

本番環境での使用では、Elasticsearch では完全一致だけでなく、あいまいなクエリシナリオも必要になります。

2. 解決策についての議論

この問題には、従来から 2 つの解決策があります。

2.1 ソリューション1: ngramトークナイザー

ngram トークナイザーを使用して、保存されたデータに対してきめ細かいセグメンテーションを実行し、きめ細かいトークンを使用して高速な呼び出しを行います。

これは、スペースを使用して時間を節約し、クエリに必要なルートコンテンツを絞り込み、正確な一致結果を持つ幅広いヒットを使用してファジー効果を実現するソリューションです。

 PUT test-005 { "settings": { "index.max_ngram_diff": 10, "analysis": { "analyzer": { "my_analyzer": { "tokenizer": "my_tokenizer" } }, "tokenizer": { "my_tokenizer": { "type": "ngram", "min_gram": 3, "max_gram": 10, "token_chars": [ "letter", "digit" ] } } } }, "mappings": { "properties": { "title": { "type": "text", "analyzer": "my_analyzer", "fields": { "keyword": { "type": "keyword" } } } } } } POST test-005/_bulk {"index":{"_id":1}} {"title":"英文官网承认刘强东一度被捕的原因是涉嫌性侵"} {"index":{"_id":2}} {"title":"别提了朋友哥哥刘强东窗事发了"} {"index":{"_id":3}} {"title":"刘强东施效颦，没想到竟然收获了流量"} {"index":{"_id":4}} {"title":"刘强东是谁？我不认识"} POST test-005/_search { "query": { "match_phrase": { "title": "刘强东" } } }

利点: 高速な呼び出しと低いパフォーマンス消費。
デメリット: かなりのスペースを消費します。粒度が細かくなるほど、消費量も大きくなります。同時に、一定の学習コストがかかり、単語の分割に関する成熟した理解が必要となるため、初心者には適していません。

ここに明らかな使用例があります。下の図に示すように、ngram を使用した test2 のインデックススペースは、keyword を使用した元のインデックススペースの約 10 倍の大きさになっています。

写真

2.2 ソリューション 2: ワイルドカードクエリ

ワイルドカードクエリを使用します。これは、ワイルドカードをサポートするあいまい検索機能であり、SQL の like 一致に似ています。

ワイルドカードおよび正規表現クエリを実装するために、Ealsticsearch が依存する Lucene4.0 は、入力文字列パターンを DFA (決定性有限オートマトン) に構築します。ただし、ワイルドカードパターンを使用して構築された DFA は複雑でコストがかかる可能性があります。

具体的な分析:

https://elasticsearch.cn/article/171

https://elasticsearch.cn/article/186

利点: 使いやすく、追加のストレージリソースを必要としません。
デメリット: 膨大なパフォーマンスを消費し、乱用するとオンライン事故を引き起こす可能性があります。

それぞれに長所があり、一部は互換性に欠ける 2 つのソリューションに直面した ES は、あいまい一致シナリオのニーズを解決するために、バージョン 7.9 でワイルドカードフィールドタイプを導入しました。

3. ワイルドカード型の使用方法の詳細な説明

Elasticsearch のワイルドカードフィールドタイプは、バージョン 7.9 で初めて導入されました。このバージョンでは、特に大量のテキストデータを処理する場合に、クエリの効率とファジーマッチングのパフォーマンスを向上させることを目的として、ワイルドカードタイプのサポートが追加されました。この新しい機能は、主に以前のバージョンのワイルドカードクエリのパフォーマンスの問題に対処し、ワイルドカードと正規表現の検索要件をより効率的に処理する方法を提供します。

写真

https://www.elastic.co/guide/en/elasticsearch/reference/7.9/release-highlights.html

まず、ワイルドカード型の使い方を見てみましょう。

まずワイルドカードタイプのフィールドを定義します

PUT my-index-000001 { "mappings": { "properties": { "my_wildcard": { "type": "wildcard" } } } }

文書を書く

PUT my-index-000001/_doc/1 { "my_wildcard" : "This string can be quite lengthy" }

ワイルドカードクエリは次のようになります。

 GET my-index-000001/_search { "query": { "wildcard": { "my_wildcard": "*quite*lengthy" } } }

結果は

{ "took" : 6, "timed_out" : false, "_shards" : { "total" : 1, "successful" : 1, "skipped" : 0, "failed" : 0 }, "hits" : { "total" : { "value" : 1, "relation" : "eq" }, "max_score" : 3.8610575, "hits" : [ { "_index" : "my-index-000001", "_type" : "_doc", "_id" : "1", "_score" : 3.8610575, "_source" : { "my_wildcard" : "This string can be quite lengthy" } } ] } }

大文字と小文字を区別しない場合は、ワイルドカードクエリで case_insensitive パラメータを使用できます。

 GET my-index-000001/_search { "query": { "wildcard": { "my_wildcard": { "value": "*Quite*lengthy", "case_insensitive": true } } } }

4. ワイルドカード原則

ワイルドカードフィールドの実装に関しては、このフィールドのリリース時に公式から関連する指示が発表されました。

新しいワイルドカードフィールドは、次の 2 つのデータ構造を使用して、ワイルドカードと正規表現の検索を自動的に高速化します。

文字列内のすべての 3 文字シーケンスの n-gram インデックス。
「バイナリドキュメント値」には、元のドキュメントの完全な値が格納されます。まず、基礎レイヤーでは依然として ngram セグメンテーションを使用してファジークエリシナリオを実装しますが、ここでの ngram 粒度は 3 であり、機能的にはファジークエリのニーズを満たし、ワイルドカードクエリの高パフォーマンスを保証します。

次に、ES で一般的に使用される doc 値形式が使用されます。ここでの主な効果は、doc 値形式の比較的高い圧縮率が活用され、自動クエリ検証によって n-gram 構文マッチングによって一致候補が生成されることです。

5. テスト

それでは、ワイルドカードの実際のパフォーマンスを見てみましょう。

5.1 スペースのサイズ

次の図に示すように、ワイルドカードフィールドを使用したインデックスは、元のインデックスとあまり変わらないことがわかります。

写真

5.2 クエリ効率

クエリDSL	キーワードタイプ	ワイルドカードタイプ
ワイルドカード: 「red bean」	715ミリ秒	71ミリ秒
ワイルドカード:”006-612014”	633ミリ秒	22ミリ秒
ワイルドカード:"55"	584ミリ秒	188ミリ秒
ワイルドカード:”11”	1359ミリ秒	357ミリ秒