Para mejorar el rendimiento de SQL, ¿por qué no simplemente poner mucha RAM en lugar de tener discos duros más rápidos?

La gente sigue diciéndome que para mejorar el rendimiento de un servidor SQL, compre los discos duros más rápidos posibles con RAID 5, etc.

Así que estaba pensando, en lugar de gastar todo el dinero en RAID 5 y discos duros rápidos súper duper (que no es barato por cierto), ¿por qué no solo obtener toneladas de RAM? Sabemos que un servidor SQL carga la base de datos en la memoria. La memoria es mucho más rápida que cualquier disco duro.

¿Por qué no cosas como 100 GB de RAM en un servidor? Luego use un disco duro SCSI normal con RAID 1. ¿No sería eso mucho más barato y más rápido?

Su análisis está bien, hasta cierto punto, en que absolutamente acelerará las cosas. Sin embargo, aún debe tener en cuenta otros problemas:

1. No todos pueden permitirse suficiente memoria; cuando tiene varios terabytes de datos, debe guardarlos en el disco alguna vez. Si no tiene muchos datos, cualquier cosa es lo suficientemente rápida.

2. El rendimiento de escritura para su base de datos seguirá estando limitado por los discos, de modo que pueda cumplir la promesa de que los datos se almacenaron realmente.

Si tiene un pequeño conjunto de datos o no necesita conservarlo en el disco, su idea no tiene nada de malo. Herramientas como VoltDB están trabajando para reducir los gastos generales que las suposiciones anteriores en las implementaciones de RDBMS hicieron que limitan el rendimiento puro en memoria.

(Por otro lado, las personas que le dicen que use RAID-5 para el rendimiento de la base de datos probablemente no sean buenas personas para escuchar sobre el tema, ya que casi nunca es la mejor opción: tiene un buen rendimiento de lectura, pero un mal rendimiento de escritura y escritura son casi siempre la restricción de producción, ya que puede usar RAM en el almacenamiento en caché para resolver la mayoría de los problemas de rendimiento del lado de lectura).

Versión corta: considere el tamaño del conjunto de trabajo. Versión larga: ¿qué tamaño tienen sus datos? Si cabe en la memoria de un servidor moderno, sí, tiene toda la razón. Desafortunadamente, el Xeon más grande puede direccionar 2TB de RAM en este momento, y eso ya no es un conjunto de datos tan grande. Si no puede comprar una máquina lo suficientemente grande como para almacenar todo su conjunto de trabajo en RAM, se ve obligado a resolver problemas con su cerebro, no con su billetera.

Si quieres velocidad:

• Aumente la RAM para que al menos los índices de uso frecuente puedan caber por completo en la RAM (por ejemplo, en un sistema en el que trabajo, 32 GB de RAM es suficiente para una base de datos de 350 GB, porque los índices son lo que necesita en RAM, no datos sin procesar)
• Use RAID10 con cualquier disco (los discos más rápidos son mejores)
• Evitar RAID5
• Divida mdf, ldf y temp DB en conjuntos de husillos discretos (ejemplo: tempdb en su propio conjunto RAID1, ldf en su propio conjunto de husillos RAID1 o RAID10, mdf en un conjunto RAID 10 con al menos 4 discos en total)

Siga esos pasos y SQL Server volará.

Luego, si lo desea, agregue más RAM ... pero primero haga lo anterior, y es posible que haya terminado.

RAM es el nuevo disco, el disco es la nueva cinta.

En http://www.tbray.org/ongoing/When/200x/2006/05/24/On-Grids . Tenga en cuenta que fue hace seis años. Sí, tenemos sistemas de bases de datos que intentan (y se esfuerzan) mantener todo el conjunto de datos en la RAM y en lugar de fragmentarlo en varias máquinas en lugar de usar el disco porque el disco es de todas maneras magnitudes más lentas. Debe escribir el conjunto de datos en el disco, pero como en el lema anterior, es más parecido a una tarea de respaldo en segundo plano que a una operación en línea. La durabilidad se logra mediante la adición de registros solo con estas bases de datos (estoy pensando en MongoDB y Redis, pero hay toneladas más).

Esta pregunta es similar a una pregunta básica que ha llevado a mucha investigación y desarrollo en arquitecturas de bases de datos en los últimos 5-10 años. Ahora que es factible almacenar una base de datos completa en RAM para muchos casos de uso, la base de datos debe estar diseñada para funcionar en RAM, en lugar de simplemente aplicar arquitecturas heredadas más antiguas al almacenamiento basado en RAM.

Del mismo modo que se han adoptado ampliamente muchos idiomas más pequeños y con fines especiales en los últimos años, estamos entrando en una era en la que se necesitarán más bases de datos con fines especiales.

Para leer más sobre este tema, recomiendo el artículo académico El fin de una era arquitectónica (es hora de una reescritura completa) . No es una lectura difícil.

No está claro si esta pregunta fue específicamente sobre SQL Server. El póster original debería aclarar esto.

Daniel Pittman escribió:

Si tiene un pequeño conjunto de datos o no necesita conservarlo en el disco, no hay nada de malo en su idea. Herramientas como VoltDB están trabajando para reducir los gastos generales que las suposiciones antiguas> en implementaciones de RDBMS hicieron que limitan el rendimiento puro en memoria.

La reducción de los gastos generales de los supuestos más antiguos en las implementaciones de RDBMS era exactamente el objetivo de diseño de VoltDB , pero se escala horizontalmente sin límite arquitectónico en el tamaño de los datos, y puede persistir en el disco para una durabilidad completa utilizando instantáneas y registro de comandos.

