2009.09_Kompresja w DB2 Optymalizacja systemu dyskoweg_[Bazy Danych].pdf

Bazy danych

Kompresja w DB2

Optymalizacja systemu dyskowego

W ostatnich latach rynek oprogramowania do zarządzania bazami danych

zupełnie zmienił swoje oblicze. Jeszcze kilka, kilkanaście lat temu bazy

danych należały do elitarnego oprogramowania i projektanci systemów

informatycznych byli wręcz skazani na korzystanie z komercyjnych

rozwiązań.

Dowiesz się:

• Jak działa kompresja w DB2;

• W jaki sposób włączyć kompresję dla tabel,

indeksów i dokumentów XML;

• Jak kompresja wpływa na wydajność.

Powinieneś wiedzieć:

• Jak uruchamiać zapytania SQL oraz polece-

nia administracyjne w DB2.

następnie uzupełnić sok wodą w odpowiednich

proporcjach. Taka operacja wymaga dodatkowej

pracy, jednak w ogólnym bilansie obniża koszty i

przyspiesza proces wytworzenia soku.

Zanim omówię zasady działania kompresji w

DB2 chciałbym zwrócić uwagę na trendy roz-

woju sprzętu komputerowego w ostatnich la-

tach. Prędkość procesorów z roku na rok sys-

tematycznie się zwiększa. Pojemność dysków

także się zwiększa. Dziś dostępne są już dyski

600 GB stosowane w macierzach z interfejsem

Fiber Channel (dyski SATA II oferują jeszcze

większe pojemności, jednak nie zawsze nadają

się do rozwiązań pod bazy danych). Natomiast

prędkość dysków pozostaje bez zmian – wyni-

ka to z fizycznych ograniczeń prędkości obro-

towej talerza dyskowego, wynoszącego maksy-

malnie 15 tysięcy obrotów na minutę. Przygo-

towując architekturę sprzętu pod bazę danych,

bardzo kusi skorzystanie z jak największych dys-

ków, ponieważ większe dyski przekładają się na

mniejszą cenę systemu dyskowego, jednak wy-

bór większych dysków oznacza mniejszą wy-

dajność. Bazy danych czytają małymi blokami,

a wydajność każdego z dysków określona jest

przez liczbę operacji losowego odczytu/zapisu

na sekundę. Zrównoważona wydajność operacji

I/O bezpośrednio zależy od liczby dysków, a nie

przestrzeni dyskowej! Tak jak pokazałem na Ry-

sunku 1, by zapewnić 600 GB przestrzeni dys-

kowej, możemy skorzystać z czterech dysków po

150 GB bądź z dwóch po 300 GB. Zastosowa-

nie większych dysków zapewne będzie tańszym

rozwiązaniem, jednak pociągnie za sobą dwa ra-

zy mniejszą wydajność mierzoną w liczbie ope-

racji I/O na sekundę.

Specjaliści przygotowujący sprzęt pod testy

wydajnościowe przetwarzania analitycznego

TPC-H ( www.tpc.org ) doskonale rozumieją ko-

nieczność użycia bardzo dużej liczby dysków.

Najlepszy wynik testu TPC-H dla bazy danych

o rozmiarze 10 TB, zrealizowany na DB2 9.5

został osiągnięty przy wykorzystaniu macierzy

Poziom

trudności

dą tak samo dobre. Różnicę będzie można za-

uważyć przy bazie, która np. zarządza kilkoma

terabajtami danych.

W tym artykule opiszę mechanizmy kom-

presji danych dostępne w DB2, które stosowa-

ne są dla dużych baz danych. Oczywiście du-

ża baza jest bardzo subiektywnym określe-

niem. Dla mnie duża baza to taka, która wy-

maga podjęcia specjalnych akcji, pozwalają-

cych na przełamanie pewnych ograniczeń bę-

dących naturalną konsekwencją rozmiaru ba-

zy. Do takich ograniczeń mogę zaliczyć mak-

symalny czas, który mogę poświęcić na wyko-

nanie backup-u bazy danych, dostępne miej-

sce na dyskach czy środki finansowe, które

mogę przeznaczyć na zakup i utrzymanie sys-

temów dyskowych.

Dla przeciętnego użytkownika kompute-

ra osobistego kompresja nie zawsze kojarzy

się z czymś pozytywnym, najczęściej z ocze-

kiwaniem na rozpakowanie plików. W wie-

lu dziedzinach to właśnie inteligentne algo-

rytmy kompresji wyznaczają kierunki rozwo-

