È l'ottimizzazione prematura per aggiungere indici di database?

Un mio collega oggi ha suggerito di passare attraverso tutte le query nella nostra applicazione e di aggiungere gli indici di conseguenza.

Ritengo sia un'ottimizzazione prematura perché la nostra applicazione non è stata ancora rilasciata. Ho suggerito di monitorare le query lente una volta che siamo online e quindi aggiungere gli indici di conseguenza.

Qual è il consenso generale durante la progettazione del database, è necessario aggiungere un indice corrispondente ogni volta che si scrive una nuova query? O è meglio semplicemente monitorare e vedere come va?

L'ottimizzazione prematura sta "ottimizzando" qualcosa a causa di un senso vago e intuitivo che, sai, probabilmente sarà lento, soprattutto a scapito della leggibilità e della manutenibilità del codice . Ciò non significa intenzionalmente non seguire buone prassi consolidate in materia di prestazioni.

A volte è una linea difficile da tracciare, ma direi sicuramente che non aggiungere alcun indice prima di andare in diretta è un'ottimizzazione troppo tardi ; questo punirà i primi utenti - i tuoi utenti più desiderosi e più importanti - e darà loro una visione negativa del tuo prodotto, che poi diffonderanno in recensioni, discussioni, ecc. Monitorare le domande per trovare punti dolenti che necessitano di indicizzazione è un buona idea, ma mi assicurerei di farlo entro e non oltre la beta.

monitorare le query lente una volta che siamo attivi

perché nulla dice qualità come far soffrire i tuoi utenti per mancanza di design!

Dovresti sapere quali query necessitano di indici quando progetti le tabelle, sai su quali colonne vengono interrogate in dove clausole e join. Questi dovrebbero essere già indicizzati perché ciò che potrebbe non essere evidente in un ambiente live potrebbe diventare rapidamente evidente quando aumenta il carico o i dati memorizzati. Quello che non vuoi fare quando succede è schiaffeggiare gli indici su ogni query "lenta", finirai con un indice su tutto.

"Ottimizzazione precoce", in senso spregiativo, significa costosa ottimizzazione che potrebbe non essere necessaria. Esso non significa che tutti i ottimizzazione attuate prima l'ultimo punto possibile per evitare il fallimento!

In particolare, è legittimo eseguire l'ottimizzazione in base ai test delle prestazioni prima di andare in diretta, per garantire che sia possibile soddisfare alcuni requisiti sensibili (anche se approssimativi) affinché l'app non si schifhi completamente.

Come minimo, è necessario caricare il database con una quantità plausibile di dati di test e verificare la reattività dell'app. Questo non è prematuro, poiché sai che accadrà e prenderà tutte le domande che innescano scansioni assurdamente lente. Come dice AE in un commento:

Utilizzare gli indici per evitare una scansione completa della tabella per qualsiasi query che l'utente finale eseguirà normalmente in tempo reale

Almeno, per le tabelle che sono pianificate per crescere in uso.

Quindi come scorciatoia a questo, se hai una significativa esperienza con il motore di database e hai già pianificato i test quando scrivi il primo taglio del codice, allora spesso saprai senza nemmeno eseguirlo che la query che stai la scrittura sarà troppo lenta senza un indice. Ovviamente sei libero di far finta di non sapere, e guardare il test fallire prima di aggiungere l'indice per farlo passare, ma non c'è motivo per il codice difettoso noto (perché non risponde) per diventare attivo.

Ritengo sia un'ottimizzazione prematura perché la nostra applicazione non è stata ancora rilasciata. Ho suggerito di monitorare le query lente una volta che siamo online e quindi aggiungere gli indici di conseguenza.

Non è possibile trattare gli utenti finali e l'ambiente di produzione come garanzia di qualità. In altre parole, stai dicendo che lo scoprirai in produzione. Non penso che sia la strada giusta e vedo che questo approccio va orribilmente storto ogni giorno .

Devi tenere a mente una cosa, poiché non puoi dipingerla con un pennello largo.

Qual è il tuo carico di lavoro comune ?

