📺 🍋 🤷🏾 Fantastic-Elasticsearch。スマートドキュメント検索を「飼いならした」方法 🐢 💪 🧔🏻

全文検索を使用すると、テキストコンテンツでドキュメントを検索できます。このような必要性は、システムに多くのテキストエンティティが含まれており、ユーザーが検索中にこのデータを考慮する必要がある場合に発生することがあります。ワークフローソリューションを開発するときに、同様の状況に直面しました*。システムデータはMS SQL ServerまたはPostgreSQLに保存され、柔軟な属性検索により、さまざまなメタ情報を使用してドキュメントを検索できます。しかし、時間が経つにつれて、これは十分ではありませんでした。テキストプロパティと添付ファイルでドキュメントを検索する方法を学習するという課題に直面しました。

問題は、全文検索が有料でのみSQLサーバーでサポートされ、必要な柔軟性が提供されないことです。その瞬間、検索エンジンが登場します。たとえば、Sphinx、Solr、Elasticsearchなど、さまざまな全文検索システムがあります。しかし、私たちの選択はそれらの最後に落ち着きました。一般に、ドキュメントの大規模な動的データベース、Elasticsearch、および全文検索用のWebインターフェースを持つ顧客の要望があります。オートコンプリート、ヒント、ファセット、およびオンラインストアの機能に近いその他の機能。この問題の解決方法に関する記事。

* Docsvisionプラットフォームの優先文書管理システム

建築

Elasticsearchデータベースでは、テーブルはインデックスと呼ばれ、ドキュメントをロードするプロセスはインデックス付けと呼ばれます。主記憶域からのデータにインデックスを付けるために、Elasticsearchで特別なサービスが作成されました。これはWindowsサービスであり、それに加えて管理者ユーティリティがあります。ユーティリティは必要な設定を設定し、インデックスを作成し、データベースへのドキュメントのロードを開始します。

ただし、データのインデックス作成の段階で問題が発生しました。システムは動的であり、ドキュメントには毎分数千の変更が発生します。インデックスサービスは、Elasticsearchデータを現在の状況にできるだけ近く維持する必要があります。そのため、SQLデータベースに新しいエンティティ（インデックス作成用のドキュメントのキュー）が表示されます。 N分ごとに、特別なジョブが前回の実行以降に変更されたすべてのドキュメントを検索し、それらの識別子をキューに追加します。その結果、サービスはインデックスでそれを必要とするドキュメントのみを更新します。

技術スタック

検索エンジン。 Elasticsearch 5.5

プラグイン 分析形態学および摂取アタッチメント

サービス C＃で書かれています。エンジンと対話するためのライブラリ：NESTおよびElasticsearchNET。

フロントエンド 角度4

ダウンロード設定

管理者ユーティリティ-インデックスを作成するドキュメントとフィールドの種類を選択するためのサービスの一部。その後、データスキームがElasticsearchに読み込まれます（ESエコシステムでは、マッピングと呼ばれます）。これは、異なるフィールドを設定に設定するために必要であり、ドキュメントのインデックス作成時に考慮されます。さらに、ユーティリティは選択結果をデータベースに保存します。

マッピング形成

マッピングは、NESTライブラリを使用して動的に生成されます。システムの各データタイプは、Elasticsearchデータタイプに関連付けられています。データベースは、ドキュメントの階層構造もサポートしています。これは、 オブジェクトとネストされたデータ型（配列の場合）に対応します。

var sectionProperty = section.SectionType == SectionType.Struct ? new ObjectProperty { Name = section.Name } : new NestedProperty { Name = section.Name };

テキストフィールド分析

Elasticsearchは、優れた全文検索機能を提供します。単語形式を考慮し、ストップワードをスキップし、言語形態を使用できます。これを行うには、マッピングを作成する段階で、これを必要とするテキストフィールドに正しいアナライザーを指定する必要があります。これらの設定は、管理者ユーティリティでも指定されます。

アナライザーには、個々の文字の変換、文字のトークンへの分割、およびこれらのトークンの処理の3つの段階が含まれます。この場合、文字のフィルタリングは必要ありません。トークナイザーとして、標準的なものを使用します。これはほとんどの場合、そのまま使用できます。ロシア語アナライザーの主要なリンクは、公式の分析形態学プラグインです。単語形式に基づいて検索できるトークンフィルターを提供します。また、すべての単語を小文字にし、独自のストップワードを使用します。

 var stopFilter = new StopTokenFilter { StopWords = new StopWords(StopWordsArray) }; var filters = new TokenFilters { { "my_stopwords", stopFilter } }; var rusAnalyzer = new CustomAnalyzer { Tokenizer = "standard", Filter = new[] { "lowercase", "russian_morphology", "my_stopwords" } }; var analazyers = new Analyzers { { "rus_analyzer", rusAnalyzer } }; var analyzis = new Analysis { Analyzers = analazyers, TokenFilters = filters };

