次の方法で共有


スキーマ最適化のベスト プラクティス

テーブル スキーマは、テーブル内のすべての列の名前と データ型 を定義します。 テーブル スキーマは、テーブルの作成時に設定することも、該当するインジェスト マッピングを変更してデータ インジェスト プロセスの一部として設定することもできます。 テーブル スキーマの定義方法は、クエリのパフォーマンスに大きな影響を与える可能性があります。 データに最適なスキーマは、ユース ケース、データ アクセス パターン、格納する予定の特定のデータなど、さまざまな要因によって異なります。 この記事では、効率的なスキーマを設計してパフォーマンスを最適化するためのベスト プラクティスについて説明します。

データ型

データ型の一般的な情報については、スカラー データ型に関するページをご覧ください。

  • 一般的に使用されるフィールドは、動的な型ではなく、型指定された列にする必要があります。

  • 動的列で頻繁に検索または集計される JSON プロパティは、文字列longreal などのより具体的な型を持つテーブルの通常の列に変換する必要があります。

  • フィルターと集計に一般的には使用されないスパース列は、DropMappedFields マッピング変換を使用して、動的列のプロパティ バッグとして収集する必要があります。

  • 日時列は、long データ型やその他のデータ型ではなく、datetime として型指定する必要があります。

    • たとえば DateTimeFromUnixMilliseconds、Unix 変換マッピングの DateTime を使用します。 =
  • 10 進型は正確な精度を提供するため、正確な精度を必要とする財務やその他のアプリケーションに最も適しています。 ただし、実際の型よりもはるかに遅くなります。 必要な場合にのみ、10 進型を使用します。

  • すべての ID (識別) 列は、数値ではなく文字列として型指定する必要があります。 この型により、インデックスの効果が大幅に向上し、検索時間が大幅に短縮されます。 パーティション分割は文字列列でのみ定義できるため、パーティション分割も有効になります。 この列で使用されるクエリ フィルターが等値のみの場合 (たとえば、列に guid がある場合)、エンコード プロファイル Identifierを使用できます。 詳細については、エンコーディング ポリシーを参照してください。

Tables

  • 狭いテーブルを最適化します。これは、数百の列を持つ広いテーブルよりも優先されます。
  • クエリ時間中に費用のかかる結合を回避するには、インジェスト中にディメンション データをエンリッチすることでディメンション データを非正規化します。 エンリッチメントに使用されるディメンション テーブルが更新され、シナリオで最新の値が必要な場合は、具体化されたビューを使用して最新の値のみを保持します。
  • スパースな列が 20 を超える場合、つまり多くの値が null であり、これらの列が検索や集計にほとんど使用されない場合は、DropMappedFields 変換マッピングを使用して、列を JSON プロパティ バッグとして動的列にグループ化します。

インデックス作成

検索されないフィールドは、インデックス作成を無効にすることができます。 エンコード ポリシーとプロファイル BigObject を使用して、文字列または動的に型指定された列のインデックス作成を無効にします。