¿La compresión de datos de SQL Server es categóricamente buena para bases de datos de solo lectura?

Algunos textos sobre la compresión de datos de SQL Server que leí indican que el costo de escritura aumenta aproximadamente cuatro veces más de lo que normalmente se requeriría. También parece implicar que este es el principal inconveniente de la compresión de datos, lo que implica que para una base de datos de archivo de solo lectura, el rendimiento (con algunas excepciones) mejorará con el uso de la compresión de datos de páginas llenas al 100%.

¿Son ciertas las afirmaciones anteriores?
¿Cuáles son las "variaciones" principales entre la compresión de datos y de otro modo (para leer)
- "CPU + x%"?
- "IO -y%"?
- ocurrencia de división de página?
- uso de tempdb?
- Uso de RAM?
¿Y para escribir?

A los efectos de esta pregunta, puede limitar el contexto a la compresión a nivel de PÁGINA de una base de datos grande (> 1 TB) , pero los comentarios adicionales siempre son bienvenidos.

Referencias

Blog del motor de almacenamiento de SQL Server (el escenario DW muestra que la compresión es muy ventajosa)
Compresión de datos: estrategia, planificación de capacidad y mejores prácticas

Un enfoque más detallado para decidir qué comprimir implica analizar las características de la carga de trabajo para cada tabla e índice. Se basa en las siguientes dos métricas:

U: El porcentaje de operaciones de actualización en una tabla, índice o partición específicos, en relación con las operaciones totales en ese objeto. Cuanto menor sea el valor de U (es decir, la tabla, el índice o la partición se actualiza con poca frecuencia), mejor candidato es para la compresión de la página.
S: El porcentaje de operaciones de escaneo en una tabla, índice o partición, en relación con las operaciones totales en ese objeto. Cuanto mayor sea el valor de S (es decir, la tabla, el índice o la partición se escanea principalmente), mejor candidato es para la compresión de la página.

Ambas de las anteriores están sesgadas de manera demostrable a recomendar la compresión de páginas para bases de datos de estilo DW (operaciones de gran volumen de lectura / exclusivas / exclusivas).

— 孔夫子
fuente

¿Qué literatura específicamente? Siempre habrá una sobrecarga de la CPU tanto para comprimir / descomprimir, pero, como con las lecturas, también está escribiendo en un número menor de páginas. De hecho, creo que el lado de escritura se beneficiaría aún más que el lado de lectura, ya que el lado de lectura a menudo tendrá las páginas comprimidas almacenadas en la memoria (esto no siempre es así, pero el mejor de los casos depende del tamaño de los datos y la memoria asignada).

— Aaron Bertrand

Va a ser muy difícil proporcionar cualquiera de las métricas que está solicitando porque depende totalmente de la naturaleza de los datos y la capacidad de comprimirlos (y esto también será diferente dependiendo de la fila frente a la página) ) Algunas personas han reportado una relación de compresión de hasta el 90%, lo que tendrá un impacto tanto en el uso de la memoria (de manera positiva) como en la CPU para realizar tanta compresión. Este juego de pelota de papel sobrecarga la CPU al 10% para la compresión de filas y más para la página . Lo que observas puede ser muy diferente.

— Aaron Bertrand

Para una base de datos de archivo de solo lectura, supongo que la pregunta sería si cabe en la memoria. Si todo puede caber en la memoria, una vez que se carga en el grupo de búferes, no hay ningún beneficio real en comprimirlo. Sin embargo, si no puede caber todo en la memoria, aún puede ver algún beneficio al intercambiar menos páginas dentro y fuera de la memoria caché, aunque se realizará un trabajo descomprimiéndolo.

— Aaron Bertrand

Ninguno de los enlaces que agregó parece mencionar esta penalización 4x por escribir. ¿Recuerdas dónde lo recogiste? Me gustaría ver el contexto.

— Aaron Bertrand

Bueno, si no puede ajustar los datos en la memoria, ese escenario es algo discutible, ¿verdad? :-)

— Aaron Bertrand

Respuestas:

Solo mis 2cents de mis propios experimentos en hardware de 1-2 años:

Operaciones de solo lectura (escaneos de estilo DW, clasificaciones, etc.) en tablas comprimidas por página (~ 80rows / página) He encontrado un punto de equilibrio en la reducción del tamaño de compresión de ~ 3x.

Es decir, si las tablas se ajustan a la memoria de todos modos, la compresión de la página solo beneficia el rendimiento si el tamaño de los datos se ha reducido en más de 3 veces. Escanea menos páginas en la memoria, pero lleva más tiempo escanear cada página.

Yo supongo que esto puede variar según si sus planes son de bucle anidado y buscan-pesado. Entre otros, esto también dependería del hardware (penalizaciones de acceso a nodos NUMA externos, velocidad de memoria, etc.).

Lo anterior es solo una regla general aproximada que sigo, basado en mis propias ejecuciones de prueba usando mis propias consultas en mi propio hardware (Dell Poweredge 910 y versiones anteriores). No es evangelio eh!

Editar: Ayer, la excelente presentación SQLBits XI de Thomas Kejser se puso a disposición como un video. Muy relevante para esta discusión, muestra la cara 'fea' del costo de la CPU para la compresión de la página: las actualizaciones se ralentizaron 4 veces, los bloqueos se mantuvieron durante un tiempo más largo.

Sin embargo , Thomas está utilizando el almacenamiento FusionIO y eligió una tabla que solo es 'solo' elegible para la compresión de la página. Si el almacenamiento se realizara en una SAN típica y los datos se comprimieran 3x-4x, entonces la imagen podría haber sido menos dramática.

— John Alan
fuente

¿Puede ser ese el viejo hardware? En hardware nuevo, SSD desnudo Para almacenamiento, encuentro que los núcleos no pueden mantenerse al día con los discos fácilmente. No obstante, creo que el beneficio comenzaría MUCHO más fácil: una reducción del 50% en IO vale la pena cuando no se hacen tantos cambios.

— TomTom

TomTom, Storage no entra en juego para estas figuras. La comparación es entre tablas no comprimidas en memoria y tablas comprimidas en memoria.

— John Alan

Nunca vi un DWH que fuera lo suficientemente bueno para la memoria. Seriamente. Volverás al disco.

— TomTom

Sí, por supuesto, ocasionalmente volverá al disco: la lectura desde el disco es donde la compresión de la página casi siempre tiene una ventaja (¡suponiendo que los datos sean lo suficientemente comprimibles!). Pero si su carga de trabajo se carga desde el disco una vez y luego manipula todo en la memoria durante el resto del día, ¿cuánto peso le daría a la lectura del disco y cuánto a las operaciones en memoria?

— John Alan

Acabo de encontrar una presentación de diapositivas relevante de SQLBits 2013 por Thomas Kejser: slideshare.net/fusionio/…

— John Alan

Puedo agregar algunas palabras de mi entorno de Data Warehouse.

¡La implementación de la compresión (PÁGINA en mi caso) en una mesa de prueba con 30 millones de filas (18GB) reduce el tamaño de la mesa de 18GB a 3GB! (eficiencia de almacenamiento seguro) pero aumente el tiempo de carga (escritura) de 22 a 36 minutos.

Por lo tanto, para leer o leer y colocar los datos en la memoria, podría ser una buena solución, pero para la carga diaria de datos podría causar una disminución del rendimiento.

— Tomasz Wieczorkowski
fuente