¿Los datos recuperados de SQL Server están comprimidos para su transmisión?

¿Se comprimen los datos recuperados de Microsoft SQL Server? Si esto está controlado por la cadena de conexión, ¿hay alguna forma simple de saber si alguna aplicación en particular la está usando?

Estoy examinando las herramientas de análisis, y el volumen de datos puede tardar minutos en transmitirse a través de nuestra red. Me pregunto si debería esperar un aumento del rendimiento si extraemos datos de un almacén de datos comprimido en el mismo servidor remoto.

Mientras estemos en el tema, tengo curiosidad: ¿los datos se transmiten en binario o ASCII? Por ejemplo, si el valor 12345se consulta desde una INTcolumna, ¿se transmite como los cinco bytes 0x31, 0x32, 0x33, 0x34, 0x35; los dos bytes necesarios para el valor; o cuatro bytes según lo requerido para la columna?

Para ser claros, entiendo que hay opciones con respecto al almacenamiento de datos con compresión y la copia de seguridad. Estoy preguntando cómo se transmiten los datos.

Los datos que desea comprimir son los que se envían por cable a través de TDS . Aquí hay alguna compresión menor, pero no se acerca al tipo de compresión que obtienes con la compresión de página / fila, compresión de respaldo o compresión ColumnStore.

Se ha pedido antes:

http://connect.microsoft.com/SQLServer/feedback/details/412131/enable-network-compression-compress-tds-stream

http://connect.microsoft.com/SQLServer/feedback/details/377479/wan-compression-option

Los artículos aún están abiertos, por lo que quizás haya algo de esperanza. No hay forma de controlar esto a través de la cadena de conexión que he visto.

Mientras tanto, hay algunos productos que dicen hacer esto, por ejemplo

http://www.nitrosphere.com/products/nitroaccelerator/

http://toonel.net/tcpany.htm

También puede configurar potencialmente la red entre su SQL Server y los servidores de aplicaciones para admitir la compresión (y otras cosas como el cifrado) pero está más allá de mi alcance aquí, y no estoy seguro de si esto sería compatible con todas las características de SQL Servidor.

Y para ser honesto, no estoy convencido de que este sea el lugar en el que desea centrarse en la optimización. La compresión de esta secuencia en realidad podría ralentizar las cosas y superar los beneficios de enviar menos bytes. Prefiero gastar el dinero en una mejor conectividad de red entre el servidor y el cliente que gastar tiempo invirtiendo en este tipo de trabajo y probar si tiene algún beneficio real, y no poder hacerlo hasta después. Desde 10/100 hasta la fibra óptica tiene un impacto conocido y predecible en la red de E / S.

No estoy seguro sobre el formato de los bytes enviados a través del cable; tendrá que configurar algún tipo de sniffer de paquetes para eso (o tal vez alguien ya lo haya hecho y vaya a intervenir).

En cuanto al impacto de la compresión, a menos que esté utilizando Fusion-IO u otras soluciones de tipo SSD de gama alta, es casi seguro que esté vinculado a E / S actualmente y no a CPU. Por lo tanto, siempre que tenga una sobrecarga de la CPU, debería ver un rendimiento más rápido con la compresión habilitada (pero esto no cambiará el rendimiento de la red , ya que los datos se descomprimen antes de la transmisión). Digo que sin saber nada sobre sus servidores, su aplicación, sus datos o sus patrones de uso, podría tener un caso extremo en el que la compresión realmente perjudica el rendimiento, o donde los datos simplemente no son un buen candidato para buenas relaciones de compresión.

¿Se comprimen los datos recuperados de Microsoft SQL Server? Si esto está controlado por la cadena de conexión, ¿hay alguna forma simple de saber si alguna aplicación en particular la está usando?

Técnicamente, los resultados se pueden comprimir muy ligeramente .

El flujo de datos tabulares (TDS) 7.3B, admitido por primera vez por SQL Server 2008 R2, introdujo algo llamado compresión de mapa de bits nulo que permite transmitir filas que contienen múltiples valores nulos utilizando menos bytes de los que normalmente requieren los valores de campo nulo.

El servidor puede mezclar filas regulares con filas comprimidas de mapa de bits nulo a su elección mientras envía resultados. El cliente no tiene control sobre esto, por lo que no hay disponibles opciones de configuración relevantes del lado del cliente.

El mapa de bits nulo es la única forma de compresión actualmente admitida por TDS. Si una fila no está comprimida en un mapa de bits nulo, se envía sin comprimir.

Mientras estemos en el tema, tengo curiosidad: ¿los datos se transmiten en binario o ASCII?

Las columnas con tipos de datos sin texto se transmiten utilizando un formato binario definido por el protocolo TDS .

Como se mencionó en otra parte , para solucionar este problema, podría considerar configurar una VPN y habilitar la compresión.

Como otros han dicho, no hay compresión integrada en el protocolo TDS de SQL Server. También vale la pena decir que, por defecto, tampoco hay cifrado. Para habilitar el cifrado, debe usar certificados y especificarlo en las cadenas de conexión.

La solución más fácil para resolver ambos problemas es abrir un túnel VPN con cifrado y compresión habilitados. Microsoft PPTP simple resuelve ambos problemas y es fácil de configurar.

¿Por qué no configurar una instancia de SQL local que almacena en caché los datos relevantes y se sincroniza cada n horas? Otra cosa a tener en cuenta es calcular previamente los cubos y tener un botón 'obtener detalles' cuando llegue a una celda de resumen. Eso luego buscaría solo las filas detalladas relevantes.