Aumentare le prestazioni della velocità effettiva per il database SQL di Azure da Analisi di flusso di Azure

  • Articolo

Questo articolo illustra i suggerimenti per ottenere prestazioni di velocità effettiva di scrittura migliori quando si caricano dati in Azure SQL database usando Analisi di flusso di Azure.

L'output di SQL nell'Analisi di flusso di Azure supporta la scrittura in parallelo come opzione. Questa opzione consente di avere topologie perfettamente parallele, dove più partizioni di output vengono scritte in parallelo sulla tabella di destinazione. L'abilitazione di questa opzione in Analisi di flusso di Azure potrebbe tuttavia non essere sufficiente per ottenere velocità effettiva più elevate, in quanto dipende in modo significativo dalla configurazione del database e dallo schema della tabella. La scelta degli indici, la chiave di clustering, il fattore di riempimento indice e la compressione possono influire sui tempi di caricamento delle tabelle. Per altre informazioni su come ottimizzare il database per migliorare le prestazioni delle query e del carico in base ai benchmark interni, vedere database SQL linee guida sulle prestazioni. L'ordinamento delle scritture non è garantito quando si scrive in parallelo a database SQL.

Ecco alcune configurazioni all'interno di ogni servizio che consentono di migliorare la velocità effettiva complessiva della soluzione.

Analisi di flusso di Azure

  • Ereditare il partizionamento – Questa opzione di configurazione dell'output di SQL consente di ereditare lo schema di partizione del passaggio precedente della query o dell'input. Con questa impostazione attivata, la scrittura in una tabella basata su disco e con una topologia perfettamente parallela per il processo, ci si aspetta di vedere migliori velocità effettive. Questo partizionamento avviene automaticamente per molti altri output. Il blocco di tabella (TABLOCK) viene inoltre disabilitato per gli inserimenti bulk eseguiti con questa opzione.

    Nota

    Quando sono presenti più di 8 partizioni di input, ereditare l'input dello schema di partizione potrebbe non essere una scelta appropriata. Il limite massimo è stato rilevato in una tabella con una colonna di identità singola e un indice cluster. In questo caso, prendere in considerazione l'uso di INTO 8 nella query per specificare in modo esplicito il numero di writer di output. In base allo schema e alla scelta degli indici, le osservazioni possono variare.

  • Dimensione batch - la configurazione di output SQL consente di specificare le dimensioni massime del batch in un output Analisi di flusso SQL di Azure, in base alla natura del carico di lavoro/tabella di destinazione. La dimensione del batch indica il numero massimo di record inviati con ogni transazione di inserimento di massa. Negli indici columnstore cluster, le dimensioni del batch intorno ai 100K consentono una maggiore parallelizzazione, una registrazione minima e le ottimizzazioni dei blocchi. Nelle tabelle basate su disco, uguale o inferiore a 10K (impostazione predefinita), può essere ottimale per la soluzione, in quanto le dimensioni di batch maggiori possono attivare l'escalation blocchi durante gli inserimenti di massa.

  • Sintonizzazione del messaggio di Input – se è stato ottimizzato tramite l'ereditare il partizionamento e la dimensione del batch, l'aumento del numero di eventi di input per ogni messaggio e partizione consente di aumentare ulteriormente la velocità effettiva di scrittura. La sintonizzazione del messaggio di input consente alle dimensioni del batch all'interno delle Analisi di flusso di Azure di arrivare alla dimensione del batch specificata, migliorando così la velocità effettiva. Ciò può essere ottenuto usando la compressione o aumentando le dimensioni dei messaggi di input in EventHub o BLOB.

SQL Azure

  • Tabelle e indici partizionati – Usare una tabella SQL partizionata e gli indici partizionati sulla tabella con la stessa colonna come chiave di partizione (ad esempio PartitionId) può ridurre notevolmente le contese tra partizioni durante la scrittura. Per una tabella partizionata, è necessario creare una funzione di partizione e uno schema di partizione nel filegroup primario. Questo aumenterà anche la disponibilità dei dati esistenti mentre vengono caricati i dati nuovi. Il limite del log IO potrebbe raggiungere il valore basato sul numero di partizioni che può essere aumentato eseguendo l'aggiornamento dello SKU.

  • Evitare le violazioni della chiave univoca – Se si verificano più messaggi di avviso di violazione della chiave nel Log di Analisi di flusso di Azure, assicurarsi che il processo non è interessato da violazioni di vincolo uniche che possono verificarsi durante i casi di ripristino. Questa operazione può essere evitata impostando l'opzione IGNORE_DUP_KEY sugli indici.

Data Factory di Azure e tabelle in memoria

  • Tabella in memoria come tabella temporanea : le tabelle in memoria consentono carichi di dati ad alta velocità, ma i dati devono adattarsi alla memoria. I benchmark mostrano che il caricamento di massa da una tabella in memoria in una tabella basata su disco è circa 10 volte più veloce rispetto all'inserimento di massa diretto tramite un unico scrittore nella tabella basata su disco con una colonna identity e un indice cluster. Per sfruttare queste prestazioni di inserimento di massa, configurare un processo di copia usando Azure Data Factory che copia i dati dalla tabella in memoria alla tabella basata su disco.

Evitare problemi di prestazioni

L'inserimento bulk dei dati è molto più veloce del caricamento dei dati con singoli inserimenti perché il sovraccarico ripetuto del trasferimento dei dati, l'analisi dell'istruzione insert, l'esecuzione dell'istruzione e l'emissione di un record di transazione viene evitato. Viene invece usato un percorso più efficiente nel motore di archiviazione per trasmettere i dati. Il costo di installazione di questo percorso è tuttavia molto superiore a un'istruzione di inserimento singola in una tabella basata su disco. Il punto di interruzione è in genere circa 100 righe, oltre il quale il caricamento bulk è quasi sempre più efficiente.

Se la frequenza degli eventi in ingresso è bassa, può facilmente creare dimensioni batch inferiori a 100 righe, che rende l'inserimento bulk inefficiente e usa troppo spazio su disco. Per risolvere questa limitazione, è possibile eseguire una di queste azioni:

  • Creare un trigger INSTEAD OF per usare un semplice inserimento per ogni riga.
  • Usare una tabella temp In-Memory, come descritto nella sezione precedente.

Un altro scenario di questo tipo si verifica quando si scrive in un indice columnstore non cluster (NCCI), dove gli inserimenti bulk più piccoli possono creare troppi segmenti, che possono arrestare l'indice. In questo caso, la raccomandazione consiste nell'usare un indice Columnstore cluster.

Riepilogo

In riepilogo, con la funzionalità di output partizionato in Analisi di flusso di Azure per l'output SQL, l'allineamento del processo di parallelizzazione con una tabella partizionata in SQL Azure dovrebbe fornire miglioramenti significativi della velocità effettiva. Sfruttando Azure Data Factory per orchestrare lo spostamento dei dati da una tabella in memoria in tabelle basate su disco, è possibile ottenere guadagni di velocità effettiva in ordine di grandezza. Se fattibile, il miglioramento della densità dei messaggi può essere un fattore determinante per migliorare la velocità effettiva complessiva.

Passaggi successivi