ju. Przykładem mogą być choćby algorytmy

kompresji wykorzystane do strumieniowego

przekazu obrazu wideo wysokiej rozdzielczo-

ści (H.264/AVC), stosowane przez wiele cy-

frowych platform satelitarnych. Nawet poza

informatyką można podać przykłady wyko-

rzystania kompresji, przynoszące odpowied-

nie korzyści. Producentom soków (np. poma-

rańczowych) opłaca się zagęścić sok w miejscu,

w którym jest on produkowany, przetranspor-

tować zagęszczony sok do docelowego kraju, a

można powiedzieć, że osiągnęły już

odpowiedni poziom dojrzałości, by

stosować je w komercyjnych systemach. Bazy

danych stały się po prostu powszechnym pro-

duktem, takim jak telewizor czy samochód. W

języku angielskim najłatwiej określić je jednym

słowem – commodity . Czy oznacza to, że dostęp-

ne na rynku bazy danych nie różnią się od siebie

i oferują podobne możliwości? Takie samo pyta-

nie można postawić w stosunku do innych pro-

duktów commodity . Czy dziś ma znaczenie, ja-

ki kupujemy samochód? Oczywiście, że ma!

Wszystko jednak zależy od wymagań, jakie sta-

wiamy. Jeśli ktoś potrzebuje samochodu, by raz

w tygodniu odwiedzić rodzinę, która miesz-

ka kilka kilometrów od naszego domu, wtedy

naprawdę nie ma znaczenia, czym będziemy

się przemieszczać. Jeśli jednak zaczniemy in-

tensywnie używać samochodu, wtedy nie bez

znaczenia będzie dla nas zużycie paliwa, bez-

pieczeństwo, niezawodność czy komfort. Je-

śli samochód stanie się dla nas miejscem pra-

cy – wtedy już na pewno zaczniemy wymagać

więcej. Podobnie jest i z bazami danych. Jeśli na-

szym jedynym wymaganiem będzie przechowa-

nie kilku GB danych, wtedy wszystkie bazy bę-

09/2009

D zisiaj o bazach danych Open Source

Kompresja w DB2

dyskowej, której powierzchnia dyskowa była 11

razy większa niż rozmiar bazy danych! 110 TB

to dużo? Drugi w kolejności wynik zrealizowany

na bazie Oracle 11g wykorzystywał macierz dys-

kową 44 razy większą niż rozmiar bazy danych

(440 TB)! Testy wydajnościowe TPC-H rządzą

się swoimi prawami, które wszystko podporząd-

kowują osiągnięciu najlepszego wyniku i czasa-

mi trudno je bezpośrednio odnieść do rzeczywi-

stych rozwiązań. Podobnie jak nikogo nie dziwi

fakt, że wykonanie kierownicy samochodu For-

muły 1 kosztuje tyle samo co wyprodukowanie

nowego, popularnego samochodu osobowego.

Przytoczyłem powyższe porównania, by zasy-

gnalizować konieczność optymalizacji sytemu

dyskowego, np. przy wykorzystaniu kompresji.

ale całych ciągów, rozciągających poprzez wiele

kolumn w wierszu. Zakładając, że słownik jest

już zbudowany, wtedy w momencie wstawie-

nia bądź aktualizacji rekordu DB2 przeprowa-

dza analizę rekordu pod kątem zgodności wzor-

ców i proponuje skrócony format zapisu rekor-

du. Jeśli w słowniku nie znajdują się wzorce, któ-

re pasują do wstawianego (modyfikowanego) re-

kordu, wtedy rekord wprowadzany jest w orygi-

nalnej postaci, tak jak dla tabel, które nie wyko-

rzystują kompresji. Słownik nie jest aktualizowa-

ny w trybie online, ponieważ wiązałoby się to ze

zbyt dużym nakładem pracy. Narzut związany

z obsługą skompresowanej tabeli jest stosunko-

wo niewielki. Wykorzystujemy dodatkowe cy-

kle procesora głównie przy modyfikacji danych,

by odszukać w słowniku wzorce. Odczyty da-

nych praktycznie nie pociągają za sobą dodatko-

wego narzutu. W momencie ewaluacji wartości

rekordu bądź wysyłania strumienia danych do

aplikacji, DB2 dynamicznie podmienia zawar-

tość znaczników. Algorytmy są tak dopracowa-

ne, że rozmiar słownika wzorców praktycznie

nie przekracza 150 KB, niezależnie od rozmia-

ru tabeli. Słownik przechowywany jest zawsze w

