Configuración de SQL para un rendimiento óptimo ... ¿SSD o HDD?


8

¿Alguien sabe de alguna comparación que muestre cómo los SSD se comparan con los HDD para el rendimiento en un entorno SQL?

Estoy tratando de entender qué tipo de beneficio de rendimiento se puede obtener al pasar a SSD.


1
Estoy seguro de que una copia del estándar SQL funcionará igual de bien en SSD que en HDD de disco giratorio. ¿O tal vez le interesa un intento particular de implementación del estándar SQL?
womble

Respuestas:


14

Si está haciendo una gran cantidad de lecturas pequeñas, los SSD son mucho más rápidos. Aquí hay una de las pocas comparaciones que flotan sobre el rendimiento de la base de datos. Mira la gráfica inferior para la respuesta corta.

Para un rendimiento en bruto, los SSD ofrecen muchas ventajas, la principal es que el tiempo de búsqueda es efectivamente 0, lo que significa que todos los pequeños golpes HD que una base de datos recibe se manejan mucho más rápido.

Sin embargo, existen algunas preocupaciones con la generación actual en la vida útil de la escritura, ya que después de tantas escrituras un bloque ya no es utilizable. Pueden escribir bastante, creo que la información dice alrededor de un petabyte de bytes para sus unidades de 32 GB antes de que comiencen a alcanzar niveles peligrosos de hardware ... esto solo mejorará con el tiempo.

Para una mejor comprensión de por qué funcionan mucho mejor, lea este artículo de Anandtech sobre SSD . Entra en gran detalle de las unidades, lo que es bueno, lo que no, y los entresijos de cómo funcionan. En la parte superior también hay un enlace a artículos de seguimiento que cubren la última serie de unidades.


2
En términos de desgaste debido a los ciclos de escritura limitados, los SSD buenos se están acercando a la seguridad de los discos giratorios en estos días debido a una combinación de una mayor capacidad de ciclo de escritura de celdas individuales, "trucos" de fusión de escritura para reducir los ciclos de bloqueo de escritura requeridos y nivelación de desgaste algoritmos Incluso para aplicaciones de alta carga de E / S como una base de datos muy activa, no es mucho más probable que un buen SSD se almacene antes del reemplazo de rutina que un disco giratorio. Simplemente mantenga copias de seguridad periódicas, probadas regularmente, como con cualquier solución de almacenamiento.
David Spillett

Estoy de acuerdo, por eso lo llamo una preocupación, no un show-stopper ... un disco barato tiene un problema real con esto en este momento, y es más un problema de firmware. Dentro de 6 meses, creo que el nivel de desgaste ni siquiera aumentará, ha progresado muy bien, muy rápido.
Nick Craver

1
Buena respuesta. Solo para agregarlo, creo que en la mayoría de los casos, el registro debe permanecer en un disco duro normal, ya que está escrito secuencialmente y los discos duros son baratos. Simplemente tenga la base de datos real en un SSD, ya que es donde está el acceso aleatorio.
PeteT

@PeteT: varía / depende un poco, recuerde que un registro particular es secuencial sí, pero en un servidor que aloja muchas bases de datos (como Stack Exchange que aloja muchos sitios en una base de datos por) el comportamiento real está mucho más cerca del acceso aleatorio / escritura que secuencial, por lo que depende de qué / cuánto esté ejecutando.
Nick Craver

Una cosa hermosa es que cuando un SSD llega al final de su vida útil y ya no se puede grabar, todavía es legible. No se puede decir eso sobre un disco giratorio que se rompe.
djangofan

4

Puede instalar su sistema operativo y software de SQL en un disco duro estándar y luego agregar un SSD para guardar los archivos de su base de datos. Esto debería limitar el número de escrituras que experimenta la unidad SSD y también maximizar la cantidad de espacio disponible para sus datos en la unidad.



2

La respuesta de Nick Craver es buena; Solo quiero agregar dos advertencias a los SSD que creo que la gente debería tener en cuenta:

a) Los problemas de SSD con el desgaste de escritura no van a desaparecer, son fundamentales para las celdas flash utilizadas. Las celdas SLC tienen una resistencia de escritura mucho más alta que MLC, por lo que el OP debe considerar obtener una unidad SLC sobre MLC. Por supuesto, SLC también es significativamente más caro.

b) Los datos actuales almacenan en caché los datos del disco antes de escribirlos. Por lo tanto, existe el riesgo de pérdida de datos si se corta la energía durante una operación de escritura. Es algo que puede evitar, pero el caché está ahí tanto para el rendimiento como para reducir la amplificación de escritura.

