Per migliorare le prestazioni di SQL, perché non mettere semplicemente molta RAM piuttosto che avere dischi rigidi più veloci?

Le persone continuano a dirmi che per migliorare le prestazioni di un server SQL, acquistare i dischi rigidi più veloci possibili con RAID 5, ecc.

Quindi stavo pensando, invece di spendere tutti i soldi per RAID 5 e dischi rigidi veloci super-duper (che non sono economici tra l'altro), perché non ottenere tonnellate di RAM? Sappiamo che un server SQL carica il database in memoria. La memoria è molto più veloce di qualsiasi disco rigido.

Perché non inserire 100 GB di RAM su un server? Quindi basta usare un normale disco rigido SCSI con RAID 1. Non sarebbe molto più economico e veloce?

La tua analisi va bene - fino a un certo punto - in quanto renderà assolutamente le cose più veloci. Devi comunque tenere conto di un paio di altri problemi:

1. Non tutti possono permettersi abbastanza memoria; quando hai più terabyte di dati, devi metterli sul disco un po 'di tempo. Se non hai molti dati, tutto è abbastanza veloce.

2. Le prestazioni di scrittura per il database saranno ancora limitate dai dischi, in modo da poter mantenere la promessa che i dati sono stati effettivamente archiviati.

Se hai un piccolo set di dati o non hai bisogno di persistere su disco, non c'è niente di sbagliato nella tua idea. Strumenti come VoltDB stanno lavorando per ridurre i costi generali che i vecchi presupposti nelle implementazioni RDBMS hanno reso vincolanti le prestazioni in memoria.

(A parte questo, le persone che ti dicono di usare RAID-5 per le prestazioni del database probabilmente non sono persone fantastiche da ascoltare sull'argomento, dal momento che non è quasi mai la scelta migliore - ha buone prestazioni di lettura, ma cattive prestazioni di scrittura e scritture sono quasi sempre il vincolo di produzione, perché è possibile inserire la RAM nella cache per risolvere la maggior parte dei problemi di prestazioni di lettura.)

Versione breve: considerare le dimensioni del set di lavoro. Versione lunga: quanto sono grandi i tuoi dati? Se può stare nella memoria di un server moderno, sì, hai assolutamente ragione. Sfortunatamente, il più grande Xeon può indirizzare 2 TB di RAM in questo momento, e non è più così grande di un set di dati. Se non riesci ad acquistare una macchina abbastanza grande da ospitare l'intero set di lavoro nella RAM, sei costretto a risolvere i problemi con il tuo cervello, non con il tuo portafoglio.

Se vuoi la velocità:

• Aumenta la RAM in modo che almeno gli indici utilizzati di frequente possano integrarsi completamente nella RAM (ad esempio, su un sistema su cui lavoro, 32 GB di RAM sono sufficienti per un database da 350 GB, perché gli indici sono ciò di cui hai bisogno nella RAM, non i dati non elaborati)
• Usa RAID10 con qualsiasi disco (i dischi più veloci sono migliori)
• Evita RAID5
• Dividi mdf, ldf e temp DB su set di mandrini discreti (esempio: tempdb sul proprio set RAID1, ldf sul proprio set di mandrini RAID1 o RAID10, mdf su un set RAID 10 con almeno 4 dischi totali)

Seguire questi passaggi e SQL Server volerà.

Quindi, se vuoi, aggiungi più RAM ... ma prima fai quanto sopra e potresti scoprire che hai finito.

La RAM è il nuovo disco, il disco è il nuovo nastro.

In http://www.tbray.org/ongoing/When/200x/2006/05/24/On-Grids . Si noti che è stato sei anni fa. Sì, disponiamo di sistemi di database che tentano (e si impegnano a fondo) di mantenere l'intero set di dati nella RAM e piuttosto di frammentare su più macchine piuttosto che di utilizzare il disco perché il disco è comunque più lento. È necessario scrivere il set di dati su disco ma, come nel motto sopra, è più simile a un'attività di backup in background che a un'operazione online. La durabilità si ottiene aggiungendo solo i registri con questi database (sto pensando MongoDB e Redis ma ce ne sono molti altri).

Questa domanda è simile a quella di base che ha portato a molte ricerche e sviluppi in architetture di database negli ultimi 5-10 anni. Ora che è possibile archiviare un intero database nella RAM per molti casi d'uso, il database deve essere progettato per funzionare nella RAM, piuttosto che semplicemente applicare architetture ereditate più vecchie allo storage basato su RAM.

Proprio come negli ultimi anni sono state ampiamente adottate molte lingue più piccole e più specifiche, stiamo entrando in un'epoca in cui saranno necessarie più banche dati specifiche.

Per qualche ulteriore lettura su questo argomento, raccomando il documento accademico The End of an Architectural Era (It's Time for a Complete Rewrite) . Non è una lettura difficile.

Non è chiaro se questa domanda riguardasse specificamente SQL Server. Il poster originale dovrebbe chiarire questo.

Daniel Pittman ha scritto:

Se hai un piccolo set di dati o non hai bisogno di persistere su disco, non c'è nulla di sbagliato> nella tua idea. Strumenti come VoltDB stanno lavorando per ridurre i costi generali che i vecchi presupposti> nelle implementazioni RDBMS hanno reso vincolanti le prestazioni in memoria.

Ridurre le spese generali da ipotesi precedenti nelle implementazioni di RDBMS era esattamente l'obiettivo di progettazione di VoltDB , ma si ridimensiona orizzontalmente senza limiti architetturali sulla dimensione dei dati e può persistere su disco per una lunga durata utilizzando snapshot e registrazione dei comandi.

Se riesci a ottenere un server con abbastanza RAM per contenere, almeno, la parte più calda del tuo set di dati, starai bene. Inoltre, RAID 1 e 5 non sono il modo più veloce per organizzare i tuoi dati - RAID 0 è più veloce, ma, quindi, dovrai considerare le probabilità più alte di un errore del filesystem che cancella il tuo database - non è una buona cosa accadere . Puoi RAID 1 o RAID 5 l'array RAID 0, a condizione che tu abbia abbastanza unità e controller.

Puoi persino giocare con la replica qui: esegui le tue scritture su un server pesante su disco che si replica su uno o più server ricchi di memoria in cui esegui query complicate.

Purtroppo, gli RDBMS sembrano essere nel regno del grande ferro - non sono così facili da coltivare in orizzontale.

Questo è un caso di "dipende da cosa stai facendo". Forse il consiglio "giusto" è di evitare del tutto l'SQL e usare memcache / redis / etc!

Sono d'accordo con te sul fatto che la RAM aggiuntiva ti aiuterà molto, specialmente se sei in grado di leggere l'intero set di lavoro nella RAM. Sì, dovrà comunque scrivere i dati, ma se si hanno principalmente letture, le scritture non avranno contese per l'I / O del disco.

Tuttavia, le prestazioni del disco sono spesso un collo di bottiglia sui server SQL e più difficile rispetto ad altre cose come la RAM per l'aggiornamento successivo (se si dispone di un server che non è completamente popolato con DIMM).

Ci sono stati alcuni commenti sul fatto che RAID5 fosse lento, ma direi che non è sempre così, quindi fai attenzione prima di fare dichiarazioni radicali. Server davvero di fascia alta con schede RAID veloci e un sacco di BBWC a volte vanno molto più velocemente in RAID5 (o RAID50 con> 4 dischi) rispetto a RAID10 ...

Nel corso degli anni ho sperimentato personalmente array RAID5 lenti, ma dopo aver confrontato un DL360 G5 con 4 dischi SAS 146G nel ~ 2009, abbiamo dovuto ricontrollare i nostri test. In effetti, l'array è andato più veloce con RAID5 rispetto a RAID10 in quasi tutti i test. I calcoli BBWC e di parità veloce hanno consentito al server di utilizzare i 4 dischi in modo molto più efficace come array RAID5 rispetto a RAID10. Alcuni dei test hanno mostrato un throughput migliore del 50% con RAID5 e quasi nessuno era più lento. I test più lenti erano solo del 5-10% di sconto.

Vorrei mettere in guardia le persone che dichiarano a vuoto che RAID5 è lento, lo dicono tutti online, ma semplicemente non è vero in ogni caso.

Hai un mix di caramelle tra cui scegliere e dipende davvero dal sapore che desideri.

1. I DB avranno la configurazione per interrogare la cache e dove esiste questa cache, memoria o disco rigido.
2. RAID 5 non è sempre il più veloce, ma RAID 0 (JBOD) è uno stripe ed è veloce, poiché RAID 5 è anche uno stripe l'idea è più o meno la stessa.
3. RAID 1 non migliorerà la tua velocità, è solo un mirror.
4. Le prestazioni SQL si basano sull'indicizzazione ed è la prima cosa da verificare. Molto importante nei database relazionali.
5. Non indicizzare tutto, l'indicizzazione eccessiva può anche ridurre la velocità perché l'indicizzazione viene sovraccaricata.
6. A volte con SQL Joins il database diventa più lento. L'uso della programmazione per eseguire il loop di una serie di risultati indicizzati minimi migliora la velocità.
7. I server virtuali sono un incubo sulla velocità se non paghi i dollari.

Basta investire nella conoscenza (gratuita) prima di sborsare denaro. 1. Scopri le configurazioni per il tuo database e guarda la tua configurazione attuale per ottimizzare. 2. Guarda le istruzioni di programmazione e sql, unit test con semplici script che imitano le operazioni coinvolte, potrebbe non essere nemmeno quello che pensi sia il problema. SE gli script semplici impiegano del tempo usando i join SQL, li dividono e fanno la stessa cosa con un ciclo programmato per fare lo stesso. Questo è dove la memoria può aiutare 3. Guarda il piano di hosting e il server. Usa ps aux in una console linux e vedi se c'è qualcosa che sta risucchiando memoria e processore.

Il disco rigido assoluto migliora la velocità ma non dipende da te in uno spazio di server virtuale. La memoria non migliora la velocità se non si configura i servizi per questo, punto. RAID a strisce (0,5), RPM e lettura / scrittura sincrona con un bus veloce lo aiutano. Un processore core con una buona cache l1, l2, l3 aiuterà a elaborare il collo di bottiglia. posso sentirlo per Xeon!

Nel complesso, devi tenere a mente dimensioni e scalabilità. Mentre potresti sembrare che inizi con piccole esigenze di archiviazione, i tuoi dati cresceranno molto rapidamente ed esponenzialmente. I DB utilizzano al meglio i dati atomici, che sono dati suddivisi nella dimensione più piccola possibile. A causa delle dimensioni ridotte, viaggia più velocemente all'interno del data warehouse. Quindi, si tiene conto anche della struttura del DB. In futuro, potresti essere collegato a DB esterni, motivo per cui anche la struttura è cruciale. In questo scenario, farebbe poca differenza per la tua query se metà dei dati vivesse al di fuori del tuo data mart. Quando i dati vengono interrogati, il punto è non conservare i dati memorizzati sulla RAM; piuttosto, la query dovrebbe essere rapida nell'accesso e nella restituzione dei dati.

• Davvero non usi sempre RAID 5 per i dati. Dipende dai dati e dalla sua importanza, oltre a ciò che è stato precedentemente menzionato sui backup. RAID 1 può essere utilizzato ed è.
• Dovresti aggiornare tutti i server nel tuo intervallo di query per migliorare la velocità. Dal momento che gran parte dei dati è al di fuori del tuo controllo, sta andando a strozzare da qualche parte al di fuori del tuo data mart. (Nel caso in cui si aggiorni il proprio)