Delen via

Partitioneringsbeleid

  • Artikel

Van toepassing op: ✅Microsoft Fabric✅Azure Data Explorer-

Het partitioneringsbeleid definieert of en hoe gebieden (gegevensshards) moeten worden gepartitioneerd voor een specifieke tabel of een gerealiseerde weergave.

Het beleid activeert een extra achtergrondproces dat plaatsvindt na het maken van gebieden, na het opnemen van gegevens. Dit proces omvat het opnieuw opnemen van gegevens uit de bronbereiken en het produceren van homogene gebieden, waarin alle waarden van de kolom die als de partitiesleutel zich binnen één partitie bevinden.

Het primaire doel van het partitioneringsbeleid is het verbeteren van queryprestaties in specifieke ondersteunde scenario's.

Notitie

Wanneer een beleid voor gegevenspartitionering niet is gedefinieerd (is null), worden de gebieden standaard gepartitioneerd op het moment van maken (opname). In de meeste gevallen hoeft u geen beleid voor gegevenspartitionering in te stellen.

Ondersteunde scenario's

Hier volgen de enige scenario's waarin het instellen van een beleid voor gegevenspartitionering wordt aanbevolen. In alle andere scenario's wordt het instellen van het beleid niet aanbevolen.

  • veelgebruikte filters op een gemiddelde of hoge kardinaliteit string of guid kolom:
    • Bijvoorbeeld: oplossingen voor meerdere tenants of een tabel met metrische gegevens waarbij de meeste of alle query's filteren op een kolom van het type string of guid, zoals de TenantId of de MetricId.
    • Gemiddelde kardinaliteit is ten minste 10.000 afzonderlijke waarden.
    • Stel de hashpartitiesleutel in als de kolom string of guid en stel de eigenschap PartitionAssignmentMode in op uniform.
  • frequente aggregaties of joins voor een hoge kardinaliteit string of guid kolom:
    • IoT-gegevens van veel verschillende sensoren of academische records van veel verschillende studenten.
    • Hoge kardinaliteit is ten minste 1.000.000 afzonderlijke waarden, waarbij de verdeling van waarden in de kolom ongeveer gelijk is.
    • In dit geval stelt u de hashpartitiesleutel in op als kolom die vaak wordt gegroepeerd op of gekoppeld, en stelt u de eigenschap PartitionAssignmentMode in op ByPartition.
  • gegevensopname buiten volgorde:
    • Gegevens die zijn opgenomen in een tabel, worden mogelijk niet geordend en gepartitioneerd in gebieden (shards) op basis van een specifieke datetime kolom die de aanmaaktijd van gegevens aangeeft en vaak wordt gebruikt om gegevens te filteren. Dit kan worden veroorzaakt door een backfill van heterogene bronbestanden die datum/tijd-waarden bevatten gedurende een lange periode.
    • In dit geval stelt u de uniforme datum/tijd-partitiesleutel voor het in op de datetime kolom.
    • Als u bewaar- en cachebeleid nodig hebt om af te stemmen op de datum/tijdwaarden in de kolom, stelt u de eigenschap OverrideCreationTime in op true.

Voorzichtigheid

  • Er zijn geen in code vastgelegde limieten ingesteld voor het aantal tabellen waarvoor het partitioneringsbeleid is gedefinieerd. Maar elke extra tabel voegt overhead toe aan het partitioneringsproces voor achtergrondgegevens. Het instellen van een beleid voor meer tabellen resulteert in meer resources die worden gebruikt en hogere kosten als gevolg van onderliggende opslagtransacties. Zie capaciteitvoor meer informatie.
  • Het wordt niet aanbevolen om een partitioneringsbeleid in te stellen als de gecomprimeerde grootte van gegevens per partitie naar verwachting kleiner is dan 1 GB.
  • Het partitioneringsproces resulteert in restopslagartefacten voor alle gebieden die zijn vervangen tijdens het partitioneringsproces en tijdens het samenvoegproces. De meeste resterende opslagartefacten worden naar verwachting verwijderd tijdens het automatische opschonen. Door de waarde van de eigenschap MaxPartitionCount te verhogen, wordt het aantal resterende opslagartefacten verhoogd en kunnen de opschoonprestaties worden verminderd.
  • Voordat u een partitioneringsbeleid toepast op een gerealiseerde weergave, bekijkt u de aanbevelingen voor gerealiseerde weergaven die het partitioneringsbeleid.