Potrebbe sembrare ovvio o noioso, ma è significativo nella pratica. Se hai 10 query che rappresentano il 98% del tuo carico di lavoro (abbastanza comune, che ci crediate o no), la mia raccomandazione sarebbe una dura analisi prima della produzione . Con dati realistici e rappresentativi, assicurati che queste 10 query siano le migliori possibili (la perfetta è una perdita di tempo prezioso e quasi non realizzabile).

Per le altre 200 query che rappresentano il 2% del carico di lavoro , quelle sono quelle che molto probabilmente non valgono una tonnellata di sforzi e compenseranno le stranezze nella risoluzione dei problemi di angolo nella produzione. Anche questa è una realtà, e non una cosa terribilmente negativa. Ma ciò non significa ignorare le migliori pratiche di indicizzazione o fare ipotesi stimate sul recupero dei dati.

È prassi comune e buona norma calcolare le prestazioni del database prima della produzione. In effetti, esiste una posizione relativamente comune per questo tipo di cose chiamata DBA di sviluppo .

Ma...

Alcuni lo spingono troppo in là e impazziscono aggiungendo indici "per ogni evenienza". Qualcuno consiglia questo è un indice mancante? Aggiungilo e altre quattro varianti. Anche una cattiva idea. Devi pensare non solo al recupero dei tuoi dati, ma alla modifica dei dati? Più indici hai su una tabella, generalmente parlando più overhead hai quando modifichi i dati.

Come la maggior parte delle cose, c'è un sano equilibrio.

Come una piccola nota divertente ... La pluralizzazione di "Index"

Gli "indici" sono per i finanziari

Gli "indici" sono per noi

No, non si tratta di ottimizzazione prematura, ma deve essere eseguita correttamente come dovrebbe essere qualsiasi ottimizzazione.

Ecco cosa farei:

1. Caricare il database con dati di test sufficienti per simulare un carico di produzione. Non è possibile ottenere questo preciso al 100% ma va bene: basta inserire abbastanza dati. Una tabella ha una quantità fissa di dati? Caricalo. Hai una tabella che contiene molti dati, ad es. Quale tabella contiene domande su questo sito? Carica alcuni milioni di record anche se solo dati fittizi.
2. Attiva la profilazione nel tuo server di database.
3. Bang via all'applicazione utilizzando una combinazione di script automatici (fornisce volume) e utenti reali (sanno come rompere le cose).
4. Rivedi i dati di profilazione. Le query specifiche sono lente? Controllare i piani di spiegazione e vedere se il server database ti sta dicendo che vuole un indice ma non esiste.

I server di database sono software complessi e intelligenti. Possono dirti come ottimizzarli se sai come ascoltare.

Le chiavi sono misurare le prestazioni prima e dopo l'ottimizzazione e lasciare che il database ti dica di cosa ha bisogno .

Seguire schemi comprovati per problemi noti (come trovare un record con il suo ID) non è nulla di prematuro. È solo ragionevole.

