SSD vs HDD per database

Sto cercando di acquistare un nuovo server su cui eseguire MySQL Server. Questo nuovo server sarà uno schiavo della mia macchina principale. Tuttavia, questo server sarà dedicato solo per la segnalazione "Molte letture e query complesse".

Ora sto cercando di investire in hard disk a stato solido ma mi chiedevo se valesse davvero il prezzo. La differenza tra un SSD e un disco rigido SATA 7200 è di circa $ 1500 e l'SSD ha meno spazio su disco. Se investo in SSD, la velocità sarà evidente?

Posso acquistare 4 (SATA 7200 da 500 GB) per $ 1500 in meno rispetto all'acquisto di 2 (SSD da 500 GB)

Potete per favore aiutarmi a prendere la decisione di vedere se vale la pena l'aggiornamento o no?

Un'altra cosa che vorrei menzionare è che non sto usando, query_cachequindi ci saranno molte letture del disco.

Questo server avrà 32 GB di RAM e eseguirà Ubuntu 12.04

Sì, con molte letture e la segnalazione di un SSD farà una grande differenza. Da 7200 RPM non ci si può aspettare più di ~ 100 IOPS mentre l'SSD più economico può essere almeno 5 volte più veloce di quello. Con un buon SSD puoi arrivare a 20000 IOPS o anche di più.

Anche le scritture casuali in SSD sono molto più veloci in quanto il disco non deve spostarsi ogni volta.

Ci sono tre fattori che devi considerare qui:

1. La dimensione del tuo database
2. La quantità di memoria che hai nel server
3. La tua configurazione my.cnf, in particolare innodb_buffer_pool_size

Se memoria disponibile> dimensioni del database , il tuo server sarà probabilmente in grado di conservare tutti i tuoi dati in memoria, e quindi un SSD potrebbe essere uno spreco di denaro. Il buffer InnoDB non ha nulla a che fare con le query_cacheopzioni.

Se memoria disponibile <dimensione del database , è possibile che le query debbano recuperare i dati dal disco. Per query estremamente complesse o se molti utenti eseguono query contemporaneamente, questo può iniziare a sollecitare il disco.

In generale, i database mantengono in memoria i dati più utilizzati: se l'80% dei dati viene utilizzato raramente / mai, per mantenere le prestazioni sarà necessario solo conservare il 20% del database.

L'esatta quantità di memoria di cui hai bisogno non sarà immediatamente ovvia, ma a meno che il tuo database non sia 200 GB +, consiglierei vivamente di seguire i consigli di Up_One e di spendere soldi extra in memoria invece di SSD.

NB: Se il tuo database utilizza MyISAM (puoi verificarlo con show table status;), considera di passare a InnoDB. MyISAM key_buffer_cachememorizza solo blocchi di indice, mentre come pool di buffer InnoDB memorizza interi blocchi di dati. Nella maggior parte dei casi, InnoDB si dimostrerà un motore migliore con cui lavorare.

Non credo sia una buona idea!
Il mio consiglio per
aumentare le dimensioni del pool di buffer InnoDB è il modo migliore per velocizzare MySQL. Se puoi aggiungere più RAM, fallo. Questo metterà in memoria la maggior parte dei tuoi dati caldi, quindi immagina! Disk vs Memory!
Lo scenario perfetto è avere il tuo memeory delle dimensioni del tuo
SSD del database - è fantastico ma sarà costoso! ed è utile solo per lavori ad alta intensità di lettura.

Controlla questo link per un bell'articolo su questo da Vadim Tkachenko

Per dare un'alternativa: è possibile utilizzare entrambi, un disco rigido di grandi dimensioni (idealmente, RAID1 con tre dischi) per conservare i dati e un SSD più piccolo per conservare gli indici.

Fondamento logico:

• gli indici sono abbastanza piccoli, quindi puoi usare un SSD più piccolo
• le query comuni dovrebbero comunque colpire principalmente gli indici
• RAID1 offre tolleranza d'errore
• RAID1 ti dà il bilanciamento del carico per letture casuali
• tre dischi lasciano la tolleranza d'errore se un disco si guasta
• gli indici possono essere ricostruiti se l'SSD fallisce

Fallo.

Hai detto che hai un carico di lavoro pesante in lettura, quindi hai già evitato il grosso problema con l'utilizzo di SSD su database: wearout. Nessuna scrittura significa nessuna usura, quindi sei d'oro.

Come menzionato edvinas.me, il tuo IOPS è più veloce degli ordini di grandezza con l'SSD che con i dischi rotanti. Per un database, IOPS si traduce praticamente in richieste al secondo. Ignorando la cache RAM, servirai circa 100 volte il numero di richieste da un SSD rispetto a un disco 7200 RPM.