Partitiesleutels

De volgende soorten partitiesleutels worden ondersteund.

Soort Kolomtype Partitie-eigenschappen Partitiewaarde
Hash- string of guid Function, MaxPartitionCount, Seed, PartitionAssignmentMode Function(ColumnName, MaxPartitionCount, Seed)
Uniform- datetime RangeSize, Reference, OverrideCreationTime bin_at(ColumnName, RangeSize, Reference)

Hashpartitiesleutel

Als het beleid een hashpartitiesleutel bevat, worden alle homogene gebieden die deel uitmaken van dezelfde partitie toegewezen aan hetzelfde gegevensknooppunt.

Notitie

Met de bewerking voor gegevenspartitionering wordt een aanzienlijke verwerkingsbelasting toegevoegd. Het is raadzaam om alleen onder de volgende voorwaarden een hashpartitiesleutel toe te passen op een tabel:

  • Als de meeste query's gelijkheidsfilters gebruiken (==, in()).
  • Het merendeel van de query's aggregeren/samenvoegen voor een specifieke kolom van het type string of guid van grote dimensie (kardinaliteit van 10 miljoen of hoger), zoals een device_IDof user_ID.
  • Het gebruikspatroon van de gepartitioneerde tabellen heeft een hoge gelijktijdigheidsquerybelasting, zoals in bewakings- of dashboardtoepassingen.
  • Een hash-modulo-functie wordt gebruikt om de gegevens te partitioneren.
  • Gegevens in homogene (gepartitioneerde) gebieden worden geordend door de hash-partitiesleutel.
    • U hoeft de hashpartitiesleutel niet op te nemen in het beleid voor rijvolgorde, als er een is gedefinieerd in de tabel.
  • Query's die gebruikmaken van de shuffle-strategieen waarin de shuffle key die worden gebruikt in join, summarize of make-series de hashpartitiesleutel van de tabel is, worden naar verwachting beter uitgevoerd omdat de hoeveelheid gegevens die nodig is om over knooppunten te verplaatsen, wordt verminderd.

Partitie-eigenschappen

Eigenschap Beschrijving Ondersteunde waarde(s) Aanbevolen waarde
Function De naam van een hash-modulo-functie die moet worden gebruikt. XxHash64
MaxPartitionCount Het maximum aantal partities dat moet worden gemaakt (het modulo-argument voor de hash-modulo-functie) per periode. In het bereik (1,2048]. Hogere waarden leiden tot een grotere overhead van het proces voor gegevenspartitionering en een hoger aantal gebieden voor elke periode. De aanbevolen waarde is 128. Hogere waarden verhogen de overhead van het partitioneren van de gegevens na opname aanzienlijk en de grootte van metagegevens en worden daarom niet aanbevolen.
Seed Gebruiken voor het randomiseren van de hashwaarde. Een positief geheel getal. 1, wat ook de standaardwaarde is.
PartitionAssignmentMode De modus die wordt gebruikt voor het toewijzen van partities aan knooppunten. ByPartition: alle homogene (gepartitioneerde) gebieden die deel uitmaken van dezelfde partitie, worden toegewezen aan hetzelfde knooppunt.
Uniform: partitiewaarden van een extents worden genegeerd. Gebieden worden uniform toegewezen aan de knooppunten.		 Als query's niet worden samengevoegd of samengevoegd op de hashpartitiesleutel, gebruikt u Uniform. Gebruik anders ByPartition.

Voorbeeld van hashpartitiesleutel

Een hashpartitiesleutel over een string-getypte kolom met de naam tenant_id. Hierbij wordt de XxHash64 hash-functie gebruikt, waarbij MaxPartitionCount is ingesteld op de aanbevolen waarde 128en de standaard-Seed van 1.

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

Partitiesleutel uniform bereik datum/tijd

Notitie

Pas alleen een uniforme datum/tijd-partitiesleutel toe op een datetime-getypte kolom in een tabel wanneer gegevens die in de tabel zijn opgenomen, waarschijnlijk niet worden gerangschikt op basis van deze kolom.

In deze gevallen kunt u de gegevens tussen gebieden opnieuw toewijzen, zodat elke mate records uit een beperkt tijdsbereik bevat. Dit proces resulteert in filters op de datetime kolom die effectiever is tijdens het uitvoeren van query's.

De gebruikte partitiefunctie is bin_at() en kan niet worden aangepast.

Partitie-eigenschappen

Eigenschap Beschrijving Aanbevolen waarde
RangeSize Een timespan scalaire constante die de grootte van elke datum/tijd-partitie aangeeft. Begin met de waarde 1.00:00:00 (één dag). Stel geen kortere waarde in, omdat deze kan leiden tot een groot aantal kleine hoeveelheden die niet kunnen worden samengevoegd in de tabel.
Reference Een datetime scalaire constante die een vast tijdstip aangeeft, volgens welke datum/tijd-partities worden uitgelijnd. Begin met 1970-01-01 00:00:00. Als er records zijn waarin de datum/tijd-partitiesleutel null waarden heeft, wordt de partitiewaarde ingesteld op de waarde van Reference.
OverrideCreationTime Een bool die aangeeft of de minimale en maximale aanmaaktijden van de resultaatbereiken moeten worden overschreven door het bereik van de waarden in de partitiesleutel. Standaard ingesteld op false. Ingesteld op true als gegevens niet worden opgenomen in volgorde van aankomst. Een enkel bronbestand kan bijvoorbeeld datum/tijd-waarden bevatten die ver weg zijn en/of u wilt retentie of caching afdwingen op basis van de datum/tijd-waarden in plaats van de tijd van opname.

Wanneer OverrideCreationTime is ingesteld op true, kunnen gebieden worden gemist in het samenvoegproces. Gebieden worden gemist als de aanmaaktijd ouder is dan de Lookback periode van het beleid voor het samenvoegen van gebieden in de tabel. Als u ervoor wilt zorgen dat de gebieden kunnen worden gedetecteerd, stelt u de eigenschap Lookback in op HotCache.

Voorbeeld van een uniform datum/tijd-partitiebereik

Het fragment toont een uniforme partitiesleutel voor het datum/tijd-bereik boven een datetime getypte kolom met de naam timestamp. Het gebruikt datetime(2021-01-01) als referentiepunt, met een grootte van 7d voor elke partitie en overschrijft de aanmaaktijden van de gebieden niet.

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

Het beleidsobject

Standaard wordt het beleid voor gegevenspartitionering van een tabel null. In dat geval worden gegevens in de tabel niet opnieuw gepartitioneerd nadat deze zijn opgenomen.

Het beleid voor gegevenspartitionering heeft de volgende hoofdeigenschappen:

  • PartitionKeys:

    • Een verzameling partitiesleutels die definiëren hoe de gegevens in de tabel moeten worden gepartitioneren.
    • Een tabel kan maximaal 2 partitiesleutels bevatten, met een van de volgende opties:
    • Elke partitiesleutel heeft de volgende eigenschappen:
      • ColumnName: string - De naam van de kolom op basis waarvan de gegevens worden gepartitioneerd.
      • Kind: string : het type gegevenspartitionering dat moet worden toegepast (Hash of UniformRange).
      • Properties: property bag - Definieert parameters op basis waarvan partitionering wordt uitgevoerd.

  • EffectiveDateTime:

    • De UTC-datum/tijd van waaruit het beleid van kracht is.
    • Deze eigenschap is optioneel. Als dit niet is opgegeven, wordt het beleid van kracht voor gegevens die zijn opgenomen nadat het beleid is toegepast.

Voorzichtigheid

  • U kunt een datum/tijd-waarde instellen in het verleden en de reeds opgenomen gegevens partitioneren. Deze procedure kan echter aanzienlijk leiden tot een aanzienlijke toename van resources die worden gebruikt in het partitioneringsproces.
  • In de meeste gevallen is het raadzaam om alleen nieuw opgenomen gegevens te partitioneren en te voorkomen dat grote hoeveelheden historische gegevens worden gepartitioneerd.
  • Als u ervoor kiest om historische gegevens te partitioneren, kunt u dit geleidelijk overwegen door de EffectiveDateTime- in te stellen op een eerdere datetime in stappen van maximaal een paar dagen wanneer u het beleid wijzigt.

Voorbeeld van gegevenspartitionering

Gegevenspartitioneringsbeleidsobject met twee partitiesleutels.

  1. Een hashpartitiesleutel over een string-getypte kolom met de naam tenant_id.
    • Hierbij wordt de XxHash64 hash-functie gebruikt, waarbij MaxPartitionCount is ingesteld op de aanbevolen waarde 128en de standaard-Seed van 1.
  2. Een uniforme partitiesleutel voor datum/tijd voor een datetime typekolom met de naam timestamp.
    • Het gebruikt datetime(2021-01-01) als referentiepunt, met een grootte van 7d voor elke partitie.
{
  "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
      }
    }
  ]
}

Aanvullende eigenschappen

De volgende eigenschappen kunnen worden gedefinieerd als onderdeel van het beleid. Deze eigenschappen zijn optioneel en we raden u aan deze eigenschappen niet te wijzigen.

Eigenschap Beschrijving Aanbevolen waarde Standaardwaarde
MinRowCountPerOperation- Minimumdoel voor de som van het aantal rijen van de bronregio's van één gegevenspartitioneringsbewerking. 0
MaxRowCountPerOperation- Maximumdoel voor de som van het aantal rijen van de bronlengten van één gegevenspartitioneringsbewerking. Stel een waarde lager dan 5M in als u ziet dat de partitioneringsbewerkingen een grote hoeveelheid geheugen of CPU per bewerking verbruiken. 0, met een standaarddoel van 5.000.000 records.
MaxOriginalSizePerOperation- Maximumdoel voor de som van de oorspronkelijke grootte (in bytes) van de bronlengten van één gegevenspartitioneringsbewerking. Als de partitioneringsbewerkingen een grote hoeveelheid geheugen of CPU per bewerking verbruiken, stelt u een waarde lager dan 5 GB in. 0, met een standaarddoel van 5.368.709.120 bytes (5 GB).

Het proces voor gegevenspartitionering

  • Gegevenspartitionering wordt uitgevoerd als een achtergrondproces na opname.
    • Een tabel die continu wordt opgenomen, is naar verwachting altijd een 'staart' aan gegevens die nog moeten worden gepartitioneerd (niet-homogene gebieden).
  • Gegevenspartitionering wordt alleen uitgevoerd op dynamische gebieden, ongeacht de waarde van de eigenschap EffectiveDateTime in het beleid.

U kunt de partitioneringsstatus van tabellen met gedefinieerde beleidsregels in een database bewaken met behulp van de .show database extents partitionering statistieken opdracht en partitionering van metrische gegevens.

Partitioneringscapaciteit

  • Om te voorkomen dat er te veel resources worden verbruikt, worden deze dynamische toenames beperkt. Mogelijk moet u ze geleidelijk en lineair verhogen buiten de limiet, als ze volledig worden gebruikt.
    • Als het verhogen van de capaciteiten een aanzienlijke toename veroorzaakt in het gebruik van de resources van het cluster, kunt u het cluster omhoog schalen/, handmatig of door automatische schaalaanpassing in te schakelen.

Beperkingen

  • Pogingen om gegevens te partitioneren in een database die al meer dan 5.000.000 gebieden heeft, worden beperkt.
    • In dergelijke gevallen wordt de eigenschap EffectiveDateTime van partitioneringsbeleidsregels van tabellen in de database automatisch met enkele uren vertraagd, zodat u uw configuratie en beleid opnieuw kunt evalueren.

Uitbijters in gepartitioneerde kolommen

  • De volgende situaties kunnen bijdragen aan een onevenwichtige distributie van gegevens tussen knooppunten en de prestaties van query's verminderen:
    • Als een hashpartitiesleutel waarden bevat die veel vaker voorkomen dan andere, bijvoorbeeld een lege tekenreeks of een algemene waarde (zoals null of N/A).
    • De waarden vertegenwoordigen een entiteit (zoals tenant_id) die vaker voorkomt in de gegevensset.
  • Als een uniforme datum/tijd-partitiesleutel een groot genoeg percentage waarden heeft dat 'ver' ligt van het merendeel van de waarden in de kolom, wordt de overhead van het gegevenspartitioneringsproces verhoogd en kan dit leiden tot veel kleine hoeveelheden om bij te houden. Een voorbeeld van een dergelijke situatie zijn datum/tijd-waarden uit het verre verleden of de toekomst.

In beide gevallen 'corrigeer' de gegevens of filtert u alle irrelevante records in de gegevens vóór of tijdens opnametijd, om de overhead van de gegevenspartitionering te verminderen. Gebruik bijvoorbeeld een updatebeleid.

Verwante inhoud