Potop Danych: Dlaczego Bazy Danych Muszą się Kurczyć

W nowoczesnej gospodarce cyfrowej dane to nowa ropa naftowa. Od każdego zakupu online i posta w mediach społecznościowych po badania naukowe i transakcje finansowe, generujemy dane w bezprecedensowym tempie. Ta eksplozja informacji musi być gdzieś przechowywana, a głównym narzędziem do zarządzania tymi ustrukturyzowanymi danymi jest baza danych.

Można myśleć o bazie danych jak o wysoce zorganizowanej, inteligentnej cyfrowej szafie na akta. Ona nie tylko przechowuje dane; pozwala na ich szybkie wyszukiwanie, modyfikację i analizę. Jednak w miarę jak te cyfrowe szafy rosną z megabajtów do gigabajtów, terabajtów, a nawet petabajtów, zaczynają napotykać poważne wyzwania:

• Rosnące Koszty Przechowywania: Każdy bajt danych musi być przechowywany na fizycznym sprzęcie, takim jak dyski twarde (HDD) lub dyski SSD. Dla dużych przedsiębiorstw lub dostawców usług chmurowych koszt zakupu, zasilania i chłodzenia tysięcy dysków może stać się poważnym wydatkiem operacyjnym.
• Wąskie Gardła Wydajności: Kiedy wykonujesz zapytanie do bazy danych, system musi odczytać odpowiednie dane z dysku do pamięci (RAM). Szybkość tej operacji odczytu z dysku, znana jako wąskie gardło I/O, jest często największym pojedynczym czynnikiem ograniczającym wydajność bazy danych. Większe bazy danych oznaczają więcej danych do odczytania z wolnego dysku, co prowadzi do wolniejszych odpowiedzi na zapytania.
• Wolne Kopie Zapasowe i Konserwacja: Tworzenie kopii zapasowych i przeprowadzanie operacji konserwacyjnych na wieloterabajtowej bazie danych może trwać wiele godzin, podczas których wydajność może być obniżona lub system może być niedostępny.

Rozwiązaniem tych problemów jest kompresja bazy danych. Używając zaawansowanych algorytmów do reprezentowania tych samych informacji w bardziej zwartej formie, systemy baz danych mogą znacznie zmniejszyć swoją powierzchnię dyskową, co często prowadzi do radykalnej poprawy szybkości działania.

Paradoksalna Korzyść: Lepsza Wydajność Dzięki Kompresji

Na pierwszy rzut oka mogłoby się wydawać, że kompresja danych spowolni działanie bazy danych. W końcu procesor (CPU) bazy danych ma teraz dodatkową pracę do wykonania: musi dekompresować dane za każdym razem, gdy są one odczytywane z dysku, zanim będzie można ich użyć. Jest to tak zwany narzut procesora związany z kompresją. Jak więc dodanie dodatkowej pracy może przyspieszyć działanie?

Odpowiedź leży w ogromnej różnicy prędkości między nowoczesnymi procesorami a urządzeniami pamięci masowej. Proces odczytu danych z dysku (operacja I/O) jest o rzędy wielkości wolniejszy niż wykonywanie obliczeń przez procesor. Nowoczesny procesor może wykonać miliardy instrukcji w czasie potrzebnym do odczytania jednego bloku danych z szybkiego dysku SSD, nie wspominając o wolniejszym, wirującym dysku twardym.

Kompresja bazy danych genialnie wykorzystuje tę nierównowagę. Poprzez kompresję danych, ilość informacji, która musi być fizycznie odczytana z wolnego dysku, jest drastycznie zmniejszona. Na przykład, jeśli zapytanie musiało odczytać 100 megabajtów nieskompresowanych danych, ale te dane są skompresowane w stosunku 4:1, baza danych musi teraz odczytać tylko 25 megabajtów. Czas zaoszczędzony na odczytaniu o 75% mniej danych z dysku jest często znacznie, znacznie większy niż niewielka ilość czasu, którą procesor poświęca na dekompresję tych 25 MB z powrotem do oryginalnych 100 MB w szybkiej pamięci.

Fundament: Przechowywanie Wierszowe kontra Kolumnowe

Aby zrozumieć, jak działają różne techniki kompresji baz danych, niezbędne jest najpierw zrozumienie dwóch głównych sposobów, w jakie baza danych może fizycznie przechowywać swoje dane na dysku: wiersz po wierszu lub kolumna po kolumnie. Ten wybór architektoniczny ma głęboki wpływ na to, jaki rodzaj kompresji będzie najskuteczniejszy.

Bazy Danych Zorientowane na Wiersze (Row Stores)

Jest to tradycyjna i wciąż najczęstsza architektura baz danych. W magazynie wierszowym wszystkie dane dla jednego rekordu, czyli wiersza, są przechowywane razem, w sposób ciągły na dysku. Rozważmy prostą tabelę pracowników:

Baza danych zorientowana na wiersze zapisałaby te dane na dysku w następujący sposób:[1, Jan, Kowalski, Sprzedaż], [2, Anna, Nowak, Marketing], ...

Najlepsze dla: Ta architektura jest zoptymalizowana pod kątem Przetwarzania Transakcji Online (OLTP). Gdy potrzebujesz pobrać, wstawić lub zaktualizować cały rekord na raz (np. "Pokaż wszystkie informacje o pracowniku Janie Kowalskim"), magazyn wierszowy jest bardzo wydajny, ponieważ wszystkie istotne dane znajdują się fizycznie razem i mogą być odczytane w jednej operacji I/O.

Bazy Danych Zorientowane na Kolumny (Column Stores)