pamięci podręcznej bazy danych, dlatego też do-

stęp do niego jest bardzo szybki.

Główną korzyścią ze stosowania kompresji

jest zmniejszenie szerokości rekordów. Na tej sa-

mej stronie zostanie zapisanych dużo więcej re-

kordów. Współczynniki kompresji silnie zależą

od samych danych. Na podstawie obserwacji rze-

czywistych systemów (np. SAP ERP) można po-

wiedzieć, że przeciętny współczynnik kompresji

wynosi ok. 60-70%, tzn. tabela o rozmiarze 100

GB po kompresji powinna zajmować 30-40 GB.

Zmniejszenie rozmiaru tabeli nie jest jedyną ko-

rzyścią wynikającą z kompresji. Ponieważ for-

mat stron przechowywanych w pulach buforów

jest taki sam jak na dyskach, w tej samej ilości pa-

mięci RAM serwera bazy danych znajdować się

będzie więcej rekordów. Dzięki kompresji wir-

tualnie zwiększamy dostępną dla bazy pamięć

RAM. Kolejną korzyścią jest zwiększenie prze-

pustowości operacji I/O. Jak już wspomniałem,

baza danych czyta blokami (stronami). Z jed-

Jak działa kompresja w DB2?

DB2 implementuje kilka różnych algorytmów

zależnie od tego, czy kompresowane są rekordy,

indeksy czy np. backup bazy danych. Dla kom-

presji tabel istotą jest zupełnie inny format zapi-

su rekordu na stronie. By zrozumieć, jak działa

kompresja, przypomnę podstawy organizacji da-

nych w DB2. Na dyskach dane zorganizowane

są w strony, które stanowią podstawową jednost-

kę operacji wejścia/wyjścia. Jeśli chcemy zapyta-

niem SQL odczytać pojedynczy rekord, wtedy

minimalną porcją danych, jaka zostanie odczy-

tana z dysku, jest strona. Strona zostanie umiesz-

czona w puli buforów (cache), która jest współ-

dzielonym obszarem pamięci RAM wykorzy-

stywanym do obsługi wszystkich aplikacji. Jeśli

inny użytkownik (bądź ten sam) będzie chciał

odczytać rekord ze strony, która znajduje się już

w puli buforów, wtedy odczyt będzie zrealizo-

wany bezpośrednio z pamięci bez konieczności

fizycznego odwoływania się do dysku. Rozmiar

strony w DB2 jest definiowalny (4 KB, 8 KB, 16

KB lub 32 KB), a na jednej stronie zwykle mieści

się typowo od kilku do kilkuset rekordów (zależ-

nie od szerokości rekordu).

Działanie kompresji polega na zredukowaniu

szerokości rekordu, tak by na stronie można by-

ło upakować większą liczbę rekordów. Jeśli czę-

sto powtarzający się w tabeli wzorzec występu-

je w rekordzie, wtedy podmieniany jest na od-

powiedni 12-bitowy znacznik, którego defini-

cja przechowywana jest w specjalnym słowni-

ku systemowym. Istotą algorytmu kompresji

DB2 jest przygotowanie odpowiedniego słow-

nika wzorców. W DB2 słownik wzorców bu-

dowany jest na podstawie zawartości całej tabe-

li (bądź wyróżnionego fragmentu tabeli). Ope-

racja taka jest stosunkowo czasochłonna (wy-

maga przeskanowania dużej liczby rekordów) i

może znacznie obciążyć system, dlatego też de-

cyzja o zbudowaniu słownika najczęściej podej-

mowana jest świadomie przez administratora

bazy danych. W momencie budowania słowni-

ka DB2 ocenia całe wiersze szukając podobnych

fragmentów lub powtórzonych wpisów danych

i to nie tylko dla wybranych pól czy części pól,

Listing 1. Sprawdzenie miejsca zajmowanego przez tabele bazy danych

select char(tabname, 10) as table, data_object_l_size as "DATA SIZE [KB]",

index_object_l_size as "INDEX SIZE [KB]" from

sysibmadm.admintabinfo where tabschema = 'TPCH' order by

data_object_l_size desc;

TABLE DATA SIZE [KB] INDEX SIZE [KB]

---------- -------------------- --------------------

LINEITEM 833024 144384

ORDERS 183808 43264

PARTSUPP 127872 45568

PART 30720 3456

CUSTOMER 27904 3968

SUPPLIER 1792 512

NATION 256 256

REGION 256 256