TRIM non farà molta differenza in quanto è un carico di lavoro pesante in lettura e sembra che tu abbia intenzione di riempire comunque il disco. Non stressarti.

Non sono sicuro da dove provenga la cosa da $ 1500. Controllando il mio fornitore locale (australiano), posso ottenere un SSD da 960 GB di marca stimabile per $ 750 ( http://www.auspcmarket.com.au/960gb-crucial-m500-sata-6gbps-2-5-7mm-with- 9-5mm-adapter-ssd-read-500mb-s-write-400mb-s / ). I dischi rotanti sono più o meno gratuiti, ma $ 750 è ancora molto più appetibile di $ 1500.

(Oh, aspetta - probabilmente stai ordinando da un fornitore di grandi nomi, quindi ti stanno caricando il naso per l'SSD? Compro sempre l'SSD separatamente e lo cambio in me stesso, ma non so se questo è ammissibile nel tuo ambiente.)

Probabilmente riuscirai a cavartela anche con meno RAM, ma senza conoscere il tuo esatto carico di lavoro, è difficile giudicare se puoi ridurre la RAM in sicurezza senza compromettere le prestazioni.

Se non sei ancora sicuro, puoi ottenere grandi unità da 10k RPM, ma finiranno comunque per costare quasi quanto l'SSD pur essendo molto più lenti.

Se è necessario ridimensionare molto oltre 1 TB, gli SSD iniziano a diventare troppo costosi, ma a 1 TB, direi che l'SSD è una chiara vittoria.

Sono assolutamente d'accordo sul fatto che il massimo per il dollaro derivi dall'aumentare le dimensioni di innodb_db_bufferpool, ma sfortunatamente dipende completamente dalla dimensione del set di dati e dalla frequenza con cui si accede a diversi blocchi di dischi. Mantengo diversi database che sono abbastanza grandi da 200 GB +, quindi inserire tutto nella RAM non è un'opzione e per questo motivo siamo recentemente passati allo storage basato su SSD. Ho fatto una ricerca abbastanza grande in termini di IOPS per l'utilizzo di MySQL su diversi array RAID a cui ho accesso. Ecco i risultati:

1.253 IOPS - 4 dischi SCSI 15k (3.5 ")

test: (g = 0): rw = randrw, bs = 4K-4K / 4K-4K / 4K-4K, ioengine = libaio, iodepth = 64 leggi: io = 3071.7MB, bw = 5012.8KB / s, iops = 1253 , runt = 627475msec scrivere: io = 1024,4 MB, bw = 1671,7 KB / s, iops = 417, runt = 627475msec cpu: usr = 0,63%, sys = 3,11%, ctx = 985926, majf = 0, minf = 22

2.558 IOPS - disco SAS (2.5 ") da 8 x 10K RPM 900GB

test: (g = 0): rw = randrw, bs = 4K-4K / 4K-4K / 4K-4K, ioengine = libaio, iodepth = 64 leggi: io = 3071.7MB, bw = 10236KB / s, iops = 2558, runt = 307293msec scrivere: io = 1024.4MB, bw = 3413.5KB / s, iops = 853, runt = 307293msec cpu: usr = 2.73%, sys = 8.72%, ctx = 904875, majf = 0, minf = 25

23.456 IOPS - Server SSD Rackspace Performance 2

test: (g = 0): rw = randrw, bs = 4K-4K / 4K-4K / 4K-4K, ioengine = libaio, iodepth = 64 leggi: io = 3071.7MB, bw = 93708KB / s, iops = 23426, runt = 33566msec scrivere: io = 1024,4 MB, bw = 31249 KB / s, iops = 7812, runt = 33566msec cpu: usr = 5,73%, sys = 35,83%, ctx = 181568, majf = 0, minf = 23

35.484 IOPS - 2 x EDGE con mirroring Boost 480 GB 2,5 "MLC ( http://www.edgememory.com )

test: (g = 0): rw = randrw, bs = 4K-4K / 4K-4K / 4K-4K, ioengine = libaio, iodepth = 64 leggi: io = 3068.4MB, bw = 141934KB / s, iops = 35483, runt = 22137msec scrivi: io = 1027,7 MB, bw = 47537 KB / s, iops = 11884, runt = 22137msec cpu: usr = 11,68%, sys = 69,89%, ctx = 24379, majf = 0, minf = 20

Quindi è chiaro che gli SSD di alta qualità di oggi sono artisti straordinari. Due SSD con mirroring possono facilmente superare l'enclosure di archiviazione SAN a 16 dischi e questa è una dichiarazione convincente da sola.

Se sei interessato ai dettagli completi, il resto della scrittura è disponibile sul mio blog:

http://www.juhavehnia.com/2015/05/using-ssds-to-improve-mysql-performance.html