Partitionierungsrichtlinie

Die Partitionierungsrichtlinie definiert, ob und wie Blöcke (Datenshards) für eine bestimmte Tabelle oder eine materialisierte Sicht partitioniert werden sollen.

Die Richtlinie löst einen zusätzlichen Hintergrundprozess aus, der nach der Erstellung von Blöcken nach der Datenerfassung stattfindet. Dieser Prozess umfasst das erneute Erfassen von Daten aus den Quellausdehnungen und das Erstellen homogener Blöcke, in denen sich alle Werte der als Partitionsschlüssel bezeichneten Spalte in einer einzelnen Partition befinden.

Das primäre Ziel der Partitionierungsrichtlinie besteht darin, die Abfrageleistung in bestimmten unterstützten Szenarien zu verbessern.

Hinweis

Wenn keine Datenpartitionierungsrichtlinie definiert ist (ist null), werden Blöcke standardmäßig nach Erstellungszeitpunkt (Erfassung) partitioniert. In den meisten Fällen ist es nicht erforderlich, eine Datenpartitionierungsrichtlinie festzulegen.

Unterstützte Szenarios

Im Folgenden sind die einzigen Szenarien aufgeführt, in denen das Festlegen einer Datenpartitionierungsrichtlinie empfohlen wird. In allen anderen Szenarien wird das Festlegen der Richtlinie nicht empfohlen.

  • Häufige Filter für eine mittlere oder hohe Kardinalität string oder guid Spalte:
    • Beispiel: mehrinstanzenfähige Lösungen oder eine Metriktabelle, in der die meisten oder alle Abfragen nach einer Spalte vom Typ string oder guidfiltern, z TenantId . B. oder MetricId.
    • Mittlere Kardinalität beträgt mindestens 10.000 unterschiedliche Werte.
    • Legen Sie den Hashpartitionsschlüssel auf die string Spalte oder fest guid , und legen Sie die PartitionAssigmentMode -Eigenschaft auf fest uniform.
  • Häufige Aggregationen oder Verknüpfungen für eine hohe Kardinalität string oder guid Spalte:
    • Beispielsweise IoT-Informationen von vielen verschiedenen Sensoren oder akademische Datensätze von vielen verschiedenen Studenten.
    • Hohe Kardinalität beträgt mindestens 1.000.000 unterschiedliche Werte, wobei die Verteilung der Werte in der Spalte ungefähr gleich ist.
    • Legen Sie in diesem Fall den Hashpartitionsschlüssel auf die Spalte fest, die häufig nach gruppiert oder verknüpft ist, und legen Sie die PartitionAssigmentMode -Eigenschaft auf fest ByPartition.
  • Nicht ordnungsgemäß erfasste Daten:
    • Daten, die in einer Tabelle erfasst werden, werden möglicherweise nicht sortiert und in Blöcke (Shards) gemäß einer bestimmten datetime Spalte, die den Zeitpunkt der Datenerstellung darstellt und häufig zum Filtern von Daten verwendet wird, in Blöcken (Shards) partitioniert. Dies kann auf eine Verfüllung aus heterogenen Quelldateien zurückzuführen sein, die datetime-Werte über einen großen Zeitraum enthalten.
    • Legen Sie in diesem Fall den partitionierten Datetime-Partitionsschlüssel für den einheitlichen Bereich auf die datetime Spalte fest.
    • Wenn Aufbewahrungs- und Zwischenspeicherungsrichtlinien an den datetime-Werten in der Spalte ausgerichtet werden sollen, legen Sie die OverrideCreationTime -Eigenschaft auf truefest, anstatt sich am Zeitpunkt der Erfassung auszurichten.

