Producenci systemów operacyjnych, serwerów, sieci i pamięci masowych przez lata prześcigali się w strojeniu przetwarzania baz danych na wszelkie możliwe sposoby. Optymalizacje odbywały się wszakże tylko w ramach poszczególnych warstw. Koordynacja pomiędzy nimi, nawet jeśli miała miejsce, wymagała od administratorów wzniesienia się ponad inżynierskie rzemiosło, czyniąc z nich prawdziwych artystów technologii. Obecnie Oracle dużymi krokami dąży do uproszczenia infrastruktury wspierającej bazy danych, by zwiększyć ich wydajność. Nigdzie nie widać tego wyraźniej, niż w obszarze pamięci masowych, i jest to jeden z powodów rosnącej popularności platform Engineered Systems. Niezależnie od nich, w Oracle 11g oraz 12c pojawiły się technologie stanowiące prawdziwą rewolucję w dziedzinie wydajności. Mowa tu m.in. o agencie Direct NFS zintegrowanym w silniku bazy danych, innowacyjnym protokole OISP, hybrydowej kompresji danych HCC i zarządzaniu nią na podstawie statystyk Heat Maps za pomocą reguł biznesowych ADO, a także funkcjach CloneDB, służących do natychmiastowego wykonywania kopii bazy przy niewielkim zapotrzebowaniu na zasoby.

Złożone systemy zwykle lepiej jest optymalizować poprzez koordynację działania poszczególnych elementów, niż przyspieszanie każdego z nich osobno. Całość środowiska jest bowiem tak wydajna, i tak niezawodna, jak jego najsłabsze ogniwo. Klasyczna architektura środowiska bazy danych jest w tym względzie przykładem wręcz modelowym. Aby zapisać dane, serwer bazy danych musi „przebić się” przez system plików, wywołania systemowe, sterownik karty sieciowej lub kontrolera HBA, oprogramowanie przełącznika Fibre Channel lub Ethernet, oprogramowanie wirtualizatora pamięci masowych i kontrolery pamięci cache w macierzy. To wersja uproszczona – w praktyce jest to proces znacznie bardziej złożony.

Poszczególne warstwy powstawały wraz z rozwojem koncepcji architektur przetwarzania danych. Każda z nich może pochodzić od innego dostawcy, zachowana jest więc separacja – baza danych nie komunikuje się bezpośrednio z macierzą, lecz korzysta z pośredników, tłumaczy, interpretatorów. Nie ma zatem wpływu na to, jak jej żądania zostaną przetworzone. Na poziomie uniwersalnej, scentralizowanej macierzy dane z bazy obsługiwane są w sposób statystyczny, tak samo, jak wszystkie inne żądania I/O. To, czy trafią do bufora cache, a później do grupy dyskowej właściwej dla nich z punktu widzenia wydajności, nie jest decyzją aplikacji, lecz oprogramowania macierzy, które optymalizuje przetwarzanie z perspektywy całości swojego obciążenia.

Aby zoptymalizować takie środowisko, potrzebny jest administrator z otwartą głową i zestawem narzędzi do śledzenia danych w ich wędrówce przez poszczególne warstwy. Taki człowiek musi rozumieć dogłębnie charakter przetwarzania i jego przełożenie na wymagania wobec zasobów. Musi potrafić skonfigurować środowisko tak, by poszczególne warstwy przynajmniej sobie nawzajem nie przeszkadzały. O takiego eksperta jednak coraz trudniej. I właśnie dlatego, innowacje w tej dziedzinie idą obecnie w kierunku upraszczania, a także efektywniejszego przekazywania „intencji” z warstwy aplikacyjnej do warstw niższych.

W dziedzinie infrastruktury samodzielnie optymalizującej swoje działanie na bieżąco, zgodnie z potrzebami aplikacji (ang. application-aware infrastructure), przynajmniej na ten moment, liderem zdecydowanie jest Oracle. Jako wiodący producent oprogramowania, a jednocześnie platform sprzętowych, może je wzajemnie stroić, uzyskując znacznie lepsze efekty, niż w przypadku oprogramowania uniwersalnego, uwzględniającego wiele możliwych architektur i konfiguracji.

