Riduci il carico

Per migliorare i tempi di risposta e aumentare le risorse disponibili per i flussi di lavoro critici potrebbe essere necessario eliminare il carico estraneo. Molte delle soluzioni trattate in questa sezione sono decisioni di compromesso che hanno delle conseguenze sull'applicazione e devono essere considerate con attenzione. È possibile considerare l'utilizzo di queste soluzioni nelle seguenti situazioni:

• Usi già istanze di dimensioni maggiori, in particolare per l'istanza di database principale scrivibile.

• Come ultima risorsa, per fornire un margine di manovra sufficiente a implementare altre modifiche nel breve periodo.

Le modifiche immediate includono:

• Spostare il traffico di lettura non critico dall'istanza database primaria.

• Archiviare o eliminare dati vecchi.

• Rimuovere l'integrità referenziale.

• Disabilitare il binlog (se in uso).

• Rinviare i processi di estrazione, trasformazione e caricamento (ETL) non critici.

• Sospendere o ridurre le funzionalità non essenziali delle applicazioni.

Prima di intraprendere queste azioni, valutale nel contesto degli obiettivi e dei rischi aziendali a lungo termine.

Separare i carichi di lavoro di lettura e scrittura

Una tecnica comune quando si eseguono applicazioni basate su MySQL consiste nell'assegnare le operazioni di lettura dall'istanza database di scrittura (principale) a una o più repliche di database di sola lettura. Riducendo il carico delle letture, è possibile ridurre il carico complessivo sull'istanza database principale e liberare spazio per le scritture. Assicurati di scegliere come target solo le letture che non dipendono dalla coerenza lettura dopo scrittura per le repliche. Un approccio più efficiente consiste nello spostare tutto il traffico di lettura sulla replica e pianificare un nuovo tentativo di lettura dopo scrittura in caso di ritardo di replica. Esistono carichi di lavoro di lettura indipendenti che possono essere scaricati, come i servizi di reporting. Altre letture richiedono modifiche a livello di applicazione, dove il contesto del motivo per cui è stata emessa la lettura è ben noto.

Un approccio alternativo consiste nell'implementare una soluzione proxy di database che funga da intermediario tra l'applicazione e il database e che fornisca la funzione di suddivisione di lettura/scrittura e di routing delle query senza che l'applicazione ne sia consapevole. ProxySQL, MariaDB MaxScale, ScaleARC e Heimdall Data sono alcune delle soluzioni proxy compatibili con MySQL disponibili. Questi prodotti offrono diverse funzionalità aggiuntive, come la memorizzazione nella cache o il multiplexing delle connessioni. Quando si verifica un improvviso aumento del traffico e si implementa una nuova tecnologia nello stack di applicazioni, si consiglia di iniziare con le funzionalità di base per suddividere le query di lettura/scrittura e testare il comportamento e le prestazioni prima di utilizzare funzionalità aggiuntive che potrebbero avere effetti collaterali indesiderati.

Archivia o rimuovi i dati più vecchi

Un'altra tecnica per migliorare le prestazioni del database è l'offload dei dati della cronologia in un'altra tabella, database o Amazon Simple Storage Service (Amazon S3). Molti database mantengono tutti i dati in linea per l'intera cronologia dell'applicazione. In circostanze normali, in una tipica applicazione rivolta agli utenti, ciò offre agli utenti la possibilità di visualizzare la cronologia di tutti i loro ordini. Quando la domanda aumenta improvvisamente, probabilmente molti utenti attivi sull'applicazione sono nuovi o sono intenti a effettuare un nuovo ordine. Se i dati storici si trovano online in un'unica tabella contenente miliardi di righe, questo comporta che. Probabilmente la tabella ha anche indici di grandi dimensioni. Sia i dati della tabella che gli indici sono memorizzati in una struttura ad albero. Un maggior numero di voci in una tabella richiede un maggior numero di livelli nell'albero, il che comporta un maggior numero di operazioni di I/O per accedere alle righe. Il che aumenta il tempo di accesso per trovare i singoli record. Ma soprattutto, fa sì che nella cache della pagina del database (pool di buffer di InnoDB) siano presenti ampie porzioni non necessarie dell'indice.

L'archiviazione dei dati più vecchi in una tabella separata, in un database separato o in Amazon S3 può ridurre i tempi di accesso per gli utenti finali, liberando preziosa cache e migliorando le prestazioni complessive delle applicazioni. L'archiviazione dei dati meno recenti prima dell'evento (ad esempio, conservandoli solo per 30 o 90 giorni) limita la dimensione delle tabelle e degli indici nelle tabelle critiche. Questo cambiamento richiede la modifica dell'applicazione per interrogare i dati precedenti da una posizione secondaria solo per il piccolo sottoinsieme di utenti che chiedono esplicitamente di visualizzare i dati storici.

Rinvia i processi ETL non critici

Le estrazioni dal sistema di database principale per i processi ETL possono presentare un rischio di stabilità per carichi di lavoro altamente transazionali e simultanei in condizioni di hyperscale. I processi ETL sono noti per le seguenti caratteristiche:

• Transazioni di lunga durata

• Blocchi estesi

• Consumo di CPU, memoria e I/O

• Conflitto con carichi di lavoro transazionali che servono al percorso critico dell'utente finale.

I processi ETL variabili o imprevedibili (ad esempio, query come INSERT INTO ... SELECT FROM ...;) aumentano la variabilità complessiva del carico e della contesa, aumentando il rischio di stabilità.

Ove possibile, posticipa o riduci la frequenza di esecuzione dei processi ETL, soprattutto se non forniscono funzioni critiche. Per i processi ETL critici, modificali in modo che funzionino in unità di lavoro limitate, come l'elaborazione di batch di numeri fissi di righe (ad esempio, utilizzando clausole LIMIT), usando transazioni separate o estraendo quantità minori di dati per un periodo di tempo prolungato per ridurre i picchi di richieste di risorse dell'istanza database.

Disattiva le funzionalità dell'applicazione meno critiche

La riduzione graduale della qualità dell'esperienza utente o la rimozione di funzionalità non fondamentali nella gestione di un aumento delle richieste consentono di risparmiare le risorse del database per le funzioni critiche. Ciò potrebbe richiedere una leggera modifica dell'esperienza del cliente, ma è meglio un flusso diverso rispetto a un sito inattivo. Forse è possibile disattivare temporaneamente la personalizzazione della prima pagina del sito che effettua sempre una chiamata al database. Oppure si può smettere di presentare offerte personalizzate ai clienti abituali durante la selezione dei prodotti. Disattivare temporaneamente le funzionalità può consentire la memorizzazione nella cache o la distribuzione della pagina senza dover richiedere l'accesso al database.

Altri esempi includono un frontend dotato di un meccanismo di polling che controlla le modifiche ai dati che richiedono una chiamata al database. La riduzione della frequenza di polling comporterà immediatamente un minor numero di chiamate al database. Le interfacce utente che richiedono l'impaginazione o che offrono agli utenti la possibilità di recuperare set di risultati ordinati più lontano dal risultato principale richiedono chiamate al database progressivamente più costose. Limita il numero di pagine in un set di risultati per proteggere il database dalle chiamate al database più costose. Utilizza i flag delle funzionalità a livello dell'applicazione per consentire al team operativo di disattivare o ridurre le funzionalità all'aumentare del carico dell'applicazione o del database.