Achtung

  • Es sind keine hartcodierten Grenzwerte für die Anzahl von Tabellen festgelegt, für die die Partitionierungsrichtlinie definiert ist. Jede zusätzliche Tabelle erhöht jedoch den Mehraufwand für die Datenpartitionierung im Hintergrund, der auf den Knoten des Clusters ausgeführt wird. Das Festlegen einer Richtlinie für mehr Tabellen führt dazu, dass mehr Clusterressourcen verwendet werden und die Kosten aufgrund der zugrunde liegenden Speichertransaktionen höher sind. Weitere Informationen finden Sie unter Kapazität.
  • Es wird nicht empfohlen, eine Partitionierungsrichtlinie festzulegen, wenn die komprimierte Größe der Daten pro Partition voraussichtlich kleiner als 1 GB ist.
  • Der Partitionierungsprozess führt zu Restspeicherartefakten für alle Blöcke, die während des Partitionierungsprozesses und während des Mergeprozesses ersetzt wurden. Es wird erwartet, dass die meisten Restspeicherartefakte während des automatischen Bereinigungsprozesses gelöscht werden. Wenn Sie den Wert der MaxPartitionCount Eigenschaft erhöhen, erhöht sich die Anzahl der verbleibenden Speicherartefakte und kann die Bereinigungsleistung verringern.
  • Bevor Sie eine Partitionierungsrichtlinie auf eine materialisierte Sicht anwenden, überprüfen Sie die Empfehlungen für die Partitionierungsrichtlinie für materialisierte Sichten.

Partitionsschlüssel

Die folgenden Arten von Partitionsschlüsseln werden unterstützt.

Variante Spaltentyp Partitionseigenschaften Partitionswert
Hash string oder guid Function, MaxPartitionCount, Seed, PartitionAssignmentMode Function(ColumnName, MaxPartitionCount, Seed)
Einheitlicher Bereich datetime RangeSize, Reference, OverrideCreationTime bin_at(ColumnName, RangeSize, Reference)

Hashpartitionsschlüssel

Wenn die Richtlinie einen Hashpartitionsschlüssel enthält, werden alle homogenen Blöcke, die zu derselben Partition gehören, demselben Datenknoten im Cluster zugewiesen.

Hinweis

Der Datenpartitionierungsvorgang führt zu einer erheblichen Verarbeitungslast. Es wird empfohlen, einen Hashpartitionsschlüssel nur unter den folgenden Bedingungen auf eine Tabelle anzuwenden:

  • Wenn die Mehrheit der Abfragen Gleichheitsfilter (==, in()) verwendet.
  • Der Großteil der Abfragen aggregiert/verknüpft für eine bestimmte Spalte vom Typ string oder guid eine große Dimension (Kardinalität von 10M oder höher), z. B. , device_IDoder user_ID.
  • Das Verwendungsmuster der partitionierten Tabellen weist eine hohe Parallelitätsabfragelast auf, z. B. in Überwachungs- oder Dashboardanwendungen.
  • Eine hash-modulo-Funktion wird verwendet, um die Daten zu partitionieren.
  • Daten in homogenen (partitionierten) Blöcken werden nach dem Hashpartitionsschlüssel sortiert.
    • Sie müssen den Hashpartitionsschlüssel nicht in die Zeilenreihenfolgerichtlinie einschließen, wenn einer in der Tabelle definiert ist.
  • Abfragen, die die Shufflestrategie verwenden und bei denen der shuffle key in joinverwendet summarize wird oder make-series der Hashpartitionsschlüssel der Tabelle ist, wird erwartet, dass sie eine bessere Leistung erbringen, da die Zum Verschieben zwischen Clusterknoten erforderliche Datenmenge geringer ist.

Partitionseigenschaften

