Tableモデル概要
DorisでTableを作成する際、データの保存と管理方法を定義するためにTableモデルを指定する必要があります。Dorisは3つのTableモデルを提供しています:Duplicate Key Model、Unique Key Model、Aggregate Key Modelで、これらは異なるアプリケーションシナリオに対応します。各モデルには、データの重複排除、集約、および更新に対応するメカニズムがあります。適切なTableモデルを選択することで、データ処理の柔軟性と効率性を確保しながら、ビジネス目標の達成に役立ちます。
Tableモデルの分類
Dorisは3種類のTableモデルをサポートしています:
-
Duplicate Key Model:指定されたKeyカラムの重複を許可し、Dorisのストレージ層は書き込まれたすべてのデータを保持します。このモデルは、すべての元データレコードを保持する必要がある状況に適しています。
-
Unique Key Model:各行が一意のKey値を持つことを保証し、指定されたKeyカラムに重複する行がないことを保証します。Dorisストレージ層は各キーについて最新の書き込みデータのみを保持するため、このモデルはデータ更新を伴うシナリオに適しています。
-
Aggregate Key Model:Keyカラムに基づいてデータを集約することを可能にします。Dorisストレージ層は集約されたデータを保持し、ストレージスペースを削減してクエリパフォーマンスを向上させます。このモデルは通常、要約または集約情報(合計や平均など)が必要な状況で使用されます。
Table作成後、Tableモデルのプロパティは確定され、変更することはできません。ビジネスに適したモデルを選択することは重要です:
-
Duplicate Key Modelは任意の次元でのアドホッククエリに適しています。事前集約の利点を活用することはできませんが、集約モデルに制約されることがなく、列指向ストレージモデルの利点を活用できます(すべてのキーカラムを読み取る必要なく、関連するカラムのみを読み取り)。
-
Unique Key Modelは一意キー制約が必要なシナリオ向けに設計されており、キーの一意性を保証します。しかし、ROLLUPなどの事前集約によってもたらされるクエリの利点を活用することはできません。
-
Aggregate Key Modelは事前集約を通じて集約クエリに必要なデータと計算を大幅に削減でき、固定スキーマのレポーティングクエリに理想的です。ただし、このモデルは
count(*)クエリには適していません。また、Valueカラムの集約方法が固定されているため、他のタイプの集約クエリを実行する際には、セマンティクスの正確性を考慮する必要があります。 -
部分カラム更新については、Unique Key Modelでの部分カラム更新およびAggregate Modelでの部分カラム更新のドキュメントを参照して、関連する使用方法のアドバイスを確認してください。
Sort Key
Dorisでは、データは列指向形式で保存され、TableはKeyカラムとValueカラムに分割できます。Keyカラムはグループ化とソートに使用され、Valueカラムは集約に使用されます。Keyカラムは1つ以上のフィールドで構成でき、Table作成時にデータはAggregate Key、Unique Key、Duplicate Keyモデルのカラムに従ってソートされ保存されます。
異なるTableモデルでは、Table作成時にKeyカラムの指定が必要で、それぞれ異なる意味を持ちます:Duplicate Key modelの場合、Keyカラムはソートを表し、一意性制約はありません。Aggregate KeyおよびUnique Keyモデルでは、Keyカラムに基づいて集約が実行され、ソート機能を持つだけでなく一意性制約も適用されます。
Sort Keyを適切に使用することで、以下の利点が得られます:
-
クエリパフォーマンスの向上:ソートキーはスキャンが必要なデータ量を削減するのに役立ちます。範囲クエリやフィルタリングクエリの場合、ソートキーはデータを直接特定できます。ソートが必要なクエリの場合、ソートキーはソートプロセスを高速化することもできます。
-
データ圧縮の最適化:ソートキーに基づいてデータを順序立てて保存することで圧縮効率が向上し、類似のデータがグループ化されるため、圧縮率が大幅に向上し、ストレージスペースが削減されます。
-
重複排除コストの削減:Unique Key Modelを使用する際、ソートキーによりDorisはより効率的に重複排除を実行でき、データの一意性を保証します。
ソートキーを選択する際は、以下の推奨事項に従うことができます:
-
KeyカラムはすべてのValueカラムより前に配置する必要があります。
-
整数型を選択することが望ましいです。これは、整数型が文字列よりも計算と検索において大幅に効率的であるためです。
-
異なる長さの整数型を選択する場合は、十分なものを選択するという原則に従います。
-
VARCHARおよびSTRING型の長さについては、十分なものを選択するという原則に従います...
Tableモデル比較
| Duplicate Key Model | Unique Key Model | Aggregate Key Model | |
|---|---|---|---|
| Keyカラムの一意性 | サポートなし、Keyカラムの重複可能 | サポート | サポート |
| 同期マテリアライズドビュー | サポート | サポート | サポート |
| 非同期マテリアライズドビュー | サポート | サポート | サポート |
| UPDATE文 | サポートなし | サポート | サポートなし |
| DELETE文 | 部分的にサポート | サポート | サポートなし |
| インポート時の全行更新 | サポートなし | サポート | サポートなし |
| インポート時の部分カラム更新 | サポートなし | サポート | 部分的にサポート |