Część literatury na temat kompresji danych SQL Server, którą czytam, stwierdza, że koszt zapisu wzrasta około czterokrotnie, co byłoby normalnie wymagane. Wydaje się również sugerować, że jest to główny minus kompresji danych, silnie sugerując, że w przypadku bazy danych archiwum tylko do odczytu wydajność (z kilkoma wyjątkami) poprawi się dzięki kompresji danych w 100% wypełnionych stronach.
- Czy powyższe stwierdzenia są prawdziwe?
Jakie są podstawowe „różnice” między kompresją danych a innymi metodami (do odczytu)
- „CPU + x%”?
- „IO -y%”?
- wystąpienie podziału strony?
- użycie tempdb?
- Wykorzystanie pamięci RAM?
- A do pisania?
Na potrzeby tego pytania możesz ograniczyć kontekst do kompresji na poziomie PAGE dużej bazy danych (> 1 TB) , ale dodatkowe komentarze są zawsze mile widziane.
Bibliografia:
Blog SQL Server Storage Engine (scenariusz DW pokazuje, że kompresja jest bardzo korzystna)
Kompresja danych: strategia, planowanie pojemności i najlepsze praktyki
Bardziej szczegółowe podejście do decyzji o tym, co należy skompresować, obejmuje analizę charakterystyki obciążenia dla każdej tabeli i indeksu. Opiera się na następujących dwóch metrykach:
U: Procent operacji aktualizacji na określonej tabeli, indeksie lub partycji w stosunku do łącznej liczby operacji na tym obiekcie. Im niższa wartość U (to znaczy tabela, indeks lub partycja jest rzadko aktualizowana), tym lepszy jest kandydat do kompresji strony.
S: Procent operacji skanowania tabeli, indeksu lub partycji w stosunku do łącznej liczby operacji na tym obiekcie. Im wyższa wartość S (tzn. Najczęściej skanowana jest tabela, indeks lub partycja), tym lepszy jest kandydat do kompresji strony.
Oba powyższe są wyraźnie tendencyjne do zalecania kompresji stron dla baz danych w stylu DW (operacje wymagające intensywnego odczytu / wyłączne, operacje na dużych danych).
Odpowiedzi:
Tylko moje 2 centy z własnych eksperymentów na 1-2-letnim sprzęcie:
Operacje tylko do odczytu (skanowanie w stylu DW, sortowanie itp.) W tabelach skompresowanych na stronie (~ 80 rzędów / strona) Stwierdziłem, że osiągają próg rentowności przy zmniejszeniu wielkości kompresji ~ 3x.
To znaczy, jeśli tabele i tak mieszczą się w pamięci, kompresja strony wpływa na wydajność tylko wtedy, gdy rozmiar danych zmniejszył się ponad 3-krotnie. Skanujesz mniej stron w pamięci, ale skanowanie każdej strony trwa dłużej.
Myślę, że twój przebieg może się różnić, jeśli twoje plany są zagnieżdżone i ciężkie do poszukiwania. Byłoby to między innymi zależne od sprzętu (kary za dostęp do obcego węzła NUMA, szybkość pamięci itp.).
Powyższe jest tylko ogólną zasadą, którą stosuję, opartą na własnych testach z wykorzystaniem własnych zapytań na własnym sprzęcie (Dell Poweredge 910 i nowsze). To nie jest ewangelia!
Edycja: Wczoraj doskonała prezentacja Thomasa Kejsera w SQLBits XI została udostępniona jako wideo. Dość istotne w tej dyskusji, pokazuje „brzydką” stronę obliczeniową procesora do kompresji stron - aktualizacje spowolnione 4x, blokady utrzymywane przez nieco dłuższy czas.
Jednak Thomas używa pamięci FusionIO i wybrał tabelę, która „tylko” kwalifikuje się do kompresji strony. Jeśli pamięć była przechowywana w typowej sieci SAN, a użyte dane były skompresowane 3x-4x, wówczas obraz mógłby być mniej dramatyczny.
źródło
Mogę dodać kilka słów ze środowiska Data Warehouse.
Implementacja kompresji (w moim przypadku PAGE) na stole testowym z 30 milionami wierszy (18 GB) zmniejsza rozmiar stołu z 18 GB do 3 GB! (wydajność przechowywania na pewno), ale zwiększ czas ładowania (zapisu) z 22 do 36 minut.
W przypadku odczytu lub odczytu i umieszczenia danych w pamięci może to być dobre rozwiązanie, ale w przypadku codziennego ładowania danych może to spowodować obniżenie wydajności.
źródło