Criterio partitioning

  • Articolo

I criteri di partizionamento definiscono se e come devono essere partizionati gli extent (partizioni di dati) per una tabella specifica o una vista materializzata.

Il criterio attiva un processo in background aggiuntivo che viene eseguito dopo la creazione di extent, dopo l'inserimento dei dati. Questo processo include il reesting dei dati dagli extent di origine e la produzione di extent omogenei , in cui tutti i valori della colonna designata come chiave di partizione si trovano all'interno di una singola partizione.

L'obiettivo principale dei criteri di partizionamento è migliorare le prestazioni delle query in scenari supportati specifici.

Nota

Per impostazione predefinita, quando un criterio di partizionamento dei dati non è definito (è null), gli extent vengono partizionati in base al momento della creazione (inserimento). Nella maggior parte dei casi non è necessario impostare un criterio di partizionamento dei dati.

Scenari supportati

Di seguito sono riportati gli unici scenari in cui è consigliabile impostare un criterio di partizionamento dei dati. In tutti gli altri scenari, l'impostazione del criterio non è consigliata.

  • Filtri frequenti su una cardinalità stringguid o una colonna media o alta:
    • Ad esempio: soluzioni multi-tenant o una tabella delle metriche in cui la maggior parte o tutte le query filtrano su una colonna di tipo string o guid, ad esempio TenantId o MetricId.
    • La cardinalità media è di almeno 10.000 valori distinti.
    • Impostare la chiave di partizione hash come string colonna o guid e impostare la PartitionAssigmentMode proprietà su uniform.
  • Aggregazioni o join frequenti in una colonna o guid cardinalità string elevata:
    • Ad esempio, le informazioni IoT provenienti da molti sensori diversi o da record accademici di molti studenti diversi.
    • La cardinalità elevata è di almeno 1.000.000 valori distinti, in cui la distribuzione dei valori nella colonna è approssimativamente pari.
    • In questo caso, impostare la chiave di partizione hash come colonna spesso raggruppata per o unita a join e impostare la PartitionAssigmentMode proprietà su ByPartition.
  • Inserimento dati non ordinato:
    • I dati inseriti in una tabella potrebbero non essere ordinati e partizionati in extent (partizioni) in base a una colonna specifica datetime che rappresenta l'ora di creazione dei dati e viene comunemente usata per filtrare i dati. Ciò potrebbe essere dovuto a un riempimento da file di origine eterogenei che includono valori datetime in un intervallo di tempo elevato.
    • In questo caso, impostare la chiave di partizione datetime dell'intervallo uniforme come datetime colonna.
    • Se sono necessari criteri di conservazione e memorizzazione nella cache per allinearsi ai valori datetime nella colonna, invece di allinearsi con l'ora di inserimento, impostare la OverrideCreationTime proprietà su true.

Attenzione

  • Non sono previsti limiti hardcoded impostati sul numero di tabelle con i criteri di partizionamento definiti. Tuttavia, ogni tabella aggiuntiva aggiunge overhead al processo di partizionamento dei dati in background eseguito nei nodi del cluster. L'impostazione di un criterio in più tabelle comporterà l'uso di più risorse cluster e un costo maggiore a causa delle transazioni di archiviazione sottostanti. Per altre informazioni, vedere capacità.
  • Non è consigliabile impostare un criterio di partizionamento se si prevede che le dimensioni compresse dei dati per partizione siano inferiori a 1 GB.
  • Il processo di partizionamento comporta artefatti di archiviazione residui per tutti gli extent sostituiti durante il processo di partizionamento e durante il processo di merge. Durante il processo di pulizia automatica è prevista l'eliminazione della maggior parte degli artefatti di archiviazione residui. L'aumento del valore della MaxPartitionCount proprietà aumenta il numero di artefatti di archiviazione residui e può ridurre le prestazioni di pulizia.
  • Prima di applicare criteri di partizionamento in una vista materializzata, esaminare i consigli per i criteri di partizionamento delle viste materializzate.

