Ottimizzazione dei carichi di lavoro di scrittura

Implementare il bilanciamento del carico e liberare l'istanza di scrittura aiuteranno il carico di lavoro di scrittura a migliorare le prestazioni durante i picchi elevati. Per ottenere prestazioni di scrittura migliori in presenza di elevata simultaneità, segui i seguenti passaggi aggiuntivi.

Sposta l'integrità referenziale nel livello applicativo

Sebbene i controlli dell'integrità referenziale siano importanti, con l'hyperscale possono influire negativamente sul carico. Prima di eseguire ogni scrittura è necessario eseguire scansioni aggiuntive, e ciò si traduce in prestazioni scadenti. Se l'applicazione richiede controlli di integrità rigorosi, inseriscili nel livello applicativo per evitare che limitino le operazioni di scrittura.

Evita di usare chiavi primarie pesanti

Mantieni leggere le chiavi primarie. Il motore di archiviazione InnoDB aggiunge la chiave primaria a ogni altro indice creato nella tabella. Quando la chiave primaria è grande, influisce sulla dimensione dell'indice. Se la chiave primaria è piuttosto grande, l'archiviazione e il recupero delle pagine di dati rallenteranno. Un esempio comune è l'uso di identificatori univoci universali come chiavi primarie. Non si tratta di un buon approccio se si punta alle prestazioni in un ambiente iperdimensionato.

Usa lo scambio di partizioni per caricare i dati in tabelle partizionate

Se stai scrivendo grandi set di dati in tabelle partizionate, la combinazione di LOAD DATA FROM S3 e scambio di partizioni può migliorare le prestazioni, poiché non è possibile accedere alla tabella principale per gli inserti. Lo scambio di partizioni prevede un DDL (data definition language) e inserisce un blocco dei metadati sulla tabella. Assicurati che ciò avvenga quando le query in esecuzione sulla tabella sono minime o assenti, in modo che il DDL dello scambio di partizioni possa ottenere il blocco dei metadati senza attese. Il completamento dello scambio richiede pochi millisecondi.

Rimuovere gli indici inutilizzati

InnoDB ottimizza i suoi piani di query in base alla crescita dei dati, ed è consigliabile controllare gli indici inutilizzati nel database e rimuoverli. Gli indici non utilizzati consumano IO quando l'applicazione scrive dati in una tabella. Controlla l'elenco degli indici non utilizzati e verifica che non si tratti di indici utilizzati in situazioni rare, come i report trimestrali. Tieni inoltre presente che devono essere presi in considerazione anche alcuni indici che vengono utilizzati per applicare l'unicità o l'ordinamento.

Assicurati che le versioni di riga precedenti vengano eliminate in modo efficiente

Nell'implementazione InnoDB del controllo della concorrenza multiversione (MVCC), quando viene modificato un record, la versione (precedente) corrente dei dati modificati viene prima registrata come record di annullamento in un log di annullamenti. Un valore della lunghezza dell'elenco della cronologia (HHL) indica che i thread di rimozione di oggetti inutili (thread di rimozione) di InnoDB non stanno al passo con il carico di lavoro di scrittura o che l'eliminazione è bloccata da una query o transazione di lunga durata. Quando la rimozione di oggetti inutili viene bloccata o ritardata, il database può sviluppare un notevole ritardo di rimozione che può influire negativamente sulle prestazioni delle query. È possibile usare i seguenti consigli per ottimizzare il processo di eliminazione.

• Mantieni le transazioni piccole.

• Per le query di lettura, usa il livello di isolamento READ COMMITTED.

• Aumenta il numero di thread di rimozione (innodb_purge_threads e innodb_purge_batch_size). Nota che l'ottimizzazione di questi parametri richiede un riavvio.

• Monitora regolarmente l'HLL e risolvi eventuali problemi di carico di lavoro che impediscono il proseguimento della rimozione di oggetti inutili.

Assicurati che la registrazione non generi ulteriori contese

Il log generale delle query registra le connessioni e le disconnessioni dei client, oltre a tutte le istruzioni ricevute dal server nell'ordine in cui sono state ricevute. Se attivata, la registrazione è sincrona, il che può comportare un notevole calo delle prestazioni su un sistema occupato. A meno che non sia necessario, si consiglia di disattivare il log generale.

Il log delle query lente registra le istruzioni che hanno richiesto più secondi del valore long_query_time per essere eseguite, con l'impostazione predefinita di 10 secondi. Quando l'impostazione è su 0, tutte le istruzioni vengono registrate in modo sincrono, il che può comportare un calo delle prestazioni nei database occupati.