Rysunek 1. Zastosowanie dwa razy większych dysków zmniejszy wydajność mierzoną w liczbie

operacji I/O na sekundę

www.sdjournal.org

Bazy danych

nym odczytem, proporcjonalnie do współczyn-

nika kompresji, czytamy większą liczbę rekor-

dów – wirtualnie wzrasta przepustowość sys-

temu dyskowego (patrz Rysunek 2). Kompre-

sja pociąga za sobą nieznaczny wzrost utyliza-

cji procesora – takie zachowanie wpisuje się w

omówiony wcześniej trend wzrostu mocy pro-

cesorów.

rze 1 GB, które wygenerowałem programem

dbgen , dostarczanym razem z testem TPC-H.

Włączenie kompresji ma sens dla tych tabel,

które zajmują dużo miejsca, oraz dla których

kompresja przyniesie odpowiednio duże ko-

rzyści (współczynniki kompresji będą odpo-

wiednio wysokie), dlatego też warto wyko-

nać wstępną analizę potencjalnych zysków z

włączenia kompresji. DB2 dostarcza szereg

odpowiednich widoków oraz funkcji admi-

nistracyjnych, które pozwalają na wyliczenie

miejsca zajmowanego przez tabele, indeksy,

obiekty XML oraz obiekty BLOB. Dostępne

są także funkcje, które pozwalają oszacować

współczynniki kompresji dla danych oraz in-

deksów. Po załadowaniu danych odpowied-

nim zapytaniem pokazanym na Listingu 1

sprawdziłem, ile miejsca zajmują poszcze-

gólne tabele oraz ich indeksy. Do wygenero-

wania raportu wykorzystałem widok admini-

stracyjny ADMINTABINFO ze schematu SY-

SIBMADM. Raport posortowałem malejąco

od największych tabel do najmniejszych. Do

dalszej analizy wybrałem trzy największe ta-

bele, które zajmowały 95% rozmiaru wszyst-

kich tabel testu TPC-H (1.4 GB): LINEITEM

– 950 MB (dane + indeksy), ORDERS – 220

MB oraz PARTSUPP – 169 MB.

Następnie dla każdej z trzech wybranych ta-

bel uruchomiłem funkcję tabelaryczną ADMIN_

GET_TAB_COMPRESS_INFO_V97 z argumentem

ESTIMATE , by wstępnie oszacować współczynni-

ki kompresji. Funkcję uruchomiłem niezależnie

dla każdej z tabel, podając nazwę tabeli jako dru-

gi argument funkcji, tak jak pokazałem to na Li-

stingu 2. Oczywiście mogłem wywołać funkcję

tak, by wyliczyć współczynniki dla wszystkich

tabel (pusty ciąg znaków zamiast nazwy tabeli)

i w warunku WHERE zapytania wybrać interesu-

jące mnie rekordy. Takie podejście byłoby dużo

kosztowniejsze dla bardzo dużej bazy danych. W

moim środowisku (notebook Lenovo T61, Intel

Core2 duo, 2 GHz) wykonanie estymacji dla

największej tabeli LINEITEM zajęło 26 sekund,

więc różnica byłaby niezauważalna – w ogól-

nym przypadku lepiej wykonywać takie anali-

zy tabela po tabeli, przede wszystkim ze wzglę-

du na większą kontrolę. Szacowane współczyn-

niki kompresji przedstawiłem na Listingu 3. Jak

widać, rozmiar słownika kompresji jest podob-

ny dla każdej z tabel (ok. 40 KB), mimo iż tabele

znacznie różniły się rozmiarem.

Kompresję włączyłem instrukcją ALTER

TABLE oraz ALTER INDEX , dla każdej z trzech wy-

branych tabel oraz indeksów tych tabel. Poniżej

przedstawiłem przykładową instrukcję dla tabe-

li LINEITEM . Nazwy indeksów dla tabeli pobra-

łem poleceniem DESCRIBE INDEXES FOR TABLE

TPCH.LINEITEM :

Włączenie kompresji

Do zademonstrowania poszczególnych kro-

ków związanych z włączeniem kompresji wy-

korzystałem tabele oraz dane przygotowa-

ne dla testu TPC-H, zgodnie ze specyfikacją

opublikowaną na stronie www.tpc.org . Tabele

załadowałem plikami tekstowymi o rozmia-

Rysunek 2. Zastosowanie kompresji pozwala zwiększyć wydajność systemu dyskowego i wirtualnie

zwiększyć bufor bazy danych