Detto questo, gli indici non sono sempre un affare semplice. Durante la fase di progettazione è spesso difficile sapere da quali indici dipenderà il tuo traffico e quali strozzature per le operazioni di scrittura. Quindi, direi di sfruttare alcune best practice "ovvie" per la progettazione di schemi (utilizzare gli appropriati di PK per i modelli di lettura / scrittura progettati e l'indice di FK); ma, non mettere un indice su nient'altro fino a quando lo stress test non lo richiede.

Quando l'applicazione viene rilasciata, è troppo tardi.

Ma qualsiasi processo di sviluppo adeguato dovrebbe includere test delle prestazioni.

Utilizzare i risultati dei test delle prestazioni per decidere quali indici aggiungere e verificarne l'efficacia ripetendo i test delle prestazioni.

Anche se non credo che ogni query debba essere ottimizzata, gli indici fanno così tanto parte di RDBMS che devono essere presi in considerazione prima di rilasciarli. Quando esegui una query, a differenza di altre forme di programmazione non stai dicendo al sistema come eseguirla. Sviluppano i propri piani e quasi sempre lo basano sulla disponibilità di un indice. La composizione e il volume dei dati saranno considerati anche in tempi successivi.

Ecco alcune cose che vorrei prendere in considerazione:

1. Ci sono alcune domande che dovresti identificare nel tuo primo sviluppo che sai solo che verranno usate frequentemente. Concentrati su di loro.
2. Ci saranno domande lente. Indicizzandoli prima, puoi quindi determinare se le prestazioni non sono ancora abbastanza veloci e quindi prendere in considerazione una riprogettazione (la denormalizzazione può essere prematura). Preferirei farlo prima di un rilascio. Nessuno vuole un sistema in cui ci vogliono 10 minuti per trovare qualcosa nell'inventario.
3. Gli indici possono migliorare le prestazioni delle query ma non devono ostacolare la modifica dei dati.
4. Molti sistemi dispongono di strumenti per analizzare le tue query, quindi non aver paura di usarle.

Dopo la tua revisione iniziale, dovresti dare seguito ad alcune considerazioni su quando dovresti rivederlo di nuovo e su come sarai in grado di raccogliere le informazioni per farlo (monitorare l'utilizzo, ottenere copie dei dati del cliente, ecc.).

Mi rendo conto che non vuoi ottimizzare prematuramente, ma è quasi certo che avrai scarse prestazioni senza indicizzare il tuo database. Togliendolo di mezzo, puoi determinare se ci sono altre aree che causano problemi di prestazioni.

Dipende anche da quanti utenti ti aspetti. Dovresti assolutamente fare alcuni test di carico e assicurarti che il tuo database possa tenere il passo con richieste da 10 a 100 a 1000 di richieste simultanee. Ancora una volta, dipende da quanto traffico ti aspetti e da quali aree ti aspetti di essere utilizzate più di altre.

In generale, vorrei mettere a punto le aree in cui mi aspetto che l'utente colpisca per primo. Quindi metterei a punto tutto ciò che è lento dal punto di vista dell'esperienza dell'utente. Ogni volta che l'utente deve aspettare qualcosa, può avere una brutta esperienza e potrebbe essere rifiutato. Non bene!

È buona norma identificare quali colonne necessitano sicuramente di un indice mediante alcune analisi iniziali. Esiste un rischio reale di degrado graduale o imprevisto delle prestazioni nella produzione poiché le dimensioni del database aumentano se non si dispone di indici. La situazione che si desidera evitare è quando una query comunemente eseguita richiede la scansione di un numero elevato di righe di tabella. Non è un'ottimizzazione prematura aggiungere indici alle colonne critiche poiché hai a disposizione gran parte delle informazioni necessarie e le potenziali differenze di prestazioni sono significative (ordini di grandezza). Ci sono anche situazioni in cui il vantaggio degli indici è meno chiaro o più dipendente dai dati - probabilmente puoi rimandare la decisione per alcuni di questi casi.

Alcune domande che devi porre sono:

• Quali saranno i limiti di progettazione per le dimensioni di ogni tavolo?

Se le tabelle saranno sempre piccole (diciamo <100 righe), non è un disastro se il database deve eseguire la scansione dell'intera tabella. Potrebbe essere utile aggiungere un indice, ma ciò richiede un po 'più di esperienza o misurazione per determinare.

• Con quale frequenza verrà eseguita ciascuna query e qual è il tempo di risposta richiesto?

Se la query viene eseguita di rado e non ha requisiti di tempo di risposta rigorosi (ad es. Generazione di report) e il numero di righe non è enorme, è probabilmente sicuro rinviare l'aggiunta di indici. Ancora una volta, l'esperienza o la misurazione possono aiutare a capire se sarà utile.

• La query richiede di cercare la tabella con qualcosa a parte la chiave primaria? Ad esempio, filtrando per intervallo di date, unendo una chiave esterna?

Se queste query vengono eseguite frequentemente e toccano le tabelle con più righe, è necessario considerare seriamente l'aggiunta preventiva di un indice. Se non sei sicuro che questo sia il caso di una query, puoi popolare il database con una quantità realistica di dati, quindi guarda il piano di query.