Compresión de datos en SQL Server 2008 (I de III)

Hoy me apetece escribir sobre las ventajas de usar la compresión en SQL Server 2008. Es un tema que ya discutí en algo de profundidad el año pasado en nuestro SUMMIT 08, pero que no por ello está en desuso sino todo lo contrario.

Ahora que ya se empiezan a ver SQL Server 2008 en clientes y que las migraciones hacia 2008 están cada vez mas a la orden del día, es un excelente momento para tratar un tema que a mas de uno le puede sacar de un aprieto. Y es que hoy en día cada vez se almacena más y más información en nuestras bases de datos y de manera mas variopinta (imágenes, vídeos, …)

Uno de los retos que tenemos ahora por tanto es que el tamaño de nuestras bases de datos puede llegar a ser inmanejable (terabytes), y que cada vez queremos más y más rendimiento en las mismas (como es de esperar ;). Para apoyarnos en la solución de estos retos, SQL Server 2008 proporciona compresión de datos.

¿Para qué nos puede servir comprimir la información?

• Tablas e índices mas pequeños requieren menos lecturas/escrituras para mantenerlos
• Ficheros mas pequeños son mas rápidos de copiar/generar/utilizar (backups, por ejemplo)

¿Qué mecanismos de compresión nos aporta SQL Server 2008?

Nos aporta por un lado la posibilidad de realizar backups comprimidos (nivel de fichero); así como compresión de páginas y filas (nivel de datos).

Compresión de backups

Realmente podemos pensar que la compresión de backups es simplemente una mejora que repercutirá simplemente en nuestros requerimientos de capacidad en disco. Bueno, pues no es eso solo ya que a poco que pensemos un momento nos daremos cuenta que hoy en día el principal limitante con el que nos encontramos es precisamente los cuellos de botella que suponen los discos donde se almacena la información. Sea por lo que sea, cuanto menos tengas que leer/escribir de disco, mas rápido irá todo (premisa que explota SQL Server hasta la saciedad gracias al excelente uso de la memoria RAM, que evita en gran medida ir a disco si no es necesario).

Dicho esto, veamos unos cuantos datos reales de backups sobre AdventureWorks (en los 3 casos el de SQL 2005):

Motor	Tiempo	Mb/s	Tamaño
SQL 2005	4.125 sec	41.692 MB/sec	168,019 kb
SQL 2008 sin compresión	3.219 sec	45.873 MB/sec	135,256 Kb
SQL 2008 con compresión	2.327 sec	57.986 MB/sec	34,976 kb

Veamos los mismos en restauración:

Motor	Tiempo	Mb/s
SQL 2005	4.171 sec	41.233 MB/sec
SQL 2008 sin compresión	3.569 sec	36.865 MB/sec
SQL 2008 con compresión	1.920 sec	68.526 MB/sec

NOTA: Quadcore Q9300 2.50Ghz, 4Gb Ram, Win2k8 x64 EE, SQL 2K5 x64 SP3, SQL 2K8 x64, Unidad de disco 2xSeagate ST3320613AS ATA en RAID 0

Evidentemente, uno ve los números y piensa que efectivamente lo que ha de hacer es comprimir los backups por defecto. Para ello podemos lanzar la ejecución:

   1:  EXEC sp_configure 'backup compression default', '1'

   2:  GO

   3:  RECONFIGURE

Sobre si en nuestro sistema es útil realizar este tipo de acciones…lo trataremos en un siguiente post.

Pero ¿cuanto ratio de compresión estamos obteniendo?

Para saberlo basta con lanzar la siguiente query:

   1:  SELECT backup_size/compressed_backup_size

   2:  FROM msdb..backupset

Con ella obtendremos el ratio de compresión alcanzado en cada backup, que será de 1 en el caso de que no hayamos comprimido y mayor que uno en el caso de haberlo hecho.

Para las pruebas anteriores, el valor medio del ratio de compresión me ha salido de 3.867, lo cual es bastante y nos da una idea de por qué un backup en SQL Server 2005 ocupa tantísimo a comparación del de SQL 2008 comprimido.

En el siguiente post, trataré en profundidad este tema, que seguro a mas de uno le interesa ;) Entre otras cosas hablaré del coste CPU de utilizar compresión, así como métodos para aprovechar resource governor en este sentido.

Falta por tanto hablar de rendimiento y de compresión de datos, que lo dejaré para dos posts de aqui en adelante. Estad atentos ;)