Listing 2. Oszacowanie współczynnika kompresji dla wybranej tabeli (TPCH.LINEITEM)

select char(tabname,10) as table, compress_dict_size as "DICTIONARY SIZE [B]",

pages_saved_percent as "PAGES SAVED [%]" from table(sysproc.

admin_get_tab_compress_info_v97 ('TPCH','LINEITEM',

'ESTIMATE') ) as t where object_type = 'DATA' ;

alter table tpch.lineitem compress yes;

alter index tpch.l_okln compress yes;

Listing 3. Wyniki wstępnego oszacowania współczynników kompresji (dane bez indeksów)

TABLE DICTIONARY SIZE [B] PAGES SAVED [%]

---------- -------------------- ---------------

LINEITEM 46208 60

ORDERS 40192 61

PARTSUPP 43648 65

Wykonanie instrukcji ALTER .. COMPRESS

zmienia definicję tabeli, natomiast nie tworzy

słownika oraz nie wykonuje przebudowania ist-

niejących tabel do nowego, skróconego forma-

tu. Taką przebudowę połączoną z tworzeniem

słownika można wykonać poleceniem REORG ,

tak jak pokazałem to poniżej. Wykonanie prze-

Tabela 1. Przykładowe dwa rekordy tabeli XML.PARTSUPP

ID PARTSUPP

<row><PS _ PARTKEY>1</PS _ PARTKEY><PS _ SUPPKEY>2</PS _ SUPPKEY><PS _ AVAILQTY>3325</PS _ AVAILQTY><PS _

SUPPLYCOST>7.7164E2</PS _ SUPPLYCOST><PS _ COMMENT>requests after the carefully ironic ideas cajole alongside

of the enticingly special accounts. lufily regular deposits haggle about the blithely ironic deposits.

regular requests sleep c</PS _ COMMENT></row>

<row><PS _ PARTKEY>1</PS _ PARTKEY><PS _ SUPPKEY>2502</PS _ SUPPKEY><PS _ AVAILQTY>8076</PS _ AVAILQTY><PS _

SUPPLYCOST>9.9349E2</PS _ SUPPLYCOST><PS _ COMMENT>careful pinto beans wake slyly furiously silent pinto beans.

accounts wake pendi</PS _ COMMENT></row>

09/2009

Kompresja w DB2

budowy największej tabeli LINEITEM zajęło w

moim środowisku 4 minuty:

testowania mechanizmu ADC powtórnie utwo-

rzyłem tabele oraz indeksy bazy TPCH, dodając

do definicji tabel klauzulę COMPRESS YES , a na-

stępnie załadowałem dane narzędziem IMPORT .

Narzędzie IMPORT ładuje dane przy wykorzysta-

niu instrukcji SQL INSERT i dobrze oddaje spo-

sób, w jaki interaktywne aplikacje wprowadzają

dane. Rozmiar tabel tylko nieznacznie różnił się

od kompresji metodą offline (patrz Listing 6 i

porównaj go z Listingiem 4). Łączny rozmiar ta-

bel skompresowanych automatycznie wyniósł

0.68 GB – dla porównania, kompresując tabe-

le metodą offline, rozmiar wynosił 0.66 GB.

W niektórych przypadkach metoda automa-

tycznego generowania słownika może dać gor-

sze współczynniki kompresji, nie wymaga jed-

nak reorganizacji i rozmiar plików na dysku jest

zbliżony do faktycznego rozmiaru (nie wymaga

pomniejszania).

ty typu BLOB przechowywane są w wydzielo-

nej przestrzeni. Podobnie też dokumenty XML

przechowywane są nie na stronach z danymi

podstawowymi, a w osobnym obszarze hierar-

chicznym. DB2 umożliwia umieszczenie tego

rodzaju obiektów na stronach razem z danymi

podstawowymi. Taka metoda przechowywania

obiektów określana jest jako inline-ing . Poniżej

przedstawiłem definicję tabeli, która przecho-

wuje dokumenty XML na stronie razem z pod-

stawowymi danymi (klauzula INLINE ):

reorg table tpch.lineitem use tempspace1

reorg indexes all for table tpch.lineitem

Po przebudowaniu wszystkich trzech tabel

( LINEITEM , ORDERS , PARTSUPP ) sprawdziłem,

ile miejsca teraz zajmują tabele. Wynik został

przedstawiony na Listingu 4. Jak widać, roz-

miar tabel znacznie się zmniejszył. Łączny roz-

miar bazy danych zmniejszył się z 1.40 GB do

