Partitioneringsprincip

Gäller för: ✅Microsoft Fabric✅Azure Data Explorer

Partitioneringsprincipen definierar om och hur omfattningar (datashards) ska partitioneras för en specifik tabell eller en materialiserad vy.

Principen utlöser ytterligare en bakgrundsprocess som äger rum efter skapandet av omfattningar, efter datainmatning. Den här processen omfattar att flytta data från källutbredningen och producera homogena omfattningar, där alla värden i kolumnen som anges som partitionsnyckel finns i en enda partition.

Det primära målet med partitioneringsprincipen är att förbättra frågeprestanda i specifika scenarier som stöds.

Scenarier som stöds

Följande är de enda scenarier där du bör ange en princip för datapartitionering. I alla andra scenarier rekommenderas inte att du anger principen.

• Frekventa filter med medelhög eller hög kardinalitet string eller guid kolumn:
  • Till exempel: lösningar för flera klientorganisationer eller en måtttabell där de flesta eller alla frågor filtrerar på en kolumn av typen string eller guid, till exempel TenantId eller MetricId.
  • Medel kardinalitet är minst 10 000 distinkta värden.
  • Ange hashpartitionsnyckeln som kolumnen string eller guid och ange egenskapen PartitionAssignmentMode till uniform.
• Frekventa aggregeringar eller kopplingar med hög kardinalitet string eller guid kolumn:
  • Till exempel IoT-information från många olika sensorer eller akademiska poster för många olika studenter.
  • Hög kardinalitet är minst 1 000 000 distinkta värden, där fördelningen av värden i kolumnen är ungefär jämn.
  • I det här fallet anger du hashpartitionsnyckeln vara kolumnen som ofta grupperas efter eller är ansluten och anger egenskapen PartitionAssignmentMode till ByPartition.
• datainmatning i fel ordning:
  • Data som matas in i en tabell kanske inte sorteras och partitioneras i omfattningar (shards) enligt en specifik datetime kolumn som representerar datagenereringstiden och som ofta används för att filtrera data. Detta kan bero på en återfyllnad från heterogena källfiler som innehåller datetime-värden under ett stort tidsintervall.
  • I det här fallet anger du datetime-partitionsnyckel för enhetligt intervall vara kolumnen datetime.
  • Om du behöver kvarhållnings- och cachelagringsprinciper för att justera med datetime-värdena i kolumnen, i stället för att justera med tiden för inmatning, anger du egenskapen OverrideCreationTime till true.

Partitionsnycklar

Följande typer av partitionsnycklar stöds.

Hashpartitionsnyckel

Om principen innehåller en hashpartitionsnyckel tilldelas alla homogena omfattningar som tillhör samma partition till samma datanod.

• En hash-modulo-funktion används för att partitionering av data.
• Data i homogena (partitionerade) omfattningar sorteras efter hashpartitionsnyckeln.
  • Du behöver inte inkludera hashpartitionsnyckeln i radordningsprincipen, om en definieras i tabellen.
• Frågor som använder shuffle-strategin, och där shuffle key som används i join, summarize eller make-series är tabellens hashpartitionsnyckel, förväntas fungera bättre eftersom mängden data som krävs för att flytta mellan noder minskar.

Partitionsegenskaper

Exempel på hashpartitionsnyckel

En hashpartitionsnyckel över en string-typad kolumn med namnet tenant_id. Den använder funktionen XxHash64 hash med MaxPartitionCount inställt på det rekommenderade värdet 128och standard Seed för 1.

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

Partitionsnyckel för enhetligt intervalldatumtid

I dessa fall kan du omfördefiniera data mellan omfattningar så att varje omfattning innehåller poster från ett begränsat tidsintervall. Den här processen resulterar i att filter i kolumnen datetime blir effektivare vid frågetillfället.

Partitionsfunktionen som används är bin_at() och är inte anpassningsbar.

Partitionsegenskaper

Exempel på datetime-partition för enhetligt intervall

Kodfragmentet visar en partitionsnyckel för enhetligt datetime-intervall över en datetime kolumn med namnet timestamp. Den använder datetime(2021-01-01) som referenspunkt, med en storlek på 7d för varje partition, och åsidosätter inte skapandetiderna för omfattningen.

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

Principobjektet

Som standard är en tabells princip för datapartitionering null, i vilket fall data i tabellen inte partitioneras om när de har matats in.