Chiavi di partizione

Sono supportati i tipi di chiavi di partizione seguenti.

Tipo Tipo di colonna Proprietà della partizione Valore della partizione
Hash string o guid Function, MaxPartitionCount, Seed, PartitionAssignmentMode Function(ColumnName, MaxPartitionCount, Seed)
Intervallo uniforme datetime RangeSize, Reference, OverrideCreationTime bin_at(ColumnName, RangeSize, Reference)

Chiave di partizione hash

Se il criterio include una chiave di partizione hash, tutti gli extent omogenei che appartengono alla stessa partizione verranno assegnati allo stesso nodo dati nel cluster.

Nota

L'operazione di partizionamento dei dati aggiunge un carico di elaborazione significativo. È consigliabile applicare una chiave di partizione hash in una tabella solo nelle condizioni seguenti:

  • Se la maggior parte delle query usa filtri di uguaglianza (==, in()).
  • La maggior parte delle query aggrega/join su una colonna specifica di tipo string o guid che è di dimensione di grandi dimensioni (cardinalità di 10M o superiore), ad esempio , device_IDo user_ID.
  • Il modello di utilizzo delle tabelle partizionate è in un carico elevato di query di concorrenza, ad esempio nelle applicazioni di monitoraggio o dashboard.
  • Per partizionare i dati viene usata una funzione hash-modulo.
  • I dati in extent omogenei (partizionati) vengono ordinati in base alla chiave di partizione hash.
    • Non è necessario includere la chiave di partizione hash nei criteri di ordine di riga, se ne è definita una nella tabella.
  • Le query che usano la strategia casuale e in cui l'oggetto shuffle key usato in joinsummarize o make-series è la chiave di partizione hash della tabella dovrebbero ottenere prestazioni migliori perché la quantità di dati necessari per spostarsi tra i nodi del cluster viene ridotta.

Proprietà della partizione

Proprietà Descrizione Valori supportati Impostazione consigliata
Function Nome di una funzione hash-modulo da utilizzare. XxHash64
MaxPartitionCount Numero massimo di partizioni da creare (argomento modulo per la funzione hash-modulo) per periodo di tempo. Nell'intervallo (1,2048]. I valori più elevati comportano un sovraccarico maggiore del processo di partizionamento dei dati nei nodi del cluster e un numero maggiore di extent per ogni periodo di tempo. Il valore consigliato è 128. I valori più elevati aumentano significativamente il sovraccarico del partizionamento dei dati dopo l'inserimento e le dimensioni dei metadati, pertanto non sono consigliati.
Seed Usare per la casualizzazione del valore hash. Numero intero positivo. 1, che è anche il valore predefinito.
PartitionAssignmentMode Modalità usata per l'assegnazione di partizioni ai nodi del cluster. ByPartition: tutti gli extent omogenei (partizionati) che appartengono alla stessa partizione vengono assegnati allo stesso nodo.
Uniform: i valori di partizione di un extent vengono ignorati. Gli extent vengono assegnati in modo uniforme ai nodi del cluster.		 Se le query non vengono unite o aggregate sulla chiave di partizione hash, usare Uniform. In caso contrario, usare ByPartition.

Esempio di chiave di partizione hash

Chiave di partizione hash su una stringcolonna tipizzata denominata tenant_id. Usa la XxHash64 funzione hash, con MaxPartitionCount impostato sul valore 128consigliato e l'impostazione predefinita Seed di 1.

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

Chiave di partizione datetime dell'intervallo uniforme

Nota

Applicare solo una chiave di partizione datetime di intervallo uniforme in una datetimecolonna tipizzata in una tabella quando è improbabile che i dati inseriti nella tabella vengano ordinati in base a questa colonna.

In questi casi, è possibile rimuffare i dati tra extent in modo che ogni extent includa record da un intervallo di tempo limitato. Questo processo consente di filtrare la datetime colonna in modo più efficace in fase di query.