Eigenschaft BESCHREIBUNG Unterstützte Werte Empfohlener Wert
Function Der Name einer zu verwendenden Hashmodulo-Funktion. XxHash64
MaxPartitionCount Die maximale Anzahl der zu erstellenden Partitionen (das modulo-Argument für die hash-modulo-Funktion) pro Zeitraum. Im Bereich (1,2048]. Höhere Werte führen zu einem höheren Mehraufwand für den Datenpartitionierungsprozess auf den Knoten des Clusters und zu einer höheren Anzahl von Blöcken für jeden Zeitraum. Empfohlener Wert: 128. Höhere Werte erhöhen den Mehraufwand für die Partitionierung der Daten nach der Erfassung und die Größe der Metadaten erheblich und werden daher nicht empfohlen.
Seed Verwenden Sie zum Zufälligen des Hashwerts. Eine positive ganze Zahl 1, der auch der Standardwert ist.
PartitionAssignmentMode Der Modus, der zum Zuweisen von Partitionen zu Knoten im Cluster verwendet wird. ByPartition: Alle homogenen (partitionierten) Blöcke, die zu derselben Partition gehören, werden demselben Knoten zugewiesen.
Uniform: Die Partitionswerte eines Bereichs werden ignoriert. Blöcke werden den Knoten des Clusters einheitlich zugewiesen.
Wenn Abfragen nicht mit dem Hashpartitionsschlüssel verknüpft oder aggregiert werden, verwenden Sie Uniform. Verwenden Sie andernfalls ByPartition.

Beispiel für Hashpartitionsschlüssel

Ein Hashpartitionsschlüssel über einer string-typisierten Spalte namens tenant_id. Es verwendet die XxHash64 Hashfunktion, wobei MaxPartitionCount auf den empfohlenen Wert 128festgelegt ist, und der Standardwert Seed1.

{
  "ColumnName": "tenant_id",
  "Kind": "Hash",
  "Properties": {
    "Function": "XxHash64",
    "MaxPartitionCount": 128,
    "Seed": 1,
    "PartitionAssignmentMode": "Uniform"
  }
}

Partitionsschlüssel für den uniformen Bereich datetime

Hinweis

Wenden Sie nur einen partitionierten Datetime-Partitionsschlüssel für einen einheitlichen Bereich auf eine datetimeSpalte vom Typ -in einer Tabelle an, wenn es unwahrscheinlich ist, dass die in die Tabelle erfassten Daten gemäß dieser Spalte sortiert werden.

In diesen Fällen können Sie die Daten zwischen Blöcken neu mischen, sodass jede Blöcke Datensätze aus einem begrenzten Zeitraum enthält. Dieser Prozess führt dazu, dass Filter für die datetime Spalte zur Abfragezeit effektiver sind.

Die verwendete Partitionsfunktion ist bin_at() und kann nicht angepasst werden.

Partitionseigenschaften

Eigenschaft BESCHREIBUNG Empfohlener Wert
RangeSize Eine timespan Skalarkonstante, die die Größe jeder datetime-Partition angibt. Beginnen Sie mit dem Wert 1.00:00:00 (ein Tag). Legen Sie keinen kürzeren Wert fest, da dies dazu führen kann, dass die Tabelle eine große Anzahl kleiner Blöcke aufweist, die nicht zusammengeführt werden können.
Reference Eine datetime Skalarekonstante, die einen festen Zeitpunkt angibt, nach dem datetime-Partitionen ausgerichtet werden. Beginnen Sie mit 1970-01-01 00:00:00. Wenn Datensätze vorhanden sind, in denen der datetime-Partitionsschlüssel Werte enthält null , wird deren Partitionswert auf den Wert von Referencefestgelegt.
OverrideCreationTime Ein bool , der angibt, ob die minimalen und maximalen Erstellungszeiten des Ergebnisumfangs durch den Bereich der Werte im Partitionsschlüssel überschrieben werden sollen. Der Standardwert lautet false. Legen Sie auf true fest, wenn Daten nicht in der Reihenfolge der Ankunft erfasst werden. Beispielsweise kann eine einzelne Quelldatei datetime-Werte enthalten, die entfernt sind, und/oder Sie möchten die Aufbewahrung oder Zwischenspeicherung basierend auf den datetime-Werten anstelle der Erfassungszeit erzwingen.

Wenn OverrideCreationTime auf truefestgelegt ist, können Erweiterungen im Mergeprozess übersehen werden. Erweiterungen werden übersehen, wenn ihre Erstellungszeit älter ist als der Lookback Zeitraum der Zusammenführungsrichtlinie für Blöcke der Tabelle. Um sicherzustellen, dass die Ausdehnungen auffindbar sind, legen Sie die Lookback -Eigenschaft auf HotCachefest.

Beispiel für eine Uniform Range-Datetime-Partition

Der Codeausschnitt zeigt einen gleichmäßigen Datetime-Bereichspartitionsschlüssel über einer datetime typisierten Spalte mit dem Namen timestamp. Sie verwendet datetime(2021-01-01) als Bezugspunkt die Größe für 7d jede Partition und überschreibt nicht die Erstellungszeiten der Erweiterungen.

{
  "ColumnName": "timestamp",
  "Kind": "UniformRange",
  "Properties": {
    "Reference": "2021-01-01T00:00:00",
    "RangeSize": "7.00:00:00",
    "OverrideCreationTime": false
  }
}

Das Richtlinienobjekt

Standardmäßig lautet nulldie Datenpartitionierungsrichtlinie einer Tabelle. In diesem Fall werden die Daten in der Tabelle nach der Erfassung nicht neu partitioniert.

Die Datenpartitionierungsrichtlinie verfügt über die folgenden Standard Eigenschaften:

  • PartitionKeys:

  • EffectiveDateTime:

    • Die UTC-Datumstime, ab der die Richtlinie wirksam ist.
    • Diese Eigenschaft ist optional. Wenn sie nicht angegeben ist, wird die Richtlinie für daten wirksam, die nach dem Anwenden der Richtlinie erfasst wurden.

Achtung

  • Sie können einen datetime-Wert in der Vergangenheit festlegen und bereits erfasste Daten partitionieren. Diese Vorgehensweise kann jedoch die im Partitionierungsprozess verwendeten Ressourcen erheblich erhöhen.
  • In den meisten Fällen empfiehlt es sich, nur neu erfasste Daten zu partitionieren und eine Partitionierung großer Mengen von Verlaufsdaten zu vermeiden.
  • Wenn Sie sich für die Partitionierung von Verlaufsdaten entscheiden, sollten Sie dies schrittweise tun, indem Sie die EffectiveDateTime in Schritten von bis zu einigen Tagen jedes Mal, wenn Sie die Richtlinie ändern, auf ein vorheriges datetime festlegen.

Beispiel für die Datenpartitionierung

Datenpartitionierungsrichtlinienobjekt mit zwei Partitionsschlüsseln.

  1. Ein Hashpartitionsschlüssel über einer string-typisierten Spalte namens tenant_id.
    • Es verwendet die XxHash64 Hashfunktion, wobei MaxPartitionCount auf den empfohlenen Wert 128festgelegt ist, und der Standardwert Seed von 1.
  2. Ein einheitlicher datetime-Bereichspartitionsschlüssel über einer datetime Typspalte mit dem Namen timestamp.
    • Als Bezugspunkt wird die Größe für 7d jede Partition verwendetdatetime(2021-01-01).
{
  "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
      }
    }
  ]
}

Zusätzliche Eigenschaften

Die folgenden Eigenschaften können als Teil der Richtlinie definiert werden. Diese Eigenschaften sind optional, und es wird empfohlen, sie nicht zu ändern.

Eigenschaft BESCHREIBUNG Empfohlener Wert Standardwert
MinRowCountPerOperation Mindestziel für die Summe der Zeilenanzahl der Quellausdehnungen eines einzelnen Datenpartitionierungsvorgangs. 0
MaxRowCountPerOperation Maximales Ziel für die Summe der Zeilenanzahl der Quellausdehnungen eines einzelnen Datenpartitionierungsvorgangs. Legen Sie einen Wert unter 5M fest, wenn Sie sehen, dass die Partitionierungsvorgänge eine große Menge an Arbeitsspeicher oder CPU pro Vorgang beanspruchen. 0, mit einem Standardziel von 5.000.000 Datensätzen.
MaxOriginalSizePerOperation Maximales Ziel für die Summe der ursprünglichen Größe (in Bytes) der Quellausdehnungen eines einzelnen Datenpartitionierungsvorgangs. Wenn die Partitionierungsvorgänge eine große Menge an Arbeitsspeicher oder CPU pro Vorgang beanspruchen, legen Sie einen Wert unter 5 GB fest. 0, mit einem Standardziel von 5.368.709.120 Bytes (5 GB).

Der Datenpartitionierungsprozess

  • Die Datenpartitionierung wird als Hintergrundprozess nach der Erfassung im Cluster ausgeführt.
    • Bei einer Tabelle, die kontinuierlich erfasst wird, wird erwartet, dass immer ein "Tail" von Daten vorhanden ist, die noch partitioniert werden müssen (nichthomogene Ausdehnungen).
  • Die Datenpartitionierung wird nur in heißen Ausdehnungen ausgeführt, unabhängig vom Wert der EffectiveDateTime Eigenschaft in der Richtlinie.

Sie können die Partitionierung status von Tabellen mit definierten Richtlinien in einer Datenbank überwachen, indem Sie den Befehl .show database extents partitioning statistics verwenden.

Partitionierungskapazität

  • Der Datenpartitionierungsprozess führt zur Erstellung weiterer Erweiterungen. Der Cluster kann seine Zusammenführungskapazität schrittweise erhöhen, sodass der Prozess der Zusammenführung von Erweiterungen schritt halten kann.
  • Wenn ein hoher Erfassungsdurchsatz oder eine ausreichende Anzahl von Tabellen vorhanden ist, für die eine Partitionierungsrichtlinie definiert ist, kann der Cluster die Partitionskapazität von Extents schrittweise erhöhen, sodass der Prozess der Partitionierungsausdehnungen Schritt halten kann.
  • Um zu viele Ressourcen zu verbrauchen, sind diese dynamischen Erhöhungen begrenzt. Möglicherweise müssen Sie sie schrittweise und linear über die Obergrenze hinaus erhöhen, wenn sie vollständig verbraucht sind.
    • Wenn das Erhöhen der Kapazitäten zu einer erheblichen Zunahme der Nutzung der Ressourcen des Clusters führt, können Sie den Cluster entweder manuell oder durch Aktivieren der automatischen Skalierung hochskalieren/.

Einschränkungen

  • Versuche, Daten in einer Datenbank zu partitionieren, die bereits über mehr als 5.000.000 Erweiterungen verfügt, werden gedrosselt.
    • In solchen Fällen wird die EffectiveDateTime Eigenschaft der Partitionierungsrichtlinien von Tabellen in der Datenbank automatisch um mehrere Stunden verzögert, sodass Sie Ihre Konfiguration und Ihre Richtlinien neu bewerten können.

Ausreißer in partitionierten Spalten

  • Die folgenden Situationen können zu einer unausgewogenen Verteilung der Daten auf den Knoten des Clusters beitragen und die Abfrageleistung beeinträchtigen:
    • Wenn ein Hashpartitionsschlüssel Werte enthält, die viel häufiger sind als andere, z. B. eine leere Zeichenfolge oder einen generischen Wert (z null . B. oder N/A).
    • Die Werte stellen eine Entität (z tenant_id. B. ) dar, die im Dataset häufiger auftritt.
  • Wenn ein uniform range datetime-Partitionsschlüssel über einen ausreichend großen Prozentsatz von Werten verfügt, die "weit" von der Mehrheit der Werte in der Spalte entfernt sind, erhöht sich der Mehraufwand des Datenpartitionierungsprozesses und kann zu vielen kleinen Ausdehnungen führen, die der Cluster nachverfolgen muss. Ein Beispiel für eine solche Situation sind datetime-Werte aus der fernen Vergangenheit oder Zukunft.

In beiden Fällen "korrigieren" Sie entweder die Daten, oder filtern Sie irrelevante Datensätze in den Daten vor oder zur Erfassungszeit heraus, um den Aufwand für die Datenpartitionierung im Cluster zu reduzieren. Verwenden Sie beispielsweise eine Updaterichtlinie.