Partitioneringsbeleid

  • Artikel

Het partitioneringsbeleid definieert of en hoe de mate (gegevensshards) moet worden gepartitioneerd voor een specifieke tabel of een gerealiseerde weergave.

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

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

Notitie

Wanneer een beleid voor gegevenspartitionering niet is gedefinieerd (is null), worden gebieden standaard gepartitioneerd op het moment van maken (opname). In de meeste gevallen is het niet nodig om een 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 afgeraden.

  • Veelgebruikte filters voor een gemiddelde of hoge kardinaliteit string of guid kolom:
    • Bijvoorbeeld: oplossingen voor meerdere tenants of een tabel met metrische gegevens waarin de meeste of alle query's filteren op een kolom van het type string of guid, zoals de TenantId of de MetricId.
    • De gemiddelde kardinaliteit is ten minste 10.000 afzonderlijke waarden.
    • Stel de hashpartitiesleutel in op de string kolom of guid en stel de PartitionAssigmentMode eigenschap in op uniform.
  • Frequente aggregaties of joins voor een hoge kardinaliteit string of guid kolom:
    • Bijvoorbeeld 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 de kolom die vaak wordt gegroepeerd op of gekoppeld, en stelt u de PartitionAssigmentMode eigenschap in op ByPartition.
  • Gegevensopname buiten volgorde:
    • Gegevens die worden opgenomen in een tabel, worden mogelijk niet geordend en gepartitioneerd in gebieden (shards) op basis van een specifieke datetime kolom die de aanmaaktijd van de gegevens vertegenwoordigt en wordt vaak 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 partitiesleutel voor uniform bereik datum/tijd in op de datetime kolom.
    • Als u bewaar- en cachebeleid wilt afstemmen op de datum/tijd-waarden in de kolom, stelt u de OverrideCreationTime eigenschap in op in plaats van uit te truelijnen met de tijd van opname.

Waarschuwing

  • Er zijn geen in code vastgelegde limieten ingesteld voor het aantal tabellen waarvoor het partitiebeleid is gedefinieerd. Elke extra tabel voegt echter overhead toe aan het achtergrondpartitioneringsproces voor gegevens dat wordt uitgevoerd op de knooppunten van het cluster. Het instellen van een beleid voor meer tabellen leidt tot het gebruik van meer clusterresources en hogere kosten vanwege onderliggende opslagtransacties. Zie capaciteit voor 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 samenvoegingsproces. De meeste resterende opslagartefacten worden naar verwachting verwijderd tijdens het automatische opschoningsproces. Het verhogen van de waarde van de MaxPartitionCount eigenschap verhoogt het aantal resterende opslagartefacten en kan de opschoonprestaties verminderen.
  • Voordat u een partitiebeleid toepast op een gerealiseerde weergave, bekijkt u de aanbevelingen voor het partitioneringsbeleid voor gerealiseerde weergaven.

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 bereik datetime RangeSize, Reference, OverrideCreationTime bin_at(ColumnName, RangeSize, Reference)

Hashpartitiesleutel

Als het beleid een hashpartitiesleutel bevat, worden alle homogene gebieden die tot dezelfde partitie behoren, toegewezen aan hetzelfde gegevensknooppunt in het cluster.

Notitie

De gegevenspartitioneringsbewerking voegt een aanzienlijke verwerkingsbelasting toe. U wordt aangeraden alleen onder de volgende voorwaarden een hashpartitiesleutel op een tabel toe te passen:

  • Als de meeste query's gebruikmaken van gelijkheidsfilters (==, in()).
  • De meeste query's aggregeren/samenvoegen op een specifieke kolom van het type string of guid die een grote dimensie heeft (kardinaliteit van 10 M of hoger), zoals een device_ID, of user_ID.
  • Het gebruikspatroon van de gepartitioneerde tabellen heeft een hoge gelijktijdigheidsquerybelasting, zoals in toepassingen voor bewaking of dashboarding.
  • Een hash-modulo-functie wordt gebruikt om de gegevens te partitioneren.
  • Gegevens in homogene (gepartitioneerde) gebieden worden geordend op basis van de hashpartitiesleutel.
    • U hoeft de hashpartitiesleutel niet op te nemen in het rijvolgordebeleid, als er een is gedefinieerd in de tabel.
  • Query's die gebruikmaken van de shuffle-strategie en waarin de shuffle key wordt gebruikt in join, summarize of make-series is de hashpartitiesleutel van de tabel, zullen naar verwachting beter presteren omdat de hoeveelheid gegevens die nodig is om over clusterknooppunten te worden verplaatst, is 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 per periode moet worden gemaakt (het modulo-argument voor de hash-modulo-functie). In het bereik (1,2048]. Hogere waarden leiden tot een grotere overhead van het gegevenspartitioneringsproces op de knooppunten van het cluster 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 en de grootte van metagegevens aanzienlijk, en worden daarom niet aanbevolen.
Seed Gebruik voor het randomiseren van de hash-waarde. Een positief geheel getal. 1, wat ook de standaardwaarde is.
PartitionAssignmentMode De modus die wordt gebruikt voor het toewijzen van partities aan knooppunten in het cluster. ByPartition: Alle homogene (gepartitioneerde) gebieden die tot dezelfde partitie behoren, worden toegewezen aan hetzelfde knooppunt.
Uniform: partitiewaarden van een gebied worden genegeerd. Gebieden worden uniform toegewezen aan de knooppunten van het cluster.		 Als query's niet worden samengevoegd of samengevoegd op de hashpartitiesleutel, gebruikt Uniformu . Gebruik ByPartitionanders .

Voorbeeld van hashpartitiesleutel

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

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

Partitiesleutel voor uniform bereik datum/tijd

Notitie

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

In dergelijke gevallen kunt u de gegevens opnieuw verdelen tussen gebieden, zodat elk bereik records uit een beperkt tijdsbereik bevat. Dit proces resulteert erin dat filters op de datetime kolom effectiever zijn 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 dit ertoe kan leiden dat de tabel een groot aantal kleine gebieden bevat die niet kunnen worden samengevoegd.
Reference Een datetime scalaire constante die een vast tijdstip aangeeft, op basis waarvan datum/tijd-partities worden uitgelijnd. Begin met 1970-01-01 00:00:00. Als er records zijn waarin de datum/tijd-partitiesleutel waarden bevat null , wordt hun partitiewaarde ingesteld op de waarde van Reference.
OverrideCreationTime Een bool die aangeeft of de minimale en maximale aanmaaktijden van het resultaatgebied moeten worden overschreven door het bereik van de waarden in de partitiesleutel. De standaardwaarde is false. Ingesteld op true als gegevens niet worden opgenomen op volgorde van de tijd van aankomst. Een enkel bronbestand kan bijvoorbeeld datum/tijd-waarden bevatten die ver weg liggen en/of u kunt 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 periode van het Lookbacksamenvoegbeleid Gebieden van de tabel. Om ervoor te zorgen dat de gebieden kunnen worden gedetecteerd, stelt u de Lookback eigenschap in op HotCache.

Voorbeeld van een datum/tijd-partitie voor uniform bereik

Het codefragment toont een uniforme partitiesleutel voor datum/tijdbereik over een datetime getypeerde 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 is nullhet gegevenspartitioneringsbeleid van een tabel , in welk geval de gegevens in de tabel niet opnieuw worden gepartitioneerd nadat ze zijn opgenomen.

Het beleid voor gegevenspartitionering heeft de volgende hoofdeigenschappen:

  • PartitionKeys:

  • EffectiveDateTime:

    • De UTC-datum/tijd vanaf 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.

Waarschuwing

  • U kunt een datum/tijd-waarde instellen in het verleden en reeds opgenomen gegevens partitioneren. Deze procedure kan echter aanzienlijk meer resources gebruiken in het partitioneringsproces.
  • In de meeste gevallen wordt aanbevolen om alleen nieuw opgenomen gegevens te partitioneren en om te voorkomen dat grote hoeveelheden historische gegevens worden gepartitioneerd.
  • Als u ervoor kiest om historische gegevens te partitioneren, kunt u dit geleidelijk doen door EffectiveDateTime in te stellen op een vorige 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.
    • Het maakt gebruik van de XxHash64 hash-functie, met MaxPartitionCount ingesteld op de aanbevolen waarde 128en de standaardwaarde Seed .1
  2. Een uniforme partitiesleutel voor datum-/tijdbereik over 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 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 bronregio's van één gegevenspartitioneringsbewerking. Stel een waarde in die lager is dan 5 miljoen als u ziet dat de partitioneringsbewerkingen per bewerking een grote hoeveelheid geheugen of CPU 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 per bewerking een grote hoeveelheid geheugen of CPU verbruiken, stelt u een waarde in die lager is dan 5 GB. 0, met een standaarddoel van 5.368.709.120 bytes (5 GB).

Het gegevenspartitioneringsproces

  • Gegevenspartitionering wordt uitgevoerd als een achtergrondproces na opname in het cluster.
    • Een tabel die continu wordt opgenomen in, heeft naar verwachting altijd een 'staart' van gegevens die nog moeten worden gepartitioneerd (niet-homogene gebieden).
  • Gegevenspartitionering wordt alleen uitgevoerd op dynamische gebieden, ongeacht de waarde van de EffectiveDateTime eigenschap in het beleid.
    • Als het partitioneren van koude gebieden is vereist, moet u het cachebeleid tijdelijk aanpassen.

U kunt de partitioneringsstatus van tabellen met gedefinieerd beleid in een database bewaken met behulp van de opdracht .show database extents partitioning statistics .

Partitioneringscapaciteit

  • Het gegevenspartitioneringsproces resulteert in het maken van meer gebieden. Het cluster kan de capaciteit voor het samenvoegen van gebieden geleidelijk vergroten, zodat het samenvoegingsproces van gebieden kan worden bijgehouden.
  • Als er een hoge opnamedoorvoer is of een groot aantal tabellen waarvoor een partitiebeleid is gedefinieerd, kan het cluster de partitiecapaciteit van Extents geleidelijk verhogen, zodat het proces van het partitioneren van gebieden kan worden bijgehouden.
  • Om te voorkomen dat u te veel resources verbruikt, worden deze dynamische verhogingen beperkt. Mogelijk moet u deze geleidelijk en lineair verhogen tot voorbij de limiet, als ze volledig zijn verbruikt.
    • Als het vergroten van de capaciteit een aanzienlijke toename in het gebruik van de clusterresources veroorzaakt, 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 EffectiveDateTime eigenschap van partitioneringsbeleid van tabellen in de database automatisch enkele uren vertraagd, zodat u uw configuratie en beleid opnieuw kunt controleren.

Uitbijters in gepartitioneerde kolommen

  • De volgende situaties kunnen bijdragen aan een onevenwichtige verdeling van gegevens over de knooppunten van het cluster en kunnen de queryprestaties verslechteren:
    • 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 datum/tijd-partitiesleutel voor een uniform bereik een groot genoeg percentage waarden heeft dat 'ver' van de meerderheid van de waarden in de kolom ligt, wordt de overhead van het gegevenspartitioneringsproces verhoogd en kan dit leiden tot veel kleine hoeveelheden die het cluster moet bijhouden. Een voorbeeld van een dergelijke situatie zijn datum/tijd-waarden uit het verre verleden of de toekomst.

In beide gevallen kunt u de gegevens 'herstellen' of irrelevante records in de gegevens eruit filteren vóór of tijdens de opname, om de overhead van de gegevenspartitionering op het cluster te verminderen. Gebruik bijvoorbeeld een updatebeleid.

Gerelateerde inhoud