次の方法で共有

FHIR サービスのパフォーマンスを向上するためのベスト プラクティス

このドキュメントでは、Azure Health Data Services FHIR® サービスのベスト プラクティスに関するガイダンスを紹介します。 FHIR サービスのパフォーマンスを向上させるために 、実行、 検討、または 回避 する必要があるプラクティスが見つかります。

注

このドキュメントは、Azure Health Data Services FHIR サービスのお客様を対象としています。

データ インジェスト

インポート操作

Azure FHIR サービスでは、インポート操作によるデータ インジェストがサポートされています。この操作では、初期モードと増分モードの 2 つのモードが提供されます。 詳細なガイダンスについては、 FHIR サービスドキュメントへのデータのインポートを 参照してください。

インポート操作で最適なパフォーマンスを実現するには、次のベスト プラクティスを検討してください。

  • データの取り込み中は大きなファイルを使用する。 インポートに最適な NDJSON ファイル サイズは 50 MB 以上 (または上限なしで 20,000 リソース以上) です。 小さいファイルを大きなファイルに結合すると、パフォーマンスが向上します。
  • HTTP API 要求に対するインポート操作を使用して、FHIR サービスにデータを取り込むことを検討する。 インポート操作は高スループットを提供します。データを読み込むためのスケーラブルな方法です。
  • 最適なパフォーマンスを得られるように、すべての FHIR リソース ファイルを 1 回のインポート操作でインポートすることを検討する。 1 回の操作で、合計ファイル サイズが 100 GB 以上 (または 1 億リソース、上限なし) を目指します。 この方法でインポートを最大化すると、複数のインポート ジョブの管理に関連付けられるオーバーヘッドを軽減できます。
  • スループットを向上させるために、同じリソースの種類にマッピングされたリソースを使用してインポート ジョブを実行することを検討してください。
  • 必要な場合にのみ複数の同時インポートを実行することを検討し、並列インポート ジョブは制限する。 単一の大規模なインポートは、使用可能なすべてのシステム リソースを消費するよう設計されており、同時実行のインポート ジョブでは処理スループットが増加しません。

バンドル

Azure FHIR サービスでは、バンドルは複数のリソースのコンテナーとして機能します。 バッチおよびトランザクション バンドルを使用すると、ユーザーは 1 つの HTTP 要求または応答でアクションのセットを送信できます。 バンドル インジェストを使用して高いスループットを実現するには、次の点を検討してください。

  • Azure FHIR サービスの負荷を線形的に生成し、バースト操作を回避してパフォーマンスの低下を防ぐ。
  • FHIR サーバーに対する同時実行のバンドル要求の数を調整する。 数値が大きい (>100) と、負のスケーリングが発生し、処理スループットが低下する可能性があります。
  • 相互に依存せず、個別に更新できる FHIR リソースには、個別のトランザクション バンドルを使用してください。
  • 条件付き作成や更新などの複雑な操作には、より小さなバンドル サイズを使用することを検討してください。
  • バッチ バンドルとトランザクション バンドルの並列処理を有効にすることを検討する。 既定では、バンドル内のリソースは順番に処理されます。 スループットを向上させるには、HTTP ヘッダー フラグを x-bundle-processing-logic 追加し、 parallelに設定することで、並列リソース処理を有効にすることができます。 詳細については、「バッチ バンドルの並列処理に関するドキュメント」を参照してください。
  • 同じリソースを同時に更新しようとする並列バンドル要求の送信を避ける。これにより、処理で遅延が発生する可能性があります。
  • 1 つの PUT または POST 要求で多数のバンドルを送信しないようにすると、トランザクションのボトルネックが発生する可能性があります。

注

x-bundle-processing-logic フラグを使用した並列バンドル処理は、HTTP 操作内のリソースの順序に暗黙的な依存関係がない場合にスループットを向上させることができます。

検索パラメーターのインデックスのチューニング

Azure FHIR サービスは、リソースごとに定義済みの検索パラメーターを使用してプロビジョニングされます。 検索パラメーターでは使いやすく効率的な検索を実現するために、インデックスが作成されます。 インデックスは、FHIR サービスの書き込みごとに更新されます。 選択可能な検索パラメーターを使用すると、組み込みの検索パラメーター インデックスを有効または無効にすることができます。 この機能は、必要な検索パラメーターのみを有効にすることで、ストレージの使用とパフォーマンスを最適化するのに役立ちます。 関連する検索パラメーターに注目すると、インジェスト中に取得されるデータの量を最小限に抑えることができます。

組織がパフォーマンスの最適化に使用しない検索インデックスを無効にすることを検討してください。

クエリ パフォーマンスの最適化

データ インジェスト後は、クエリのパフォーマンスを最適化することが重要です。 最適なパフォーマンスを確保するには:

  • Azure FHIR サービスの負荷を線形的に生成し、バースト操作を回避してパフォーマンスの低下を防ぐ。
  • インデックスの使用を最適化するには、カーディナリティが低いパラメーターに対して最も選択的な検索パラメーター (たとえば、) を使用identifierしてください。
  • 論理識別子を使用して決定論的な検索を実行することを検討する。 FHIR サービスには、リソースを識別する 2 つの方法 (論理識別子とビジネス識別子) が用意されています。
    論理識別子は「決定論的」と見なされます。論理識別子で実行される FHIR 操作は予測可能であるためです。 ビジネス識別子は、システムの状態によって動作が異なるため、「条件付き」と見なされます。 論理識別子を使用して、決定論的な操作を行うことをおすすめします。
  • 該当する場合は、POST の代わりに HTTP 動詞を使用PUT。 PUT 要求は、データの整合性を維持し、リソース管理を最適化するのに役立ちます。 POST 要求は、リソースの重複、データ品質の低下、および FHIR データ サイズの不必要な増加につながる可能性があります。
  • 結果セットが無制限になり、待機時間が長くなる可能性があるため、検索クエリでを使用_revincludeします。
  • クエリのパフォーマンスに影響を与える複雑な検索 (、チェーン検索パラメーターなど) は使用_has。

データ抽出

データの抽出には、$exportで指定されている一括操作を使用します。

  • スループットを最大化するためにフィルターを使用しない場合は、システム レベルのエクスポートに大きなデータ ブロックを使用してください。 Azure FHIR サービスは、それらを自動的に並列ジョブに分割します。
  • 患者、グループ、フィルター処理されたシステムのエクスポートを、エクスポート用の小さなデータ ブロックに分割することを検討してください。

エクスポート操作の詳細については、「FHIR データをエクスポートする」をご覧ください。

FHIR リソースへのバイナリ データの格納

  • FHIR リソース内に base64 でエンコードされた文字列として小さなペイロード (最大 2 MB) を格納します。
  • より大きなバイナリ データには外部ストレージ ソリューションを使用することを検討してください。 非効率性を回避するために、バイナリ データを BLOB ストレージに格納し、URL を使用して FHIR リソースで参照します。
  • 大きなバイナリ ファイルを小さなチャンク (2 MB 未満) に分割し、それらを個別のバイナリ リソースとして格納し、FHIR リソースを使用して一緒にリンクすることを検討してください。
  • FHIR リソース内に大きなバイナリ データを直接格納することは避けてください。これは、インポート、エクスポート、検索などの FHIR サービス機能の制限と非効率性につながる可能性があるためです。

これらのベスト プラクティスを適用して、Azure FHIR サービスでのデータ インジェスト、バンドル処理、クエリ実行、データ抽出のパフォーマンスと効率を向上させることができます。

注

FHIR® は HL7 の登録商標であり、HL7 の許可を得て使用しています。