„(…) baza danych nie komunikuje się bezpośrednio z macierzą, lecz korzysta z pośredników, tłumaczy, interpretatorów. Nie ma zatem wpływu na to, jak jej żądania zostaną przetworzone. Aby zoptymalizować takie środowisko, potrzebny jest administrator z otwartą głową (…). Taki człowiek musi rozumieć dogłębnie charakter przetwarzania i (…) potrafić skonfigurować środowisko tak, by poszczególne warstwy przynajmniej sobie nawzajem nie przeszkadzały. O takiego eksperta jednak coraz trudniej. I właśnie dlatego, innowacje w tej dziedzinie idą obecnie w kierunku upraszczania, a także efektywniejszego przekazywania „intencji” z warstwy aplikacyjnej do warstw niższych”

Niezależnie od optymalizacji na styku sprzętu i oprogramowania, Oracle stara się wprowadzać także całkiem nowe pomysły. Już w wersji 11g serwera Oracle pojawiły się ważne nowości automatycznie optymalizujące wydajność, w szczególności Direct NFS – klient NFS wbudowany w silnik bazy danych, Hybrid Columnar Compression (HCC), a także funkcje natychmiastowego wykonywania kopii bazy, znane jako CloneDB. W wersji 12c mamy do czynienia z całą falą dalszych istotnych optymalizacji. Na szczególną uwagę zasługują: Oracle Intelligent Storage Protocol (OISP), Heat Maps, oraz Automatic Data Optimization (ADO).

Wyższa inteligencja pomiędzy warstwami

Koncepcja protokołu OISP zakłada, że serwer baz danych instruuje podsystem dyskowy o tym, jaki jest charakter zapisywanych danych, i jak należy traktować je z punktu widzenia wydajności. Każdy typ danych – pliki baz danych, bieżące zmiany, sumy kontrolne, logi transakcyjne, logi archiwalne itd. – otrzymuje własny, odrębny priorytet zapisu, kontrolowany poprzez parametr write bias (proporcja zapisów do odczytów w przyznanym oknie operacji I/O). OISP może także stosować różne wielkości bloków danych dla poszczególnych typów danych, co jest rewolucją z punktu widzenia efektywności zarządzania pojemnością przeznaczoną na bazy danych.

Mając informacje o udziałach sieciowych i wykorzystywanych przez nie grupach dyskowych, system plików może zapisywać dane różnego rodzaju w odpowiednich dla nich lokalizacjach. W typowej instalacji środowiska Oracle administrator musi zdefiniować nawet siedem różnych przestrzeni dyskowych na poszczególne rodzaje danych. Aktywując OISP administrator nie musi już manualnie definiować odrębnych udziałów sieciowych. Serwer baz danych całkowicie autonomicznie instruuje system plików, by stworzył udziały sieciowe, i nie siedem, a tylko dwa. Jeden z nich zostaje przeznaczony na dane, zmiany i sumy kontrolne, drugi zaś na wszystkie rodzaje logów. Z tej perspektywy, OISP znacznie ogranicza ilość pracy administratora, np. w celu stworzenia nowych baz danych dla środowisk testowych. Ogranicza także możliwość popełnienia błędu konfiguracyjnego, skutkującego pogorszeniem wydajności środowiska.

„[Dzięki OISP] Każdy typ danych – pliki baz danych, bieżące zmiany, sumy kontrolne, logi transakcyjne, logi archiwalne itd. – otrzymuje własny, odrębny priorytet zapisu, kontrolowany poprzez parametr write bias (proporcja zapisów do odczytów w przyznanym oknie operacji I/O). OISP może także stosować różne wielkości bloków danych dla poszczególnych typów danych, co jest rewolucją z punktu widzenia efektywności zarządzania pojemnością”

Trzeba w tym miejscu zaznaczyć, że do poprawnego działania protokołu OISP wymagany jest stworzony jeszcze przez Sun Microsystems i intensywnie rozwijany przez Oracle system plików ZFS, który jest jednocześnie menedżerem woluminów. Sam ZFS dostępny jest obecnie w systemach pamięci masowych Oracle ZFS Storage Appliance – dedykowanych dla środowisk Oracle. Czy OISP będzie dostępny także na platformach innych producentów, wyposażonych w system plików ZFS rozwijany na zasadach open source (www.openzfs.org) – tego na razie nie wiemy.

