Criterio partitioning

Si applica a: ✅Microsoft Fabric✅Azure Esplora dati

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 la ripetizione 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.

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.

• guid 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 uniform
• string o guid cardinalità elevata:
  • Ad esempio, le informazioni IoT da molti sensori diversi o 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 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 backfill 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 allinearli ai valori datetime nella colonna, anziché allinearli al tempo di inserimento, impostare la OverrideCreationTime proprietà su true.

Chiavi di partizione

Sono supportati i tipi di chiavi di partizione seguenti.

Chiave di partizione hash

Se i criteri includono una chiave di partizione hash, tutti gli extent omogenei che appartengono alla stessa partizione verranno assegnati allo stesso nodo dati.

• Una funzione hash-modulo viene usata per partizionare i dati.
• 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 dell'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 viene ridotta.

Proprietà della partizione

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 di intervallo uniforme

In questi casi, è possibile rimshuffare i dati tra extent in modo che ogni extent includa record da un intervallo di tempo limitato. Questo processo comporta l'efficacia dei filtri sulla datetime colonna in fase di query.

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

Proprietà della partizione

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:

  • Raccolta di chiavi di partizione che definiscono come partizionare i dati nella tabella.
  • Una tabella può avere fino a chiavi di 2 partizione, con una delle opzioni seguenti:
    • Una chiave di partizione hash.
    • Una chiave di partizione datetime di intervallo uniforme.
    • Una chiave di partizione hash e una chiave di partizione datetime di intervallo uniforme.
  • Ogni chiave di partizione ha le proprietà seguenti:
    • ColumnName: string - Nome della colonna in base al quale verranno partizionati i dati.
    • Kind: - string Tipo di partizionamento dei dati da applicare (Hash o UniformRange).
    • Properties: property bag - Definisce i parametri in base al partizionamento eseguito.

• EffectiveDateTime:

  • Datetime 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.

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.
   • datetime(2021-01-01) Usa 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.

Processo di partizionamento dei dati

• Il partizionamento dei dati viene eseguito come processo in background post-inserimento.
  • 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 criteri definiti in un database usando il comando .show database extents partitioning statistics e le metriche di partizionamento.

Capacità di partizionamento

• Il processo di partizionamento dei dati comporta la creazione di più extent. La capacità di unione degli extent può aumentare gradualmente, in modo che il processo di unione degli extent possa rimanere aggiornato.

• Se è presente una velocità effettiva di inserimento elevata o un numero sufficiente di tabelle con criteri di partizionamento definiti, la capacità della partizione Extents può aumentare gradualmente, in modo che il processo di partizionamento degli extent possa rimanere aggiornato.

Limiti

• 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 e 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 intervallo uniforme ha una percentuale sufficientemente elevata di valori "lontani" dalla maggior parte dei valori nella colonna, l'overhead del processo di partizionamento dei dati viene aumentato e può portare a molte piccole dimensioni per tenere traccia. Un esempio di tale situazione è costituito dai valori datetime del passato o del futuro distanti.

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. Ad esempio, usare un criterio di aggiornamento.

Contenuto correlato

• Comandi di gestione dei criteri di partizionamento