En mi humilde opinión, ninguno de los anteriores es un factor decisivo. Estaría listo para implementar SSD en producción hoy, pero con algo de planificación primero.

  1. Si un pequeño riesgo de pérdida de datos es inaceptable, entonces los discos duros SAS convencionales con almacenamiento en caché de datos desactivado pueden ser una mejor opción.
  2. Creo que debería medir la cantidad de datos escritos en la unidad SSD en un día normal. Según esto y las especificaciones de uso de los fabricantes, calcule la vida útil esperada del SSD con su patrón de uso. Si la vida útil esperada es menor que la vida útil planificada de los servidores, establezca una fecha de reemplazo preventiva para el SSD. Al igual que las partes del avión, cámbielo antes de que sea probable que falle.

Partes del avión? No es la mejor analogía si la extiende a los transbordadores de la NASA, que se ejecutan en computadoras IBM AP101S con 1 GB de RAM y sin HDD. La necesidad de previsibilidad y fiabilidad está por encima de todas las demás consideraciones.
CJM

1

Algo para tener en cuenta.

Si está llegando a la base de datos lo suficiente como para que sus lecturas se ralenticen y necesite SSD, entonces necesita corregir sus índices o buscar agregar más RAM al servidor.

La mayoría de los servidores de bases de datos, una vez que están totalmente sintonizados, no necesitan SSD para funcionar bien.


Mis lecturas no se están ralentizando. Estamos tratando de optimizar una consulta de "primer acierto" en la que se tarda unos 120-130 ms la primera vez que se ejecuta la consulta y 80 ms después de eso. Estos tiempos excluyen la creación de los planes de consulta y la lectura de las estadísticas relevantes. Podemos ver que la diferencia de tiempo en nuestro caso se pasa leyendo desde el disco, por lo que trato de explorar cómo puedo hacer que ese primer golpe se acerque a los 80 ms.
spoon16

Entonces, incluso después de la primera carrera, ¿aún tarda 80 ms? ¿Son principalmente lecturas de datos o mucha CPU (agregación u ordenación)? Todavía creo que hay mucho espacio para la optimización "tradicional" antes de recurrir a tecnologías de almacenamiento exóticas.
BradC

Si tiene que ir al disco en la primera ejecución de la consulta, entonces SQL está sacando los datos de la memoria caché por algún motivo. Es posible que primero desee ver cuál es la esperanza de vida de su página. Si es bajo, entonces hay más RAM en orden. ¿Cuál es su índice de aciertos de caché antes, durante y después de la consulta? Si está por debajo del 99.8% más o menos, entonces la indexación y más RAM están en orden. ¿Estás haciendo CUALQUIER escaneo? Si es así, entonces es posible que se necesite más indexación.
mrdenny

En una carga de trabajo de escritura pesada con almacenamiento en caché de escritura (es decir, datos comprometidos físicamente en el disco antes de que vuelva la llamada), debería obtener un rendimiento de escritura notablemente mejor desde un SSD, suponiendo que su aplicación realmente esté vinculada a E / S. Tenga en cuenta que esta es la estrategia de almacenamiento en caché preferida para SQL Server, especialmente en SAN, y MS requiere que las SAN garanticen este comportamiento para obtener la certificación para su uso con SQL Server.
Preocupado

1

Lea este artículo (bastante antiguo - 2009):

Resumen: reemplace las unidades SAS 24 x 15k RPM con 6 (sí seis) SSD y aún obtenga un 35% más de rendimiento. Esto fue con Intel X25M que ya no son los mejores para SSD.

Para las personas de la base de datos, esto es fantástico, ya que puede tener servidores más pequeños y rápidos con menos energía.


1

Una cosa a tener en cuenta es tener el registro de transatcion en un HDD y su MDF en un SSD. Además, la vida útil dependerá en gran medida del tipo de aplicación. OLTP puede grabarse rápidamente donde los datos razonablemente estáticos no deberían tener problemas.


1

Mi propia experiencia fue mixta aquí ...

Pruebas en Windows 7 con SQL Server 2008 Express R2. Se ejecuta en un escritorio i7 con Sandy Bridge y 12G ram instalado (¿DDR3, creo?). Disculpe que la configuración sea de escritorio, justo después de ver cuántos registros puedo administrar en la plataforma i7 antes de construir un servidor.

Primero ejecuté estas pruebas en la unidad instalada de 1.5TB 7200rpm para obtener los tiempos base.

10k registros con procesos de actualización, optimicé las tablas para almacenar los datos relacionados anteriormente en una tabla plana, añadí índices hasta que reduje los tiempos a unos pocos segundos como punto de partida, luego dupliqué los registros hasta 1,2 millones y obtuve un tiempo de 0: 3: 37 para las mismas actualizaciones. 3 1/2 minutos no es malo para esta configuración sin incursión.

Duplicar los registros hasta 2,56 millones me dio un tiempo de 0:15:57, casi un aumento de 5 veces. Probablemente debido principalmente a la paginación más allá de la memoria 12G instalada.