Automatyczna optymalizacja zbiorów danych

Wydajność można optymalizować także poprzez eliminację nadmiaru przetwarzanych danych. W Oracle 12c pojawiły się nowe rozszerzenia języka SQL, dzięki którym dane nie wykorzystywane na bieżąco są kompresowane. Oracle zastosował tu m.in. hybrydową technologię kompresji. Metoda HCC – Hybrid Columnar Compression polega na grupowaniu rekordów w niewielkie zestawy, zwane Compression Units, a następnie transponowaniu ich w ramach tychże zestawów do postaci kolumnowej. Dzięki dużej jednorodności danych w ramach kolumn oraz odpowiedniej optymalizacji algorytmicznej, możliwa jest bardzo silna kompresja – rzędu powyżej 10x.

Automatyczne przydzielanie zasobów aplikacjom w Oracle FS1

Przydzielanie zasobów pamięci masowych środowiskom aplikacyjnym, a także późniejsze zarządzanie przypisanymi zasobami w sposób bezpieczny dla trwającego przetwarzania, to jeden z poważniejszych „bólów głowy” administratorów. Również i w tej dziedzinie Oracle stara się wprowadzać innowacje, czego dowodem są najnowsze macierze blokowe. Oracle FS1 to druga generacja macierzy Oracle przeznaczonej do pracy w sieciach SAN. Jest to de facto kontynuacja rozwoju technologii wywodzącej się z macierzy Pillar Axiom. Oprócz rozbudowanych mechanizmów zoptymalizowanego dla aplikacji Oracle tieringu, nowe macierze oferują także automatyczne przydzielanie zasobów aplikacjom (provisioning). Dzięki temu, a także dzięki technologiom Heat Maps oraz Automatic Data Optimization, nowe macierze umożliwiają przygotowanie systemu pamięci masowych na potrzeby obsługi środowisk aplikacyjnych za pomocą przysłowiowego „jednego guzika”. Ile warta jest taka automatyzacja wie ten, kto miał okazję osobiście konfigurować duże, złożone środowiska i zarządzać nimi, wprowadzając nieustannie zmiany konfiguracyjne zasobów w odpowiedzi na zmieniające się obciążenia, oczekiwania biznesu, problemy, ograniczenia i różne inne „względy”.

Środowisko Oracle 12c samodzielnie zbiera informacje o tym, które dane są najbardziej zmienne, i które są najczęściej odczytywane. Funkcje analityczne Heat Maps analizują częstotliwość wykorzystania danych na dowolnym zadanym poziomie – rekordów, stron bazy danych, czy też obiektów bazy danych, np. tabel. Na tej podstawie administrator może tworzyć polityki Automatic Data Optimization (ADO), służące do automatyzacji zarządzania danymi z punktu widzenia szybkości dostępu do nich. Platforma Oracle 12c wykonuje zdefiniowane polityki automatycznie, ale istnieje również możliwość aktywowania ich ad hoc.

Dotychczas stosowane optymalizacje związane z kompresją dotyczyły głównie danych składowanych na potrzeby analiz i raportowania (hurtownie danych). W wersji 12c kompresja objęła także dane na bieżąco aktualizowane, a więc transakcyjne. Oprócz różnych poziomów wydajności (performance tiers) wynikających z różnej wydajności grup dyskowych, Oracle rozróżnia także kilka poziomów kompresji (compression tiers). Im starsze lub im rzadziej używane są dane, tym silniejszej kompresji mogą być poddawane. To o tyle słuszne, że rozmiar danych przetwarzanych na bieżąco zwykle rośnie powoli, natomiast dane archiwalne „puchną”, zajmując, często zupełnie niepotrzebnie, cenne zasoby.

„Dotychczas stosowane optymalizacje związane z kompresją dotyczyły głównie danych składowanych na potrzeby analiz i raportowania (hurtownie danych). W wersji 12c kompresja objęła także dane na bieżąco aktualizowane, a więc transakcyjne. Co więcej, polityki [ADO] mogą odwoływać się do obiektów biznesowych, takich jak faktura lub zamówienie, a także odzwierciedlać reguły biznesowe. Można np. kompresować i przenosić do archiwum zamówienia 60 dni po zakończeniu ich realizacji, albo kompresować dokumenty, które nie zostały otworzone ani razu w ciągu ostatnich 30 dni”

