Czy dane są pobierane z SQL Server kompresowane do transmisji?

Czy dane są pobierane z Microsoft SQL Server skompresowane? Jeśli jest to kontrolowane przez parametry połączenia, czy jest jakiś prosty sposób na stwierdzenie, czy używa go jakaś konkretna aplikacja?

Badam narzędzia analityczne, a przesyłanie danych przez sieć może zająć kilka minut. Zastanawiam się, czy powinienem oczekiwać wzrostu wydajności, jeśli ściągniemy dane ze skompresowanego magazynu danych na tym samym zdalnym serwerze.

Tak długo, jak zajmujemy się tym tematem, jestem ciekawy: czy dane są przesyłane w formacie binarnym czy ASCII? Na przykład, jeśli wartość 12345jest odpytywana z INTkolumny, czy jest przesyłana jako pięć bajtów 0x31, 0x32, 0x33, 0x34, 0x35; dwa bajty wymagane dla wartości; lub cztery bajty wymagane dla kolumny?

Dla jasności rozumiem, że istnieją opcje dotyczące przechowywania danych z kompresją i tworzenia kopii zapasowej. Pytam o sposób przesyłania danych.

Dane, które chcesz skompresować, są przesyłane przewodowo przez TDS . Występuje tutaj niewielka kompresja, ale nigdzie w pobliżu rodzaju kompresji uzyskiwanej w przypadku kompresji strony / wiersza, kompresji kopii zapasowej lub kompresji ColumnStore.

Został on wcześniej zapytany:

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

Przedmioty są nadal otwarte, więc może jest jakaś nadzieja. Nie ma sposobu, aby to kontrolować za pomocą ciągu połączenia, który kiedykolwiek widziałem.

W międzyczasie istnieją produkty, które twierdzą, że to robią, np

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

http://toonel.net/tcpany.htm

Możesz także potencjalnie skonfigurować sieć między serwerem SQL Server a serwerami aplikacji, aby obsługiwała kompresję (i inne rzeczy, takie jak szyfrowanie), ale jesteś poza moim zakresem, a nie jestem pewien, czy byłoby to obsługiwane przez każdą funkcję SQL Serwer.

I szczerze mówiąc, nie jestem przekonany, że to miejsce, na którym chcesz się skupić na optymalizacji. Kompresowanie tego strumienia może faktycznie spowolnić proces i przeważyć korzyści wynikające z wysłania mniejszej liczby bajtów. Wolę poświęcić pieniądze na lepszą łączność sieciową między serwerem a klientem (klientami) niż poświęcać czas na inwestowanie w tego rodzaju pracę i testowanie, czy przynosi to jakieś rzeczywiste korzyści - i nie będę w stanie tego zrobić do tego czasu. Od 10/100 do gigabajtów światłowód ma znany i przewidywalny wpływ na sieciowe operacje we / wy.

Nie jestem pewien formatu bajtów przesyłanych przewodowo; będziesz musiał skonfigurować do tego jakiś rodzaj sniffera pakietów (a może ktoś już to zrobił i włączy się).

Jeśli chodzi o wpływ kompresji, o ile nie korzystasz z Fusion-IO lub innych zaawansowanych rozwiązań typu SSD, prawie na pewno jesteś obecnie związany I / O, a nie procesorem. Tak długo, jak masz narzut procesora, powinieneś widzieć większą wydajność z włączoną kompresją (ale to nie zmieni wydajności sieci , ponieważ dane są nieskompresowane przed transmisją). Mówię, że nie wiedząc nic o twoich serwerach, aplikacji, danych lub wzorcach użytkowania - możesz mieć bardzo dobry przypadek, w którym kompresja faktycznie szkodzi wydajności lub gdzie dane po prostu nie są dobrym kandydatem na dobre współczynniki kompresji.

Czy dane są pobierane z Microsoft SQL Server skompresowane? Jeśli jest to kontrolowane przez parametry połączenia, czy jest jakiś prosty sposób na stwierdzenie, czy używa go jakaś konkretna aplikacja?

Technicznie wyniki można bardzo nieznacznie skompresować .

Tabelaryczny strumień danych (TDS) 7.3B - po raz pierwszy obsługiwany przez SQL Server 2008 R2 - wprowadził coś, co nazywa się kompresją bitmapy zerowej, która pozwala na przesyłanie wierszy zawierających wiele wartości zerowych przy użyciu mniejszej liczby bajtów niż zwykle wymagane przez wartości pola zerowego.

Serwer może mieszać zwykłe wiersze z wierszami skompresowanymi o pustej mapie bitowej według własnego wyboru, gdy wysyła wyniki. Klient nie ma nad tym kontroli, więc nie są dostępne odpowiednie opcje konfiguracji po stronie klienta.

Bitmapa zerowa jest jedyną formą kompresji obsługiwaną obecnie przez TDS. Jeśli wiersz nie jest skompresowany z zerową bitmapą, jest wysyłany bez kompresji.

Tak długo, jak zajmujemy się tym tematem, jestem ciekawy: czy dane są przesyłane w formacie binarnym czy ASCII?

Kolumny z nietekstowymi typami danych są przesyłane w formacie binarnym określonym przez protokół TDS .

Jak wspomniano w innym miejscu , w celu obejścia tego problemu można rozważyć skonfigurowanie sieci VPN i włączenie kompresji.

Jak powiedzieli inni, nie ma wbudowanej kompresji w SQL Server TDS Protocol. Warto również powiedzieć, że domyślnie nie ma też szyfrowania. Aby włączyć szyfrowanie, musisz użyć certyfikatów i określić je w ciągach połączeń.

Najłatwiejszym rozwiązaniem obu problemów jest otwarcie tunelu VPN z włączonym szyfrowaniem i kompresją. Prosty Microsoft PPTP rozwiązuje oba problemy i jest łatwy w konfiguracji.

Dlaczego nie skonfigurować lokalnej instancji SQL, która buforuje odpowiednie dane i synchronizuje co n godzin? Inną rzeczą, na którą warto spojrzeć, jest obliczenie kostek i posiadanie przycisku „zobacz szczegóły” po dotarciu do komórki podsumowania. Spowoduje to pobranie tylko odpowiednich szczegółowych wierszy.