O czym mówią testy

Praktyczną przydatność benchmarków baz danych podważano od dawna. Mimo to producenci oprogramowania nie szczędzą dziesiątek milionów dolarów na przeprowadzanie kolejnych testów.

Praktyczną przydatność benchmarków baz danych podważano od dawna. Mimo to producenci oprogramowania nie szczędzą dziesiątek milionów dolarów na przeprowadzanie kolejnych testów.

Testy wydajności baz danych przypominają zawody sportowe. Firmy przy-gotowują swoje bazy, podobnie jak sportowcy miesiącami trenujący przed olimpiadą, by w krótkim sprawdzianie osiągnąć rekordowy wynik. Przygotowania pochłaniają ogromne koszty, w obu przypadkach zdarza się stosowanie niedozwolonego dopingu. Z tą różnicą, że mistrza olimpijskiego wyłania się raz na cztery lata, podczas gdy dopiero co zdobyte trofeum rekordzisty baz danych można stracić już następnego dnia.

Potrzeba rywalizacji

Lata 60. i 70. to czas przetwarzania wsadowego. Na początku lat 80. coraz większą rolę zaczęły odgrywać transakcje online. Pierwszym testem w systemie online był TP1 opracowany przez IBM. Pomiar opierał się jednak na analizie transakcji w trybie wsadowym, bez uwzględniania wpływu sieci i interakcji z użytkownikiem. W roku 1985 Jim Gray zaproponował pomiar wydajności systemów on-line za pomocą metodologii DebitCredit, wymagając, by test uwzględniał całkowity koszt systemu. Obowiązkowe było uwzględnienie wpływu użytkowników i rozmiaru tabel. Został także określony wymóg, by 95% odpowiedzi było przekazywanych w czasie krótszym niż sekunda.

Problemem był brak instytucji nadzorującej testy, a wprowadzenie DebitCredit pogłębiło chaos. W latach 80. każdy producent dostosował TP1 i DebitCredit do własnego systemu, a wyniki testów stały się nieporównywalne. Przełomem było powołanie organizacji kontrolującej przebieg testów. W 1988 r. powstało Transaction Processing Preformance Council (TPC), stowarzyszenie producentów, którego celem było miarodajne testowanie systemów bazodanowych.

Od A do W

Pierwszy test TPC-A niemal dokładnie odpowiadał metodologii DebitCredit. Pierwszy wynik TPC-A wynosił 33 tpsA (transakcje na sekundę w teście TPC-A) przy koszcie 25 tys. USD. Ostatni wynik TPC-A to 3692 tpsA przy koszcie transakcji nie przekraczającym 5 tys. USD. Tak duży wzrost w ciągu kilku lat był spowodowany m.in. tym, że w wyniku pojawienia się w miarę rzetelnego tes- tu porównawczego producentom zaczęło bardziej zależeć na poprawie wydajności i wyeliminowaniu wąskich gardeł serwerów.

Test TPC-B był tak naprawdę testem TP1, opartym na przetwarzaniu wsadowym. Cieszył się dużą popularnością wśród producentów, ponieważ był testem typu "stress" dla samej bazy danych. Inne zdanie na temat jego przydatności mieli klienci, dla których ważny był czas potrzebny do otrzymania wyniku na monitorze, a nie czas przetwarzania w bazie danych.

W 1992 r. opracowano test TPC-C, najbardziej znany benchmark. Opiera się on na wyimaginowanej strukturze systemu przetwarzania zamówień. Precyzyjnie definiuje strukturę bazy, a także sposób tworzenia losowych danych. Test polega na wykonaniu ciągu operacji, z których każda ma swoją wagę, ściśle określone są elementy badające cechy transakcyjności (musi obejmować m.in. uszkodzenie dysku twardego). TPC-C jest przeznaczony dla środowiska OLTP. Obejmuje jednoczesne wykonywanie wielu transakcji - zarówno online, jak i operacji wsadowych. Zakłada się, że do systemu musi uzyskać dostęp wiele terminali.

Z czasem pojawiła się konieczność wykonywania testów hurtowni danych. W tym celu opracowano TPC-D, który ściśle określa wielkość i zawartość bazy danych. Jest ustalonych kilka kate- gorii "rozmiaru" bazy danych (obecnie 1-10 000 GB), bez ograniczonego rozmiaru na indeksy. Dość szybko TPC-D okazał się niemiarodajny. W hurtowniach danych można bowiem określić dwa typy zapytań - dobrze znane analizy (np. sprzedaż w zależności od regionu) i pytania mające na celu znalezienie ukrytych zależności. Benchmark TPC-D podzielono więc na dwie klasy: TPC-H, gdzie nie są znane zapytania kierowane do systemu, i TPC-R, w którym określono standardowy zbiór zapytań.