0.66 GB. Oczywiście rozmiar plików na dys-

ku pozostał ten sam, a jedynie wewnętrzne

wykorzystanie przestrzeni zostało zredukowa-

ne. By zredukować także rozmiar plików na

dysku, można wykorzystać instrukcję ALTER

TABLESPACE REDUCE , tak jak poniżej:

create tablespace xmlspace;

create table xml.partsupp

(id int, partsupp xml inline length 1000)

in xmlspace compress yes;

Przy takiej definicji tabeli dokumenty XML

nieprzekraczające 1000 bajtów (klauzula

LENGTH 1000 ) będą przechowywane na stro-

nach razem z podstawowymi danych (pole ID).

Jeśli rozmiar dokumentu przekroczy zdefinio-

wany próg 1000 bajtów, wtedy zawartość po-

alter tablespace userspace1 reduce max

XML, BLOB

DB2 9.7 pozwala także kompresować doku-

menty XML oraz BLOB-y. Standardowo obiek-

Wykonanie powyższej instrukcji spowoduje

zmniejszenie rozmiaru kontenerów (plików)

obszaru tabel USERSPACE1 poprzez usunięcie

pustych ekstent-ów, nieprzydzielonych do żad-

nego z obiektów. Porównałem rozmiary konte-

nera tego obszaru tabel (plik C0000000.LRG

) sprzed i po wykonaniu tej instrukcji i wy-

nik odpowiada uzyskanemu współczynnikowi

kompresji (patrz Listing 5).

Listing 4. Sprawdzenie miejsca zajmowanego przez tabele po kompresji

SELECT CHAR(TABNAME, 10) AS TABLE, DATA_OBJECT_L_SIZE AS "DATA SIZE [KB]",

INDEX_OBJECT_L_SIZE AS "INDEX SIZE [KB]" FROM

SYSIBMADM.ADMINTABINFO WHERE TABSCHEMA = 'TPCH' ORDER BY

DATA_OBJECT_L_SIZE DESC;

Automatyczne

generowanie słownika

Przedstawione powyżej podejście kompresji ist-

niejących danych wymaga reorganizacji tabeli

w trybie offline, co oznacza, że tabela jest nie-

dostępna dla użytkowników na czas przebudo-

wy. Do skompresowania tabeli podczas normal-

nej pracy użytkowników można wykorzystać

specjalną procedurę składowaną ADMIN_MOVE_

TABLE , która pozwala przenosić tabele w trybie

online pomiędzy różnymi obszarami tabel. W

trakcie przenoszenia istnieje możliwość zmia-

ny atrybutów tabeli, w tym tych związanych z

kompresją.

Innym mechanizmem włączenia kompresji,

nieograniczającym dostępności tabeli, jest me-

chanizm automatycznego generowania słowni-

ka kompresji – ADC ( Automatic Dictionary Cre-

ation ). Wykorzystanie tego mechanizmu ograni-

cza się do utworzenia tabeli z włączonym atry-

butem kompresji. Podczas wstawiania danych

do tabeli, DB2 na bieżąco aktualizuje definicję

słownika kompresji. Rekordy wstawiane są jed-

nak w nieskompresowanym formacie aż do mo-

mentu, kiedy DB2 uzna, że jakość wzorców w

słowniku jest na tyle dobra, że można zatwier-

dzić jego definicję. Od tego momentu słownik

nie będzie już aktualizowany, a nowo wstawiane

dane będą zapisywane już w skompresowanym

formacie. Moment, w którym DB2 zaczyna za-

pisywać rekordy w nowym formacie, jest auto-

matycznie wybierany przez DB2. W celu prze-

TABLE DATA SIZE [KB] INDEX SIZE [KB]

---------- -------------------- --------------------

LINEITEM 324864 115072

ORDERS 71040 37760

PARTSUPP 43136 35584

PART 30720 3456

CUSTOMER 27904 3968

SUPPLIER 1792 512

NATION 256 256

REGION 256 256

Listing 5. Porównanie rozmiaru plików bazy na dysku sprzed i po kompresji

Directory of C:\DB2\NODE0000\TPCH\T0000002

2009-07-19 22:54 1 509 949 440 C0000000.LRG

2009-07-19 22:35 0 SQLCRT.FLG

2 File(s) 1 509 949 440 bytes

2009-07-20 02:35 714 080 256 C0000000.LRG

2009-07-19 22:35 0 SQLCRT.FLG

2 File(s) 714 080 256 bytes

Tabela 2. Rozmiar i czas wykonania backup-ów

Rozmiar

backup-u

Czas

Komresja tabel Kompresja backup-u

1536 MB

5m 25s

nie

532 MB

2m 02s

nie

tak

608 MB

2m 09s

tak

nie

456 MB

1m 36s

tak

www.sdjournal.org

Bazy danych

la PARTSUPP zostanie automatycznie przenie-

siona do hierarchicznego repozytorium. Prze-

chowywanie mniejszych obiektów XML ra-

zem z pozostałymi danymi pozwala skorzystać

z omówionych wcześniej algorytmów kompre-

sji. By zademonstrować kompresję dokumen-

tów XML, załaduję narzędziem LOAD tabelę

XML.PARTSUPP danymi z tabeli TPCH.PARTSUPP .

Narzędzie LOAD ładuje dane w sposób bloko-

wy (nietransakcyjny) i podobnie jak narzędzie

IMPORT obsługuje automatyczną kompresję. Po-

lecenia ładujące tabelę przedstawiłem na Listin-

gu 7. W pierwszej linii tworzę kursor oparty na

zapytaniu przetwarzającym wszystkie rekordy

z tabeli TPCH.PARTSUPP , natomiast w drugiej ła-

duję docelową tabelę, podając nazwę kursora

K1 jako źródło ładowanych danych. Zapytanie

pobierające wiersze do załadowania wykorzy-

stuje funkcję XMLROW , która buduje dokument

XML zawierający wartości wszystkich pól ta-

beli ubranych w znaczniki będące nazwami ko-

lumn. W Tabeli 1 pokazałem przykładowe dwa

rekordy z XML.PARTSUPP .

Podobne ćwiczenie wykonałem dla tabeli o

identycznej strukturze co XML.PARTSUPP , lecz

nieskompresowanej. Nieskompresowana tabela

XML zajmowała 357 MB, natomiast utworzo-

na z klauzulą COMPRESS YES – 118 MB, co da-

ło 70% współczynnik kompresji. Warto jeszcze

wspomnieć, że dla obiektów XML DB2 budu-

je dodatkowy (drugi) słownik, ponieważ wzor-

ce dokumentów XML mogą znacząco różnić

się od wzorców występujących w danych pod-

stawowych.

Backup

DB2 udostępnia także mechanizm kompresji

backup-ów, który na bieżąco pakuje bloki prze-

syłane do obrazu backup-u. By wykonać skom-

presowany backup, wystarczy dodać klauzulę

COMPRESS, tak jak w przykładzie poniżej:

ogólnym przypadku czasy mogą się różnić. Je-

śli dysponujemy dostatecznie dużą liczbą dys-

ków, wtedy kompresja backup-u najprawdopo-

dobniej spowolni proces tworzenia archiwum.

Natomiast niezależnie od liczby dysków, skom-

presowana wcześniej baza danych zawsze bę-

dzie się bakcup-ować szybciej, ponieważ bę-

dzie mniej stron do odczytania. Regułę tę po-

twierdza praktyka. Jeden z klientów DB2 i SAP

ERP w Polsce przy wykorzystaniu kompresji

DB2 zmniejszył prawie o połowę rozmiar bazy

danych (z 3 TB) i dzięki temu nie musiał zmie-

niać polityki backup-owej, by wykonać backup

w założonym oknie czasowym.

db2 backup db tpch compress

Opcjonalnie można także podać nazwę biblio-

teki, która ma być wykorzystana do kompreso-

wania bloków danych (jeśli ma być inna niż ta

dostarczona z instalacją DB2). Przeprowadzi-

łem kilka testów, by zorientować się, jak kom-

presja wpływa na rozmiar plików zawierają-

cych obraz backup-u oraz czas jego wykona-

nia. Najpierw wykonałem backup dla bazy nie-

skompresowanej z wyłączoną opcją kompre-

sji backup-u. Następnie jeszcze raz wykona-

łem backup tej samej bazy, ale z włączoną opcją

kompresji backup-u. Obydwa pomiary powtó-

rzyłem dla bazy danych, która zawierała już

skompresowane dane. W Tabeli 2 przedstawi-

łem wyniki doświadczenia. Jak widać, najdłu-

żej wykonywał się backup bazy, która nie za-

wierała skompresowanych tabel oraz dla której

nie włączono kompresji backup-u. Na pierw-

szy rzut oka może dziwić, że włączenie kom-

presji backupu spowodowało skrócenie czasu

jego wykonania (druga pozycja w tabeli). Moż-

na to jednak bardzo prosto wytłumaczyć. Pod-

czas tworzenia archiwum DB2 musi odczytać

całą bazę danych, a następnie zapisać jej zawar-

tość do pliku, będącego obrazem archiwum. W

moim systemie baza była utworzona na dysku

C natomiast obraz archiwum tworzony był na

dysku D. Wąskim gardłem był zapis na dysk,

który zawierał docelowy obraz archiwum. Od-

czyt stron z dysku i ich kompresja w locie by-

ła szybsza niż sam zapis na dysk D. Najlepszy

rezultat został osiągnięty dla kompresowane-

go backup-u i skompresowanej już bazy, po-

nieważ w tym przypadku ilość stron do sko-

piowania oraz zapisania była najmniejsza. W

Wydajność

Bez dwóch zdań – kompresja zużywa moc pro-

cesora! Jeśli ktoś w teście wydajnościowym chce

wycisnąć maksimum, przy dodatkowym zało-

żeniu, że dysponuje nieskończenie szybką macie-

rzą dyskową , wtedy kompresji włączać nie powi-

nien. Oczywiście określenie nieskończenie szyb-

ką wydaje się być przesadą, choć nie do końca.

W laboratoryjnych testach wydajnościowych

(takich jak TPC-H) dokłada się tyle dysków, aż

uzyska się moment, w którym dyski odpowiada-

ją na tyle szybko, że da się osiągnąć 100% utyli-

zację procesorów. W rzeczywistych systemach,

przede wszystkim ze względu na duże koszty,

wymiaruje się systemy, zwracając w pierwszej

kolejności uwagę na wymaganą przestrzeń dys-

kową. W rzeczywistych systemach także nie za-

kłada się 100% utylizacji procesorów – obciąże-

nie jest niejednorodne i zawsze rezerwuje się ja-

kiś zapas mocy na skoki przetwarzania. Dlatego

też w rzeczywistych systemach opartych o DB2

stosuje się kompresję – najczęściej w dużych roz-

wiązaniach, np. takich jak SAP ERP czy SAP BI.

Wnikliwszym czytelnikom polecam opracowa-

nie Waldemara Gaidy DB2 9 Row Compression

in a SAP , w którym opisał wpływ kompresji na

wydajność przetwarzania na podstawie jednego

z rzeczywistych projektów (Google: waldemar

gaida sap compression ). Ogólny wniosek z opra-

cowania jest taki: dzięki kompresji procesy wsa-

dowe działają szybciej, system charakteryzuje

się lepszymi czasami odpowiedzi, wzrasta śred-

nia utylizacja procesorów. Tak jak już wcześniej

wspomniałem, oszczędne formaty zapisu da-

nych na dyskach z jednej strony wpisują się w

trendy rozwoju sprzętu, a z drugiej strony wpi-

sują się w ideę Smarter Planet (Mądrzejszej Pla-

nety), propagowaną przez IBM, zmierzającą do

oszczędności oraz inteligentniejszego i optymal-

niejszego działania.

Tabele tymczasowe

Warto wspomnieć, że DB2 posiada także wbu-

dowane mechanizmy kompresji tabel tymcza-

sowych. Kompresja dla takich tabel stosowana

jest przez DB2 automatycznie. Baza samoczyn-

nie sprawdza, czy wykorzystanie kompresji dla

danej tabeli tymczasowej przyniesie korzyści i

podejmuje decyzję o włączeniu bądź wyłącze-

niu kompresji.

Listing 6. Rozmiary tabel ładowanych instrukcją SQL INSERT z automatyczną kompresją

TABLE DATA SIZE [KB] INDEX SIZE [KB]

---------- -------------------- --------------------

LINEITEM 339072 112128

ORDERS 79744 40064

PARTSUPP 45568 41600

CUSTOMER 15616 3072

PART 12032 3200

SUPPLIER 1792 384

NATION 256 256

REGION 256 256

Listing 7. Załadowanie tabeli XML.PARTSUPP danymi XML

declare k1 cursor for select row_number() over(), xmlrow( ps_partkey, ps_suppkey,

ps_availqty, ps_supplycost, ps_comment) from tpch.partsupp;

ARTUR WROŃSKI

Od piętnastu lat specjalizuje się w rozwiązaniach

przetwarzania danych. Aktualnie pracuje jako

kierownik zespołu technicznego IBM Information

Management Software.

Kontakt z autorem: artur.wronski@pl.ibm.com

load from k1 of cursor insert into xml.partsupp ;

09/2009

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: