Ottimizzazione delle query del database nel codice testabile dell'unità

Question

Ottimizzazione delle query del database nel codice testabile dell'unità

#1 da (5 voti)
#2 da (1 voti)
#3 da (1 voti)
#4 da (0 voti)
#5 da (-1 voti)

4

Quindi diciamo che stai scrivendo software per qualche azienda. Le best practice, così come le comprendo, imporranno che per scopi di sviluppo, si compila il DB con dati falsi . Ci sono una serie di vantaggi a questo.

Se utilizzerai, per esempio, Vagrant per gestire l'ambiente di sviluppo, la maggior parte delle immagini pre-costruite ha un HDD di dimensioni limitate. Come diciamo che la produzione ha 100 di GB di dati. La tua scatola di Vagrant non sarà probabilmente così grande. Inoltre, se stai facendo test di integrazione continui, probabilmente non vorrai farlo con un DB di dimensioni di produzione.
In teoria, gli sviluppatori non dovrebbero avere informazioni personali identificabili dei clienti del mondo reale e questo lo facilita.

Un grosso problema che vedo con questo, tuttavia, è ... diciamo che il tuo DB di sviluppo è, nel complesso, di dimensioni pari a 1 MB, mentre la produzione è di 100 GB di dimensioni. Uno sviluppatore potrebbe scrivere una query che unisce le tabelle insieme su colonne non indicizzate. Forse con 1 MB di dati funziona benissimo ma con 100 di GB di dati?

Come si dovrebbe affrontare questo problema?

(se è per questo, a volte ci può essere una quantità eccessiva di burocrazia da tagliare per far sì che i dati di produzione riproducano accuratamente un problema specifico per un cliente, ma questo è un problema organizzativo, non tecnico)

database optimization

posta neubert 27.01.2017 - 04:31

fonte

5 risposte

Leggi altre domande sui tag database optimization

Un modo migliore per memorizzare coppie chiave-valore nel database? Usando Bridge e Strategy insieme, la mia idea è corretta / utile?

score 5 · Answer 1

Questa domanda ha niente in comune con il "test dell'unità", non è causata dal test dell'unità, non può essere rilevata e ovviamente non risolta dal "test dell'unità".

Avere applicazioni che affrontano serie di dati più grandi nella produzione del previsto durante lo sviluppo è un problema molto vecchio (suppongo che abbia 50 anni). Non è in alcun modo limitato ai database e alle query di database, e lo stesso vale per le tattiche per affrontarlo:

Fai una pianificazione e stima corrette per i dati che ti aspetti nella produzione.
Profili con set di dati più piccoli ed estrapolati per quelli più grandi che ti aspetti (e assicurati di non estrapolarli in modo lineare quando l'ordine di crescita è quadratico o peggiore).
Verifica correttamente e assicurati che il tuo programma possa fornirti anche informazioni di profilazione quando viene eseguito in produzione.
Assicurati di non scegliere un'architettura che ti porti in un vicolo cieco per la quantità di dati prevista.
Ottimizza secondo necessità - inizia con l'ottimizzazione quando hai indicatori per problemi di prestazioni, ma non prima. Assicurati che i tuoi sviluppatori sappiano cosa significa "ottimizzazione prematura" e che non ottimizzano le parti errate del codice "nel caso in cui".
Assicurati di avere esperti istruiti, esperti e / o db che lavorano sulle parti critiche dell'applicazione. Scrivere un buon software non è un gioco per principianti.

score 1 · Answer 2

In un mondo ideale:

Hai lasciato che gli amministratori di database si occupassero di questo. Hanno gli strumenti e lo sfondo per prendere le giuste decisioni su cosa e cosa non indicizzare.

In un mondo meno che ideale ci sono alcune cose che puoi fare, tra queste:

1: Sii ragionevole. Non usare un "select *" e se si fa un "select personid from persons where somecondition = x", si può trovare un indice su un buon livello, a meno che, naturalmente, non si faccia 10.000 insert / second sul tavolo.

2: Lascia che la tua applicazione esegua il profiling. Il server SQL, ad esempio, offre alcuni buoni modi per trovare gli indici e le prestazioni del database mancanti in generale.

Il server SQL, ad esempio, ha funzionalità incorporate per trovare gli indici mancanti ed è attivo per impostazione predefinita: Trova gli indici mancanti nel server SQL.

score 1 · Answer 3

Come si dovrebbe affrontare questo problema?

Costruisci un ambiente di test delle prestazioni. Compilare un database con 100s di GB di dati di test. Utilizza tecniche di caricamento collettivo per popolare rapidamente il database. Quindi prova le prestazioni della tua applicazione. Verifica che gli indici e le query funzionino correttamente con questa quantità di dati. In caso contrario, aggiungi o riorganizza i tuoi indici in modo appropriato.

Dai un'occhiata sempre a quanti dati il tuo sistema avrà [N] anni da oggi. Sviluppa una strategia di spurgo / potatura. Metti alla prova le tue domande in relazione ai tuoi high water mark programmati per evitare potenziali problemi di prestazioni in futuro.

score 0 · Answer 4

Test di costruzione Idealmente, non dovresti escludere il codice dal vivo se non ha superato un certo tipo di test di build e il test di compilazione dovrebbe essere abbastanza intelligente da rilevare enormi cambiamenti in termini di prestazioni.
Ottieni un amministratore del database Gli amministratori del database sapranno come creare indici intelligenti sui tavoli.
Buone pratiche di codice Le aziende con set di dati di grandi dimensioni dovrebbero implementare alcuni tipi di standard o pratiche di codice esattamente per questo tipo di motivo.

score -1 · Answer 5

Stored procedure

Se ti trovi in una fase in cui hai un db critico che può essere eliminato da query errate, devi essere un po 'più professionale del semplice inserimento di sql nel codice.

Se tutte le query DB utilizzano SProcs ti fornisce quel livello aggiuntivo di astrazione che è necessario per consentire di modificare le query per le prestazioni man mano che il database si evolve.