¿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.
¿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.
Respuestas:
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.
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.
Le recomiendo que lea el siguiente documento Migración del almacenamiento del servidor a SSD: Análisis de compensaciones , es una buena lectura.
En mi opinión, todavía no hay suficientes beneficios de los SDD en el área del servidor. Tal vez en unos años valga la pena comprarlos, bot por ahora HDD son una mejor opción.
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.
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.
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.
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.
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.
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...
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