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

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

データ型

データ型の一般的な情報については、「 スカラー データ型」を参照してください。

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

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

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

• 日付時刻列は datetime として入力する必要があり、 長い データ型やその他のデータ型は入力しないでください。

  • Unix 変換マッピングの DateTime を使用します (例: DateTimeFromUnixMilliseconds)。 .

• decimal 型は正確な精度を提供するため、正確な精度を必要とする財務やその他のアプリケーションに最も適しています。 ただし、 実際 の型よりもはるかに遅いです。 必要に応じて、10 進数の型のみを使用します。

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

テーブル

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

インデックス作成

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

関連コンテンツ

• .show table schema コマンド