ファイルの設定

Elasticsearchバージョン5.0では、新しいエンティティであるIngestノードが導入されています。このようなノードは、ドキュメントをインデックス化する前にドキュメントを処理するために使用されます。これを行うには、 パイプラインを作成し、それにプロセッサを追加します。任意のノードを取り込みとして使用できます。または、プライマリ処理用に別のノードを選択できます。

システムの多くのドキュメントにはテキストファイルが含まれています。全文検索は、コンテンツに対して機能する必要があります。これを実装するために、最近導入されたパイプライン技術を使用するIngest Attachmentプラグインを使用しました。プラグインを介して利用可能な各ドキュメントファイルのプロセッサを使用するプロセッサを定義します。このプロセッサの本質は、別のフィールドのBase64文字列からテキストを抽出することです。残っているのは、インデックス作成中にファイルからBase64文字列を取得してマッピングを開始することだけです。プロセッサでは、ファイルを含むフィールド （ Field ）とテキストを配置する場所（ TargetFiled ）を示します。 IndexedCharactersを設定すると、処理されるファイルの長さが制限されます（-1により制限がなくなります）。

 new PutPipelineRequest(pipelineName) { Processors = new List<ProcessorBase> { new ForeachProcessor { Field = "Files", Processor = new AttachmentProcessor { TargetField = "_ingest._value.attachment", Field = "_ingest._value.RawContent", IndexedCharacters = -1 } } } };

索引付け

サービスのタスクは、キューから新しいオブジェクトを継続的に抽出し、関連するドキュメントにインデックスを付けることです。このプロセスでは、NESTオブジェクトモデルではなく、低レベルのElasticsearchNetライブラリを使用します。 JSONを介してデータベースインターフェイスを提供します。ドキュメントの階層構造の深さをトラバースすることにより、オブジェクトを動的に形成します。よく知られているNewtonsoftJsonライブラリがこれに使用されます。

 client.LowLevel.IndexPut<string>(indexName, typeName, documentId, json);

インデックス作成は、各ドキュメントの並列処理でマルチスレッドで実装されます。 JSONを生成するプロセスは、JSONをインデックス化するよりも桁違いに長くかかります。したがって、APIは、ドキュメントの配列が1回の呼び出しでESにロードされるBulk APIではなく、個々のドキュメントのインデックス作成に使用されます。この場合、インデックスは最大のドキュメントのJSON生成レートで発生します。

ファイルのインデックス付け

ファイルは、JSONオブジェクトの一部として残りのデータとともにインデックス付けされます。必要なのは、バイトストリームをBase64文字列に変換することだけです。これは、標準ライブラリを使用して行われます。さらに、ファイルがプロセッサー定義に該当する必要があります。そうしないと、魔法は発生せず、通常のBase64文字列のままになります。インデックス作成時にパイプラインを使用するには、メソッド呼び出しを変更します。

 client.LowLevel.IndexPut<string>(indexName, typeName, documentId, json, parameters => parameters.Pipeline(pipelineName));

自動補完

オートコンプリート（オートコンプリート）は、ユーザーが入力した行の継続の可能性を示唆します。

この場合、オートコンプリートは、管理者ユーティリティで対応するフラグが設定されているテキストフィールドで機能するはずです。マッピングをロードする段階で、すべての補完的な行に対して個別のインデックスが作成されます。これは、検索が複数のインデックスで機能する必要があるという事実によるものです。マッピングは、特別なタイプの補完フィールドで形成されます。

 var completionProperty = new CompletionProperty { Name = "autocomplete", Analyzer = "simple", SearchAnalyzer = "simple" };

