La compresión de datos en SQL Server es una funcionalidad clave que permite optimizar el almacenamiento y mejorar el rendimiento de entrada/salida (E/S) en bases de datos con grandes volúmenes de información. SQL Server ofrece dos tipos principales de compresión: a nivel de fila y a nivel de página. En este artículo veremos ambos métodos así como sus ventajas y casos de uso, y mostraremos cómo evaluar el impacto de estas técnicas en el almacenamiento mediante herramientas nativas de SQL Server.
Compresión de fila
La compresión de fila elimina redundancias en datos almacenados en columnas de tipos de datos de longitud fija, como CHAR e INT. Además, optimiza el almacenamiento de valores NULL y ceros.
Características principales:
Como no podía ser de otra manera, la principal característica de este tipo de compresión es la optimización ligera de espacio. Con esto quiero decir que reduce el tamaño al eliminar espacios en blanco innecesarios y valores repetitivos pero sin mucho impacto en el sistema. No es una compresión muy intrusiva, lo que nos lleva a su segunda característica principal, la compatibilidad. La compresión a nivel de fila es transparente para las operaciones de lectura y escritura, ya que no requiere descompresión y tiene un impacto bajo en la CPU (tercera característica). Esto la hace una solución ideal para sistemas con limitaciones de procesamiento.
Casos de uso:
Como ya hemos dicho esta solución es la más recomendada en tablas con numerosos valores NULL o ceros o tablas con columnas de tipos de datos de longitud fija donde tengamos limitaciones o estemos cerca del límite de la CPU. Si no tenemos problemas de CPU podremos optar por el siguiente tipo de compresión como vamos a ver ahora mismo.
Compresión de página
La compresión de página es la más completa, combina la compresión de fila con técnicas de codificación más avanzadas, como el uso de diccionarios para reducir patrones repetitivos dentro de las páginas de datos. Es decir, además de toda la compresión que ya teníamos a nivel de fila elimina los datos duplicados en disco para reducir así el espacio. Es como una “deduplicación” de los datos de la tabla, así entre comillas pero para entendernos.
Características principales:
Lo estarás ya imaginando, la principal característica de la compresión a nivel de página es la reducción significativa del espacio. Es ideal para tablas con datos repetitivos o históricos. Por contra tiene un mayor uso de CPU ya que requiere más procesamiento, especialmente durante la compresión inicial. Hay que poner en una balanza este coste extra de CPU al comprimir con la eficiencia en almacenamiento. En teoría reduce los costes al minimizar el espacio físico necesario pero carga la CPU.
Ahora bien, si no tenemos tantas escrituras y nuestro consumo de CPU es mayoritariamente en lecturas podemos llevarnos una sorpresa. Comprimir los datos hace que podamos almacenar más datos en RAM, incluso en la caché del procesador y puede darse el caso que lo que notemos sea justo lo contrario, una reducción del uso de la CPU. Si lo piensas no es tan descabellado, es la manera de trabajar de los índices.
Casos de uso:
En este caso, los casos de uso son un poco más específicos que en el anterior tipo. Usaremos la compresión a nivel de página en tablas de archivos históricos y tablas de solo lectura. También nos lo podemos plantear en bases de datos con grandes tablas con volúmenes de datos repetitivos siempre y cuando el consumo de CPU no sea un problema para nosotros. Por último, en servidores donde el principal cuello de botella sea la E/S de disco (ejem, Azure, ejem) el beneficio también será sustancial.
Evaluación del impacto en el almacenamiento
Antes de implementar la compresión, es fundamental evaluar el impacto potencial en el almacenamiento para entender los beneficios que puede ofrecer. SQL Server proporciona el procedimiento almacenado de sistema sp_estimate_data_compression_savings, que permite estimar el ahorro de espacio para diferentes tipos de compresión.
Sintaxis del procedimiento:
EXEC sp_estimate_data_compression_savings
@schema_name = 'NombreEsquema',
@object_name = 'NombreTabla',
@index_id = 0, -- 0 para todos los índices
@partition_number = NULL, -- NULL para todas las particiones
@data_compression = 'PAGE'; -- Alternativas: ROW, NONEEjemplo práctico:
Supongamos que tenemos una tabla Ventas en el esquema dbo y queremos evaluar el impacto de habilitar compresión de página:
EXEC sp_estimate_data_compression_savings
@schema_name = 'dbo',
@object_name = 'Ventas',
@index_id = 1, -- Índice específico
@partition_number = NULL, -- Todas las particiones
@data_compression = 'PAGE';Resultado:
El procedimiento devuelve una estimación del espacio actual y el espacio proyectado después de aplicar la compresión. Esto incluye:
- size_with_current_compression_setting: Tamaño actual.
- size_with_requested_compression_setting: Tamaño estimado con la compresión solicitada.
- savings_in_bytes: Ahorro en bytes.
Implementación de la compresión
Una vez evaluado el impacto, podemos habilitar la compresión mediante las siguientes instrucciones:
-- Compresión de fila
ALTER TABLE dbo.Ventas
REBUILD PARTITION = ALL
WITH (DATA_COMPRESSION = ROW);
-- Compresión de página
ALTER TABLE dbo.Ventas
REBUILD PARTITION = ALL
WITH (DATA_COMPRESSION = PAGE);
-- Deshabilitar la compresión
ALTER TABLE dbo.Ventas
REBUILD PARTITION = ALL
WITH (DATA_COMPRESSION = NONE);Beneficios adicionales de la compresión
En líneas generales, sea cual sea el tipo de compresión que utilicemos, hay una serie de ventajas que son comunes. El principal beneficio que podemos destacar es la reducción de espacio físico en disco o en almacenamiento en la nube lo que implica directamente una reducción de costes. Por otro lado, vamos a encontrarnos con mejoras en E/S lo que se traduce en operaciones más rápidas al transferir menos datos.
Por último, debemos hablar de la compatibilidad. La compresión no es solo a nivel tabla, también se aplica a índices, optimizando consultas.
Conclusión
La compresión en SQL Server es una herramienta poderosa para reducir costes y mejorar el rendimiento de bases de datos. Evaluar previamente el impacto con sp_estimate_data_compression_savings asegura que tomemos decisiones informadas, maximizando los beneficios en almacenamiento y rendimiento. Ya sea con compresión de fila o de página, estas técnicas pueden adaptarse a una amplia gama de necesidades y escenarios empresariales.
Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!
