SSD vs HDD para bases de datos

Estoy tratando de comprar un nuevo servidor para ejecutar MySQL Server. Este nuevo servidor será esclavo de mi máquina principal. Sin embargo, este servidor se dedicará a informar solo "Muchas lecturas y consultas complejas".

Ahora estoy buscando invertir en discos duros de estado sólido, pero me preguntaba si realmente vale la pena el precio. La diferencia entre un SSD y un disco duro SATA 7200 es de aproximadamente $ 1500 y el SSD tiene menos espacio en disco. Si invierto en SSD, ¿se notará la velocidad?

Puedo comprar 4 (500GB SATA 7200) por $ 1500 menos que comprar 2 (500GB SSD)

¿Pueden ayudarme a tomar la decisión de ver si vale la pena la actualización o no?

Una vez más, me gustaría mencionar que no estoy usando, query_cachepor lo que habrá muchas lecturas de disco.

Este servidor tendrá 32 GB de RAM y ejecutará Ubuntu 12.04

Sí, con muchas lecturas y reportar un SSD hará una gran diferencia. Desde una unidad de 7200 RPM, puede esperar no más de ~ 100 IOPS, mientras que el SSD más barato puede ser tan mínimo 5 veces más rápido que eso. Con un buen SSD puede llegar a 20000 IOPS o incluso más.

También las escrituras aleatorias en SSD son mucho más rápidas ya que el disco no tiene que moverse cada vez.

Hay tres factores que debe considerar aquí:

1. El tamaño de su base de datos.
2. La cantidad de memoria que tienes en el servidor
3. Su configuración my.cnf, específicamente innodb_buffer_pool_size

Si la memoria disponible> el tamaño de la base de datos , su servidor probablemente podrá mantener todos sus datos en la memoria y, por lo tanto, un SSD podría ser una pérdida de dinero. El búfer de InnoDB no tiene nada que ver con las query_cacheopciones.

Si la memoria disponible <tamaño de la base de datos , es posible que las consultas necesiten recuperar datos del disco. Para consultas extremadamente complejas, o si muchos usuarios están ejecutando consultas a la vez, esto puede comenzar a estresar el disco.

En general, las bases de datos guardan los datos más utilizados en la memoria: si el 80% de sus datos rara vez / nunca se usan, solo necesitará mantener el 20% de su base de datos en la memoria para mantener el rendimiento.

La cantidad exacta de memoria que necesita no será obvia de inmediato, pero a menos que su base de datos tenga más de 200GB, recomendaría encarecidamente que siga los consejos de Up_One y gaste dinero extra en memoria en lugar de SSD.

NB: Si su base de datos está utilizando MyISAM (puede verificar esto con show table status;), considere cambiar a InnoDB. MyISAM key_buffer_cachesolo almacena bloques de índice, mientras que InnoDB Buffer Pool almacena bloques de datos completos. En la mayoría de los casos, InnoDB demostrará ser un mejor motor para trabajar.

¡No creo que sea una buena idea!
Mi consejo:
aumentar el tamaño de su grupo de búferes InnoDB es la mejor manera de acelerar MySQL. Si puede agregar más RAM, hágalo. Esto pondrá la mayoría de sus datos calientes en la memoria, ¡así que imagínese! ¡Disco contra memoria!
El escenario perfecto es tener su memoria del tamaño de la
SSD de su base de datos , ¡es genial, pero será costosa! y solo es bueno para leer trabajos intensivos.

Consulte este enlace para ver un buen artículo sobre esto de Vadim Tkachenko

Para dar una alternativa: podría usar ambos, un disco duro grande (idealmente, RAID1 con tres discos) para guardar datos, y un SSD más pequeño para guardar índices.

Razón fundamental:

• los índices son bastante pequeños, por lo que puede usar un SSD más pequeño
• las consultas comunes deberían golpear principalmente los índices de todos modos
• el RAID1 le brinda tolerancia a fallas
• el RAID1 le brinda equilibrio de carga para lecturas aleatorias
• tres discos dejan tolerancia a fallas si falla un disco
• los índices se pueden reconstruir si falla el SSD

Hazlo.

Mencionó que tiene una carga de trabajo de lectura pesada, por lo que ya ha evitado el gran problema con el uso de SSD en las bases de datos: desgaste. Sin escritura significa sin desgaste, así que eres dorado.

Como mencionó edvinas.me, su IOPS es mucho más rápido con el SSD que con los discos giratorios. Para una base de datos, IOPS se traduce prácticamente en solicitudes por segundo. Ignorando la memoria caché de RAM, atenderá aproximadamente 100 veces más solicitudes de un SSD que de un disco de 7200 RPM.

TRIM no hará mucha diferencia, ya que es una carga de trabajo de lectura pesada y parece que planeas llenar el disco de todos modos. No te estreses por eso.

No estoy seguro de dónde vino la cosa de $ 1500. Al consultar a mi proveedor local (australiano), puedo obtener un SSD de 960 GB de marca acreditada por $ 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 / ). Los discos giratorios son más o menos gratis, pero $ 750 sigue siendo mucho más apetecible que $ 1500.

(Oh, espera, probablemente estás pidiendo a un proveedor de renombre, ¿entonces te están cobrando por el SSD? Siempre compro el SSD por separado y lo cambio por mí mismo, pero no sé si eso es permisible en su entorno).

Es probable que también salga con menos RAM, pero sin conocer su carga de trabajo exacta, es difícil juzgar si puede reducir la RAM de manera segura sin afectar el rendimiento.

Si aún no está seguro, puede obtener unidades grandes de 10k RPM, pero terminarán costando casi tanto como la SSD de todos modos, mientras que son mucho más lentas.

Si necesita escalar mucho más allá de 1 TB, los SSD comienzan a ser demasiado caros, pero a 1 TB, diría que el SSD es una clara victoria.

Definitivamente, estoy de acuerdo en que el mayor beneficio del dinero proviene de aumentar el tamaño de su innodb_db_bufferpool, pero desafortunadamente depende completamente de qué tan grande es su conjunto de datos y con qué frecuencia se accede a diferentes bloques de disco. Mantengo varias bases de datos que son bastante grandes de 200 GB +, por lo que encajar todo en la RAM no es realmente una opción y por esa razón recientemente cambiamos al almacenamiento basado en SSD. He realizado una gran investigación en términos del uso de IOPS para MySQL en diferentes matrices RAID a las que tengo acceso. Aquí están los resultados:

1,253 IOPS - 4 x SCSI 15k (3.5 ") disco

prueba: (g = 0): rw = randrw, bs = 4K-4K / 4K-4K / 4K-4K, ioengine = libaio, iodepth = 64 read: io = 3071.7MB, bw = 5012.8KB / s, iops = 1253 , runt = 627475msec write: io = 1024.4MB, bw = 1671.7KB / s, iops = 417, runt = 627475msec cpu: usr = 0.63%, sys = 3.11%, ctx = 985926, majf = 0, minf = 22

2,558 IOPS - 8 x 10K RPM 900GB SAS (2.5 ") disco

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

23,456 IOPS - Servidor SSD Rackspace Performance 2

prueba: (g = 0): rw = randrw, bs = 4K-4K / 4K-4K / 4K-4K, ioengine = libaio, iodepth = 64 read: io = 3071.7MB, bw = 93708KB / s, iops = 23426, runt = 33566msec escribir: io = 1024.4MB, bw = 31249KB / s, iops = 7812, runt = 33566msec cpu: usr = 5.73%, sys = 35.83%, ctx = 181568, majf = 0, minf = 23

35,484 IOPS - 2 x MLC reflejado EDGE 480GB 2.5 "MLC ( http://www.edgememory.com )

prueba: (g = 0): rw = randrw, bs = 4K-4K / 4K-4K / 4K-4K, ioengine = libaio, iodepth = 64 leer: io = 3068.4MB, bw = 141934KB / s, iops = 35483, runt = 22137msec write: io = 1027.7MB, bw = 47537KB / s, iops = 11884, runt = 22137msec cpu: usr = 11.68%, sys = 69.89%, ctx = 24379, majf = 0, minf = 20

Por lo tanto, está claro que los SSD de alta calidad de hoy son artistas increíbles. Dos SSD duplicados pueden superar fácilmente el alojamiento de almacenamiento SAN de 16 discos y esa es una declaración convincente por sí sola.

Si está interesado en todos los detalles, el resto de la redacción se encuentra en mi blog:

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