ドキュメントのインデックスを作成するとき、自動補完に必要なテキストは用語のセットに分割され、インデックスにロードされます。用語は正規表現を満たしている必要があります。短すぎず、文字のみで構成される単語を強調することが重要です。セットは1つの用語だけ順次シフトされるため、各単語に対して、インデックスで始まる行があります。セットの長さは上から制限されているため、4に等しいcompleteSizeを使用します。

 var regex = new Regex(pattern, RegexOptions.Compiled); var words = regex.Matches(text); for (var i = 0; i < words.Count; i++) { var inputWords = words.OfType<Match>().Skip(i).Take(completeSize).ToArray(); var wordValues = inputWords.Select(x => x.Value).ToArray(); var output = string.Join(" ", wordValues); //   JSON }

検索中に、オートコンプリートの個別のリクエストが機能しています。各文字を入力すると、対応するサブストリングを使用してデータベースにアクセスします。 Elasticsearchへのリクエストはjsonオブジェクトです。オートコンプリートを取得するには、サジェストブロックのみが必要です。 Completion Suggesterが含まれているため、プレフィックスですばやく検索できます。補完フィールドでのみ機能します。タイプミスについて話し合うとき、他のサグスターと会います。

 { "suggest": { "completion_suggest": { "text": "  ", "completion": { "field": "autocomplete", "size": 10 } } } }

検索する

インターフェイスの基本部分は検索文字列です。ユーザーが文字を入力すると、オートコンプリートと検索の2つの要求が満たされます。それらの最初の結果に基づいて、印刷を続行するようにプロンプトが表示され、2番目に従って、ドキュメントの発行が構築されます。検索クエリは複数のブロックで構成され、各ブロックは異なるプロパティを担当します。

全文検索

クエリブロックは、クエリの検索部分に対応します。彼のおかげで、発行されるドキュメントが選択されます。他の重要なクエリブロックがこれらの結果に適用されます。クエリは、ブール演算を使用して接続されたサブクエリを持つことができます。これを行うには、 boolブロックを定義します。 4つのタイプの条件を含めることができます： must 、 filter 、 must_not 、 should 。このクエリでは、論理ORに一致するshould条件を使用します。複数のフルテキストサブクエリを組み合わせます。 フィルターブロックに戻りますが、今のところ、ドキュメントのセット全体を探していると考えています。

 { "query": { "bool": { "filter": [], "should": [ //   ] } } //   }

全文検索の場合、 multi_matchブロックが使用されます。 クエリパラメータのテキストは、 fieldsパラメータで指定されたいくつかのフィールドで一度に検索されます。要求への応答として、ドキュメントのリストが返されます。各リストにはスコアがあります。文書がクエリに一致するほど、この数値は高くなります。 multi_matchリクエストは、テキストを単一のフレーズとは見なしませんが、個々の用語を検索します。同様のブロックを追加しますが、必要な機能を実装するフレーズパラメーターを使用します。一致するフレーズを含むドキュメントの値を高くするために、 boostパラメーターを指定します。ドキュメントのスコアに指定された数を掛けます。

 { "multi_match": { "query": " ", "fields": [ "FieldName" ] } }, { "multi_match": { "query": " ", "fields": [ "FieldName" ], "type": "phrase", "boost": 10 } }

落とし穴の中でも、配列内のオブジェクト間の検索に注意することができます。マッピングを作成するときに、いくつかのフィールドをネストされたものとしてマークしました。これは、それらがオブジェクトの配列であることを意味します。これらのオブジェクトのフィールドで検索するには、 nestedと呼ばれる別のサブクエリが必要です。その中で、配列へのパス （ path ）とリクエスト自体を指定する必要があります。 1つのインデックスを探している場合、これで十分です。ただし、この場合、検索は複数のインデックスで同時に機能し、そのようなパスがインデックスのいずれにも存在しない場合、ESはエラーを返します。したがって、ネストされたクエリはindecesブロックで囲まれ、検索するインデックスを示す必要があります。残りのインデックスが検索を必要としないことを明確に示すために、「 no_match_query 」：「 none 」と記述します。

 { "indices": { "index": "indexName", "query": { "nested": { "path": "PathToArray", "query": { "multi_match": { "query": " ", "fields": [ "PathToArray.FieldName" ] } } } }, "no_match_query": "none" } }

ハイライト

Elasticsearchは、リクエストに応じてドキュメント内で見つかったテキストを強調表示する優れた方法を提供します。

これを行うには、新しい要求ブロックを追加します： highlight フィールドに、ハイライトを返すフィールドをリストします。 pre_tagsおよびpost_tagsパラメーターでは、単語を強調表示する文字を指定します。検索が大きなテキストフィールド（ファイルなど）で機能する場合、Elasticsearchは、フィールド全体ではなく、小さな通路内でハイライトを返します。その結果、エンジンはすべての作業を行ってくれました。マッチを太字で強調表示し、コンテキストを強調表示しました。

 { "highlight": { "pre_tags": [ "<b>" ], "post_tags": [ "</b>" ], "fields": { "FieldName": {} } } }

この機能の便利さにもかかわらず、この機能を使用する際に深刻な問題が発生しました。ハイライトが配列内のオブジェクトに作用した場合、リクエストへの応答によって、どのオブジェクトに属しているかを判断することはできません。ファイルは配列に格納され、ファイルによる強調表示は顧客の重要な要件の1つです。この問題の論理的な解決策は、 File_iという形式のフィールドのセットを作成することです。ここで、 iは妥当な量の添付ファイルをカバーします。次に、強調表示することにより、ファイルがどのインデックスを持っているかが明らかになり、検索結果からこのインデックスによってファイル名を取得できます。

しかし、すべてがそれほど単純ではないことが判明しました。 Base64文字列からテキストへの変換プロセッサは、同じ名前のフィールドを持つ配列でのみ機能します。 Discussion.elastic.coフォーラムのヘルプのおかげで、解決策が見つかりました。テキストに変換した後、フィールドの名前を目的のフォームに変更する別のプロセッサを追加します。 CPUコード：

 "script": { "lang": "painless", "inline": """for (def i = 0; i < ctx.Files.length; i++) { def f = 'File' + (i+1); ctx.Files[i][f] = ctx.Files[i].attachment; ctx.Files[i][f].Name = ctx.Files[i].Name; for (def rf : ['attachment', 'Name']) { ctx.Files[i].remove(rf); } }""" }

サジェスト

リクエストを入力するときに、ユーザーがタイプミスをすることがあります。この場合、検索結果は空になります。ただし、Elasticsearchはエラーの可能性を示唆する場合があります。

この機能は、提案ブロックを介して実装されます。オートコンプリートについて説明したときにすでに彼と会っていましたが、タイプミスを処理するために別のタイプの悲しい身振り手が使用されています。 フレーズと呼ばれ、個々の単語ではなくフレーズ全体を指定してエラーを検索します。結果のヒントの数（ size ）、検索のフィールド （ field ）、およびフレーズの可能なタイプミスの数（ max_errors ）を示します。不要な結果をカットするには、結果のsjestが少なくとも1つのインデックスフィールドに含まれていることを確認するサブクエリ （ collate ）を追加します。ツールチップは、スペルミスの単語を強調表示する組み込みの強調表示もサポートしています。

 { "suggest": { "my_suggest": { "text": " ", "phrase": { "size": 1, "field": "_all", "max_errors": 4, "collate": { "query": { "inline": { "match": { "{{field_name}}": { "query": "{{suggestion}}", "operator": "and" } } } }, "params": { "field_name": "_all" } }, "highlight": { "pre_tag": "<b>", "post_tag": "</b>" } } } } }

ファセット

Elasticsearchを使用して実装できるもう1つの興味深い機能。ファセットは、オンラインストアでよく見られる集計ブロックです。 aggsブロックをリクエストに追加します。このブロックに追加できる最も一般的なタイプの集約は、 termsと呼ばれます。結果には、対応するフィールドの一意の値と、それらが見つかったドキュメントの数がすべて含まれます。集計がドキュメントのセット全体に適用されるのではなく、検索クエリを満たすドキュメントのみに適用されることが重要です。したがって、テキストを入力すると、ファセットのコンテンツが動的に変更されます。

 { "aggs": { "types": { "terms": { "field": "TypeField" } }, "min_date": { "min": { "field": "DateField" } } } }

ファセットを完全に実装するには、検索クエリにフィルタリングブロックを追加する必要があります。これにより、ファセットで選択されたドキュメントパラメータのみに検索が制限されます。 フィルターブロックで、 フィルターブロックごとにサブクエリを追加します。

 { "terms" : { "TypeField" : [ /*   */] } }, { "range" : { "DateField" : { "gte" : /*   */ } } }

まとめ

これが全体像の見え方です。

インデックス統計

現在、パイロットバージョンでは構成が使用されます。

2台のサーバー：

CPU ：Intel Xeon Platinum 8160（10コア）

RAM ：40 GB

インデックスボリューム：260 GB

インデックス内のドキュメントの数：60万

インデックス作成速度：5000 doc / h

Fantastic-Elasticsearch。 スマートドキュメント検索を「飼いならした」方法

建築