Condividi tramite

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

Questo articolo illustra i suggerimenti per ottenere prestazioni migliori per la velocità effettiva di scrittura durante il caricamento dei dati nel database SQL di Azure tramite Analisi di flusso di Azure.

L'output SQL in Analisi di flusso di Azure supporta la scrittura in parallelo come opzione. Questa opzione consente topologie di processo completamente parallele , in cui più partizioni di output scrivono nella tabella di destinazione in parallelo. L'abilitazione di questa opzione in Analisi di flusso di Azure potrebbe tuttavia non essere sufficiente per ottenere velocità effettiva più elevate, perché dipende in modo significativo dalla configurazione del database e dallo schema della tabella. La scelta degli indici, della chiave di clustering, del fattore di riempimento dell'indice e della compressione ha un impatto sul tempo necessario per caricare le tabelle. Per altre informazioni su come ottimizzare il database per migliorare le prestazioni delle query e del carico in base ai benchmark interni, vedere Linee guida sulle prestazioni del database SQL. L'ordinamento delle scritture non è garantito durante la scrittura in parallelo al database SQL.

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

Analisi di streaming 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 opzione abilitata, scrivere su una tabella basata su disco e avere una topologia completamente parallela per il processo, si può prevedere una velocità effettiva migliore. Questo partizionamento avviene già automaticamente per molti altri output. Il blocco di tabella (TABLOCK) viene inoltre disabilitato per gli inserimenti bulk eseguiti con questa opzione.

    Annotazioni

    Quando sono presenti più di 8 partizioni di input, l'ereditarietà dello schema di partizionamento di input potrebbe non essere una scelta appropriata. Questo limite superiore è stato osservato in una tabella con una singola colonna di identità e un indice clusterizzato. In questo caso, è consigliabile usare 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.

  • Dimensioni batch : la configurazione dell'output SQL consente di specificare le dimensioni massime del batch in un output SQL di Analisi di flusso di Azure in base alla natura della tabella o del carico di lavoro di destinazione. La dimensione del batch è il numero massimo di record inviati con ogni transazione di inserimento bulk. Negli indici columnstore clustered, le dimensioni dei batch intorno a 100.000 consentono una maggiore parallelizzazione, una registrazione minima e ottimizzazioni di blocco. 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.

  • Ottimizzazione dei messaggi di input - Se hai ottimizzato utilizzando partizionamento ereditato e dimensioni batch, aumentare il numero di eventi di input per messaggio per ogni partizione aiuta ad aumentare ulteriormente il throughput di scrittura. L'ottimizzazione dei messaggi di input consente alle dimensioni dei batch in Azure Stream Analytics di raggiungere le dimensioni specificate, migliorando così il throughput. A tale scopo, è possibile usare la compressione o aumentare le dimensioni dei messaggi di input in EventHub o BLOB.

SQL Azure

  • Tabella e indici partizionati : l'uso di una tabella SQL partizionata e di indici partizionati nella tabella con la stessa colonna della chiave di partizione ,ad esempio PartitionId, può ridurre significativamente i conflitti tra le partizioni durante le scritture. Per una tabella partizionata, è necessario creare una funzione di partizione e uno schema di partizione nel filegroup PRIMARY. Ciò aumenterà anche la disponibilità dei dati esistenti durante il caricamento di nuovi dati. Il limite di I/O del log può essere raggiunto in base al numero di partizioni, che possono essere aumentate aggiornando lo 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.

Tabelle di Azure Data Factory e In-Memory

  • In-Memory Tabella come tabella temporanea : le tabelleIn-Memory consentono caricamenti di dati ad alta velocità, ma i dati devono essere inseriti in 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 bulk, 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 rispetto al caricamento di dati con singoli inserimenti perché viene evitato 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 invece usato un percorso più efficiente nel motore di archiviazione per trasmettere i dati. Il costo di configurazione di questo percorso è tuttavia molto superiore a una singola istruzione insert in una tabella basata su disco. Il punto di pareggio è in genere di circa 100 righe, oltre il quale il caricamento in blocco è quasi sempre più efficiente.

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

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

Un altro scenario di questo tipo si verifica quando si scrive in un indice columnstore non clusterizzato (NCCI), in cui gli inserimenti bulk più piccoli possono creare troppi segmenti che possono causare il crash dell'indice. In questo caso, è consigliabile usare un indice Columnstore clusterizzato.

Sommario

In sintesi, con la funzionalità di output partizionato in Analisi di flusso di Azure per l'output SQL, la parallelizzazione allineata del processo con una tabella partizionata in SQL Azure dovrebbe offrire miglioramenti significativi della velocità effettiva. L'uso di Azure Data Factory per orchestrare lo spostamento dei dati da una tabella In-Memory in tabelle basate su disco può offrire un aumento sostanziale della velocità di trasmissione. Se possibile, migliorare la densità dei messaggi può anche essere un fattore importante per migliorare la velocità effettiva complessiva.

Passaggi successivi

  • Last updated on