31 votos

Para mejorar el rendimiento de SQL, ¿por qué no poner un montón de RAM en lugar de los discos duros más rápidos?

Las personas me dicen que con el fin de mejorar el rendimiento de SQL server, comprar el disco duro más rápido posible con RAID 5, etc.

Así que tengo que pensar, en lugar de gastar todo el dinero para RAID 5 y super rápido de los discos duros (que no es barato, por cierto), ¿por qué no acaba de obtener toneladas de RAM? Sabemos que una de SQL server se carga la base de datos en la memoria. La memoria es wayyyy más rápido que los discos duros.

¿Por qué no cosas como 100 GB de RAM en un servidor? A continuación, sólo tiene que utilizar un regular SCSI del disco duro con RAID 1. ¿No sería mucho más barato y más rápido?

51voto

Daniel Pittman Puntos 4208

Su análisis está bien -- a un punto en que absolutamente va a hacer las cosas más rápido. Usted todavía tiene en cuenta un par de cuestiones:

  1. No todo el mundo puede permitirse el lujo de suficiente memoria; cuando se tiene varios terabytes de datos, tienes que ponerlo en el disco algún tiempo. Si usted no tiene la cantidad de datos, nada es lo suficientemente rápido.

  2. Escribir el rendimiento de su base de datos es todavía va a estar limitada por la de los discos, de modo que puede mantener la promesa de que los datos se almacenan realmente.

Si usted tiene un pequeño conjunto de datos, o no es necesario conservar en el disco, no hay nada de malo con su idea. Herramientas como VoltDB están trabajando para reducir los gastos generales, de que los mayores supuestos en RDBMS implementaciones hecho que limitan puro en el rendimiento de la memoria.

(Un inciso, que la gente le diga a utilizar RAID-5 para el rendimiento de base de datos probablemente no son grandes a la gente a escuchar sobre el tema, ya que casi nunca es la mejor opción - que tenga un buen rendimiento de la lectura, pero la mala calidad de la escritura, y escribe casi siempre son la producción de restricción, porque no se puede tirar la RAM en la caché para resolver los más leídos del lado de los problemas de rendimiento.)

11voto

Marcin Puntos 1453

Versión corta: tener en cuenta el tamaño del trabajo conjunto. Versión larga: ¿cuán grandes son tus datos? Si puede caber en memoria de un servidor moderno, sí, tienes razón. Desafortunadamente, el Xeon más grande puede abordar ahora 2TB de RAM, y eso no es tan grande de un conjunto de datos más. Si no puedes comprar máquina lo suficientemente grande para albergar su trabajo conjunto en la memoria RAM, te obligan a resolver los problemas con tu cerebro, no tu billetera.

8voto

Brian Mitchell Puntos 1881

Si desea que la velocidad:

  • Aumentar la memoria RAM para, al menos, con frecuencia utilizan los índices de todo se puede caber en la memoria RAM (por ejemplo, en un sistema de trabajo en, 32 gb de RAM es suficiente para un 350GB de la base de datos, ya que los índices son lo que usted necesita en la RAM, no datos en bruto)
  • Uso RAID10 con los discos (discos más rápidos son mejores)
  • Evitar RAID5
  • División de mdf, ldf y temp DB en discretos eje conjuntos (ejemplo: tempdb en su propio RAID1 conjunto, ldf en su propio RAID 1 o RAID 10 conjunto de ejes, mdf en un RAID 10 con al menos 4 discos)

Siga los pasos y SQL Server va a volar.

A continuación, si lo desea, agregue más memoria RAM... pero ¿el de arriba en primer lugar, y usted podría encontrar que usted está hecho.

2voto

chx Puntos 1273

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í, disponemos de sistemas de base de datos que intenta (y tratar de disco duro) para mantener todo el conjunto de datos en la memoria RAM y en lugar de fragmentos de varios equipos de usar el disco porque el disco es de magnitudes más lento de todos modos. Usted tendrá que escribir el conjunto de datos en el disco, pero como en el lema anterior, que es más parecido a un fondo de tarea de copia de seguridad de una operación en línea. La durabilidad se consigue a través de anexar sólo los registros con estas bases de datos (estoy pensando en MongoDB y Redis, pero hay muchísimas más).

1voto

BenjaminBallard Puntos 111

Esta pregunta es similar a un básico que ha llevado a una gran cantidad de investigación y desarrollo en arquitecturas de bases de datos en los últimos 5-10 años. Ahora que es posible almacenar una base de datos completa en la memoria RAM para muchos casos de uso, la base de datos debe ser diseñado en torno al trabajo de la memoria RAM, en lugar de simplemente aplicar mayores heredado de las arquitecturas de la memoria RAM de almacenamiento basado en.

Al igual que muchos más pequeños y más de propósito especial de los idiomas han sido ampliamente adoptadas en los últimos años, estamos entrando en una era de más de propósito especial de las bases de datos serán necesarios.

Para más información sobre este tema, recomiendo el artículo académico El Final de una Arquitectura de la Época (Es el Momento para una Reescritura Completa). No es difícil de leer.

No está claro si esta pregunta es específicamente acerca de SQL Server. El cartel original debe aclarar esto.

Daniel Pittman escribió:

Si usted tiene un pequeño conjunto de datos, o no es necesario conservar en el disco, no hay nada de malo >con su idea. Herramientas como VoltDB están trabajando para reducir los gastos generales, de que los mayores suposiciones >en RDBMS implementaciones hecho que limitan puro en el rendimiento de la memoria.

La reducción de los gastos generales de los antiguos supuestos en RDBMS implementaciones era exactamente el objetivo del diseño de VoltDB, pero hace escala horizontal sin límite de arquitectura en el tamaño de los datos, y puede persistir en el disco por completo la durabilidad de uso de creación de instantáneas y de comandos de registro.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: