テーブルモデルの概要
Doris でテーブルを作成する際は、データの保存、重複排除、集約、更新の方法を決めるテーブルモデルを指定する必要があります。Doris には、Duplicate モデル（Duplicate Key）、Unique モデル（Unique Key）、Aggregate モデル（Aggregate Key）の三種類があります。それぞれ、元データの保持、主キーによる更新、事前集約を使った分析という典型的な用途に対応します。テーブル作成後にモデルを変更することはできないため、適切なモデルを選ぶことが重要です。
用途に応じたテーブルモデルの選択
次の表を参考に、テーブルの作成前に適切なモデルを選んでください。
| 用途 | 推奨モデル | 主な特徴 |
|---|---|---|
| ログ、イベント、行動分析など、すべての元レコードを保持する必要がある場合 | Duplicate モデル（Duplicate Key） | Key 列の値が重複してもよい。任意のディメンションを使うアドホッククエリに適している |
| リアルタイムのディメンションテーブル、注文、ユーザープロファイルなど、主キーで更新する場合 | Unique モデル（Unique Key） | Key 列の値は一意。同じ Key について最後に書き込まれたデータだけを保持する |
| レポートのロールアップ、トラフィック統計など、事前集約を必要とする定型分析 | Aggregate モデル（Aggregate Key） | Key 列で事前集約し、スキャン量と計算量を減らす |
三つのテーブルモデルの詳細
Duplicate Key モデル
- 基本的な仕組み：指定した Key 列の値は重複できます。ストレージ層は、書き込まれたすべてのデータを重複排除や集約をせずに保持します。
- 適した用途：ログ、詳細なイベント、行動ストリームなど、元データの全レコードを保持する必要がある場合。
- 利点：集約上の制約がなく、列指向ストレージの利点を十分に活用できます。クエリは必要な列だけを読み取り、すべての Key 列を読み取る必要がないため、任意のディメンションを使うアドホッククエリに適しています。
- 制限：事前集約によるクエリ高速化の恩恵は受けられません。
- 詳細：Duplicate モデル
Unique Key モデル
- 基本的な仕組み：各行の Key 値は一意です。ストレージ層は、各 Key について最後に書き込まれたデータだけを保持します。
- 適した用途：リアルタイムのディメンションテーブル、注文の状態、ユーザープロファイルなど、一意の主キー制約が必要で、データを継続的に更新する場合。
- 利点：主キーの一意性を保証し、
UPDATE文とDELETE文をサポートします。また、取り込み時には行全体の更新と一部の列の更新の両方をサポートします。 - 制限：ROLLUP などの事前集約機能によるクエリ高速化の恩恵は受けられません。
- 詳細：Unique モデル
Aggregate Key モデル
- 基本的な仕組み：Key 列ごとに Value 列を事前集約します。ストレージ層は集約結果だけを保持します。
- 適した用途：指標のロールアップ、トラフィック統計、広告クリックの集計など、ディメンションが固定されたレポート形式のクエリ。
- 利点：事前集約によって、クエリ実行時にスキャンするデータ量と必要な計算量を大幅に減らせます。
- 制限：
count(*)クエリには適していません。- Value 列の集約方法はテーブル作成時に固定されます。別の種類の集約クエリを実行する場合は、結果の意味が正しいか確認する必要があります。
- 詳細：Aggregate モデル
Unique モデルと Aggregate モデルは、どちらも列の部分更新をサポートします。使用する際の推奨事項については、Unique モデルの列の部分更新とAggregate モデルの列の部分更新を参照してください。
ソートキー
Doris ではデータを列単位で保存し、テーブルの列は次の二種類に分かれます。
- Key 列：グループ化とソートに使用します。テーブル作成時に明示的に指定します。
- Value 列：Key 列とともに保存し、集約計算に使用します。
Key 列は一つ以上のフィールドで構成できます。どのテーブルモデルを使用する場合も、テーブル作成時に Key 列を指定する必要があり、ストレージ層では Key 列に従ってデータをソートして保存します。Key 列の意味はモデルごとに少し異なります。
| テーブルモデル | Key 列の役割 |
|---|---|
| Duplicate モデル（Duplicate Key） | ソートにのみ使用し、一意性は強制しない |
| Unique モデル（Unique Key） | ソートと一意性制約に使用し、主キーによる重複排除を行う |
| Aggregate モデル（Aggregate Key） | ソートと一意性制約に使用し、Key ごとに事前集約を行う |
適切に設計されたソートキーの利点
適切に設計されたソートキーは、次の三つの点で性能を改善します。
- クエリ性能の向上：ソートキーはスキャンするデータ量を減らします。範囲クエリやフィルタークエリではソートキーに基づいてデータを直接見つけられ、ソートが必要なクエリも高速化できます。
- データ圧縮の最適化：ソートキーによって類似するデータがまとまるため、圧縮率が大きく向上し、ストレージ使用量が減ります。
- 重複排除コストの削減：Unique モデルでは、ソートキーを使うことで、Doris は主キーによる重複排除をより効率的に行い、データの一意性を保証できます。
ソートキー設計の推奨事項
Key 列を設計する際は、次の原則に従ってください。
- Key 列はすべての Value 列より前に配置する。
- 整数型を優先する：整数は文字列よりも計算と検索の効率がはるかに高くなります。
- 整数型は必要な大きさに抑える：業務で必要な範囲内で、できるだけ短い整数型を選びます。
VARCHARとSTRINGの長さは必要な範囲に抑える：過度に長いフィールド長を確保しないでください。
テーブルモデルの機能比較
次の表は、三つのテーブルモデルについて、重複排除、ビュー、更新、取り込みの違いをまとめたものです。
| 機能 | Duplicate モデル | Unique モデル | Aggregate モデル |
|---|---|---|---|
| Key 列の一意性制約 | 非対応。Key 列の値は重複可能 | 対応 | 対応 |
| 同期マテリアライズドビュー | 対応 | 対応 | 対応 |
| 非同期マテリアライズドビュー | 対応 | 対応 | 対応 |
UPDATE 文 | 非対応 | 対応 | 非対応 |
DELETE 文 | 一部対応 | 対応 | 非対応 |
| 取り込み時の行全体の更新 | 非対応 | 対応 | 非対応 |
| 取り込み時の列の部分更新 | 非対応 | 対応 | 一部対応 |
次のステップ
モデル間の違いを理解したら、それぞれの詳細なドキュメントを参照してください。
Duplicate モデル
Duplicate Key モデルのテーブル作成構文と書き込み時の動作を詳しく説明します。ログやイベントなど、元データのレコードを保持する必要がある場合に適しています。
Unique モデル
Unique Key モデルの主キーによる重複排除、UPDATE/DELETE、列の部分更新を詳しく説明します。リアルタイム更新に適しています。
Aggregate モデル
Aggregate Key モデルの事前集約の仕組みと集約関数の選び方を詳しく説明します。レポートや指標のロールアップ分析に適しています。
ベストプラクティス
テーブルモデルの選び方、Aggregate モデルの制限、テーブル作成時の Key 列とデータ型に関するベストプラクティスを説明します。