Partitioning ポリシー
パーティション分割ポリシーでは、特定のテーブルまたは具体化されたビューのエクステント (データ シャード) をパーティション分割するかどうか、およびその方法を定義します。
このポリシーは、エクステントの作成後、データ インジェストに続いて実行される追加のバックグラウンド プロセスをトリガーします。 このプロセスには、ソース エクステントからのデータの再取り込みと 同種 エクステントの生成が含まれます。このエクステントでは、 パーティション キー として指定された列のすべての値が 1 つのパーティション内に存在します。
パーティション分割ポリシーの主な目的は、サポートされている特定のシナリオでクエリのパフォーマンス を向上させることです。
注意
既定では、データ パーティション分割ポリシーが定義されていない場合 (が )、 null
エクステントは作成時 (インジェスト) によってパーティション分割されます。 ほとんどの場合、データパーティション分割ポリシーを設定する必要はありません。
サポートされるシナリオ
データ パーティション分割ポリシーを設定することが推奨されるのは次のシナリオだけです。 他のすべてのシナリオでは、このポリシーの設定は推奨されません。
- 中または高のカーディナリティまたは
guid
列に対する頻繁なstring
フィルター:- たとえば、マルチテナント ソリューション、または メトリック テーブル。ほとんどのクエリまたはすべてのクエリが、 や などの型
string
またはguid
の列でフィルター処理されますMetricId
。TenantId
- 中程度のカーディナリティは、少なくとも 10,000 個の異なる値です。
- ハッシュ パーティション キーを または
guid
列にstring
設定し、 プロパティをPartitionAssigmentMode
にuniform
設定します。
- たとえば、マルチテナント ソリューション、または メトリック テーブル。ほとんどのクエリまたはすべてのクエリが、 や などの型
- カーディナリティ
string
が高い列で頻繁に集計またはguid
結合を行う場合:- 例: さまざまなセンサーからの IoT 情報や、さまざまな学生の学業成績。
- 高いカーディナリティは、少なくとも 1,000,000 個の異なる値であり、列の値の分布はほぼ均等です。
- この場合、頻繁にグループ化または結合される列をハッシュ パーティション キーに設定し、
PartitionAssigmentMode
プロパティをByPartition
に設定します。
- 順不同のデータ インジェスト:
- データ作成時間を表し、データのフィルター処理によく使用される特定の
datetime
列に基づいて、テーブルに取り込まれたデータが順序付けられてエクステント (シャード) に分割されない場合があります。 これは、長期間にわたる datetime 値を含む異種ソース ファイルからのバックフィルが原因である可能性があります。 - この場合、
datetime
列を均一範囲 datetime パーティション キーに設定します。 - インジェストの時間ではなく、列の datetime 値に合わせたデータ保有ポリシーおよびキャッシュ ポリシーが必要な場合は、
OverrideCreationTime
プロパティをtrue
に設定します。
- データ作成時間を表し、データのフィルター処理によく使用される特定の
注意事項
- パーティション分割ポリシーが定義されたテーブルの数には、ハードコーディングされた制限は設定されていません。 ただし、テーブルを追加するたびに、クラスターのノードで実行されるバックグラウンド データパーティション分割プロセスにオーバーヘッドが追加されます。 より多くのテーブルにポリシーを設定すると、クラスター リソースが多く使用され、基になるストレージ トランザクションによるコストが高くなります。 詳細については、容量に関するセクションを参照してください。
- パーティションあたりのデータの圧縮サイズが 1 GB 未満であることが予想される場合は、パーティション分割ポリシーを設定しないことをお勧めします。
- パーティション分割プロセスでは、パーティション分割プロセス中とマージ プロセス中に置き換えられたすべてのエクステントに対して、残りのストレージ成果物が生成されます。 残りのストレージ成果物のほとんどは、自動クリーンアップ プロセス中に削除される予定です。 プロパティの値を
MaxPartitionCount
大きくすると、残りのストレージ成果物の数が増え、クリーンアップのパフォーマンスが低下する可能性があります。 - 具体化されたビューにパーティション分割ポリシーを適用する前に、具体化されたビューのパーティション分割ポリシーに関する推奨事項を確認してください。
パーティション キー
次の種類のパーティション キーがサポートされています。
種類 | 列の型 | パーティションのプロパティ | パーティション値 |
---|---|---|---|
Hash | string または guid |
Function , MaxPartitionCount , Seed , PartitionAssignmentMode |
Function (ColumnName , MaxPartitionCount , Seed ) |
均一範囲 | datetime |
RangeSize , Reference , OverrideCreationTime |
bin_at (ColumnName , RangeSize , Reference ) |
ハッシュ パーティション キー
ポリシーに "ハッシュ パーティション キー" が含まれている場合、同じパーティションに属するすべての同種エクステントが、クラスター内の同じデータ ノードに割り当てられます。
Note
データ パーティション分割操作により、大きな処理負荷がかかります。 次の条件でのみ、テーブルにハッシュ パーティション キーを適用することをお勧めします。
- ほとんどのクエリで等値フィルター (
==
、in()
) を使用する場合。 - クエリの大部分は、型
string
の特定の列、またはguid
大次元 (カーディナリティが 10M 以上) の 列 (、 など) に対して集計/user_ID
結合されますdevice_ID
。 - パーティション分割されたテーブルが、監視アプリケーションやダッシュボード アプリケーションなどでの負荷の高いコンカレンシー実行クエリで使用される場合。
- ハッシュ剰余関数は、データをパーティション分割するために使用されます。
- 同種 (パーティション分割された) エクステントのデータは、ハッシュ パーティション キーによって順序付けられます。
- テーブルで行順序ポリシーが定義されている場合、ハッシュ パーティション キーをポリシーに含める必要はありません。
- シャッフル戦略を使用し、
join
、summarize
、またはmake-series
で使用されるshuffle key
がテーブルのハッシュ パーティション キーであるクエリは、クラスター ノード間を移動する必要があるデータの量が削減されるため、パフォーマンスの向上が見込まれます。
パーティションのプロパティ
プロパティ | 説明 | サポートされる値 | 推奨値 |
---|---|---|---|
Function |
使用するハッシュ剰余関数の名前。 | XxHash64 |
|
MaxPartitionCount |
期間ごとに作成するパーティションの最大数 (ハッシュ剰余関数の剰余引数)。 | (1,2048] の範囲内。 |
値を大きくすると、クラスターのノードでのデータ パーティション分割プロセスのオーバーヘッドが増加し、各期間のエクステント数が増加します。 推奨値は 128 です。 値を大きくすると、インジェスト後のデータ パーティション分割のオーバーヘッドとメタデータのサイズが大幅に増加するため、推奨されません。 |
Seed |
ハッシュ値のランダム化に使用します。 | 正の整数。 | 1 。既定値でもあります。 |
PartitionAssignmentMode |
クラスター内のノードにパーティションを割り当てる際に使用するモード。 | ByPartition : 同じパーティションに属するすべての同種 (パーティション分割された) エクステントが同じノードに割り当てられます。 Uniform : エクステントのパーティション値は無視されます。 エクステントは、クラスターのノードに均一に割り当てられます。 |
クエリでハッシュ パーティション キーに基づいて結合または集計を実行しない場合は、Uniform を使用します。 それ以外の場合は、 ByPartition を指定します。 |
ハッシュ パーティション キーの例
tenant_id
という名前の string
型の列に対するハッシュ パーティション キー。
XxHash64
ハッシュ関数を使用し、MaxPartitionCount
を推奨値の 128
に、Seed
を既定値の 1
に設定しています。
{
"ColumnName": "tenant_id",
"Kind": "Hash",
"Properties": {
"Function": "XxHash64",
"MaxPartitionCount": 128,
"Seed": 1,
"PartitionAssignmentMode": "Uniform"
}
}
均一範囲 datetime パーティション キー
Note
テーブルの datetime
型の列に均一範囲 datetime パーティション キーを適用するのは、テーブルに取り込まれたデータが、この列に基づいて順序付けられる可能性が低い場合に限られます。
このような場合、各エクステントに限られた時間範囲のレコードが含まれるように、エクステント間でデータを再シャッフルすることができます。 このプロセスにより、クエリ時に datetime
列のフィルターがより効果的になります。
使用されるパーティション関数は bin_at() です。これはカスタマイズできません。
パーティションのプロパティ
プロパティ | 説明 | 推奨値 |
---|---|---|
RangeSize |
各 datetime パーティションのサイズを示す timespan スカラー定数。 |
値 1.00:00:00 (1 日) から開始します。 これより短い値を設定しないでください。マージできない小さなエクステントがテーブルに多数含まれる可能性があるためです。 |
Reference |
整合させる datetime パーティションに基づいて、固定された時点を示す datetime スカラー定数。 |
1970-01-01 00:00:00 で開始します。 datetime パーティション キーに null 値が含まれているレコードがある場合、そのパーティション値は値 Reference に設定されます。 |
OverrideCreationTime |
結果エクステントの最小および最大作成時間を、パーティション キーの値の範囲でオーバーライドするかどうかを示す bool 。 |
既定値は false です。 true 到着時刻の順序でデータが取り込まれない場合は に設定します。 たとえば、1 つのソース ファイルに離れた datetime 値を含めたり、インジェスト時ではなく datetime 値に基づいて保持またはキャッシュを適用したりできます。が に true 設定されている場合OverrideCreationTime 、マージ プロセスでエクステントが見逃される可能性があります。 エクステントの作成時間がテーブルのエクステント マージ ポリシーの期間よりLookback 古い場合、エクステントは見逃されます。 エクステントが検出可能であることを確認するには、 プロパティを Lookback に HotCache 設定します。 |
均一範囲 datetime パーティションの例
このスニペットは、timestamp
という名前 datetime
型の列に対する均一範囲 datetime パーティション キーを示しています。
各パーティションのサイズが の7d
参照ポイントとして を使用datetime(2021-01-01)
し、エクステントの作成時間をオーバーライドしません。
{
"ColumnName": "timestamp",
"Kind": "UniformRange",
"Properties": {
"Reference": "2021-01-01T00:00:00",
"RangeSize": "7.00:00:00",
"OverrideCreationTime": false
}
}
ポリシー オブジェクト
既定では、テーブルのデータ パーティション分割ポリシーは です null
。この場合、テーブル内のデータは取り込まれた後に再パーティション分割されません。
データ パーティション分割ポリシーには、次の主要プロパティがあります。
PartitionKeys:
- テーブル内のデータをパーティション分割する方法を定義するパーティション キーのコレクション。
- テーブルには、最大
2
つのパーティション キーを設定できます。次のいずれかのオプションを使用します。- 1 つのハッシュ パーティション キー。
- 1 つの均一範囲 datetime パーティション キー。
- 1 つのハッシュ パーティション キーと 1 つの均一範囲 datetime パーティション キー。
- 各パーティション キーには次のプロパティがあります。
ColumnName
:string
- パーティション分割するデータに応じた列の名前。Kind
:string
- 適用するデータ パーティション分割の種類 (Hash
またはUniformRange
)。Properties
:property bag
- 実行されるパーティション分割に応じてパラメーターを定義します。
EffectiveDateTime:
- ポリシーが有効になる UTC 日時。
- このプロパティは省略可能です。 指定されていない場合は、ポリシーが適用された後に取り込まれたデータに対してポリシーが有効になります。
注意事項
- 過去の datetime 値を設定し、既に取り込まれているデータをパーティション分割できます。 ただし、この方法では、パーティション分割プロセスで使用されるリソースが大幅に増加する可能性があります。
- ほとんどの場合、新しく取り込まれたデータだけをパーティション分割し、大量の過去のデータをパーティション分割しないようにすることをお勧めします。
- 過去のデータをパーティション分割する場合は、ポリシーを変更するたびに、EffectiveDateTime を最大数日単位で以前の
datetime
に設定して、徐々に行うことを検討してください。
データ パーティション分割の例
2 つのパーティション キーを持つデータ パーティション分割ポリシー オブジェクト。
tenant_id
という名前のstring
型の列に対するハッシュ パーティション キー。XxHash64
ハッシュ関数を使用し、MaxPartitionCount
を推奨値の128
に、Seed
を既定値の1
に設定しています。
timestamp
という名前のdatetime
型の列に対する均一範囲 datetime パーティション キー。datetime(2021-01-01)
を基準点として使用し、各パーティションのサイズを7d
に設定しています。
{
"PartitionKeys": [
{
"ColumnName": "tenant_id",
"Kind": "Hash",
"Properties": {
"Function": "XxHash64",
"MaxPartitionCount": 128,
"Seed": 1,
"PartitionAssignmentMode": "Uniform"
}
},
{
"ColumnName": "timestamp",
"Kind": "UniformRange",
"Properties": {
"Reference": "2021-01-01T00:00:00",
"RangeSize": "7.00:00:00",
"OverrideCreationTime": false
}
}
]
}
追加のプロパティ
ポリシーの一部として次のプロパティを定義できます。 これらのプロパティは省略可能であり、変更しないことをお勧めします。
プロパティ | 説明 | 推奨値 | 既定値 |
---|---|---|---|
MinRowCountPerOperation | 1 つのデータ パーティション分割操作のソース エクステントの行数の合計に対応する最小ターゲット。 | 0 |
|
MaxRowCountPerOperation | 1 つのデータ パーティション分割操作のソース エクステントの行数の合計に対応する最大ターゲット。 | パーティション分割操作で操作ごとに大量のメモリまたは CPU が消費される場合は、5M 未満の値を設定します。 | 0 。既定のターゲットは 5,000,000 レコードです。 |
MaxOriginalSizePerOperation | 1 つのデータ パーティション分割操作のソース エクステントの元のサイズ (バイト単位) の合計に対応する最大ターゲット。 | パーティション分割操作で操作ごとに大量のメモリまたは CPU が消費される場合は、5 GB 未満の値を設定します。 | 0 。既定のターゲットは 5,368,709,120 バイト (5 GB) です。 |
データ パーティション分割プロセス
- データ パーティション分割は、クラスターでインジェスト後のバックグラウンド プロセスとして実行されます。
- 継続的に取り込まれるテーブルには、パーティション分割されていないデータの "尾" が常に存在することが想定されます (異種エクステント)。
- ポリシーの
EffectiveDateTime
プロパティの値に関係なく、データ パーティション分割はホット エクステントでのみ実行されます。- コールド エクステントのパーティション分割が必要な場合は、キャッシュ ポリシーを一時的に調整する必要があります。
.show database extents partitioning statistics コマンドを使用すると、データベース内のポリシーが定義されたテーブルのパーティション分割の状態を監視できます。
パーティション分割の容量
- データ パーティション分割プロセスにより、さらに多くのエクステントが作成されます。 クラスターはエクステントのマージ容量を徐々に増やすことができるので、エクステントをマージするプロセスに対応できます。
- インジェスト スループットが高い場合、またはパーティション分割ポリシーが定義されている十分な数のテーブルがある場合、クラスターはエクステントのパーティション容量を徐々に増やすことができるので、エクステントをパーティション分割するプロセスに対応できます。
- リソースが過剰に消費されるのを防ぐために、これらの動的な増加には上限が設定されています。 容量を完全に使い切った場合、上限を超えて徐々に直線的に増やすことが必要になる可能性があります。
制限事項
- エクステント数が既に 5,000,000 を超えているデータベースでは、データのパーティション分割の試行が抑制されます。
- このような場合、
EffectiveDateTime
データベース内のテーブルのパーティション分割ポリシーのプロパティは、構成とポリシーを再評価できるように、自動的に数時間遅れます。
- このような場合、
パーティション分割された列の外れ値
- 次の状況は、クラスターのノード間でのデータの分散に偏りが生じる一因となり、クエリのパフォーマンスが低下する可能性があります。
- ハッシュ パーティション キーに、他の値よりもはるかに一般的な値 (たとえば、空の文字列や汎用値 (
null
やN/A
など)) が含まれている場合。 - 値は、データセットでより一般的なエンティティ (など
tenant_id
) を表します。
- ハッシュ パーティション キーに、他の値よりもはるかに一般的な値 (たとえば、空の文字列や汎用値 (
- 均一範囲 datetime パーティション キーに含まれている値の多くが、列のほとんどの値から "かけ離れている" 場合、データ パーティション分割プロセスのオーバーヘッドが増加し、クラスターが追跡する必要がある小さなエクステントが多数作成される可能性があります。 このような状況の例として、遠い過去または将来の datetime 値があります。
どちらの場合も、データを "修正" するか、インジェスト前またはインジェスト時にデータ内の無関係なレコードを除外して、クラスターでのデータ パーティション分割のオーバーヘッドを削減します。 たとえば、更新ポリシーを使用します。
関連コンテンツ
フィードバック
https://aka.ms/ContentUserFeedback」を参照してください。
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「フィードバックの送信と表示