Nowocześniejsza architektura, popularna w hurtowniach danych i analityce. W magazynie kolumnowym wszystkie dane z jednej kolumny są przechowywane razem, w sposób ciągły. Używając tej samej tabeli pracowników, baza danych zorientowana na kolumny zapisałaby dane w ten sposób:

Najlepsze dla: Ta architektura jest zoptymalizowana pod kątem Analitycznego Przetwarzania Online (OLAP). Gdy musisz przeprowadzić agregację lub analizę na kilku kolumnach obejmujących miliony wierszy (np. "Oblicz średnią pensję dla wszystkich pracowników w dziale Sprzedaży"), magazyn kolumnowy jest niewiarygodnie szybki. Musi odczytać dane tylko z kolumn 'Dział' i 'Pensja', całkowicie ignorując dane w kolumnach 'ID', 'Imię' i 'Nazwisko', co radykalnie zmniejsza ilość operacji I/O.

Ten kolumnowy układ przechowywania danych jest również rajem dla kompresji. Dane w obrębie jednej kolumny są zazwyczaj tego samego typu i często bardzo powtarzalne, co czyni je znacznie łatwiejszymi do skompresowania niż heterogeniczne dane znajdujące się w wierszu.

Techniki Kompresji w Bazach Danych Zorientowanych na Wiersze

Ponieważ magazyny wierszowe grupują różne typy danych w ramach każdego rekordu, ich strategie kompresji są często bardziej ogólnego przeznaczenia.

Kompresja na Poziomie Strony

Jest to najczęstsza forma kompresji w systemach OLTP. Bazy danych nie odczytują i nie zapisują pojedynczych wierszy na dysku; pracują z większymi porcjami danych zwanymi stronami danych. Kompresja na poziomie strony działa, biorąc całą stronę, wypełnioną wieloma wierszami, i kompresując ją w całości tuż przed zapisaniem na dysku. Gdy strona jest ponownie potrzebna, jest odczytywana z dysku w formie skompresowanej, a następnie dekompresowana w pamięci.

Używane algorytmy są zazwyczaj standardowe, szybkie i ogólnego przeznaczenia, takie jak zlib (oparty na DEFLATE) lub LZ4, które są bardzo skuteczne w znajdowaniu i zastępowaniu powtarzających się sekwencji bajtów na stronie danych.

Inne Techniki Wierszowe

• Kompresja Specyficzna dla Typu Danych: Bazy danych mogą wykorzystywać wiedzę na temat typów danych. Na przykład, liczby całkowite i daty mogą być przechowywane przy użyciu mniejszej liczby bajtów niż ich domyślna alokacja, jeśli ich zakres wartości jest mały.
• Kompresja Prefiksów: W przypadku indeksowanych kolumn tekstowych, jeśli wiele kolejnych wpisów ma wspólny prefiks (np. adresy URL zaczynające się od $https://www.przyklad.pl/$), baza danych może zapisać prefiks raz, a następnie tylko różniące się sufiksy dla kolejnych wpisów.

Techniki Kompresji w Bazach Danych Zorientowanych na Kolumny

Bazy danych kolumnowe mogą osiągać znacznie wyższe współczynniki kompresji, ponieważ mogą stosować specyficzne, wysoce skuteczne algorytmy do jednolitych danych w każdej kolumnie.

Kodowanie Słownikowe

To jedna z najskuteczniejszych technik. Jest idealna dla kolumn o niskiej kardynalności, co oznacza niewielką liczbę unikalnych wartości. Baza danych buduje słownik, który mapuje każdą unikalną wartość w kolumnie na mały kod całkowitoliczbowy. Zamiast przechowywać pełną, potencjalnie długą wartość tekstową (np. "Stany Zjednoczone Ameryki") dla każdego wiersza, przechowuje tylko zwarty kod całkowitoliczbowy. Sam słownik jest przechowywany tylko raz. Oszczędność miejsca może być ogromna.

Kodowanie Długości Serii (RLE)

RLE jest genialne do kompresji posortowanych danych. Zastępuje ono ciągłą sekwencję identycznych wartości pojedynczą parą: wartością i liczbą jej powtórzeń. Na przykład, zamiast przechowywać `[Sprzedaż, Sprzedaż, Sprzedaż, Sprzedaż, IT, IT]`, RLE zapisałoby `[(Sprzedaż, 4), (IT, 2)]`. Gdy dane w bazie danych kolumnowej są posortowane (np. według daty), RLE staje się niezwykle potężne.

Kodowanie Delta

Używane jest dla kolumn z liczbami, które zmieniają się powoli lub w przewidywalny sposób, jak kolejne numery ID, znaczniki czasu czy odczyty z czujników. Zamiast przechowywać pełną wartość dla każdego wpisu, baza danych przechowuje wartość bazową, a następnie małe różnice (delty) od poprzedniej wartości. Na przykład sekwencja $1005, 1006, 1007$ mogłaby być przechowywana jako $1005, +1, +1$. Te małe wartości delt można następnie bardzo wydajnie skompresować przy użyciu innej techniki.

Pakowanie Bitów

Standardowe typy danych często marnują miejsce. Na przykład typ 64-bitowej liczby całkowitej jest używany nawet wtedy, gdy liczby w kolumnie nigdy nie przekroczą 100. Pakowanie bitów przechowuje każdą liczbę, używając tylko minimalnej wymaganej liczby bitów. Technika ta jest często łączona z innymi; na przykład małe kody całkowitoliczbowe z kodowania słownikowego lub małe delty z kodowania delta można wydajnie przechowywać przy użyciu pakowania bitów.

Łącząc te wyspecjalizowane algorytmy, bazy danych kolumnowe mogą osiągać współczynniki kompresji 10:1 lub nawet wyższe, co czyni je wyjątkowo dobrze przystosowanymi do analizy danych na dużą skalę i hurtowni danych.