pobierz plik referatu - BDAS

Transkrypt

Rozdział monografii: 'Bazy Danych: Rozwój metod i technologii', Kozielski S., Małysiak B., Kasprowski P., Mrozek D. (red.), WKŁ 2008
Rozdział 4
w
Przegląd technik kompresji map bitowych dla
zastosowań w hurtowniach danych
w
da
.b
w
Streszczenie. Indeksy bitmapowe stanowią jeden z głównych rodzajów indeksów stosowanych w optymalizacji zapytań analitycznych w hurtowniach
danych. W najprostszym podejściu, indeks bitmapowy jest zbiorem tzw. map
bitowych. Mapa bitowa jest wektorem bitów i jest tworzona dla każdej wartości indeksowanego atrybutu. Mapa taka opisuje rekordy posiadające określoną wartość indeksowanego atrybutu. Do zalet indeksów bitmapowych zalicza się: (1) dużą efektywność wyszukiwania danych z równościowymi warunkami selekcji i (2) ich mały rozmiar dla indeksowanych atrybutów o wąskich dziedzinach. Natomiast, dla indeksowanych atrybutów o szerokich dziedzinach indeksy bitmapowe osiągają ogromne rozmiary i w konsekwencji
oferują gorszą efektowność. Z tego względu, w praktyce stosuje się różne
techniki kompresji indeksów bitmapowych. W niniejszym artykule zostaną
omówione różne techniki kompresji, m.in. gzip, BBC, WAH i RLH.
1 Wprowadzenie
pl
s.
Hurtownie danych (HD) (ang. data warehouses) są niezastąpionym komponentem systemów wspomagających zarządzanie i podejmowanie decyzji w instytucjach i przedsiębiorstwach. Wyróżnia się dwa podstawowe cele stosowania HD. Po pierwsze, zapewnienie
integracji danych pochodzących z wielu autonomicznych, heterogenicznych i rozproszonych źródeł danych. Po drugie, dostarczenie platformy tzw. przetwarzania analitycznego –
OLAP (ang. On-Line Analytical Processing), które umożliwia wykonywanie zaawansowanych analiz danych. Wyniki tych analiz stanowią podstawę podejmowania decyzji zarządczych w instytucjach i przedsiębiorstwach.
Jednym z głównych problemów technologicznych w hurtowniach danych jest optymalizacja zapytań analitycznych. Zapytania analityczne odczytują ogromne wolumeny danych.
Typową klasą zapytań analitycznych są tzw. zapytania gwiaździste (ang. star queries), które
łączą wiele tabel wymiarów z tabelą faktów, filtrują dane poprzez nałożenie warunków selekcji zarówno na atrybuty tabel faktów jak i wymiarów, oraz agregują dane. Dla zapytań
Jan Chmiel, Michał Stabno
QXL Poland Sp. z. o. o., Ul. Marcelińska 90, 60-324, Poznań,
Politechnika Poznańska, Instytut Informatyki, Ul. Piotrowo 2, 60-965 Poznań
email:{Jan.Chmiel, Michal.Stabno}@allegro.pl
Robert Wrembel
Politechnika Poznańska, Instytut Informatyki, Ul. Piotrowo 2, 60-965 Poznań
email: [email protected]
(c) Copyright by Politechnika Śląska, Instytut Informatyki, Gliwice 2008
J. Chmiel, M. Stabno, R. Wrembel
w
o takiej charakterystyce, standardowe indeksy w postaci B-drzew okazują się nieefektywne,
ponieważ po pierwsze, nie zapewniają wystarczająco szybkiego dostępu do danych, po drugie, ich rozmiary są zbyt duże, przez co wzrastają koszty ich przetwarzania, przechowywania i utrzymywania. Z tego względu, w zastosowaniach hurtowni danych bardzo często stosuje się tzw. indeksy bitmapowe (ang. bitmap indexes).
Ich zaletą jest duża efektywność wyszukiwania danych dla kryteriów poszukiwania
z operatorem równościowym. Ponadto, dla indeksowanych atrybutów o wąskiej dziedzinie
rozmiary indeksów bitmapowych są znacznie mniejsze niż indeksów typu B-drzewo.
Główną wadą indeksów bitmapowych jest ich duży rozmiar (wielokrotnie większy niż Bdrzew) dla atrybutów o szerokich dziedzinach. W celu zmniejszenia rozmiarów indeksów
bitmapowych, w praktyce stosuje się ich kompresowanie.
Celem niniejszego rozdziału jest omówienie podstawowych technik kompresji wykorzystywanych w procesie kompresowania indeksów bitmapowych. W rozdziale omówiono następujące techniki kompresji: gzip, kompresję Huffmana, BBC, WAH, RLH, RLH-1024.
Struktura pracy jest następująca: w podrozdziale 2 przedstawiono podstawową koncepcję indeksu bitmapowego, w podrozdziale 3 omówiono techniki kompresji, w podrozdziale
4 porównano własności poszczególnych technik kompresji, a w podrozdziale 5 podsumowano pracę.
w
w
da
.b
2 Podstawowy indeks bitmapowy
pl
s.
Podstawowy indeks bitmapowy [7], [8] bazuje na tzw. mapach bitowych umożliwiających
znalezienie rekordów z zadaną wartością indeksowanego atrybutu. Mapa bitowa jest wektorem bitów. Każda wartość z dziedziny indeksowanego atrybutu posiada odrębną mapę.
Liczba bitów każdej mapy jest identyczna i odpowiada liczbie rekordów indeksowanej tabeli. Mapa bitowa utworzona dla wartości w indeksowanego atrybutu A opisuje te rekordy,
których wartością atrybutu A jest w. Bit o numerze n przyjmuje wartość 1 w mapie, jeśli
atrybut A rekordu o numerze n przyjmuje wartość w. W przeciwnym przypadku bit n przyjmuje wartość 0.
Jako przykład ilustrujący powyższą koncepcję indeksu bitmapowego rozważmy tabelę
Klienci, której fragment przedstawiono poniżej. Na atrybucie płeć zdefiniowano indeks bitmapowy, przedstawiony w Tabeli 1. Ponieważ dziedziną indeksowanego atrybutu płeć są
dwie wartości, tj. 'kobieta' i 'mężczyzna', więc indeks bitmapowy składa się z dwóch map
bitowych. Bit pierwszy mapy opisującej wartości 'kobieta' ma wartość 0, ponieważ wartością atrybutu płeć dla pierwszego rekordu nie jest 'kobieta', itp.
Indeksy bitmapowe posiadają znacznie mniejsze rozmiary od indeksów w postaci Bdrzewa dla atrybutów, które posiadają wąską dziedzinę (kilka do kilkudziesięciu różnych
wartości), dla tabel o dużej liczbie rekordów, np. miliony. Przykładowo, dla tabeli zawierającej milion rekordów i liczności dziedziny indeksowanego atrybutu równej 4 indeks bitmapowy będzie złożony z 4 map bitowych o długości miliona bitów każda. Rozmiar takiego indeksu będzie więc równy około 500 kB. Indeks B-drzewo utworzony na tym samym
atrybucie, przyjmując rozmiar wskaźnika do rekordu równy 10 B, będzie miał rozmiar 10
MB.
Indeksy bitmapowe sprawdzają się dla określonej klasy zapytań. Są to zapytania wykorzystujące dużą liczbę warunków selekcji z operatorami równości oraz zapytania wykorzystujące funkcję count. Większa efektywność tych indeksów wynika z: (1) dużej szybkości
przetwarzania map bitowych za pomocą operatorów and, or i not, (2) małego rozmiaru indeksów bitmapowych dla atrybutów o wąskiej dziedzinie, (3) możliwości wykonywania
52
Przegląd technik kompresji map bitowych dla zastosowań w hurtowniach danych
operacji logicznych i funkcji count bezpośrednio na indeksach bitmapowych (znajdujących
się w pamięci operacyjnej), a nie na samych rekordach.
Tabela 1. Przykładowa tabela Klienci i indeks bitmapowy na atrybucie płeć
w
da
.b
w
w
Główną wadą indeksów bitmapowych jest ich duży rozmiar dla atrybutów o szerokich dziedzinach. W konsekwencji efektywność przetwarzania takiego indeksu zmaleje. Przykładowo, dla tabeli zawierającej milion rekordów i liczności dziedziny indeksowanego atrybutu
równej 200 indeks bitmapowy będzie złożony z 200 map bitowych o długości miliona bitów każda. Rozmiar takiego indeksu będzie więc równy około 100 MB. Indeks B-drzewo
utworzony na tym samym atrybucie, będzie miał cały czas rozmiar 10 MB. Opisany tu problem w literaturze często nazywa się problemem rozmiaru.
3 Techniki kompresji
pl
s.
W praktyce, problem rozmiaru jest rozwiązywany poprzez użycie różnych technik kompresji map bitowych. Dotychczas w literaturze naukowo-technicznej zaproponowano wiele
efektywnych technik kompresji map bitowych, z których kilka wykorzystywanych jest
w produktach komercyjnych. Takie techniki zapewniają znaczący współczynnik kompresji.
Jednocześnie, przetwarzanie zapytań wykorzystujących skompresowane mapy bitowe może
się okazać bardziej czasochłonne niż z użyciem nieskompresowanych map bitowych. Ten
problem zainspirował opracowanie specjalizowanych schematów kompresji takich jak:
Byte-aligned Bitmap Code (BBC) [1] i Word-Aligned Hybrid (WAH) [12], [13], [14]. Specjalizowane schematy kompresji map bitowych zastępują tradycyjnie używane w hurtowniach danych techniki kompresji ogólnego przeznaczenia, np. GZIP [3]. We wspomnianych
technikach kompresji, algorytm kompresji jest stosowany do każdej z map bitowych niezależnie.
Efektywność korzystania ze skompresowanego indeksu bitmapowego jest mierzona sumą czasu dostępu do mapy bitowej na dysku i czasu przetwarzania mapy bitowej (dekompresja, operacje bitowe). Oznacza to, że dla hurtowni danych dobry współczynnik kompresji nie jest jedyną pożądaną własnością schematu kompresji map bitowych. Czas dekompresji staje się równie istotny.
53
w
Bardzo trudno jest optymalizować współczynnik kompresji i czas przetwarzania map
bitowych jednocześnie. W hurtowniach danych czas przetwarzania jest bardziej istotny, zatem wystarczy by schemat kompresji jedynie gwarantował, że całkowita wielkość skompresowanych map bitowych indeksu bitmapowego była mniejsza od wielkości struktur odpowiadającego temu przypadkowi indeksu B-drzewo. W przypadku, gdy ten warunek jest
spełniony, czas poświęcany na operacje dyskowe dla skompresowanego indeksu bitmapowego będzie mniejszy do czasu poświeconego na operacje dyskowe dla indeksu B-drzewo.
Dobrze znana i powszechnie stosowana kompresja GZIP oferuje tylko dobry współczynnik
kompresji. W przypadku kompresji BBC i WAH dobre czasy odpowiedzi na zapytania
uzyskiwane są kosztem dobrego współczynnika kompresji (w akceptowalnych granicach
wspomnianych wcześniej).
Jako alternatywę do kompresji BBC i WAH, opracowano w Instytucie Informatyki
Politechniki Poznańskiej, tzw. kompresję RLH (ang. Run-Length Huffman) [9], [10]. Podobnie jak BBC i WAH, kompresja RLH wykorzystuje kodowanie run-length w powiązaniu z algorytmem kodowania Huffmana [11]. W kompresji RLH zliczaniu podlegają odległości pomiędzy kolejnymi bitami o wartości jeden, a nie długości jednorodnych ciągów bitów o tej samej wartości. W kolejnych podrozdziałach zostaną scharakteryzowane
wspomniane wyżej techniki kompresji.
w
w
3.1 Algorytm Huffmana
da
.b
pl
s.
Kompresja Huffmana [11] to jedna z najprostszych i łatwiejszych w implementacji technik
kompresji bezstratnej. Algorytm kompresji nie należy do najefektywniejszych systemów
bezstratnej kompresji danych, dlatego też praktycznie nie używa się go samodzielnie.
Często wykorzystuje się go jako ostatni etap w różnych systemach kompresji, zarówno
bezstratnej jak i stratnej, np. MP3 lub JPEG. Pomimo, że nie jest on doskonały, stosuje się
go ze względu na prostotę oraz brak ograniczeń patentowych.
Sposób działania algorytmu jest stosunkowo prosty. W pierwszym kroku określamy
prawdopodobieństwo lub częstość występowania każdego symbolu ze zbioru danych podlegających kodowaniu. W drugim kroku tworzymy listę węzłów postaci: symbol – prawdopodobieństwo (częstość) jego występowania. W trzecim kroku budujemy tzw. drzewo kodów Huffmana. Usuwamy z listy dwa węzły o najmniejszym prawdopodobieństwie (częstości wystąpień) i wstawiamy węzeł, który staje się rodzicem dla tych dwóch węzłów
o wartości równej sumie prawdopodobieństw (częstości wystąpień) dwóch usuniętych węzłów. Nowy węzeł nie przechowuje symbolu. Operacje te powtarzamy do momentu, gdy na
liście pozostanie jeden węzeł. Wartość zapisana w korzeniu jest sumą prawdopodobieństw
(częstości) występowania wszystkich symboli w kompresowanym zbiorze danych.
W liściach drzewa znajdują się kodowane symbole.
Algorytm kompresji Huffmana nie określa sposobu wyboru węzłów z listy o tych samych prawdopodobieństwach (częstościach wystąpień), dlatego też jest algorytmem niedeterministycznym. Nieokreślone jest również, który z węzłów staje się lewym, a który prawym potomkiem. Nie ma to jednak znaczenia, gdyż długość kodu symbolu w liściu drzewa
kodów Huffmana nie zmienia się.
Sposób tworzenia kodów na podstawie drzewa kodów Huffmana jest równie prosty, co
budowa drzewa. Każdej lewej krawędzi w drzewie przyporządkowujemy wartość 0, a każdej prawej krawędzi wartość 1. Następnie przechodzimy w głąb drzewa zaczynając od korzenia aż do liścia zawierającego określony symbol. Przechodząc przez krawędź oznaczoną
0 dopisujemy do kodu wartość 0. Przechodząc przez krawędź oznaczoną 1 dopisujemy do
kodu wartość 1.
54
Działanie algorytmu Huffmana ilustruje przykład przedstawiony poniżej, w którym dokonamy kompresji następującego ciągu symboli:
AAABBABBCCDCAAA
Kolejne kroki algorytmu będą przebiegały następująco:
− Krok 1: Tworzymy listę symboli A, B, C, D wraz z ich częstościami wystąpień. Listę
częstości wystąpień sortujemy malejąco.
w
Tabela 2. Ilustracja działania algorytmu Huffmana: Krok 1
Lista częstości wystąpień
Symbol
Częstość wystąpień
w
A
7
B
4
C
3
D
1
da
.b
w
− Krok 2: Rozpoczynamy budowę drzewa kodów Huffmana. Każdy symbol i jego
częstość tworzą jeden z liści drzewa kodów Huffmana. Lista zawiera węzły, które
jeszcze nie zostały wykorzystane przy budowie drzewa. Z listy wybieramy dwa
symbole o najmniejszych częstościach wystąpień. W naszym przykładzie są to
symbole C i D. Usuwamy je z listy i dodajemy nowy symbol X1 o wartości częstości
wystąpień równej sumie częstości wystąpień węzłów C i D, czyli 4. Węzeł X1 pełni
rolę rodzica węzłów C i D.
Lista wystąpień
Symbol
A
7
B
4
X1
4
O
Drzewo kodów Huffmana
X1
1
D
C
pl
s.
Rys. 1. Ilustracja działania algorytmu Huffmana: Krok 2
− Krok 3: Usuwamy z listy węzły B i X1, a na ich miejsce wstawiamy do listy węzeł
X2 o wartości równej sumie częstości wystąpień zawartych w węzłach B i X1, czyli
8. Węzeł X2 pełni rolę rodzica dla węzłów B i X1.
Lista wystąpień
Symbol
X2
8
A
7
X2
O
O
D
X1
1
B
1
C
55
− Krok 4: Usuwamy z listy węzły A i X2, a na ich miejsce wstawiamy węzeł X3 o
wartości równej sumie częstości wystąpień węzłów A i X2, czyli 15. Węzeł X3 pełni
rolę rodzica węzłów A i X2 w drzewie kodów Huffmana. Ponieważ na liście
znajduje się tylko jeden węzeł, algorytm kończy pracę.
Lista wystąpień
Symbol
w
X3
15
X3
O
1
A
X2
w
O
X1
O
1
B
1
D
C
w
Częstość
występowania
symbolu
da
.b
W celu uzyskania kodów dla symboli przechodzimy poprzez drzewo od korzenia do liści:
− A: lewo: 0
− B: prawo→ prawo: 11
− C: prawo→ lewo→ prawo: 101
− D: prawo→ lewo→ lewo: 100
Średnią długość uzyskanych kodów symboli można obliczyć sumując iloczyny częstości
wystąpień symboli przez długość ich kodów i dzieląc sumę przez sumę częstości wystąpień
wszystkich symboli. W naszym przypadku średnia długość kodu symbolu wynosi:
( 7 * 1 + 4 * 2 + 3 * 3 + 1 * 3 ) / 15 = (7 + 8 + 9 + 3) / 15 =27 / 15 = 9 / 5 = 1.8 bitów
Liczba bitów
kodu symbolu
Suma częstości występowania
wszystkich symboli
pl
s.
W trywialnym kodowaniu symboli o stałej długości na jeden symbol potrzebujemy 2 bity.
Uzyskane kody symboli stanowią rozwiązanie optymalne, tzn. nie da się uzyskać innych
kodów symboli o zmiennej długości, dla których zakodowany ciąg danych byłby krótszy.
Po zakodowaniu, ciąg danych AAABBABBCCDCAAA ma postać binarną:
000111101111101101100101000. Wraz z zakodowanym ciągiem danych przechowujemy
listę wystąpień częstości symboli i same symbole. Posłużą one do odbudowy drzewa kodów Huffmana w momencie dokonywania dekompresji ciągu.
Dekompresja nie jest złożona obliczeniowo i przebiega strumieniowo. Czytamy zakodowany ciąg danych po jednym bicie. Zaczynając od korzenia drzewa kodów Huffmana i w
zależności od wartości odczytanego bitu, przechodzimy do lewego lub prawego potomka.
Kiedy wybrany wierzchołek drzewa jest liściem (nie posiada już żadnych potomków) zapisujemy symbol przechowywany w liściu do zdekodowanego ciągu danych i powracamy do
korzenia drzewa kodów Huffmana. Proces ten kontynuujemy do wyczerpania bitów ze strumienia bitów zakodowanego ciągu.
56
3.2 Kompresja GZIP
w
W celu zrozumienia działania schematów kompresji BBC i WAH konieczna jest znajomość
struktury typowego schematu kompresji ogólnego przeznaczenia. Jako przykład zostanie
użyty schemat kompresji GZIP. Algorytm ten bazuje na algorytmie DEFLATE [4], który
jest złożeniem algorytmu LZ77 [5] oraz algorytmu kodowania Huffmana [11].
Algorytm LZ77 należy do klasy tzw. koderów słownikowych (ang. dictionary coders).
Algorytm zamienia ciągi danych na referencje do pasujących ciągów danych, które
wystąpiły już wcześniej w strumieniu danych. Dopasowany ciąg danych jest kodowany
dwoma wartościami: długością pasującego ciągu danych, oraz przesunięciem pomiędzy
początkiem referowanego ciągu, a pasującego ciągu danych występującego wcześniej w nie
skompresowanym strumieniu danych. W celu poszukiwania pasujących ciągów danych
koder musi buforować część strumienia danych. Dekoder również utrzymuje fragment
strumienia danych w celu zinterpretowania referencji na wyniki znalezione przez koder.
Najważniejsze kroki algorytmu LZ77 ilustruje poniższy przykład:
w
Bufor kodera
11114526
14575
w
Bufor słownika
Nieodczytany strumień danych
5 2 6 3 2 5......
Rys. 4. Odczyt przykładowego strumienia danych przez LZ77
da
.b
3.3 Kompresja BBC
pl
s.
Przyjmijmy, że kompresji podlega ciąg symboli 1111452614575526325... Do bufora
słownika mamy już wczytany ciąg symboli: 11114526. Koder poszukuje w buforze słownika najdłuższego ciągu symboli zgodnego z prefiksem swojego buforu. W tym przypadku
taki warunek spełnia ciąg symboli 145. Jest to najdłuższy ciąg symboli od początku bufora
kodera, który występuje w buforze słownika. Ciągowi temu zostaje przyporządkowana para
liczb: jego długość równa 3 oraz offset przesunięcia względem pozycji pasującego ciągu
w słowniku równy 5. Następnie bufor słownika i bufor kodera zostają przesunięte w prawo
o długość dopasowanego ciągu, czyli o 3.
W drugiej fazie algorytmu DEFLATE, ciągi danych, ich długości oraz offsety uzyskane
przez algorytm LZ77 w pierwszej fazie są kodowane z użyciem algorytmu kodowania
Huffmana. GZIP dzieli ciągi bitów na segmenty mające maksymalną długość do 65535
bitów i kompresuje je z użyciem algorytmu LZ77 i kodowania Huffmana. Każdy segment
posiada własne drzewo kodów Huffmana, które również jest kompresowane i zapisywane
z odpowiadającym mu skompresowanym segmentem.
Technika kompresji BBC (ang. Byte-aligned Bitmap Code) [Ant94] została oparta o tak
zwane kodowanie run-length. W kodowaniu run-length przyjmuje się, że ciągi bitów o jednakowych wartościach są reprezentowane jako wartości długości tych ciągów. Na przykład,
dla ciągu bitów 11100001011 kodowanie run-length ma postać: 34112. Pierwsze trzy bity
kodowanego ciągu o wartości jeden zapisujemy jako 3, cztery następne bity o wartości zero
zapisujemy jako 4, itd. W przypadku schematu kompresji BBC nałożono jeszcze jeden dodatkowy warunek. Ciąg bitów w mapie bitowej został podzielony na bajty. Bajty zostały
następnie pogrupowane w tak zwane przebiegi (ang. runs). Przebieg składa się ze słowa będącego wypełnieniem (ang. fill), lub dopełnieniem (ang. tail). Wypełnienie reprezentuje ciąg
bajtów złożonych z bitów o tej samej wartości. Dopełnienie (ang. tail) reprezentuje ciąg
bajtów złożonych z bitów o różnych wartościach. Podział mapy bitowej na bajty ogranicza
57
miarę długości jednorodnych ciągów bitów do wartości będących wielokrotnością długości
jednego bajtu.
Każdy przebieg w schemacie kompresji BBC ma postać:
[wypełnienie][dopełnienie].
w
W zależności od długości wypełnienia oraz struktury dopełnienia wyróżnia się cztery
typy przebiegów:
− Przebieg typu 1-Run. Przebieg ten jest przeznaczony do reprezentacji wypełnienia o
długości od 0 do 3 bajtów i dopełnienia o długości od 0 do 15 bajtów. Przebieg typu
1-Run posiada nagłówek złożony z jednego bajtu postaci:
1[Bit wypełnienia][długość wypełnienia(2 bity)][długość dopełnienia(4 bity)]
w
w
Bajty dopełnienia znajdują się po bajcie nagłówka. Przebieg typu 1-Run ilustruje następujący przykład:
Nieskompresowana mapa bitowa:
00000000
00000000
10001010
00110111
Przebieg typu 1-Run
{1}{0}{10}{0010}
{10001010
00110111}
Liczba bajtów
Liczba bajtów
dopełnienia (4 bity)
wypełnienia (2 bity)
da
.b
Bit oznaczający typ
przebiegu (1 bit)
Wartość bitów
wypełnienia
(1 bit)
Dwa bajty
dopełnienia
Rys. 5. Przykład przebiegu 1-Run
− Przebieg typu 2-Run. Przebieg ten jest przeznaczony do reprezentacji wypełnienia
o długości od 0 do 3 bajtów i dopełnienia złożonego z jednego bajtu posiadającego
jeden bit różny od bitów wypełnienia. Przebieg typu 2-Run posiada nagłówek złożony z jednego bajtu postaci:
01[Bit wypełnienia][długość wypełnienia(2 bity)][pozycja różniącego się bitu
w dopełnieniu(3 bity)]
pl
s.
Bajt dopełnienia nie jest przechowywany. Przebieg ten ilustruje następujący przykład:
00000000
00000000
00000000
00000010
Bity
oznaczające
typ przebiegu
(2 bity)
Przebieg typu 2-Run
{01}{0}{11}{001}
Wartość bitów
wypełnienia (1 bit)
Pozycja różniącego się bitu
Liczba bajtów
dopełnienia (3 bity)
wypełnienia (2 bity)
− Przebieg typu 3-Run. Przebieg ten jest przeznaczony do reprezentacji wypełnienia
o rozmiarze większym niż 3 bajty i dopełnienia złożonego od 0 do 15 bajtów. Wielo58
bajtowy licznik reprezentuje długość wypełnienia. Przebieg typu 3-Run posiada nagłówek złożony z jednego bajtu postaci:
001[bit wypełnienia][długość dopełnienia (4 bity) ].
Bajty wielobajtowego licznika następują po nagłówku. Następnie znajdują się bajty dopełnienia. Każdy bajt licznika wielobajtowego (z wyjątkiem ostatniego) ma postać:
1[ (7 bitów) przechowywana wartość]
w
Bity
oznaczające
typ przebiegu
(3 bity)
w
w
Ostatni bajt licznika ma wartość pierwszego bitu równą 0. Liczba bajtów w dopełnieniu jest
równa wartości licznika powiększonego o 4. Przebieg 3-Run ilustruje następujący przykład:
00000000
00000000
00000000
00000000
00000000
11110011
Przebieg typu 3-Run
{001}{0}{0001}
{0}{0000001}
{11110011}
Liczba
Wartość bitów bajtów
wypełnienia wypełnienia
(1 bit)
(4 bity)
Bit końca
licznika (1 bit)
Licznik bajtów
wypełnienia (7 bitów)
Bajt
dopełnienia
da
.b
− Przebieg typu 4-Run. Przebieg ten jest przeznaczony do reprezentacji wypełnienia o
rozmiarze większym niż 3 bajty i dopełnienia złożonego z jednego bajtu
posiadającego jeden bit różny od bitów wypełnienia. Przebieg typu 4-Run posiada
nagłówek złożony z jednego bajtu postaci:
0001[Bit wypełnienia][pozycja różniącego się bitu w dopełnieniu(3 bity)]
Bajt dopełnienia nie jest przechowywany. Bajty wielobajtowego licznika następują po nagłówku. Następnie znajdują się bajty dopełnienia. Każdy bajt licznika wielobajtowego (z
wyjątkiem ostatniego) ma postać:
pl
s.
1[ (7 bitów) przechowywana wartość]
Ostatni bajt licznika ma wartość pierwszego bitu równą 0. Liczba bajtów w dopełnieniu jest
równa wartości licznika powiększonego o 4. Przebieg typu 4-Run ilustruje następujący
przykład:
00000000
00000000
00000000
00000000
00000000
00000010
Przebieg typu 4-Run
{0001}{0}{001}
{0}{0000001}
Bity
oznaczające
typ przebiegu
(4 bity)
Pozycja
różniącego
Wartość
się bitu
bitów
wypełnienia dopełnienia
(3 bity)
(1 bit)
Bit końca
licznika (1 bit)
Licznik bajtów
wypełnienia (7 bitów)
59
w
Schemat kompresji BBC osiąga niemal tak dobry współczynnik kompresji jak kompresja
GZIP. Struktura przebiegów jest stosunkowo prosta i pozwala algorytmowi dekompresji
ustalić typ przebiegu w wyniku przeprowadzenia do 5-6 operacji bitowych. Prostota struktury przebiegów pozwala również na przeprowadzanie operacji bitowych na skompresowanych mapach bitowych. Taka strategia zapewnia krótkie czasy wykonywania zapytań z wykorzystaniem skompresowanych map bitowych przy satysfakcjonującym współczynniku
kompresji. Z powyższego powodu nadaje się on do zastosowań w hurtowniach danych
z przetwarzaniem w trybie OLAP i jest już wykorzystywany w produktach komercyjnych
(Np. Oracle).
3.4 Kompresja WAH
w
da
.b
w
Technika kompresji WAH (ang. Word-Aligned Hybrid) [2] podobnie, jak BBC została
oparta o kodowanie run-length. Ciągi bitów w mapach bitowych również są dzielone na
mniejsze fragmenty. W przypadku WAH są to 31-bitowe słowa. Podział na 31-bitowe słowa ma na celu dostosowanie długości fragmentów do procesorów 32-bitowych. Słowa te
spełniają podobną rolę, co przebiegi w schemacie kompresji BBC, jednakże mają o wiele
prostszą budowę niż przebiegi w BBC.
Pierwszy bit przebiegu przechowuje typ danego przebiegu. Stąd prosty wniosek, że
w kompresji WAH wyróżniamy tylko dwa następujące typy przebiegów: wypełnienie i dopełnienie.
− Wypełnienie (ang. fill) informuje o liczbie następujących po sobie 31-słów wypełnionych samymi bitami o wartości 0 lub samymi bitami o wartości 1. Pierwszy bit 32bitowego wypełnienia ma wartość 1 i informuje nas o tym, że mamy do czynienia z
wypełnieniem. Następny bit informuje nas o tym, jaką wartością wypełnione są 31bitowe słowa. Pozostałe 30 bitów jest używanych do zapisu liczby 31-słów wypełnionych bitami o tej samej wartości. Jedno wypełnienie pozwala, więc zapisać informację o wystąpieniu do 1073741823 31-bitowych słów. Ideę wypełnienia ilustruje
następujący przykład:
Cztery 31-bitowe słowa wypełnione samymi zerami:
000....31bit...0000 000....31bit...0000 000....31bit...0000 000....31bit...0000
Bit typu
przebiegu
pl
s.
{1}{0}{000000
32-bitowe Wypełnienie:
00000000
00000000
Bit równy wartości bitów
31-bitowych słów
Rys. 9. Przykład wypełnienia w kompresji WAH
00000100}
Liczba 31-bitowych
słów
− Dopełnienie (ang. tail) podobnie jak w schemacie kompresji BBC stanowi ciąg bitów
o następujących po sobie różnych wartościach bitów. Pierwszy bit 32-bitowego dopełnienia ma wartość 0. Następujące po nim 31-bitów stanowi 31-bitowe słowo, którego nie można było poddać kompresji. Ideę dopełnienia ilustruje następujący przykład:
60
Cztery 31-bitowe słowa wypełnione naprzemiennie zerami i jedynkami:
010....31bit...1010 010....31bit...1010 010....31bit...1010 010....31bit...1010
Cztery 32-bitowe wypełnienia:
0010....31bit...1010 0010....31bit...1010
{0}010....31bit...1010
0010....31bit...1010
w
Bit typu przebiegu
Rys. 10. Przykład dopełnień w kompresji WAH
40000380
C0000002
40000380
Postać skompresowana map bitowych A,B i C:
80000002
001FFFFF
7C0001E0
3FE00000
80000003
0000000F
00000003
00000003
pl
s.
A
B
C
da
.b
w
w
Kompresja WAH posiada dwie postacie użytkowe: skompresowaną i zdekompresowaną.
W postaci skompresowanej występują zarówno wypełnienia jak i dopełnienia. W tej postaci
mapy bitowe są przechowywane na dysku. W postaci zdekompresowanej występują tylko
dopełnienia. Każde wypełnienie zostaje zdekompresowane do dopełnień o liczności równej
liczbie 31-bitowych słów o jednakowych bitach zapisanych w wypełnieniu. Postaci zdekompresowanej używa się do reprezentacji mapy bitowej w pamięci. Taka reprezentacja
jest o 1/32 większa od reprezentacji nieskompresowanej mapy bitowej. Wzrost rozmiaru nie
wpływa na efektywność przetwarzania. Schemat kompresji WAH posiada na tyle prostą
strukturę w obu reprezentacjach, że umożliwia przeprowadzanie operacji logicznych zarówno na skompresowanej jak i zdekompresowanej postaci WAH.
Poniższy przykład ilustruje obie postacie oraz w jaki sposób przeprowadzane są operacje
bitowe na skompresowanych mapach bitowych:
Postać zdekompresowana map bitowych A,B i C:
A
40000380
00000000
00000000
001FFFFF
0000000F
B
7FFFFFFF
7FFFFFFF
7C0001E0
3FE00000
00000003
C
40000380
00000000
00000000
00000000
00000003
Rys. 11. Operacja AND (A AND B = C) przeprowadzana na mapach bitowych
skompresowanych WAH w postaci zdekompresowanej i skompresowanej [6]
Przeprowadzanie operacji logicznych na zdekompresowanej formie map bitowych jest równie proste jak na mapach bitowych nie skompresowanych. Jedynie musimy zagwarantować,
że wartość pierwszego bitu informująca nas o typie przebiegu pozostanie równa jeden. By
przeprowadzić operacje logiczne na mapach bitowych skompresowanych musimy przeprowadzić dodatkowe operacje bitowe. Musimy zidentyfikować typy przebiegów oraz typy
słów, jakie uzyskamy w wyniku przeprowadzanej operacji. Forma zdekompresowana jest
używana, gdy operacje logiczne są przeprowadzane na wielu mapach bitowych jednocześnie jak w przypadku zapytań o warunkach zakresowych. Forma skompresowana jest wykorzystywana w przypadku pojedynczych operacji logicznych jak w przypadku zapytań z warunkami równościowymi.
61
3.5 Kompresja RLH
w
Schemat kompresji Run-Length Huffman (RLH) [9, 10] łączy w sobie dwie techniki:
kodowanie run-length oraz kodowanie Huffmana.
− Wariant kodowania run-length. W standardowym schemacie kodowania run-length,
kodowaniu podlegają długości ciągów tych samych symboli, np. dla ciągu
000011110100 otrzymujemy kod 44112. W przypadku kodowania zaproponowanego
w niniejszym rozdziale, kodowaniu podlegają odległości do kolejnego bitu o wartości jeden. Przykładowo dla ciągu 000011110100 otrzymujemy kod 400012, przy założeniu, że koniec ciągu interpretujemy tak jak bit o wartości jeden. Zatem, dla powyższego ciągu pierwszy bit o wartości 1 jest odległy o 4 bity, następny bit o wartości jeden jest odległy o 0 bitów, itd. Takie rozwiązanie zostało przyjęte ze względu na malejące gęstości bitów o wartości jeden w mapach bitowych wraz ze wzrostem liczności dziedziny atrybutu indeksowanego. W efekcie, dla pojedynczej mapy bitowej
powstaje znacznie mniej symboli (odległości do bitów o wartości jeden) niż przy
standardowej formie kodowania run-length. W taki sposób kodujemy wszystkie mapy bitowe.
− Algorytm kodowania Huffmana jest wykorzystywany w drugim kroku schematu
kompresji. Dane wejściowe dla algorytmu Huffmana stanowią zebrane statystyki
częstości występowania symboli we wszystkich mapach bitowych zakodowanych
z użyciem zmodyfikowanego kodowania run-length w pierwszym kroku. Na podstawie tych statystyk zostaje utworzone drzewo kodów Huffmana. Kody Huffmana służą do zakodowania wszystkich map bitowych. Tak zakodowane mapy bitowe są następnie zapisywane na dysku. Drzewo kodów Huffmana jest również zapisywane na
dysku, jednakże w oddzielnej strukturze. Rozmiar takiego drzewa jest stosunkowo
niewielki. Dla danych testowych: tabeli o 2 milionach rekordów i liczności dziedziny
atrybutu indeksowanego równej 1000, rozmiar drzewa zapisanego na dysku sięgał 65
KB.
Poniżej przedstawiono prosty przykład zastosowania proponowanego schematu kompresji
na tabeli liczącej 19 rekordów, posiadającej atrybuty ID oraz Płeć. Indeks bitmapowy
został założony na atrybucie Płeć.
da
.b
w
w
pl
s.
Tabela 3. Przykładowa tabela Klienci i indeks bitmapowy na atrybucie płeć
62
Kolejne kroki algorytmu będą przebiegały następująco:
− Krok 1: Dokonujemy kodowania map bitowych za pomocą kodowania run-length.
Kolejne symbole oznaczają odległości do kolejnych jedynek w mapach bitowych.
Kodowanie run-length na mapach bitowych
Kobieta
Mężczyzna
w
w
1
0
0
3
0
0
3
0
0
2
3
0
0
0
0
3
1
3
0
w
0
Rys. 12. Przykład użycia kompresji RLH: Krok 1
da
.b
− Krok 2: Zliczamy statystyki częstości występowania poszczególnych symboli. Będą
one stanowić dane wejściowe dla algorytmu Huffmana.
Uzyskane statystyki częstości występowania
Symbol
Częstość
0
12
3
5
1
2
2
1
O
pl
s.
− Krok 3: Budujemy drzewo kodów Huffmana i uzyskujemy kody dla poszczególnych
symboli.
X3
0
1
X2
O
3
O
1
X1
1
1
Uzyskane kody Huffmana
Symbol
2
Kod symbolu
0
0
3
10
1
110
2
111
63
− W efekcie, algorytm daje nam następujące skompresowane mapy bitowe. Poszczególne komórki (por. rys.5.5) obrazują zawartość kolejnych bajtów. Ciągi bitów zakodowanych map bitowych składają się z kodów Huffmana odpowiadających symbolom zawartym w mapach bitowych zakodowanym przy użyciu kodowania runlength.:
Skompresowana mapa bitowa dla atrybutu o wartości Kobieta:
{110} {0} {0} {10} {0}
{10}{0}{0} {110} {0}
{0}
w
1
0
0
3
0
3
0 0
1
0
0
w
Skompresowana mapa bitowa dla atrybutu o wartości Mężczyzna
{0} {10} {0} {0} {111}
{0} {0} {10} {10}
3
0
0
2
w
0
0 0
3
3
Rys. 15. Mapy bitowe z rys. 7.1 w postaci skompresowanej
da
.b
Rozmiar drzewa kodów Huffmana okazuje się sprawą kluczową dla przebiegu
algorytmu dekompresji i użytkowania tak skompresowanych map bitowych. Rozmiar ten
jest na tyle niewielki, iż można założyć, że drzewa kodów Huffmana mogą być
przechowywane na stałe w pamięci w czasie użytkowania hurtowni danych. Na przykład
dla tabeli o 2 000 000 rekordów i liczności dziedziny atrybutu indeksowanego równej 1000
użytej w przeprowadzonych testach, rozmiar drzewa kodów Huffmana zapisanego na dysku
wynosił 65 KB. Dzięki przechowywaniu drzewa kodów Huffmana w pamięci RAM
zmniejszamy koszt wykonania operacji dekompresji.
W celu dokonania dekompresji mapy bitowej musimy jedynie dokonać odczytu kolejnych bitów skompresowanej mapy bitowej i przetransformować je z wykorzystaniem drzewa kodów Huffmana do symboli, które te kody reprezentują. Takie postępowanie nadal
wymaga wykonania większej liczby operacji niż liczba operacji, jaką należy wykonać
w czasie dekompresji map bitowych skompresowanych z użyciem schematów kompresji
WAH czy BBC. Dla każdej odczytanej wartości int z pliku musimy dokonać 32 porównań
w celu ustalenia wartości bitów na kolejnych pozycjach. Natomiast schemat kompresji
WAH wymaga dla każdej odczytanej wartości int z pliku jednego porównania w celu
stwierdzenia typu występującego przebiegu. Dodatkowo, w czasie wykonywania operacji
bitowych, mapy bitowe skompresowane z użyciem WAH przechowuje się w tak zwanej
postaci zdekompresowanej.
Proces aktualizacji map bitowych w momencie aktualizacji danych stanowi dość poważny problem. Pielęgnacja tak skompresowanych indeksów bitmapowych jest trudna do przeprowadzenia. W celu aktualizacji indeksu, należy zdekompresować mapy bitowe. Następnie należy zmodyfikować wartości bitów rekordów, które uległy zmianie. W końcowym
etapie należy jeszcze raz przeprowadzić kompresję map bitowych. Jest to konieczne ze
względu na zmiany w statystykach częstości występowania symboli kodowania run-length
w mapach bitowych. Używając starego drzewa kodów Huffmana, uzyskiwalibyśmy mapy
bitowe skompresowane w sposób nieoptymalny. Dodatkowo, mogłoby się zdarzyć, że
w wyniku aktualizacji w statystykach pojawiłby się nowy symbol nie ujęty w drzewie kodów Huffmana. Zasadniczo, w hurtowniach danych, założone indeksy są kasowane przed
procesem aktualizacji danych i budowane od nowa po zakończeniu tego procesu. Z tych
pl
s.
64
powodów przedstawione powyżej ograniczenia w kompresji RLH nie są tak ważne. Indeks
bitmapowy zostanie stworzony i skompresowany od podstaw przy każdym odświeżeniu danych. Jednakże, w celu zniwelowania i tej wady dla innych zastosowań kompresji RLH niż
hurtownie danych zaproponowany został schemat kompresji RLH-1024 [10].
3.6 Kompresja RLH-1024
w
da
.b
w
w
W kompresji RLH-1024 przed dokonaniem kompresji RLH, mapy bitowe są dzielone na
1024-bitowe fragmenty, co stanowi pierwszą różnicę. Następnie dla każdego fragmentu liczone są częstości odległości kolejnych bitów o wartości jeden, podobnie jak w RLH.
Wszystkie częstości wszystkich fragmentów są używane do konstrukcji jednego drzewa kodów Huffmana. Kody uzyskane tylko z tego samego, jednego drzewa są wykorzystywane
przy kompresji wszystkich fragmentów. Przy czym, końcowa lista kodów będzie zawierać
kody dla wszystkich 1024 możliwych odległości. Odległości, które nie wystąpiły w kompresowanej mapie bitowej mają przyporządkowaną częstość równą 1.
Kompresja RLH-1024 ma następujące zalety w porównaniu z pierwszym wariantem
RLH. Po pierwsze, zawiera wszystkie możliwe odległości bitów o wartości jeden w drzewie Huffmana eliminując konieczność przebudowy drzewa w przypadku, gdy aktualizacja
mapy bitowej wygeneruje niewystępującą wcześniej odległość. Po drugie, 1024-bitowe
fragmenty mogą być czytane i przetwarzane równolegle. Po trzecie, w celu dokonania aktualizacji map bitowych, jedynie odpowiedni 1024-bitowy fragment musi zostać odczytany
i zdekompresowany.
4 Porównanie technik kompresji
4.1 GZIP
pl
s.
Technika kompresji GZIP posiada lepszy współczynnik kompresji niż BBC czy WAH,
jednocześnie jest najwolniejszym schematem kompresji pod względem mierzonych czasów
odpowiedzi na zapytania z użyciem skompresowanych map bitowych. Nie jest to
niespodzianką, zważywszy, że GZIP jako schemat kompresji ogólnego przeznaczenia nie
był opracowany w celu zastosowań w hurtowniach danych. GZIP nie wspiera operacji
bitowych na skompresowanych mapach bitowych. Algorytm kompresji i dekompresji GZIP
jest znacznie bardziej złożony niż ten używanych w BBC, czy WAH. Te wady mogą zostać
rozszerzone na wszystkie schematy kompresji ogólnego przeznaczenia. Podsumowując,
schematy kompresji ogólnego przeznaczenia nie mogą w żaden sposób konkurować ze
specjalizowanymi schematami kompresji na polu kompresji map bitowych w hurtowniach
danych.
4.2 BBC I WAH
Zarówno BBC jak i WAH bazują na tej samej strategii. Oba schematy kompresji korzystają
z prostego algorytmu kompresji, który kosztem osiąganego współczynnika kompresji gwarantuje niskie czasy przetwarzania skompresowanych map bitowych. Takie podejście jest
sensowne dla indeksowanych atrybutów o wysokiej liczności (>30). W tym przypadku, mapy bitowe są w większości wypełnione bitami o wartości 0. Dzieląc je na 8-bitowe (dla
65
w
BBC) i na 31-bitowe (dla WAH) słowa, uzyskujemy w większości słowa wypełnione samymi bitami o wartości 0. Są one kompresowane do przebiegów typu wypełnienie (ang.
fill). Wynika to z faktu, że średnie odległości bitów o wartości jeden w takich mapach bitowych są znacznie większe niż wielkości słów używane przez te kompresje. Dla liczności
atrybutu indeksowanego mniejszej niż 30, obie techniki kompresji uzyskują gorsze współczynniki kompresji, jeśli wartości atrybutu indeksowanego w danych są ułożone losowo.
W takim przypadku, średnia długość jednorodnego ciągu bitów jest mniejsza niż długość
używanych słów w kompresjach i niewiele słów jest zapisywanych jako przebiegi typu wypełnienie. Zarówno wielkości map bitowych jak i czasy wykonania zapytań na tych mapach
bitowych będą w takim przypadku niemal identyczne z czasami wykonania zapytań na nie
skompresowanych mapach bitowych.
Techniki kompresji BBC i WAH zostały poddane eksperymentom obliczeniowym w celu porównania z techniką kompresji GZIP [6]. Eksperyment wykorzystywał 2,2 miliona rekordów danych uzyskanych z eksperymentu fizyki wysokich energii STAR. Testy były
przeprowadzane na maszynie Sun Enterprise 450 wyposażonej w procesory 400 MHz
UltraSPARC II, 4 GB RAM, które wystarczały na przechowywanie całych przypadków
testowych w pamięci. Eksperyment mierzył dwie wartości: czas przetwarzania map bitowych oraz wielkości skompresowanych map bitowych.
Wykres po lewej ukazuje czasy przeprowadzania operacji bitowej OR na mapach bitowych. Wiele takich operacji ma miejsce na zapytaniach zakresowych opartych o atrybut
indeksowany. Pokazane czasy nie zawierają w sobie czasów poświęcanych na operacje I/O
i stanowią jedynie czasy przetwarzania map bitowych w pamięci. Wykres po prawej stronie
ukazuje średnie wielkości skompresowanych map bitowych. Oba wykresy są opisane
w dziedzinie gęstości map bitowych. Gęstość mapy bitowej oznacza stosunek liczby bitów
o wartości jeden w mapie bitowej do liczby wszystkich bitów w mapie bitowej. Proste
oznaczone jako "LIT" na obu wykresach ukazują wartości oczekiwane dla nie skompresowanych map bitowych.
da
.b
w
w
pl
s.
Rys. 16. Porównanie czasów przetwarzania operacji OR oraz rozmiarów skompresowanych
map bitowych [6]
Z rys. 16 wynika, że o ile technika kompresji BBC został zoptymalizowany dla czasów
wykonywania zapytań, tak WAH powziął tą optymalizację do ekstremalnego punktu. Technika kompresji WAH umożliwia do dwunastu razy szybsze przetwarzanie operacji
bitowych na skompresowanych mapach bitowych niż BBC, jednocześnie kompresując
mapy bitowe do wielkości 60 % większych niż te skompresowane przez BBC. W
porównaniu do map bitowych nie skompresowanych, WAH niemal zawsze daje lepszy czas
66
odpowiedzi na zapytanie pod względem czasu przetwarzania. Dodatkowo mapy bitowe
WAH są łatwiejsze w przetwarzaniu niż mapy bitowe BBC. W celu rozpoznania przebiegu
WAH musimy dokonać tylko jednej operacji bitowej, tymczasem dla mapy bitowej
skompresowanej BBC potrzeba wykonać przynajmniej trzech operacji bitowych by
rozpoznać typ przebiegu BBC. Technika kompresji BBC jest lepiej przystosowana do
kodowania krótszych wypełnień. Jednakże BBC tworzy w ten sposób więcej przebiegów
niż WAH, co prowadzi to ogólnej utraty efektywności przetwarzania map bitowych.
w
4.3 WAH, RLH I RLH-1024
da
.b
w
w
W artykułach [9], [10] przedstawiono wyniki eksperymentów obliczeniowych z udziałem
kompresji WAH, RLH oraz RLH1024. Eksperymenty były przeprowadzane na komputerze
klasy PC wyposażonym w procesor Athlon(TM) XP 2500+, dysk twardy Seagate 80 GB
oraz pamięć 768 MB RAM. Wszystkie kompresje zostały zaimplementowane w środowisku Javy i były uruchamiane pod kontrolą Windows. Dane oraz indeksy bitmapowe (skompresowane i nieskompresowane) były przechowywane na dysku pod kontrolą systemu operacyjnego. Testy zostały przeprowadzone dla tabeli liczącej 2 miliony rekordów. Indeks bitmapowy został zdefiniowany na atrybucie typu integer mającym sparametryzowaną liczność dziedziny w zakresie od 2 do 1000 unikalnych wartości. Rozkład tych wartości na rekordy tabeli był losowy.
Celem testów było porównanie kompresji WAH do kompresji RLH i RLH-1024 na tle
indeksu bitmapowego nieskompresowanego względem dwóch miar: (1) czasu odpowiedzi
na zapytanie z warunkiem nałożonym na indeksowany atrybut, (2) wielkością skompresowanych map bitowych. Zapytanie wykorzystywane w testach miało poniższą postać:
select ... from ... where A in (v1, v2, ..., v100)
gdzie A oznacza atrybut ze zdefiniowanym indeksem bitmapowym, v1,v2, ..., v100 reprezentują 100 losowo wybranych wartości atrybutu indeksowanego. Wyniki eksperymentu
przedstawiono na rys. 17. Czas na wykresie jest średnim czasem przetwarzania pojedynczej
mapy bitowej.
pl
s.
Rys. 17. Czasy odpowiedzi na zapytanie oraz rozmiary indeksów dla kompresji WAH,
RLH i RLH-1024 i przy braku kompresji [10]
Z wykresów czasu odpowiedzi wynika, że RLH i RLH1024 oferują gorsze czasy odpowiedzi niż WAH i nieskompresowany indeks bitampowy dla wielkości dziedziny atrybutu
67
w
indeksowanego mniejszej niż 5. Dzieje się tak dlatego, że w przypadku małych dziedzin
atrybutu indeksowanego mapy bitowe osiągają wysoką gęstość bitów o wartości jeden.
W konsekwencji średnie odległości występujące pomiędzy jedynkami okazują się niewielkie. Optymalne kodowanie Huffmana daje w efekcie nikły zysk na rozmiarze indeksu, a co
za tym idzie nikły zysk na czasie poświęcanym na odczyt mapy bitowej z dysku. Jednocześnie operacje logiczne dokonywane w pamięci okazują się bardziej złożone w przypadku RLH, niż odpowiednie operacje przeprowadzane na mapach bitowych skompresowanych z użyciem WAH, czy na nieskompresowanych mapach bitowych. Dla liczności dziedziny atrybutu indeksowanego większej niż 5 sytuacja ulega odwróceniu. Wraz ze wzrostem liczności dziedziny spada gęstość bitów o wartości jeden w mapach bitowych. Algorytm Huffmana wykorzystany w RLH i RLH-1024 korzysta na tym zjawisku znacznie
lepiej niż odpowiadające mu mechanizmy w kompresji WAH.
Obserwując rozmiary indeksów, można zauważyć, że przyrost wielkości map bitowych
dla kompresji RLH i RLH-1024 jest łagodniejszy niż dla kompresji WAH. Ponadto, różnica
w wielkościach indeksów RLH i RLH-1024 nie jest znacząca i maleje wraz ze wzrostem
liczności dziedziny atrybutu indeksowanego. Na gorszy wynik RLH-1024 ma wpływ podział map bitowych na 1024-bitowe słowa oraz wykorzystywanie nieoptymalnego drzewa
w kodowaniu Huffmana.
w
w
da
.b
5 Podsumowanie
Literatura
1.
2.
3.
pl
s.
W rozdziale przedstawiono szereg technik kompresji map bitowych w zastosowaniach
w hurtowniach danych. Techniki kompresji ogólnego przeznaczenia takie jak GZIP okazują
się zbyt wymagające czasowo do wykonywania operacji dekompresji w czasie wykonywania zapytań. Aktualnie najlepszym rozwiązaniem znajdującym zastosowanie w praktyce
okazują się być techniki kompresji BBC i WAH zaprojektowane w taki sposób, aby minimalizować czas odpowiedzi na zapytania kosztem uzyskiwanego współczynnika kompresji.
Od współczynnika kompresji oczekuje się jedynie by zapewniał rozmiary skompresowanego indeksu nie większe niż odpowiadające rozmiary indeksu B-drzewo. Inne rozwiązanie
prezentuje kompresja RLH i jej wariant RLH-1024, które minimalizują czas odpowiedzi na
zapytania za pomocą struktur pomocniczych przechowywanych w pamięci i wykorzystywanych przez hurtownie danych przy operacjach kompresji i dekompresji map bitowych.
Dzięki takiemu podejściu możemy zastosować bardziej skomplikowany algorytm kompresji. Przeprowadzone eksperymenty pokazują, że kompresje RLH i RLH-1024 dla atrybutów
o dziedzinach z zakresu kilka do 1000 różnych wartości posiadają lepsze charakterystyki
niż BBC i WAH. Kompresje RLH i RLH-1024 mogą znaleźć zastosowanie poza hurtowniami danych pod warunkiem, że będą gwarantować podobny czas aktualizacji skompresowanych map bitowych, co kompresje BBC i WAH.
Antoshenkov G.: Byte-aligned bitmap compression. Technical report, Oracle Corp, U.S. Patent
number 5,363,098, 1994.
Chan C. Y., Ioannidis Y. E.: An Efficient Bitmap Encoding Scheme for Selection Queries.
Materiały konferencji: ACM SIGMOD Int. Conference on Management of Data, 1999.
3,ZLIB Compressed Data Format Specification version 3.3, http://www.faqs.org/rfcs/3.html
68
4.
5.
6.
7.
w
8.
RFC 1951, DEFLATE Compressed Data Format Specification version 1.3,
http://www.faqs.org/rfcs/4.html
RFC 1952, GZIP file format specification version 4.3, http://www.faqs.org/rfcs/5.html
Wu K., Otoo E. J., Shoshani A.: Compressing Bitmap Indexes for Faster Search Operations.
Materiały konferencji: Int. Conference on Scientific and Statistical Database Management
(SSDBM).
O'Neil, P., Quass, D.: Improved Query Performance with Variant Indexes. Materiały
konferencji: ACM SIGMOD Int. Conference on Management of Data, 1997.
Jurgens M., Lenz H.J.: Tree Based Indexes vs. Bitmap Indexes: A Performance Study.
International Journal of Cooperative Information Systems. 10(3), 2001.
Stabno M., Wrembel R.: RLH: Bitmap Compression Technique Based on Run-length and
11fman Encoding. Materiały konferencji: ACM Int. Workshop on Data Warehousing and OLAP
(DOLAP), 2007.
Stabno M., Wrembel R.: Run-Length 11fman - alternatywny algorytm kompresji map bitowych.
Materiały konferencyjne II Krajowa Konferencja Naukowa Technologie Przetwarzania Danych,
2007.
1fman Compression. Odczytane 08.05.2007 ze strony
http://www.geocities.com/SiliconValley/2151/11fman.html
Stockinger, K., Wu, K., Shoshani, A.: Strategies for Processing ad hoc Queries on Large Data
Sets. International Workshop on Data Warehousing and OLAP (DOLAP), USA, 2002.
Wu K., Otoo E.J., Shoshani A.: On the Performance of Bitmap Indices for High Cardinality
Attributes. International Conference on Very Large Data Bases (VLDB), Canada, 2004.
Wu K., Otoo E., Shoshani A.: An Efficient Compression Scheme for Bitmap Indices. Technical
Report LBNL-49626, 2006.
9.
11.
12.
13.
14.
da
.b
w
w
10.
pl
s.
69
w
da
.b
w
w
pl
s.

pobierz plik referatu - BDAS

Transkrypt

Podobne dokumenty

Kompresja danych

Klasa I Temat: Kompresja i dekompresja danych.

SŁOWNICZEK DVB-T (Digital Video Broadcasting – Terrestrial

KOMPRESJA STRATNA I BEZSTRATNA W