Il database sta funzionando lentamente, anche tutte le tabelle stanno avendo la normalizzazione

Vorrei parlare di come ci siano molte cose che possono essere fatte per migliorare le prestazioni. La prima cosa è sempre quella di verificare se sono presenti gli indici corretti. Di particolare preoccupazione in un database normalizzato è assicurarsi che gli FK siano indicizzati. Probabilmente ciò risolverebbe molti problemi di prestazioni.

Altre cose da considerare riscriverebbero il codice SQL per usare tecniche più performanti come sbarazzarsi di cursori e subquery correlate e rendere le clausole sargable. Si desidera esaminare singolarmente le query con il rendimento peggiore. Dovresti anche esaminare le query che vengono eseguite frequentemente (specialmente se più utenti le eseguono simultaneamente) poiché una piccola modifica in quelle potrebbe moltiplicarsi nel sistema. Se le tue domande peggiori provengono da un ORM, potrebbero dover essere riscritte come stored proc in modo che possano essere ottimizzate per le prestazioni.

Potresti anche assicurarti di avere un problema di prestazioni. Quello che potresti avere è in realtà un problema di blocco in cui il codice performante viene bloccato da altri processi e deve attendere.

Quindi dovresti considerare l'hardware, se hai sottodimensionato hardware e connessioni di rete, probabilmente nessun altro cambiamento lo risolverà.

In un sistema aziendale di grandi dimensioni, è possibile prendere in considerazione il partizionamento dei dati.

La denormalizzazione è una tecnica per migliorare le prestazioni, ma è la ultima cosa che vorresti considerare. Primo, hai il rischio di modificare drasticamente la struttura. La conversione dei dati nella nuova struttura è qualcosa che può andare molto male se viene commesso un errore ed è più dispendioso in termini di tempo apportare questo tipo di cambiamento strutturale rispetto agli altri possibili miglioramenti delle prestazioni. Sarebbe anche irresponsabile denormalizzare senza creare trigger per assicurarsi che i dati rimangano sincronizzati mentre viene modificato nelle tabelle denormalizzate. Ciò potrebbe significare che le selezioni sono imporse ma le query di azione sono più lente, quindi le prestazioni potrebbero non essere imputate tanto quanto si pensa. È anche una preoccupazione che nella denormalizzazione, potresti rendere le tabelle significativamente più ampie e che possono influire negativamente sulle prestazioni se hai tabelle ampie.

Mi sembra che il tuo intervistatore non stia cercando una risposta data scientist ma semplicemente cercando di capire che "normalizzazione"!="performance". Quindi terrò questa risposta al livello che suppongo abbia voluto.

Normalizzazione significa minimizzare la ridondanza nei dati memorizzati. Invece si impostano le relazioni (spesso con vincoli esterni) tra più tabelle. Tuttavia, mentre la normalizzazione potrebbe portare a una minore quantità di dati memorizzati, spesso crea problemi di prestazioni perché ora molte query finiscono per unirsi a più tabelle. Stessa cosa con l'aggiunta di dati in cui è ora possibile aggiornare più tabelle contemporaneamente.

Spesso, i guadagni di velocità potrebbero essere ottenuti declassificando i dati. Stai archiviando di più e potrebbero esserci duplicati, ma quando si tratta di eseguire le query più frequentemente utilizzate, tutti i tuoi dati ora si troverebbero in un'unica tabella. Ottenere risultati da una tabella di solito è molto più semplice sull'hardware che dover unire più tabelle

Rendere le istruzioni INSERT più veloci è un po 'un'arte arcana. Ma questo probabilmente non è l'obiettivo. Il punto di un database non sta mettendo i dati in esso; sta tornando in modi interessanti e utili. Quindi le cose principali su cui concentrarsi sono le istruzioni SELECT.

La prima cosa che guarderei è controllare i piani di query su query lente. Verifica se hai scansioni di tabelle che occupano una percentuale significativa del tuo tempo. Una scansione della tabella è quando il motore del database deve esaminare ogni riga individualmente per vedere se soddisfa un criterio WHERE. Se trovi uno di questi, puoi eseguire la query più velocemente indicizzando la tabella nei criteri WHERE appropriati. Questo può richiedere tempi di ricerca da O (N) a O (log N) o anche O (1).

Alcuni database ti renderanno più facile: il loro programma di analisi delle query ti indicherà che ti manca un indice e suggerisci cosa dovresti creare.

Inoltre, controlla i join sulla tua query. Assicurati che non stiano utilizzando criteri di adesione troppo ampi e fai attenzione a non utilizzare i join esterni a sinistra quando un join completo funzionerebbe. Entrambi questi problemi possono causare una query mal scritta per produrre troppe righe e impiegare più tempo per l'esecuzione.

Se non hai indici mancanti o join errati, un trucco più avanzato è denormalizzazione : impostazione di colonne su tabelle che duplicano dati che possono essere trovati in altre tabelle, per consentire di evitare join o aggregati che possono essere costosi. Questo deve essere fatto con attenzione, però, con trigger in modo che i dati rimangano sincronizzati, ed è meglio farlo solo se sai cosa stai facendo e se non ci sono alternative migliori disponibili.

In particolare, nel Query Execution Plan cerca le azioni che sono scansioni di tabelle invece di ricerche di indice. È un suggerimento che potresti voler aggiungere un indice per dire una colonna che rappresenta la chiave esterna (non vengono creati automaticamente)

Altre opzioni sarebbero mettere i file di dati su dischi fisici diversi. Anche l'utilizzo del RAID per le partizioni potrebbe funzionare. Per lo meno, si desidera separare i file di registro da quei file di dati ... in modo che la scrittura nel registro non influenzi il tempo di scrittura sul file di dati.

Altri scenari avanzati includono il clustering e il sharding per consentire il carico delle ricerche su più nodi.