domingo, 15 de marzo de 2009

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):

MotorTiempoMb/sTamaño
SQL 20054.125 sec41.692 MB/sec168,019 kb
SQL 2008 sin compresión3.219 sec45.873 MB/sec135,256 Kb
SQL 2008 con compresión2.327 sec57.986 MB/sec34,976 kb

Veamos los mismos en restauración:

MotorTiempoMb/s
SQL 20054.171 sec41.233 MB/sec
SQL 2008 sin compresión3.569 sec36.865 MB/sec
SQL 2008 con compresión1.920 sec68.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 ;)

Publicar un comentario