Azure Data Manager for Energy のインデックス作成と検索ワークフロー

プラットフォームに取り込まれるすべてのデータと関連するメタデータには、検索を可能にするためにインデックスが作成されます。 データを使用できない場合でも認識できるよう、メタデータにはアクセスできます。

インデクサー サービス

Indexer Serviceには、構造化および非構造化データを含むドキュメントにインデックスを作成するメカニズムが用意されています。

インデックス作成ワークフロー

下の図は、インデックス作成ワークフローを示しています。

顧客がプラットフォームにデータを読み込むと、関連するメタデータがStorage serviceを使用して取り込まれます。 Storage serviceには、インジェスト (永続化)、変更、削除、バージョン管理、取得、データ スキーマ管理など、メタデータのライフサイクル全体を管理するための一連の API が用意されています。 Storage serviceによって作成された各ストレージ メタデータ レコードには、基になる "スキーマ" を示す kind パラメーターが含まれています。 このスキーマで、Indexer serviceによってインデックスが作成される属性が決まります。

Storage serviceでは、メタデータ レコードを作成すると、recordChangedMessages イベントを発生させます。これは、Azure Service Bus (メッセージ キュー) に収集されます。 Indexer queue サービスでは、Azure Service Bus からメッセージをプルし、基本的な検証を実行してそれをIndexer serviceに送信します。 Indexer serviceへのメッセージの送信でエラーが発生した場合、Indexer queue サービスでは構成可能な最大許容再試行回数までメッセージの送信を再試行します。 再試行の試みが失敗すると、否定受信確認応答が Azure Service Bus に送信され、メッセージがアーカイブされます。

Indexer Serviceでは、recordChangedMessages イベントを受信すると、スキーマ キャッシュから、または Schema service API を介して必要なスキーマをフェッチします。 その後、Indexer Serviceでは Elasticsearch 内に新しいインデックスを作成 (まだ存在しない場合) し、さらに一括クエリを送信して、必要に応じてレコードを作成または更新します。 Elasticsearch からの応答が、"サービス利用不可" または "要求がタイムアウトした" という種類のエラー応答である場合、Indexer Serviceでは、これらの失敗したレコード ID に対して recordChangedMessages を作成し、メッセージを Azure Service Bus に格納します。 これらのメッセージは、Indexer Queue サービスによってもう一度プルされ、前と同じフローに従います。

詳細については、インデクサー サービスに関する情報を提供するインデクサー サービスの OSDU® ドキュメントを参照してください

検索ワークフロー

Search serviceには、インデックスが作成されたメタデータ ドキュメントを検出するメカニズムが用意されています。 Search API では、地理空間検索と共に、文字列フィールドのフルテキスト検索、日付、数値、または文字列フィールドに対する範囲クエリなどをサポートします。

メタデータ レコードが Storage service を使用してプラットフォームに読み込まれると、acl フィールドでメタデータ レコードの閲覧者と所有者のアクセス許可を構成できます。 閲覧者と所有者は、Entitlement service で定義されているようにグループを介して割り当てられます。 ユーザーとして検索を実行すると、一致したメタデータ レコードは、グループに割り当てられているユーザーに対してのみ表示されます。

Search serviceに関する詳細なチュートリアルについては、Search Service の OSDU® ドキュメントを参照してください

インデックス再作成ワークフロー

Reindex API を使用すると、ユーザーは storage API を使用してレコードを再取り込みしなくても種類のインデックスを再作成できます。 詳細については、インデックス再作成の OSDU® ドキュメントを参照してください

OSDU® は The Open Group の商標です。

次のステップ