VI Seminarium PLOUG Warszawa Styczeñ 2003 Zastosowania tabel o strukturze indeksu - (Index Organized Table) Wojciech Karwowski Oracle Polska Na podstawie artyku³u Index Organized Tables.When should they be used?, Alon Peled Alon Peled jest konsultantem, specjalizuj¹cym siê w projektowaniu i dostrajaniu systemów opartych na bazach Oracle, a tak e w prowadzeniu szkoleñ w ich zakresie. Ma 14-letnie doœwiadczenie na rynku informatycznym. T³umaczenie i redakcja: Wojciech Karwowski; Wojciech Karwowski jest pracownikiem firmy Oracle Polska od 6 lat. Jako ISV Channel Consultant zajmuje siê wsparciem technologicznym partnerów firmy Oracle. Jest ekspertem od zagadnieñ wydajnoœciowych. Wykorzystano materia³y Oracle Corporation oraz Palcom Systems Ltd. Streszczenie Baza danych Oracle umo liwia osi¹gniêcie tego samego celu ró nymi sposobami. Ka dy problem mo na rozwi¹zaæ wieloma metodami, a ka de ograniczenie mo na obejœæ rozmaitymi drogami. Od wersji Oracle8 nawet organizacjê tabel mo na zrealizowaæ na dwa sposoby: wed³ug stosu (heap) lub wed³ug indeksu (Index Organized Table ). Ka dy administrator baz danych zadaje sobie to pytanie: kiedy i w jakich bazach uzasadnione jest stosowanie tabel zorganizowanych wed³ug indeksu? Zastrze enie: Poni sze informacje s¹ osobistymi opiniami autora i nie powinno siê ich wykorzystywaæ w systemach eksploatacyjnych bez odpowiedniego testowania. Autor nie ponosi odpowiedzialnoœci za szkody wynik³e z wdra ania funkcji opisanych w niniejszym dokumencie.
Zastosowania tabel o strukturze indeksu (Index Organized Table) 45 1. Wprowadzenie Od wczesnych wersji Oracle w organizacji danych tabel stosowano jedną metodę: stos (heap). Wszystkie wiersze umieszczano w blokach danych bez określonego porządku i bez definiowania połączeń. Aby przyspieszyć pobieranie danych, administrator w razie potrzeby dodawał indeksy. Zapytania wyszukujące specyficzny wiersz lub przedział wierszy wymagały wykonania przez bazę następujących kroków: A. odczytania segmentu indeksu, B. wyszukania odpowiedniego klucza w zrównoważonym drzewie (B-tree) indeksu, C. pobrania odpowiednich identyfikatorów wierszy, D. uzyskania dostępu do odpowiedniego bloku danych przez identyfikatory wierszy. Na rysunku 1 przedstawiono organizację z zastosowaniem indeksu i stosu. [opis rysunku 1] index segment segment indeksu table segment segment tabeli
46 Wojciech Karwowski 2. Wady korzystania z indeksu 2.1 Pamięć masowa: Indeks zajmuje dodatkową pamięć masową. W segmencie indeksu muszą zostać zapisane wartości kluczy i identyfikatory wierszy wskazujące na odpowiednie bloki danych. 2.2 Wydajność: Każda operacja DML (, lub uaktualnienie kolumny klucza) albo zapytanie przez indeks wymaga wykonania przez bazę następujących zadań: pierwszego wczytania segmentu indeksu do pamięci i dopiero wtedy pobrania bloku danych z dysku, drugiego uaktualnienia bloków tabeli i indeksu. 3. Tabele zorganizowane wg indeksu () W celu rozwiązania opisanych wyżej problemów firma Oracle opracowała nowy sposób organizacji tabel: Dane są zapisywane w tabeli w taki sam sposób, jak w indeksie. Tabela zachowuje się jak zwykła tabela z dodatkowym indeksem, ale do przyspieszania wyszukiwania wierszy nie trzeba stosować zewnętrznego indeksu. Wiersze są już we właściwym porządku i występują między nimi odpowiednie połączenia. Teoretycznie tabela zajmuje mniej miejsca w pamięci masowej, a wyszukanie konkretnych wierszy lub przedziału wierszy wymaga wykonania mniejszej liczby fizycznych operacji wejścia-wyjścia. Administrator, który chce przyspieszyć działanie bazy, może przenieść kolumny niezawierające wartości kluczowych do innej przestrzeni tabeli. Dzięki temu liczba bloków zawierających wartości kluczowe się zmniejsza. Na rysunku 2 przedstawiono metodę organizacji :
Zastosowania tabel o strukturze indeksu (Index Organized Table) 47 [opis rysunku 2] block organization organizacja bloków 4. Porównanie funkcji Funkcja Sposób unikalnej identyfikacji wierszy Tabela ze stosem Identyfikator wiersza Tabela zorganizowana wg indeksu Klucz podstawowy Duplikacja wierszy Dozwolona Obowiązkowy klucz podstawowy Może stanowić część klastra Tak Nie Może zawierać typy danych LONG i LOB Tylko LOB LONG i LOB Obsługa przez aplikacje Zwykła Zwykła, jak w tabeli ze stosem Rozproszony SQL Dozwolony Tylko od wersji Oracle9i Replikacja Dozwolona Tylko od wersji Oracle9i Partycjonowanie Dozwolone Tylko od wersji Oracle8i
48 Wojciech Karwowski 5. Który sposób jest szybszy? 5.1 Opis testu Wykonano kilka testów. Do tabel obu typów wstawiono ponad 500 000 wierszy. Następnie wiersze te pobierano, uaktualniano i usuwano ponad 10 000 razy. Tabele miały różne wielkości od 10 do ponad 100 MB. Testy wykonywano na krótkich i długich wierszach, średnio od 18 do 170 bajtów. Tworzono także indeksy podstawowe i podrzędne. 5.2 Testowane aspekty Przetestowano następujące aspekty działania tabel: A. obciążenie przez dane przez operację wstawiania (), B. przetwarzanie wierszy uaktualnianie () oraz usuwanie (), C. pobieranie konkretnych wierszy przez indeks podstawowy, D. skanowanie przedziału wierszy przez indeks podrzędny, E. wszystkie powyższe testy przeprowadzono na wierszach o różnej długości. 5.3 Wyniki testów 5.3.1 Tabela z dwoma kolumnami + tylko klucz podstawowy 3 9 11 15 2 9 25 27 0 5 10 15 20 25 30 [opis tabeli 1] W przypadku krótkich kolumn czas realizacji zapytania był o ponad 400% krótszy. To klasyczny przykład tabeli, w której organizacja zapewnia największe korzyści.
Zastosowania tabel o strukturze indeksu (Index Organized Table) 49 5.3.2 Tabela z wieloma kolumnami + jeden indeks jako klucz podstawowy 36 49 48 66 24 33 36 38 0 10 20 30 40 50 60 70 [opis tabeli 2] Kiedy tabela zawiera ponad dwie lub trzy kolumny, korzyści zapewniane przez rozwiązanie są niewielkie i należy tutaj raczej zwrócić uwagę na czas zapytania, który jest o 40% krótszy niż w tabelach ze stosem. 5.3.3 Tabela z wieloma kolumnami + klucz podstawowy + parametr PCTTHRESHOLD 36 78 27 66 9 38 33 36 0 10 20 30 40 50 60 70 80 90 [opis tabeli 3] Kiedy stosuje się parametr PCTTHRESHOLD, zapytania w tabelach są realizowane o 400% szybciej niż w tabelach ze stosem.
50 Wojciech Karwowski 5.3.4 Tabela z wieloma kolumnami + klucz podstawowy + indeks podrzędny Secondary index use 69 61 56 41 127 162 230 321 844 870 0 100 200 300 400 500 600 700 800 900 1000 [opis tabeli 4] W aspekcie czasu realizacji zapytania w tabelach, korzystanie z indeksu podrzędnego nie zapewnia większych korzyści niż zastosowanie indeksu podrzędnego w tabelach ze stosem. 5.3.5 Długie wiersze, klucz podstawowy + klucz podrzędny + użycie parametru PCTTHRESHOLD Secondary index use 71 35 57 19 175 215 229 341 831 970 0 200 400 600 800 1000 1200 [opis tabeli 5] W przypadku stosowania parametru PCTTHRESHOLD w tabeli, nawet w kontekście indeksu podrzędnego, wyniki ulegają istotnej zmianie. Choć zapytania o indeks podrzędny wykonywane były 15% wolniej, zapytania przez klucz podstawowy w tabeli były o 400% szybsze.
Zastosowania tabel o strukturze indeksu (Index Organized Table) 51 5.3.6 Jak wyżej, ale tylko 5000 wierszy Secondary index use 2 2 3 3 5 0 1 2 3 4 5 6 [opis tabeli 6] Ten test ma być może największe znaczenie: jeśli tabele są niewielkie, metoda organizacji nie ma znaczenia. W obu przypadkach wyniki są podobne. 6. Konkluzje Stosowanie tabel może znacznie przyspieszyć działanie bazy w niektórych przypadkach. Największe korzyści można zaobserwować w dużych tabelach, w których ważny jest czas działania klucza podstawowego przy wyszukiwaniu konkretnych wierszy oraz gdzie operacje DML wykonywane są na niewielkich zbiorach danych. W większości przypadków, tam gdzie wyszukuje się konkretnych wierszy przez klucz podstawowy, tabele działają dużo szybciej niż te ze stosem. Korzyści sięgają od 15 do 400% i zależą od długości wierszy, liczby kolumn oraz stosowania parametru PCTTHRESHOLD. Jeśli w danej aplikacji jest realizowana większa liczba transakcji, należałoby przeprowadzić odpowiednie, własne testy. To samo dotyczy stosowania indeksu podrzędnego. W przypadku tabel o niewielkiej liczbie wierszy (poniżej 5 000) nie zauważyłem wyraźnych różnic w wydajności. Podobnie jak w przypadku innych opcji lub decyzji, które należy podjąć przy programowaniu aplikacji, obie metody organizacji należy przetestować we właściwym środowisku. Moich wniosków nie należy wykorzystywać w praktyce bez wnikliwego przetestowania. Nie należy zakładać, że ktoś wie więcej o systemach niż sam administrator bazy. 7. Składnia CREATE TABLE nazwa tabeli (definicja_kolumny PRIMARY KEY, definicja_kolumny, definicja_kolumny ) ORGANIZATION INDEX TABLESPACE nazwa_przestrzeni_tabeli
52 Wojciech Karwowski PCTTHRESHOLD wart_procentowa INCLUDING nazwa_kolumny OVERFLOW TABLESPACE nazwa_innej_przestrzeni_tabeli W tabeli zorganizowanej wg indeksu konieczne jest określenie klucza podstawowego, ponieważ to on w unikalny sposób określa dany wiersz. Klucz podstawowy stosuje się zamiast identyfikatora wiersza przy bezpośrednim dostępie do wierszy zorganizowanych wg indeksu. PCTTHRESHOLD wartość_całkowita Określa wartość procentową przestrzeni zarezerwowanej na blok indeksu w wierszu tabeli zorganizowanej wg indeksu. Ta część wiersza, która wykracza poza zdefiniowany próg zapisywana jest w segmencie nadmiaru (overflow). Wartość PCTHRESHOLD musi się mieścić w przedziale 1-50. Ograniczenie: PCTTHRESHOLD musi być wystarczająco duży, aby pomieścić klucz podstawowy. Nie można określić progu PCTTHRESHOLD dla indywidualnych partycji tabeli zorganizowanej wg indeksu. OVERFLOW Wiersze danych tabeli zorganizowanej wg indeksu przekraczające określony próg są umieszczane w segmencie danych określonym w tej dyrektywie. Kiedy tworzona jest tabela zorganizowana wg indeksu, Oracle sprawdza maksymalną wielkość każdej kolumny i określa, jaki może być najdłuższy możliwy wiersz. Jeśli konieczne jest wprowadzenie wiersza przekraczającego tę wielkość, ale nie określono parametru OVERFLOW, Oracle zgłasza błąd i nie wykonuje dyrektywy CREATE TABLE. Taka kontrola gwarantuje, że późniejsze operacje DML na tabeli zorganizowanej wg indeksu powiodą się mimo braku segmentu nadmiaru. Wszystkie atrybuty fizyczne i parametry pamięci masowej określone po słowie kluczowym OVERFLOW dotyczą tylko segmentu nadmiaru tabeli. Atrybuty fizyczne i parametry pamięci masowej samej tabeli zorganizowanej wg indeksu, domyślne wartości opisujące wszystkie jej partycje oraz wartości opisujące indywidualne partycje należy umieścić przed tym słowem kluczowym. Jeśli tabela zorganizowana wg indeksu zawiera przynajmniej jedną kolumnę LOB, wartości LOB będą zapisywane na zewnątrz, chyba że zostanie określone słowo kluczowe OVERFLOW. Tak będzie nawet w przypadku obiektów na tyle małych, że można je zapisać wewnątrz tabeli. INCLUDING nazwa_kolumny Określa ona kolumnę, w miejscu której przebiega podział tabeli zorganizowanej wg indeksu na części indeksu i nadmiaru. Wszystkie kolumny, które nie zawierają klucza podstawowego i występują po nazwa_kolumny, są zapisywane w segmencie nadmiaru. Nazwa_kolumny jest albo nazwą ostatniej kolumny z kluczem podstawowym, albo dowolną kolejną kolumną niezawierającą takiego klucza. Ograniczenie: Nie można określić tej dyrektywy dla indywidualnych partycji tabeli zorganizowanej wg indeksu.
Zastosowania tabel o strukturze indeksu (Index Organized Table) 53 Dyrektywa kompresji Włącza lub wyłącza kompresję. Dyrektywa ta jest przydatna, gdy klucz podstawowy występuje w więcej niż jednej kolumnie. COMPRESS Włącza kompresję kluczy. W ten sposób eliminuje się zdublowane wartości w kolumnie kluczy w tabelach zorganizowanych wg indeksu. Podając wartość_całkowitą, określa się długość przedrostka (liczbę kolumn przedrostka, które mają podlegać kompresji). Wartość przedrostka może się mieścić w przedziale od 1 do liczby kolumn z kluczami podstawowymi minus 1. Domyślna długość przedrostka to liczba kolumn z kluczami podstawowymi minus 1. Ograniczenie: Na poziomie partycji można określić parametr COMPRESS, ale nie można określić długości przedrostka przez podanie wartości_całkowitej. NOCOMPRESS Wyłącza kompresję kluczy w tabelach zorganizowanych wg indeksu. Jest to ustawienie domyślne. 8. Przykład: SQL> Create table info_o_pracowniku ( id number not null constraint klucz_inf_o_pracowniku primary key, Nazwisko varchar2(50), Adres varchar2(250), Telefon varchar2(50), Suma1 number, Suma2 number, Data1 date, Data2 date, Ilość1 number, Ilość2 number, Tekst char(50) ) ORGANIZATION INDEX PCTTHRESHOLD 2 OVERFLOW TABLESPACE ts_info, SQL> Create index info_o_pracowniku_i2 on info_o_pracowniku (Nazwisko) tablespace ts_indeks; 9. Materiały referencyjne Oracle Technology Network: www.otn.com