Nowym testem jest TPC-W, w którym baza danych jest obsługiwana za pośrednictwem interfejsu WWW. W nim odbywa się analiza zarówno wydajności serwera internetowego oraz bazy danych, jak i poziomu bezpieczeństwa. Na razie w tej kategorii dostępny jest tylko jeden test.

Wraz ze wzrostem popularności testów TPC pojawiła się konieczność dalszego sformalizowania procedury. Szybko wyszło na jaw, że wiele firm specjalnie dostosowało swoje produkty pod kątem testowania. To zmusiło TPC do przyjęcia zasady, że testom jest poddawane tylko oprogramowanie komercyjne, bez żadnych zmian czy przeróbek. W roku 1993 odkryto, że Oracle wprowadził do swojej bazy specjalny typ "ukrytej" transakcji, co wpłynęło na wyniki testów. W efekcie TPC przyjęło dosyć niejasną klauzulę stanowiącą, iż niedozwolone są wszelkie zmiany, które polepszają wyniki testów, a nie są wykorzystywane w rzeczywistych aplikacjach. Paradoksalnie ten nieprecyzyjny zapis sprawił, że ostatnio rzadko zdarzają się naruszenia zasad wynikające jawnie ze złej woli producenta.

Wróżenie z testów

Minęła era, gdy serwer bazodanowy był samodzielnym komputerem. Obecnie większość rekordów osiągają środowiska klastrowe. Przy okazji ujawnia się słabość testów TPC, wynikająca z braku uwzględniania stopnia trudności zarządzania serwerem. Zarządzanie bazą na mainframe w 1993 r. było znacznie prostsze niż administrowanie dzisiaj klastrem 32-węzłowym ze 128 procesorami Intela. Testy TPC nie oceniają również środowiska programistycznego czy jego zgodności ze standardami. Każda baza ma własny dialekt SQL i to również niesie określone konsekwencje dla klienta.

TPC nie zajmuje się dostępnością bazy danych. Stosowane w testach klastry zwiększające wydajność (np. przodujące obecnie bazy DB 2 i SQL 2000) nie wpływają na podniesienie dostępności. W przypadku gdy jeden z węzłów przestaje odpowiadać, dana część bazy jest niedostępna dla użytkowników. TPC-C obejmuje tylko "pewność" zapisu. Warto zwrócić uwagę, że takie bazy, jak Oracle Parallel Server mają inną architekturę. Dzięki temu, że dyski są dzielone przez wszystkie elementy klastra, użytkownik ma dostęp do informacji nawet w razie awarii jednego węzła.

Ponadto w testach TPC czasami "faworyzowane" są określone rozwiązania programowe. Przykładowo, test TPC-D nie zezwala na agregację danych i przechowywanie ich w oddzielnych plikach (na tym opierają się usługi OLAP w SQL 7.0). Nie zabraniają natomiast wykonywania preagregacji w bazie danych, tak jak odbywa się to w Oracle 8i.

Testy niewątpliwie pokazują, jaką maksymalną wydajność można osiągnąć przy danej konfiguracji sprzętowo-programowej. Jeżeli ktoś kupuje serwer w cenie ponad 14 mln USD, zapewne ucieszy go wynik 441 tys. transakcji na minutę w teście TPC-C przy średnim koszcie transakcji ok. 32 USD (to najnowsze wyniki bazy IBM DB2 UDB 7.1 na serwerach Netfinity). Co ma jednak zrobić menedżer, gdy dysponuje 20 tys. USD, za które musi kupić i oprogramowa- nie, i serwer? Czy ma zdecydować się na SQL Server 2000, który charaktery- zuje się najniższym kosztem transakcji (12,5 USD)? A może powinien za namową programistów wybrać bazę Oracle, ponieważ tworzenie w niej aplikacji przebiega szybko dzięki wygodnemu PL/SQL? Tych dylematów benchmarki TPC nie rozstrzygną.

Czy w ogóle testy porównawcze, w których biorą udział coraz bardziej zróżnicowane konfiguracje, mają sens? Wydaje się, że w najbliższym czasie zmiana formuły testów jest nieuchronna. Powinny uwzględniać m.in. pracę aplikacji i analizę pod kątem "użyteczności" bazy. W przeciwnym razie będzie utrwalał się pogląd, że testy są coraz mniej przekonywującym narzędziem marketingowym. Warto wspomnieć o jednej cesze testów TPC. Zmiana metodologii testów następuje bardzo rzadko. Na przykład opracowywana przez 2 lata wersja 4.0 TPC-C nie została ostatecznie zatwierdzona - zarówno z powodu dużej popularności TPC-C 3.0, jak i ryzyka, że wyniki z wersji 4.0 (która obejmowała chociaż niektóre współczesne możliwości baz danych) nie będą mogły być porównywane z testami poprzednimi.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200