Si puede obtener un servidor con suficiente RAM para contener, al menos, la parte activa de su conjunto de datos, estará bien. Además, RAID 1 y 5 no son la forma más rápida de organizar sus datos: RAID 0 es más rápido, pero, entonces, tendrá que considerar las probabilidades más altas de un fallo del sistema de archivos que borre su base de datos; no es algo agradable que suceda . Puede RAID 1 o RAID 5 su matriz RAID 0, siempre que tenga suficientes unidades y controladores.

Incluso puede jugar con la replicación aquí: haga sus escrituras en un servidor con gran capacidad de disco que se replica en uno o más servidores con mucha memoria donde ejecuta consultas complicadas.

Lamentablemente, los RDBMS parecen estar en el gran reino del hierro: no son tan fáciles de cultivar horizontalmente.

Este es un caso de "depende de lo que esté haciendo". ¡Quizás el consejo "correcto" es evitar SQL por completo y usar memcache / redis / etc!

Estoy de acuerdo con usted en que la RAM adicional ayudará mucho, especialmente si puede leer todo el conjunto de trabajo en la RAM. Sí, todavía tendrá que escribir datos, pero si ha leído principalmente, las escrituras no tendrán contención para la E / S de disco.

Sin embargo, el rendimiento del disco a menudo es un cuello de botella en los servidores SQL y es más difícil que otras cosas como la RAM para actualizar más tarde (si tiene un servidor que no está completamente poblado con DIMM).

Hubo una serie de comentarios acerca de que RAID5 es lento, pero diría que este no es siempre el caso, así que tenga cuidado antes de hacer declaraciones radicales. Los servidores de gama alta con tarjetas RAID rápidas y muchos BBWC a veces funcionan mucho más rápido en RAID5 (o RAID50 con> 4 discos) que en RAID10 ...

A lo largo de los años, personalmente he experimentado matrices RAID5 lentas, pero después de comparar un DL360 G5 con 4 discos SAS 146G en ~ 2009, tuvimos que verificar nuestras pruebas. De hecho, la matriz fue más rápida con RAID5 que RAID10 en casi todas las pruebas. BBWC y los cálculos rápidos de paridad permitieron que el servidor pudiera usar los 4 discos de manera mucho más efectiva como una matriz RAID5 que RAID10. Algunas de las pruebas mostraron un rendimiento 50% mejor con RAID5, y casi ninguna fue más lenta. Las pruebas que fueron más lentas fueron solo 5-10% de descuento.

Advierto a las personas que hacen declaraciones generales que RAID5 es lento, todos lo dicen en línea, pero simplemente no es cierto en todos los casos.

Tiene una bolsa de dulces para elegir y realmente depende del sabor que desee.

1. Las bases de datos tendrán configuraciones para las consultas de caché y, si existe este caché, memoria o disco duro.
2. RAID 5 no siempre es el más rápido, pero RAID 0 (JBOD) es una banda y es rápido, ya que RAID 5 también es una banda, la idea es muy parecida.
3. RAID 1 no mejorará su velocidad, es solo un espejo.
4. El rendimiento de SQL se basa en la indexación y es lo primero que se debe verificar. Muy importante en bases de datos relacionales.
5. No indexe todo, la indexación excesiva también puede reducir la velocidad porque su indexación se sobrecarga.
6. A veces, con SQL Joins, la base de datos se vuelve más lenta. El uso de la programación para repetir un conjunto de resultados indexados mínimos mejora la velocidad.
7. Los servidores virtuales son una pesadilla para la velocidad si no paga los dólares.

Simplemente invierta en el conocimiento (gratis) antes de desembolsar efectivo. 1. Aprenda las configuraciones para su base de datos y mire su configuración actual para optimizar. 2. Mire las declaraciones de programación y sql, prueba de unidad con scripts simples que imitan las operaciones involucradas, puede que ni siquiera sea lo que cree que es el problema. SI las secuencias de comandos simples toman tiempo usando SQL Joins, divídalas y haga lo mismo con un ciclo programado para hacer lo mismo. Esto es donde la memoria puede ayudar 3. Mire el plan de alojamiento y el servidor. Use ps aux en una consola de Linux y vea si hay algo que esté absorbiendo su memoria y procesador.

El disco duro absoluto mejora la velocidad, pero no depende de usted en un espacio de servidor virtual. La memoria no mejora la velocidad a menos que configure los servicios para ella, punto. RAID rayado (0,5), RPM y lectura / escritura síncrona con un bus rápido ayuda a eso. Un procesador central con buena caché l1, l2, l3 ayudará a procesar el cuello de botella. puedo escucharlo por Xeon!

En general, debe tener en cuenta el tamaño y la escalabilidad. Si bien puede parecer que comienza con pequeñas necesidades de almacenamiento, sus datos crecerán muy rápida y exponencialmente. Las bases de datos son mejores utilizando datos atómicos, que son datos desglosados ​​al tamaño más pequeño posible. Debido al pequeño tamaño, viaja más rápido dentro del almacén de datos. Luego, también tiene en cuenta la estructura de la base de datos. En el futuro, podría estar vinculándose a bases de datos externas, por lo que la estructura también es crucial. En este escenario, sería una pequeña diferencia para su consulta si la mitad de los datos viven fuera de su data mart. Cuando se consultan datos, el punto no es mantener los datos almacenados en la RAM; más bien, la consulta debería ser rápida para acceder y devolver datos.

• Realmente no siempre usas RAID 5 para los datos. Depende de los datos y su importancia, además de lo que se mencionó anteriormente sobre las copias de seguridad. RAID 1 se puede usar y es.
• Tendría que actualizar todos los servidores dentro de su rango de consulta para mejorar la velocidad. Dado que gran parte de los datos están fuera de su control, se va a bloquear en algún lugar fuera de su data mart. (En el caso de que actualices el tuyo)