Instalé la unidad SSD y moví las bases de datos, el tiempo en realidad aumentó a poco más de 20 minutos. Supongo que esto se debe a que los archivos de página son por disco duro y no había ninguno por defecto en la unidad SSD, ya que no estaba instalado como unidad del sistema operativo (pantallas azules en abundancia cuando lo intenté).

Se agregó un archivo de paginación a la unidad SSD y se volvió a realizar la prueba, 0: 5: 52 -m, por lo que el archivo de paginación parece haber hecho el truco, pero no estoy seguro de que un archivo de paginación sea adecuado para una unidad SSD por todas las razones anteriores, están fuertemente escritos y pueden agregar un desgaste indebido en el disco.

Una advertencia, también habilité Smartboost en esa unidad y que también puede haber influido en los tiempos, se volverá a ejecutar sin ella.

Mi mejor idea es que es más fácil agregar memoria en estos días, y por el costo, tal vez una incursión 0 + 1 de discos híbridos haría un trabajo casi tan bueno sin los problemas.

editar: deshabilitó el archivo de paginación en el SSD y dejó que el impulso inteligente hiciera lo suyo, el tiempo mejoró de 5:52 minutos a 4:55 minutos para 2.56 millones de registros con una serie de 3 actualizaciones cada uno. A continuación, probaré el caché SSD 8G en la unidad híbrida seagate 750G. entonces, si eso no está mal, los probaré en la incursión 0 + 1.

última actualización sobre esto ya que este es un hilo viejo, pero quería poner los resultados que obtuve para que alguien pueda encontrarlos.

Moviendo la base de datos al Seagate 750G Hybrid con un caché SSD 8G Ejecuté la prueba varias veces para que el caché SSD pueda aprender. Me da un tiempo de 5:15 m: s para la misma prueba, actualizando 2.56 millones de registros, lo suficientemente cerca del rendimiento de la SSD (4:55 m: s con Intel Smartboost) para que yo pueda considerar el costo.

Con alrededor de $ 50 más ($ 239 frente a $ 189 en este momento), el híbrido proporciona más de 6 veces el almacenamiento y casi el mismo rendimiento, sin ejecutar ningún software adicional para la optimización. En una incursión 0 + 1, espero que los tiempos mejoren mucho y este disco tiene una garantía de 5 años, y espero no necesitarlo.


0

Personalmente, no usaría SSD por las razones ya mencionadas; gradualmente disminuirán la velocidad antes de eventualmente fallar. Todavía no sabemos realmente cuándo será esto: las estimaciones actuales son solo eso: estimaciones. ¿Recuerdas cuando todos compramos esos CD 'indestructibles' a principios / mediados de los 80? Unos años más tarde, consideramos que el almacenamiento temporal de datos en CD era tan tonto como usar disquetes.

Si tiene su hardware, sistema operativo y base de datos configurados correctamente, entonces no necesitará apostar por los SSD.

En unos años, cuando los productos hayan madurado un poco, será un escenario diferente. Pero hasta entonces...


0

El artículo de Microsoft Research se refiere al costo por GB en lugar de la ganancia de rendimiento. En realidad, no se ajusta y prueba las unidades, pero utiliza un algoritmo de conversión retro basado en archivos de registro de servidores reales.

Algunas cosas que vienen a la mente con SSD y SQL:

1 / Si no agrega los índices correctos, SSD será mucho más indulgente ya que los tiempos de búsqueda aleatoria son muy bajos.

2 / Los costos están muy bajos cuando se realizó ese estudio y para pequeñas aplicaciones web, por ejemplo, para ejecutar el back-end de una aplicación de teléfono, no servidores de Exchange empresariales, el rendimiento podría ahorrar gastos al contratar a un consultor para ajustar SQL Server.

3 / Una sola unidad SSD con instantáneas seguramente tiene que ser más barata que un montón de husillos en un gabinete RAID y el controlador y las conexiones. Sin mencionar el poder y la calefacción y el espacio de rack.

4 / Los husillos son conocidos por ser la parte que más comúnmente muere en una computadora. El SSD no tiene partes móviles y una hora de inactividad comercial podría costar el precio de un SSD de una sola vez.

5 / El desgaste es un problema, pero tienen formas de administrarlo (que implican bloques de dispersión) que son posibles porque los datos fragmentados al azar no ralentizarán un SSD. Además, una pequeña base de datos en un disco grande probablemente no se desgastará a tiempo para comprar una nueva más barata en el futuro.

6 / Existe una tendencia hacia las bases de datos no relacionales y las uniones en el nivel medio. Esto realmente podría cambiar las cosas: E / S a tablas simples no indexadas en unidades SSD en fragmentos sin penalización de rendimiento y con una propuesta de escala mucho más simple. También se ahorra en licencias de SQL Server por fragmento.

7 / Todo esto es teórico. Si alguien tiene pruebas de rendimiento del mundo real contra husos, me encantaría verlo.

Luke

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.