La pregunta lo dice todo. Pero, ¿es verdad? ¿Alguien puede explicar cuál es el factor diferenciador aquí (cómo un tipo de disco es mejor que otro para un propósito específico)?
(Para su información, intenté buscar y pude hacerlo bienun articulo, que fue escrito hace como 3 años).
Respuesta1
Ya no. También puede ejecutar bases de datos de discos SATA: los WD Velociraptors son bastante comparables a muchas unidades SAS a menos que obtenga un rendimiento REALMENTE alto (por lo tanto, base de datos! = base de datos).
El paso más grande es de 3,5" a 2,5": ahorra mucho dinero (por GB) cuando utiliza unidades grandes y lentas de 3,5".
Los factores diferenciadores son:
- Los discos SAS normalmente son más rápidos y admiten colas de comandos más largas que los SATA (límite de 32 frente a MUCHO más).
- Los SSD son otra historia. Hablando de 60.000 IOPS versus 450.
En general, las bases de datos se utilizan mucho cuando se vuelven más pesadas, con IO totalmente aleatorias, por lo que no cuenta los gigabytes ni las RPM, sino las IOPS (operaciones de IO por segundo).
Respuesta2
Si bien no puedo decir haber oído hablar alguna vez de la regla, el contenido estático tiene ventajas que los servidores de bases de datos no pueden proporcionar tan fácilmente.
Las unidades SATA generalmente tienen tiempos medios de falla más bajos, son más lentas y funcionan peor en E/S aleatorias. El resultado es que su coste por GB es más económico.
Cuando almacena medios como contenido estático, el sistema generalmente almacena en caché el contenido, por lo que normalmente no se lee mucho del disco, lo que elimina la necesidad de tener un disco de alta velocidad.
Esto es especialmente cierto para los sitios web donde el 90% de los datos presentados representan el 99% de las solicitudes.
Por otro lado, las bases de datos suelen tener un perfil de IO que es mucho más aleatorio. Las bases de datos tampoco suelen depender del subsistema de almacenamiento en caché del kernel para administrar su contenido, por lo que puede beneficiarse del uso de discos más rápidos. También tienden a realizar muchas más escrituras que el contenido estático, que es donde las unidades SAS realmente pueden ayudar.
Tenga en cuenta que hay tantos tonos de gris que no es tan simple ni tan directo como eso.
- ¿Quizás su base de datos no se utiliza mucho?
- ¿Quizás sepa exactamente qué tablas se leerán y la probabilidad de que se utilicen los datos?
- ¿Quizás las escrituras en bases de datos casi nunca se realizan?
- ¿Quizás los tiempos de respuesta que tiene y los números de concurrencia que tiene se puedan lograr de manera efectiva con SATA?
No diría que existe una "regla general". En su lugar, ¿por qué no obtener algunas mediciones de E/S para su aplicación ahora y saber cuáles anticipa que necesitará dentro de 2 años? ¿Crees que SATA será adecuado entonces? ¿Qué pasa con SAS? ¿Quizás SSD sea aún mejor? Si habla de tiempos de recuperación 30 ms más rápidos con SAS, ¿realmente vale la pena gastar más? ¿Sus clientes exigen esa velocidad adicional de 30 ms?
Para la mayor parte del trabajo que hago, los números que genera nuestra operación realmente no justifican a SAS. Y, de todos modos, el margen de rendimiento que se obtiene frente al coste por GB no es tan atractivo para mí. Ahora que hay SSD en el mercado, estoy aún menos impresionado con las ofertas de SAS.
Esono significaEstoy diciendo que SAS no es adecuado para usted. Pero calcule su costo por GB, determine cuáles serán probablemente sus necesidades de rendimiento ahora y, dentro de unos años, compare los resultados con las necesidades específicas de sus clientes.