La funzione di partizione usata è bin_at() e non è personalizzabile.

Proprietà della partizione

Proprietà Descrizione Impostazione consigliata
RangeSize Costante timespan scalare che indica le dimensioni di ogni partizione datetime. Iniziare con il valore 1.00:00:00 (un giorno). Non impostare un valore più breve, perché può comportare l'unione di un numero elevato di extent ridotti che non possono essere uniti.
Reference Costante datetime scalare che indica un punto fisso nel tempo, in base al quale le partizioni datetime sono allineate. Iniziare con 1970-01-01 00:00:00. Se sono presenti record in cui la chiave di partizione datetime ha null valori, il valore della partizione viene impostato sul valore di Reference.
OverrideCreationTime Oggetto bool che indica se i tempi minimi e massimi di creazione dell'extent del risultato devono essere sottoposti a override dall'intervallo dei valori nella chiave di partizione. Il valore predefinito è false. Impostare su true se i dati non vengono inseriti nell'ordine di arrivo. Ad esempio, un singolo file di origine può includere valori datetime distanti e/o può essere necessario applicare la conservazione o la memorizzazione nella cache in base ai valori datetime anziché all'ora di inserimento.

Quando OverrideCreationTime è impostato su true, è possibile che gli extent non vengano rilevati nel processo di merge. Gli extent non vengono rilevati se il tempo di creazione è precedente al Lookback periodo dei criteri di unione extent della tabella. Per assicurarsi che gli extent siano individuabili, impostare la Lookback proprietà su HotCache.

Esempio di partizione datetime dell'intervallo uniforme

Il frammento di codice mostra una chiave di partizione di intervallo datetime uniforme su una datetime colonna tipizzata denominata timestamp. datetime(2021-01-01) Usa come punto di riferimento, con una dimensione di 7d per ogni partizione e non esegue l'override dei tempi di creazione degli extent.

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

Oggetto criteri

Per impostazione predefinita, i criteri di partizionamento dei dati di una tabella sono null, nel qual caso i dati nella tabella non verranno ripartizionati dopo l'inserimento.

I criteri di partizionamento dei dati hanno le proprietà principali seguenti:

  • PartitionKeys:

  • EffectiveDateTime:

    • Data/ora UTC da cui è effettivo il criterio.
    • Questa proprietà è facoltativa. Se non viene specificato, il criterio avrà effetto per i dati inseriti dopo l'applicazione del criterio.

Attenzione

  • È possibile impostare un valore datetime nei dati già inseriti in passato e partizionato. Tuttavia, questa procedura può aumentare significativamente le risorse usate nel processo di partizionamento.
  • Nella maggior parte dei casi, è consigliabile disporre solo di dati appena inseriti partizionati ed evitare il partizionamento di grandi quantità di dati cronologici.
  • Se si sceglie di partizionare i dati cronologici, è consigliabile farlo gradualmente, impostando EffectiveDateTime su un datetime precedente nei passaggi fino a pochi giorni ogni volta che si modificano i criteri.

Esempio di partizionamento dei dati

Oggetto criteri di partizionamento dei dati con due chiavi di partizione.

  1. Chiave di partizione hash su una stringcolonna tipizzata denominata tenant_id.
    • Usa la XxHash64 funzione hash, con MaxPartitionCount impostato sul valore 128consigliato e l'impostazione predefinita Seed di 1.
  2. Chiave di partizione dell'intervallo datetime uniforme su una datetime colonna di tipo denominata timestamp.
    • Viene usato datetime(2021-01-01) come punto di riferimento, con una dimensione di 7d per ogni partizione.
{
  "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
      }
    }
  ]
}

Proprietà aggiuntive

Le proprietà seguenti possono essere definite come parte dei criteri. Queste proprietà sono facoltative e è consigliabile non modificarle.