Principen för datapartitionering har följande huvudegenskaper:

• PartitionKeys:

  • En samling partitionsnycklar som definierar hur data ska partitioneras i tabellen.
  • En tabell kan ha upp till 2 partitionsnycklar med något av följande alternativ:
    • En hashpartitionsnyckel.
    • En datetime-partitionsnyckel för enhetligt intervall.
    • En hashpartitionsnyckel och en partitionsnyckel för enhetligt intervall.
  • Varje partitionsnyckel har följande egenskaper:
    • ColumnName: string – namnet på kolumnen enligt vilken data ska partitioneras.
    • Kind: string – Datapartitioneringstypen som ska tillämpas (Hash eller UniformRange).
    • Properties: property bag – Definierar parametrar enligt vilka partitionering utförs.

• EffectiveDateTime:

  • UTC-datetime som principen gäller från.
  • Den här egenskapen är valfri. Om den inte anges börjar principen gälla för data som matas in efter att principen har tillämpats.

Exempel på datapartitionering

Principobjekt för datapartitionering med två partitionsnycklar.

1. En hashpartitionsnyckel över en string-typad kolumn med namnet tenant_id.
   • Den använder funktionen XxHash64 hash med MaxPartitionCount inställt på det rekommenderade värdet 128och standard Seed för 1.
2. En partitionsnyckel för enhetligt datetime-intervall över en kolumn av datetime typ med namnet timestamp.
   • Den använder datetime(2021-01-01) som referenspunkt, med storleken 7d för varje partition.

{
  "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
      }
    }
  ]
}

Ytterligare egenskaper

Följande egenskaper kan definieras som en del av principen. De här egenskaperna är valfria och vi rekommenderar att du inte ändrar dem.

Datapartitioneringsprocessen

• Datapartitionering körs som en bakgrundsprocess efter inmatning.
  • En tabell som kontinuerligt matas in i förväntas alltid ha en "tail" av data som ännu inte har partitionerats (icke-homogena omfattningar).
• Datapartitionering körs endast i frekventa utsträckningar, oavsett värdet för egenskapen EffectiveDateTime i principen.
  • Om det krävs partitionering av kalla omfattningar måste du tillfälligt justera cachelagringsprincipen.

Du kan övervaka partitioneringsstatusen för tabeller med definierade principer i en databas med hjälp av .show database extents partitioneringsstatistik kommando och partitioneringsmått.

Partitioneringskapacitet

• Processen för datapartitionering resulterar i att fler omfattningar skapas. Sammanslagningskapaciteten för omfattningar kan gradvis öka, så att processen med sammanslagnings omfattningar kan hänga med.

• Om det finns ett högt dataflöde för inmatning eller ett tillräckligt stort antal tabeller som har definierat en partitioneringsprincip kan partitionskapaciteten Omfattningar gradvis öka, så att processen med partitioneringsutbredningar kan hänga med.

Begränsningar

• Försök att partitionering av data i en databas som redan har mer än 5 000 000 omfattningar begränsas.
  • I sådana fall fördröjs den EffectiveDateTime egenskapen för partitioneringsprinciper för tabeller i databasen automatiskt med flera timmar, så att du kan omvärdera konfigurationen och principerna.

Extremvärden i partitionerade kolumner

• Följande situationer kan bidra till obalanserad fördelning av data mellan noder och försämra frågeprestanda:
  • Om en hashpartitionsnyckel innehåller värden som är mycket vanligare än andra, till exempel en tom sträng eller ett allmänt värde (till exempel null eller N/A).
  • Värdena representerar en entitet (till exempel tenant_id) som är vanligare i datauppsättningen.
• Om en datetime-partitionsnyckel för enhetligt intervall har en tillräckligt stor procentandel värden som är "långt" från majoriteten av värdena i kolumnen, ökar datapartitioneringsprocessens omkostnader och kan leda till många små delar att hålla reda på. Ett exempel på en sådan situation är datetime-värden från det avlägsna förflutna eller framtiden.

I båda dessa fall kan du antingen "åtgärda" data eller filtrera bort eventuella irrelevanta poster i data före eller vid inmatningstid, för att minska kostnaderna för datapartitioneringen. Använd till exempel en uppdateringsprincip.

Relaterat innehåll

• partitioneringsprinciphanteringskommandon