El grupo de investigación de Microsoft de Cambridge acaba de publicar un documento acerca de la conveniencia o no de tener el sistema de almacenamiento de SQL Server en discos SSD. Estos discos son más rápidos en lecturas aleatorias (principalmente) y gastan menos que los tradicionales (al no tener partes mecánicas), son por el contrario mucho más caros, pero en principio deberían ser una buena alternativa para aumentar el rendimiento de nuestro servidor, ya que el subsistema de disco suele ser el recurso más lento del servidor. Sin embargo, en primer lugar debemos asegurarnos que el cuello de botella (en caso de tenerlo) está ahí y luego comprobar que efectivamente la única alternativa es mejorar sí o sí la velocidad de nuestros discos.

El caso es que no se conocen muchos casos de empresas que hayan montado un sistema de discos basado en SSDs. La razón podríamos encontrarlo en los precios que tienen estas cabinas (que haberlas haylas), pero también puede ser que no nos fiemos aún de esta tecnología o, directamente, que aún no merezca la pena. Este documento (no es un whitepaper, sino un documento de investigación, de análisis, por lo que es mucho más técnico) viene a concluir esto último: con las cargas de trabajo digamos, “normales”, siguen teniendo más sentido nuestros tradicionales HDD. Sólo en el caso de grandes sistemas OLTP (grandes de verdad), puede uno comenzar a plantearse la conveniencia de usar esta nueva tecnología.

El documento, en inglés, está accesible aquí

0 Shares:
Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

You May Also Like
Leer más

Hilando fino en SSAS multidimensional

El equipo de SolidQ ha estado buscando la mejor manera de implementar una jerarquía padre-hijo de cuentas contables con un operador unitario que tuviera un buen rendimiento, a pesar de la gran cantidad de datos a la que tenía que enfrentarse. Veremos cómo aplanar la jerarquía, cómo implementarlo con SSAS, con una alternativa MDX, cómo añadir ordenación a las cuentas basadas en otro atributo, Time Balance Average y algún otro truco de tuning.
In-Memory OLTP: Otra historia de corrupción y problemas de DMVs
Leer más

In-Memory OLTP: Otra historia de corrupción y problemas de DMVs

El uso de la funcionalidad In-Memory OLTP sigue siendo una rareza en general entre nuestros clientes y se desconoce el alto potencial para poder mejorar el rendimiento de los sistemas con alto nivel de concurrencia y transacciones. Nuestro experto Rubén Garrigós nos explica cómo habilitar dicha funcionalidad, qué problemas pueden ocurrir y cómo solucionarlos.

Carga de Slowly Changing Dimensions y tabla de Hechos con atributos de Tipo 2 (Parte 2 de 3)

Este es el segundo post de la serie en el que explicaremos como cargar nuestra tabla de Hechos a partir de una dimensión con atributos de Tipo 2, usando dos maneras diferentes, una de ellas será mediante un componente “Look Up” con caché parcial y la otra opción será usando un componente “Merge Join” con un “Conditional Split” para seleccionar el registro que se encuentra en el rango de fechas correcto. Para mas información sobre qué es un atributo de Tipo 2 y sobre como cargar la dimensión que usaremos en este ejemplo puedes consultar el primer post de la serie.