¿El advenimiento del SSD tiene alguna implicación para la optimización de la base de datos?

Hoy estaba hojeando un libro sobre la optimización de SQL Server y parecía que cierta cantidad de ideas se basaba en un modelo lineal de almacenamiento. Como los SSD tienen un modelo de almacenamiento completamente diferente, ¿cambian de alguna manera el juego con respecto a cómo se piensa en la optimización u optimización de la base de datos?

Sí, cambian el juego. Las optimizaciones basadas en las características de los discos magnéticos giratorios (como el tiempo de búsqueda y el retraso de rotación ) pueden no ser relevantes en las unidades SSD. Un artículo reciente ^* publicado en FITME 2010 presenta un nuevo algoritmo de optimización de consultas basado en las características de los SSD.

Sin embargo, estos cambios probablemente serán cambios de bajo nivel (por ejemplo, en algoritmos de almacenamiento y recuperación) que los desarrolladores de bases de datos pueden implementar de manera efectiva. Probablemente no afectarán tanto a los usuarios de la base de datos.

^* IEEE Xplore: una optimización de consultas de almacenamiento orientada a columnas para bases de datos basadas en flash

Actuación

Los SSD son de alto rendimiento: no tienen que buscar, y el rendimiento es vertiginoso. La mayoría del software que trata con discos, en la medida en que están optimizados, está optimizado para reducir el número de búsquedas sincrónicas. Al hacerlo, presentan una gran cantidad de complejidades. Con el advenimiento de escrituras rápidas y sin búsqueda en el almacenamiento persistente, los nuevos sistemas de almacenamiento de datos ya no requerirán tales complejidades.

Durabilidad

Los SSD actualmente tienen altas tasas de falla. Su SSD fallará. Sus SSD fallarán a una velocidad mucho mayor que los discos magnéticos. Debe solucionar esto con replicación, copias de seguridad, etc. Esto introduce su propio conjunto de complejidades.

La reducción general en el precio del almacenamiento tiene efectos mucho más profundos.

Antes de tener SQL, teníamos bases de datos jerárquicas y de red súper optimizadas donde los DBA tenían que planificar cuidadosamente la ubicación de los datos en la pista y el cilindro.

Las bases de datos SQL son mucho menos eficientes. Pero ahora que los discos son baratos, enormes y rápidos, apenas nos importa.

Las bases de datos NoSQL ("Documento") pueden ser algo menos eficientes que SQL porque no existe la misma capacidad de mapeo lógico a físico entre el esquema lógico SQL y el esquema físico subyacente de archivos o espacios de tablas o lo que sea. Y apenas nos importa.

Es probable que las mejoras de rendimiento de SSD se pierdan en los cambios causados ​​por el uso de bases de datos NoSQL en la forma en que diseñamos los sistemas en general.

El principal problema con la optimización de cualquier cosa para SSD tiene que ver con cómo escriben los datos. Un disco duro tradicional generalmente almacena datos en pequeños sectores de alrededor de 512 bytes y en realidad puede manipular sectores directamente en o incluso por debajo de ese nivel.

Los SSD tienen algunos inconvenientes con respecto a las escrituras:

• Un tamaño mínimo de escritura de bloque de alrededor de 4-8 KB.
• Las escrituras solo se pueden realizar en una página completa de típicamente 256KB.
• Solo se pueden escribir bloques vacíos.

Un escenario típico de pesadilla, denominado amplificación de escritura , es cuando desea escribir un solo byte en una ubicación en el disco que ya tiene algunos bloques en uso. Para escribir allí, primero debe copiar toda la página de 256 KB en la memoria, borrar todo el bloque, cambiar el byte único en la página y luego volver a escribir toda la página de 256 KB modificada. Entonces, para escribir un solo byte, ¡ha habido aproximadamente medio megabyte de "tráfico"!

Hay muchas optimizaciones para este problema implementadas en el SSD, el controlador e incluso el nivel del sistema operativo, pero sin duda los DBMS pueden beneficiarse al adaptar estas optimizaciones a su funcionamiento específico.

Sin embargo, esto no es algo en lo que los usuarios de la base de datos (como en el uso de una base de datos en su aplicación) tengan que pensar, ya que dependerá en gran medida de las decisiones de diseño / implementación a nivel de DBMS.

Por lo que deduzco del blog ServerFault , los servidores de bases de datos deben tener hardware fornido. El servidor de bases de datos de los sitios de intercambio de la pila está ejecutando SSD (consulte http://blog.serverfault.com/post/our-storage-decision/ ) y me imagino que la optimización de consultas todavía es muy necesaria. La CPU y la memoria se ven afectadas por las consultas de la base de datos, así como por IO.

Sin embargo, el rendimiento de la base de datos depende en gran medida de IO, por lo que los SSD seguramente ayudarían.

Sí, por las razones que todos han declarado.

Estaba escuchando un podcast que decía que grandes porciones de RDBMS como Oracle, SQL Server, etc. comenzarán a ser "opcionales" si pueden resolver la separación correctamente. Detecta si se trata de una unidad SSD y optimiza en consecuencia.

Hay una gran cantidad de código adicional integrado en el almacenamiento en caché y la escritura de datos que simplemente ya no se requieren.

Aún más interesante es el RAMSAN y sus variantes. Básicamente, una unidad de disco duro hecha de chips de RAM con un SAI incorporado de X horas y la capacidad de escribir en segundo plano en el almacenamiento HDD a largo plazo.