Partitioning ポリシー
パーティション分割ポリシーでは、特定のテーブルまたは具体化されたビューのエクステント (データ シャード) をパーティション分割するかどうか、およびその方法を定義します。
このポリシーは、データ インジェストに続いてエクステントの作成後に行われる追加のバックグラウンド プロセスをトリガーします。 このプロセスには、ソース・エクステントからのデータの再取り付けと、パーティション・キーとして指定された列のすべての値単一パーティション内に存在する同種エクステントの生成が含まれます。
パーティション分割ポリシーの主な目的は、特定の サポートされているシナリオでクエリのパフォーマンスを向上させることです。
Note
既定では、データパーティション分割ポリシーが定義されていない場合 ( null)、エクステントは作成時 (インジェスト) によってパーティション分割されます。 ほとんどの場合、データパーティション分割ポリシーを設定する必要はありません。
サポートされるシナリオ
データ パーティション分割ポリシーを設定することが推奨されるのは次のシナリオだけです。 他のすべてのシナリオでは、このポリシーの設定は推奨されません。
- 中または高カーディナリティの
stringまたはguid列に対する頻繁なフィルター:- たとえば、マルチテナント ソリューションや、ほとんどのクエリまたはすべてのクエリが
string型またはguidの列 (TenantIdやMetricIdなど) でフィルター処理するメトリック テーブルです。 - 中程度のカーディナリティは、少なくとも 10,000 個の異なる値です。
- hash パーティション キーを
stringまたはguid列に設定し、PartitionAssignmentModeプロパティをuniformに設定します。
- たとえば、マルチテナント ソリューションや、ほとんどのクエリまたはすべてのクエリが
- カーディナリティの高い
stringまたはguid列での頻繁な集計または結合:- 例: さまざまなセンサーからの IoT 情報や、さまざまな学生の学業成績。
- 高いカーディナリティは、少なくとも 1,000,000 個の異なる値であり、列の値の分布はほぼ均等です。
- この場合、頻繁にグループ化または結合される列をハッシュ パーティション キーに設定し、
PartitionAssignmentModeプロパティを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()) を使用する場合。 - クエリの大部分は、
device_IDやuser_IDなど、string型またはguid型の特定の列 (large-dimension (カーディナリティが 10M 以上) で集計/結合されます。 - パーティション分割されたテーブルが、監視アプリケーションやダッシュボード アプリケーションなどでの負荷の高いコンカレンシー実行クエリで使用される場合。
- ハッシュ剰余関数は、データをパーティション分割するために使用されます。
- 同種 (パーティション分割された) エクステントのデータは、ハッシュ パーティション キーによって順序付けられます。
- テーブルで行順序ポリシーが定義されている場合、ハッシュ パーティション キーをポリシーに含める必要はありません。
- シャッフレ戦略を使用するクエリ、
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 値に基づいて保持またはキャッシュを適用する必要がある場合があります。OverrideCreationTimeを true に設定すると、マージ プロセスでエクステントが見落とされる可能性があります。 作成時間がテーブルの Extents マージ ポリシーのLookback期間より古い場合、エクステントは見落とされます。 エクステントが検出可能であることを確認するには、 Lookback プロパティを HotCache に設定します。 |
均一範囲 datetime パーティションの例
このスニペットは、timestamp という名前 datetime 型の列に対する均一範囲 datetime パーティション キーを示しています。
datetime(2021-01-01)を参照ポイントとして使用し、パーティションごとに7dのサイズを指定し、エクステントの作成時間をオーバーライドしません。
{
"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 データベース エクステントのパーティション分割統計コマンドとパーティション分割メトリックを使用して、データベース内のポリシーが定義されたテーブルのパーティション分割状態監視できます。
パーティション分割の容量
データ パーティション分割プロセスにより、さらに多くのエクステントが作成されます。 マージ容量が徐々に増加する可能性があるため、エクステントをマージするプロセスが維持されます。
インジェスト スループットが高い場合、またはパーティション分割ポリシーが定義されているテーブルの数が十分に多い場合は、 Extents パーティション容量 が徐々に増加する可能性があるため、エクステント パーティション分割のプロセス を維持できます。
::: モニカー範囲 = "azure-data-explorer"
- リソースが過剰に消費されるのを防ぐために、これらの動的な増加には上限が設定されています。 容量を完全に使い切った場合、上限を超えて徐々に直線的に増やすことが必要になる可能性があります。
制限事項
- エクステント数が既に 5,000,000 を超えているデータベースでは、データのパーティション分割の試行が抑制されます。
- このような場合、データベース内のテーブルのパーティション 分割ポリシーの
EffectiveDateTimeプロパティは、構成とポリシーを再評価できるように、数時間の遅延が自動的に行われます。
- このような場合、データベース内のテーブルのパーティション 分割ポリシーの
パーティション分割された列の外れ値
- 次の状況は、ノード間でのデータの分散が不均衡になり、クエリのパフォーマンスが低下する可能性があります。
- ハッシュ パーティション キーに、他の値よりもはるかに一般的な値 (たとえば、空の文字列や汎用値 (
nullやN/Aなど)) が含まれている場合。 - 値は、データセットでより一般的なエンティティ (
tenant_idなど) を表します。
- ハッシュ パーティション キーに、他の値よりもはるかに一般的な値 (たとえば、空の文字列や汎用値 (
- 均一範囲の datetime パーティション キーに、列の値の大部分から "遠い" 値が十分に大きい場合、データパーティション分割プロセスのオーバーヘッドが増加し、追跡するエクステントが多数になる可能性があります。 このような状況の例として、遠い過去または将来の datetime 値があります。
どちらの場合も、データを "修正" するか、インジェスト時またはインジェスト時にデータ内の無関係なレコードを除外して、データパーティション分割のオーバーヘッドを減らします。 たとえば、更新ポリシーを使用します。