¿Puede una importación masiva de datos MySQL en un SSD dañarlo?

Tengo que importar una gran cantidad de datos (~ 100 millones de filas, ~ 100 veces) en una base de datos MySQL. Actualmente, está almacenado en mi disco duro, y el cuello de botella de mi importación parece ser la velocidad de escritura del disco duro.

He oído que a los SSD no les gustan las escrituras continuas masivas, y que tienden a dañarlos. ¿Qué piensas? ¿Es esto realmente un problema en los SSD modernos?

Realmente no es una respuesta directa a esto.

Los SSD no se preocupan tanto por las escrituras continuas como por cuántas veces se sobrescribe un sector en particular. Cuando aparecieron los SSD, algo como SQL era una mala palabra, ya que el sistema operativo en general trataba el disco como un HDD tradicional y las fallas eran muy frecuentes.

Desde entonces, las unidades se han vuelto más grandes, más baratas, más confiables, destinadas a más lecturas / escrituras y los sistemas operativos se han vuelto más inteligentes.

Los SSD en SQL no solo son comunes, sino que a menudo se recomiendan. Siéntase libre de examinar el sitio hermano de DBA .

Mis pensamientos son hacerlo, suponiendo que el servidor SQL esté construido correctamente con discos redundantes. De lo contrario, espere un fracaso eventualmente de todos modos.

Las lecturas están bien, y los SSD pueden leer sus bits sin ningún efecto perjudicial.

Las escrituras son otro asunto. Borrar un bit afecta la integridad del bit y después de muchas escrituras secuenciales, el bit dejará de aceptar nuevas escrituras por completo. Sin embargo, todavía se puede leer.

Permítanme decir que los límites de escritura en las nuevas unidades empresariales son enormes. Tome el nuevo 845DC Pro de Samsung. Es bueno para 10 unidades escritas por día durante 5 años en garantía. Me imagino que hará el doble de ese número. Para poner eso en números, son 14,600 TB escritos durante 5 años en el modelo de 800 GB.
O 2920 TB por año,
u 8 TB por día, durante cinco años .

Muéstrame un disco duro con una garantía que cubra tanto uso. Ni siquiera estoy seguro de que pueda escribir 8 TB en un HDD en un día: - (50 MB / s de rendimiento promedio * 60 (segundos) * 60 (minutos) * 24 (horas) = ​​4,320,000 MB / día = 4.32 TB / día) Resulta que no puedes (en una unidad promedio).

Siempre que use una unidad como esta, basada en V-NAND (o SLC igualmente duradero), no una basada en TLC o flash MLC defectuoso, debería estar bien. Y de todos modos, RAID 10 y las copias de seguridad son su amigo por una razón. Y al menos si el límite de escritura SSD se convierte en un problema, aún puede leer los datos almacenados en los bits defectuosos.

Los SSD también son más baratos de usar, más frescos, más silenciosos y los modelos empresariales son especialmente resistentes a los problemas de energía. No más temores de choque de cabeza y, por supuesto, un gran aumento del rendimiento para sus necesidades de acceso a la base de datos.

Escribir en SSD no es necesariamente malo. Es la escritura y reescritura de un solo bloque lo que es malo. Es decir, si escribe un archivo, bórrelo y luego vuelva a escribirlo, o realice pequeñas cantidades de cambios en un archivo una y otra vez. Esto causa desgaste en los SSD. Las bases de datos definitivamente encajarían en esta categoría.

Sin embargo, de acuerdo con este artículo , los petabytes de datos se han escrito en SSD y aún se pueden utilizar. Esto probablemente se deba a los avances en la nivelación del desgaste :

Use los intentos de nivelación para evitar estas limitaciones organizando los datos de manera que los borrados y reescrituras se distribuyan de manera uniforme en todo el medio. De esta manera, ningún bloque de borrado falla prematuramente debido a una alta concentración de ciclos de escritura.

En su situación particular, quisiera que las bases de datos residan en el SSD para mayor velocidad, pero se realicen copias de seguridad a diario. También puede considerar obtener dos SSD en una matriz RAID 1 también. La probabilidad de que dos SSD fallen al mismo tiempo es baja.

Nota: ¡Las matrices RAID NO son copias de seguridad! No importa si usa una matriz RAID o no, tenga una copia de seguridad. No importa si usa un SSD o no, tenga una copia de seguridad.

Supongamos que su importación no implica actualizaciones ni eliminaciones. Entonces estás haciendo todas las inserciones. Esto solo debería estar escribiendo datos nuevos en el registro de transacciones.

Esto significa que a medida que se agregan datos, siempre se escriben en un nuevo sector. Puede haber algunos buffers / swap que se agitan / escriben varias veces, pero ignorando eso, todas esas inserciones teóricamente darían como resultado no más de una escritura por sector . Dependiendo de cómo se implemente MySQL, y qué tipo de inserción masiva esté realizando, podría generar un segundo conjunto de escrituras más tarde cuando el registro de transacciones se integre en el archivo de datos principal (voy a entender diferentes motores de DB) , y suponiendo que MySQL es algo similar en cómo se vacían los registros de transacciones).

El punto es que no estás "agitando" el SSD. Es decir, no está haciendo muchas modificaciones / movimientos / eliminaciones / etc. eso podría reescribir potencialmente sobre los mismos sectores muchas veces. Por lo tanto, esencialmente solo va a generar un número muy pequeño de escrituras por sector y eso es lo que realmente importa.

Suponiendo que no está llenando completamente el SSD, debe haber suficiente espacio libre para esos puntos calientes (como buffers / swap) que se están batiendo para minimizar el desgaste a través de algoritmos de nivelación de desgaste.

(Los índices pueden ser otra cuestión. Como los índices agrupados en muchas bases de datos implican muchas modificaciones a medida que se insertan los datos. Por lo general, cuando se realizan grandes inserciones en un entorno de depósito de datos, se desactivan los índices durante la importación masiva y luego se actualizan después).

Esto no es problema

En primer lugar, los SSD han mejorado mucho durante los últimos años. El aprovisionamiento excesivo y la nivelación del desgaste (y en una pequeña cantidad, el comando TRIM, aunque no es aplicable en su caso) los han hecho bastante adecuados como discos de uso general para trabajos pesados. No estoy usando nada más que SSD en mi PC de desarrollo (que regularmente compila mucho) sin siquiera acercarme al conteo del ciclo de borrado.

Además, esta declaración:

A los SSD no les gustan las escrituras continuas masivas y tienden a dañarlos

está completamente equivocado. El caso opuesto es que las escrituras pequeñas frecuentes , si acaso, pueden dañar los SSD.

A diferencia de los discos duros tradicionales, los SSD (o más bien el flash interno basado en NAND) están físicamente organizados en grandes bloques que lógicamente contienen varios sectores. Un tamaño de bloque típico es 512kB mientras que los sectores (que es la unidad que usa el sistema de archivos) son tradicionalmente 1kB (son posibles valores diferentes, hace dos décadas 512B era común).
Se pueden hacer tres cosas con un bloque de 512kB. Se puede leer, parte de él o todo se puede programar (= escribir en), y se puede borrar todo. Borrar es lo que es problemático porque hay un número limitado de ciclos de borrado, y solo puedes borrar un bloque completo.

Por lo tanto, las escrituras grandes son muy compatibles con SSD, mientras que las escrituras pequeñas no.

En el caso de pequeñas escrituras, el controlador debe leer un bloque, modificar la copia, borrar un bloque diferente y programarlo. Sin almacenamiento en caché, en el peor de los casos, necesitaría borrar 512,000 bloques para escribir 512 kilobytes. En el mejor caso posible (escritura grande y continua), debe hacer exactamente 1 borrado.

Hacer una importación en una base de datos MySQL es muy diferente de hacer muchas consultas de inserción por separado. El motor puede colapsar muchas escrituras (tanto datos como índices) juntas y no necesita sincronizarse entre cada par de inserciones. Esto equivale a un patrón de escritura mucho más amigable con SSD.

A los SSD no les gusta. Si mantiene la velocidad máxima de escritura durante 5-10 años (24 horas al día, 7 días a la semana), entonces podría terminar con un SSD roto.

De c. Después de 5 años, la mayoría de los servidores han alcanzado su fin económico.

Descargo de responsabilidad:
no intente esto con la primera generación de SSD. Aquellos donde menos robustos.

Si está realmente interesado en averiguar los detalles, necesitará responder la siguiente pregunta:

En promedio, ¿cuántos bytes hay en cada fila?

Si me puede decir que hay 10 columnas, cada columna es varchar (100) y la codificación es UTF-8, entonces puedo adivinar en el peor de los casos que tiene 4.000 bytes de datos por fila y agregar algunos bytes más para metadatos así que digamos 4.200 bytes?

Su tortura SQL calcula los 4,200 x 100 x 100,000,000 = 42,000,000,000,000 bytesdatos escritos en el disco

42,000,000,000,000 / 1000 = 42,000,000,000 KB

42,000,000,000 / 1000 = 42,000,000 MB

42,000,000 / 1000 = 42,000 GB

42,000 / 1000 = 42 TB

En este peor escenario teórico, estará escribiendo 42 TB en el disco

De acuerdo con este artículo , proporcionado por @KronoS, debería ser bueno para unas 25 rondas más de su SQL de tortura.

Como decía el cartel de este artículo sobre SSD , lo que es realmente dañino es escribir una y otra vez pequeños fragmentos de datos.

• los bits se almacenan en celdas de {1,2,3} bits. Estos tienen una vida útil limitada.
• las celdas se agrupan en páginas de [2-16] KB (unidad de escritura más pequeña)
• las páginas se agrupan en bloques (128-256 páginas) (unidad borrable más pequeña)
• para que una página se reescriba, primero debe borrarse, y todo su bloque,

Por eso se recomienda

• nunca escriba menos de una página a la vez,
• búfer pequeñas escrituras, y
• solicitudes separadas de lectura y escritura
• "Una escritura grande de un solo hilo es mejor que muchas escrituras concurrentes pequeñas"

Entonces, una cantidad realmente grande a la vez parece mucho mejor.