I dati recuperati da SQL Server sono compressi per la trasmissione?

I dati recuperati da Microsoft SQL Server sono compressi? Se questo è controllato dalla stringa di connessione, c'è un modo semplice per sapere se una particolare app lo sta usando?

Sto esaminando gli strumenti di analisi e il volume dei dati può richiedere alcuni minuti per la trasmissione sulla nostra rete. Mi chiedo se dovrei aspettarmi un aumento delle prestazioni se estraiamo i dati da un archivio di dati compressi sullo stesso server remoto.

Finché siamo sull'argomento, sono curioso: i dati vengono trasmessi in binario o ASCII? Ad esempio, se il valore 12345viene richiesto da una INTcolonna, viene trasmesso come cinque byte 0x31, 0x32, 0x33, 0x34, 0x35; i due byte richiesti per il valore; o quattro byte come richiesto per la colonna?

Per essere chiari, capisco che ci sono opzioni relative alla memorizzazione dei dati con compressione e al loro backup. Sto chiedendo come vengono trasmessi i dati.

I dati che stai cercando di comprimere sono quelli inviati via cavo tramite TDS . C'è una compressione minore qui, ma in nessun posto vicino al tipo di compressione che si ottiene con la compressione di pagine / righe, compressione di backup o compressione ColumnStore.

È stato richiesto prima:

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

Gli oggetti sono ancora aperti, quindi forse c'è qualche speranza. Non c'è modo di controllarlo tramite la stringa di connessione che io abbia mai visto.

Nel frattempo ci sono alcuni prodotti che affermano di farlo, ad es

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

http://toonel.net/tcpany.htm

Puoi anche potenzialmente configurare la rete tra il tuo SQL Server e i server delle applicazioni per supportare la compressione (e altre cose come la crittografia) ma qui sei al di fuori del mio ambito di applicazione, e non sono sicuro che questo sarebbe supportato da ogni singola funzionalità di SQL Server.

E ad essere sincero, non sono convinto che questo sia il posto in cui vuoi concentrarti sull'ottimizzazione. La compressione di questo flusso potrebbe effettivamente rallentare le cose e superare i vantaggi dell'invio di meno byte. Preferirei spendere i soldi per una migliore connettività di rete tra server e client piuttosto che spendere tempo investendo in questo tipo di lavoro e testando se ha benefici effettivi - e non potendo farlo fino a dopo. Dal 10/100 al gig la fibra ha un impatto noto e prevedibile sull'I / O di rete.

Non sono sicuro del formato dei byte inviati tramite il filo; dovrete impostare una sorta di sniffer di pacchetti per quello (o forse qualcuno lo ha già fatto e si farà avanti).

Per quanto riguarda l'impatto della compressione, a meno che non si utilizzi Fusion-IO o altre soluzioni di tipo SSD di fascia alta, quasi sicuramente si è attualmente collegati in I / O e non in CPU. Quindi, fintanto che hai un sovraccarico della CPU, dovresti vedere prestazioni più veloci con la compressione abilitata (ma questo non cambierà le prestazioni della rete , poiché i dati non sono compressi prima della trasmissione). Dico che non sapendo nulla dei tuoi server, della tua applicazione, dei tuoi dati o dei tuoi schemi di utilizzo, potresti benissimo avere un caso limite in cui la compressione danneggia effettivamente le prestazioni o dove i dati non sono un buon candidato per buoni rapporti di compressione.

I dati recuperati da Microsoft SQL Server sono compressi? Se questo è controllato dalla stringa di connessione, c'è un modo semplice per sapere se una particolare app lo sta usando?

Tecnicamente, i risultati possono essere compressi leggermente .

Tabular Data Stream (TDS) 7.3B — inizialmente supportato da SQL Server 2008 R2 — ha introdotto qualcosa chiamato compressione bitmap null che consente di trasmettere righe contenenti più null utilizzando meno byte di quelli normalmente richiesti dai valori di campo null.

Il server può mescolare righe regolari con righe compresse bitmap nulle a sua scelta mentre invia risultati. Il client non ha alcun controllo su questo, quindi non sono disponibili opzioni di configurazione sul lato client.

La bitmap nulla è l'unica forma di compressione attualmente supportata da TDS. Se una riga non è compressa bitmap nulla, viene inviata non compressa.

Finché siamo sull'argomento, sono curioso: i dati vengono trasmessi in binario o ASCII?

Le colonne con tipi di dati non testuali vengono trasmesse utilizzando un formato binario definito dal protocollo TDS .

Come menzionato altrove , per ovviare a questo problema potresti prendere in considerazione la configurazione di una VPN e l'abilitazione della compressione.

Come altri hanno già detto, non esiste alcuna compressione integrata nel protocollo TDS di SQL Server. Vale anche la pena dire che per impostazione predefinita non esiste nemmeno la crittografia. Per abilitare la crittografia è necessario utilizzare i certificati e specificarli nelle stringhe di connessione.

La soluzione più semplice per risolvere entrambi i problemi è aprire un tunnel VPN con crittografia e compressione abilitate. Microsoft PPTP semplice risolve entrambi i problemi ed è facile da configurare.

Perché non configurare un'istanza SQL locale che memorizza nella cache i dati rilevanti e si sincronizza ogni n ore? Un'altra cosa da guardare è pre-calcolare i cubi e avere un pulsante 'ottieni dettagli' quando raggiungi una cella di riepilogo. Ciò recupererebbe quindi solo le righe dettagliate pertinenti.