Pianificazione della capacità del disco e della RAM
Pianificare la capacità del disco e della memoria per un server di database è un'arte nera. Più "è meglio. Più veloce è meglio.
Come linee guida generali offro quanto segue:
- Volete più spazio su disco di quanto non avrete MAI bisogno.
Prendi la tua migliore stima di quanto spazio su disco avrai bisogno per i prossimi 3-5 anni, quindi raddoppialo.
- Avrai bisogno di RAM sufficiente per conservare gli indici del database in memoria, gestire la tua query più grande almeno due volte, e avere ancora spazio sufficiente per una cache del disco del sistema operativo integra.
Le dimensioni dell'indice dipendono dal database e tutto il resto dipende fortemente dal set di dati e dalla struttura di query / database. Offrirò "Almeno il doppio della dimensione della tua tabella più grande" come suggerimento, ma tieni presente che questo suggerimento si suddivide in operazioni di data warehousing molto grandi in cui la tabella più grande può essere di decine o centinaia di gigabyte.
Ogni fornitore di database ha alcune istruzioni su come ottimizzare le prestazioni del kernel del disco / memoria / SO - Trascorrere del tempo con questa documentazione prima della distribuzione. Aiuterà.
Benchmarking del carico di lavoro e pianificazione della capacità
Supponendo che non sia stato ancora distribuito ...
Molti sistemi di database vengono forniti con strumenti di benchmarking - Ad esempio,
PostgreSQL viene fornito con
pgBench .
Questi strumenti dovrebbero essere la tua prima tappa nel benchmarking delle prestazioni del database. Se possibile, eseguirli su tutti i nuovi server di database per avere un'idea di "quanto lavoro" può fare il server di database.
Dotato ora di un benchmark non elaborato che ABSOLUTELY MEANINGLESSconsideriamo un approccio più realistico al benchmarking: carica lo schema del database e scrivi un programma che lo popola con dati fittizi, quindi esegui le query della tua applicazione su tali dati.
Questo mette a confronto tre cose importanti: 1. Il server di database (hardware) 2. Il server di database (software) 3. La progettazione del database e il modo in cui interagisce con (1) e (2) sopra.
Si noti che ciò richiede uno sforzo molto maggiore rispetto ai semplici benchmark predefiniti come pgBench: È necessario scrivere del codice per eseguire il popolamento e potrebbe essere necessario scrivere del codice per eseguire le query e riportare i tempi di esecuzione.
Questo tipo di test è anche sostanzialmente più accurato: poiché stai lavorando con lo schema e le query, puoi vedere come verranno eseguite e ti offre l'opportunità di creare un profilo e migliorare il tuo database / query.
I risultati di questi benchmark sono una visione idealizzata del tuo database. Per sicurezza, supponi che raggiungerai solo il 50-70% di queste prestazioni nel tuo ambiente di produzione (il resto è un cuscino che ti permetterà di gestire una crescita inaspettata, guasti hardware, modifiche del carico di lavoro, ecc.).
È troppo tardi! È in produzione!
Una volta che i sistemi sono in produzione, è davvero troppo tardi per eseguire il "benchmark": è possibile attivare brevemente la registrazione / tempistica delle query e vedere quanto tempo ci vuole per eseguire le operazioni, ed è possibile eseguire alcune query di "stress test" su set di dati di grandi dimensioni durante lo spegnimento ore. Puoi anche guardare l'utilizzo della CPU, RAM e I / O (larghezza di banda del disco) del sistema per avere un'idea di quanto sia pesantemente caricato.
Sfortunatamente, tutto ciò che farà è darti un'idea di ciò che il sistema sta facendo e un vago concetto di quanto sia vicina alla saturazione.
Questo ci porta a ...
Monitoraggio continuo
Tutti i parametri di riferimento nel mondo non ti aiuteranno se il tuo sistema sta vedendo improvvisamente nuovi / diversi schemi di utilizzo.
Nel bene e nel male le distribuzioni di database non sono statiche: i tuoi sviluppatori cambieranno le cose, il tuo set di dati crescerà (non sembreranno mai ridursi) e i tuoi utenti creeranno in qualche modo combinazioni folli di eventi che non hai mai previsto nei test.
Per pianificare correttamente la capacità del tuo database, dovrai implementare un qualche tipo di monitoraggio delle prestazioni per avvisarti quando le prestazioni del database non soddisfano più le tue aspettative. A quel punto puoi prendere in considerazione azioni correttive (nuovo hardware, schema DB o modifiche alle query per ottimizzare l'uso delle risorse, ecc.).
Nota: questa è una guida generica di altissimo livello per il dimensionamento dell'hardware del database e per capire quanti abusi può richiedere. Se non sei ancora sicuro di come determinare se un sistema specifico soddisfa le tue esigenze, dovresti parlare con un esperto di database.
Esiste anche un sito Stack Exchange specificamente dedicato alla gestione del database: dba.stackexchange.com . Cerca nel loro archivio di domande o sfoglia i tag specifici per il tuo motore di database per ulteriori consigli sull'ottimizzazione delle prestazioni.