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 😉
