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:

  • EffectiveDateTime:

    • ポリシーが有効になる UTC 日時。
    • このプロパティは省略可能です。 指定されていない場合は、ポリシーが適用された後に取り込まれたデータに対してポリシーが有効になります。

注意事項

  • 過去の datetime 値を設定し、既に取り込まれているデータをパーティション分割できます。 ただし、この方法では、パーティション分割プロセスで使用されるリソースが大幅に増加する可能性があります。
  • ほとんどの場合、新しく取り込まれたデータだけをパーティション分割し、大量の過去のデータをパーティション分割しないようにすることをお勧めします。
  • 過去のデータをパーティション分割する場合は、ポリシーを変更するたびに、EffectiveDateTime を最大数日単位で以前の datetime に設定して、徐々に行うことを検討してください。

データ パーティション分割の例

2 つのパーティション キーを持つデータ パーティション分割ポリシー オブジェクト。

  1. tenant_id という名前の string 型の列に対するハッシュ パーティション キー。
    • XxHash64 ハッシュ関数を使用し、MaxPartitionCount を推奨値の 128 に、Seed を既定値の 1 に設定しています。
  2. 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 値があります。

どちらの場合も、データを "修正" するか、インジェスト前またはインジェスト時にデータ内の無関係なレコードを除外して、クラスターでのデータ パーティション分割のオーバーヘッドを削減します。 たとえば、更新ポリシーを使用します。

関連コンテンツ