Przykładowo, rekordy starsze niż 3 miesiące można poddawać kompresji standardowej, a po 12 miesiącach kompresji silniejszej. Wizja Oracle najwyraźniej zakłada, że jeśli dane zostały uznane za archiwalne, powinny być skompresowane. Co więcej, polityki mogą odwoływać się do obiektów biznesowych, takich jak faktura lub zamówienie, a także odzwierciedlać reguły biznesowe. Można np. kompresować i przenosić do archiwum zamówienia 60 dni po zakończeniu ich realizacji, albo kompresować dokumenty, które nie zostały otworzone ani razu w ciągu ostatnich 30 dni.

CloneDB i wbudowany klient Direct NFS

Technologie optymalizujące pojawiły się już w wersji 11g, ale z mojego rozeznania wynika, że nie wszyscy klienci Oracle mieli okazję zapoznać się z nimi. Istotna z punktu widzenia wydajności jest technologia Direct NFS oraz CloneDB. Oracle Direct NFS jest zoptymalizowanym klientem NFS (Network File System), umożliwiającym szybszy i bardziej skalowalny dostęp do zasobów NFS zlokalizowanych w pamięciach masowych z dostępem plikowym (NAS). Direct NFS wbudowany jest bezpośrednio w silnik bazy danych – tak jak funkcje Automatic Storage Management, służące do komunikacji bazy danych z pamięciami z dostępem blokowym, działającymi w sieciach SAN.

Direct NFS gwarantuje szybszy dostęp do danych, niż uzyskiwany z wykorzystaniem klienta NFS działającego jako odrębna usługa w systemie operacyjnym, poza środowiskiem Oracle. Wbudowany w bazę Oracle klient Direct NFS pomija warstwę systemu operacyjnego przy dostępie do danych. Nie wymaga inicjalnego konfigurowania i późniejszego strojenia. Z punktu widzenia wydajności ważne jest to, że dane buforowane są w pamięci cache tylko raz, w przestrzeni użytkownika – nie ma potrzeby utrzymywania odrębnej kopii danych w przestrzeni jądra systemu operacyjnego. Efektem jest wzrost wydajności i mniejsze obciążenie zasobów serwera. Wydajność można podnieść jeszcze bardziej, rozkładając komunikację z pamięciami masowymi na wiele interfejsów sieciowych serwera bazy danych, jeśli tylko są dostępne.

„Direct NFS gwarantuje szybszy dostęp do danych, niż uzyskiwany z wykorzystaniem klienta NFS działającego jako odrębna usługa w systemie operacyjnym. (…) pomija warstwę systemu operacyjnego przy dostępie do danych. Z punktu widzenia wydajności ważne jest to, że dane buforowane są w pamięci cache tylko raz, w przestrzeni użytkownika – nie ma potrzeby utrzymywania odrębnej kopii danych w przestrzeni jądra systemu operacyjnego. Efektem jest wzrost wydajności i mniejsze obciążenie zasobów serwera”

CloneDB to właściwie specyficzne wykorzystanie funkcjonalności Direct NFS. W miejsce tradycyjnego podejścia, w którym duplikat bazy danych wykonuje się za pomocą narzędzia RMAN, CloneDB posługując się technologią Direct NFS w sposób natychmiastowy tworzy klon logiczny na podstawie istniejącej kopii zapasowej. Klon tworzony jest oczywiście w trybie copy-on-write – jedynie bloki które ulegają zmianie zachowywane są lokalnie, podczas gdy dostęp do niezmienionych danych uzyskiwany jest z kopi zapasowej. Takie podejście znakomicie przyspiesza tworzenie klonów baz danych oraz umożliwia tworzenie wielu odrębnych klonów na bazie pojedynczego zestawu danych, co znacząco ogranicza wymogi na pojemność dyskową systemu.

Piotr Zając

Autor jest specjalistą w dziedzinie architektury rozwiązań Oracle w firmie Advatech. Wcześniej pracował w Sun Microsystems oraz Oracle. Można się z nim skontaktować pod adresem pzajac w domenie advatech kropka pl.

Autorem zdjęcia Piotra Zająca jest Monika Dyba.