Proprietà Descrizione Impostazione consigliata Valore predefinito
MinRowCountPerOperation Destinazione minima per la somma del numero di righe degli extent di origine di una singola operazione di partizionamento dei dati. 0
MaxRowCountPerOperation Destinazione massima per la somma del numero di righe degli extent di origine di una singola operazione di partizionamento dei dati. Impostare un valore inferiore a 5M se si nota che le operazioni di partizionamento utilizzano una grande quantità di memoria o CPU per operazione. 0, con una destinazione predefinita di 5.000.000 record.
MaxOriginalSizePerOperation Destinazione massima per la somma delle dimensioni originali (in byte) degli extent di origine di una singola operazione di partizionamento dei dati. Se le operazioni di partizionamento utilizzano una grande quantità di memoria o CPU per operazione, impostare un valore inferiore a 5 GB. 0, con una destinazione predefinita di 5.368.709.120 byte (5 GB).

Processo di partizionamento dei dati

  • Il partizionamento dei dati viene eseguito come processo in background post-inserimento nel cluster.
    • Si prevede che una tabella inserita continuamente in abbia sempre una "coda" di dati che deve essere ancora partizionata (extent non omogenei).
  • Il partizionamento dei dati viene eseguito solo in extent ad accesso frequente, indipendentemente dal valore della EffectiveDateTime proprietà nei criteri.
    • Se è necessario partizionare extent ad accesso sporadico, è necessario modificare temporaneamente i criteri di memorizzazione nella cache.

È possibile monitorare lo stato di partizionamento delle tabelle con i criteri definiti in un database usando il comando .show database extents partitioning statistics .

Capacità di partizionamento

  • Il processo di partizionamento dei dati comporta la creazione di più extent. Il cluster può aumentare gradualmente la capacità di unione degli extent, in modo che il processo di unione degli extent possa essere mantenuto.
  • Se è presente una velocità effettiva di inserimento elevata o un numero sufficiente di tabelle con criteri di partizionamento definiti, il cluster può aumentare gradualmente la capacità di partizione extent, in modo che il processo di partizionamento degli extent possa essere mantenuto.
  • Per evitare di consumare troppe risorse, questi aumenti dinamici vengono limitati. Potrebbe essere necessario aumentarli gradualmente e linearmente oltre il limite, se vengono usati completamente.
    • Se l'aumento delle capacità comporta un aumento significativo dell'uso delle risorse del cluster, è possibile aumentare le prestazioni del cluster/, manualmente o abilitando la scalabilità automatica.

Limitazioni

  • I tentativi di partizionare i dati in un database con più di 5.000.000 extent verranno limitati.
    • In questi casi, la EffectiveDateTime proprietà dei criteri di partizionamento delle tabelle nel database verrà ritardata automaticamente di diverse ore, in modo da poter rivalutare la configurazione e i criteri.

Outlier nelle colonne partizionate

  • Le situazioni seguenti possono contribuire alla distribuzione sbilanciata dei dati tra i nodi del cluster e a ridurre le prestazioni delle query:
    • Se una chiave di partizione hash include valori molto più diffusi di altri, ad esempio una stringa vuota o un valore generico (ad esempio null o N/A).
    • I valori rappresentano un'entità (ad esempio tenant_id) più diffusa nel set di dati.
  • Se una chiave di partizione datetime di un intervallo uniforme ha una percentuale sufficientemente elevata di valori "lontani" dalla maggior parte dei valori nella colonna, il sovraccarico del processo di partizionamento dei dati viene aumentato e può portare a molti piccoli extent di cui il cluster dovrà tenere traccia. Un esempio di tale situazione è rappresentato dai valori datetime del passato o del futuro distante.

In entrambi questi casi, "correggere" i dati o escludere eventuali record irrilevanti nei dati prima o in fase di inserimento, per ridurre il sovraccarico del partizionamento dei dati nel cluster. Ad esempio, usare un criterio di aggiornamento.

Contenuti correlati