Oracle Database In-Memory: jak przyspieszyć analitykę nawet kilkudziesięciokrotnie

Czym jest Oracle Database In-Memory

Oracle Database In-Memory to opcja wprowadzona w wersji 12c, która fundamentalnie zmienia sposób przetwarzania zapytań analitycznych. Tradycyjnie Oracle przechowuje dane w formacie wierszowym, co jest optymalne dla operacji OLTP, gdzie aplikacja odczytuje lub modyfikuje pojedyncze wiersze. Problem pojawia się przy analityce, gdy zapytanie musi przeskanować miliony wierszy, ale potrzebuje tylko kilku kolumn.

In-Memory wprowadza dodatkową reprezentację danych w formacie kolumnowym, przechowywaną wyłącznie w pamięci RAM. Co istotne, nie jest to osobna baza danych ani kopia zapasowa. To ten sam zbiór danych, ale zorganizowany w sposób optymalny dla zapytań analitycznych. Oracle automatycznie decyduje, którego formatu użyć dla konkretnego zapytania.

Dual Format Architecture w praktyce

Architektura podwójnego formatu to jedna z najbardziej eleganckich koncepcji w nowoczesnych bazach danych. Te same dane istnieją równocześnie w dwóch postaciach: tradycyjnym row store na dysku (i w buffer cache) oraz column store w dedykowanym obszarze pamięci In-Memory.

Dla systemów OLTP nic się nie zmienia. Operacje INSERT, UPDATE, DELETE nadal korzystają z formatu wierszowego. Transakcje działają dokładnie tak samo, z pełnym wsparciem ACID. Natomiast zapytania analityczne, szczególnie te skanujące duże zakresy danych z agregacjami, automatycznie wykorzystują format kolumnowy.

W praktyce oznacza to, że możesz uruchomić In-Memory na istniejącej bazie produkcyjnej bez modyfikowania aplikacji. System ERP dalej wykonuje tysiące małych transakcji na sekundę, podczas gdy równolegle dział controllingu odpala ciężkie raporty, które wcześniej blokowały system na godziny.

Po włączeniu In-Memory dla głównej tabeli faktów w hurtowni jednego z klientów, raport miesięczny wykonujący pełny skan 800 milionów wierszy spadł z 47 minut do 23 sekund. Bez zmiany ani jednego zapytania SQL. Oczywiście nie każdy system przyspieszy w takim stopniu, największe korzyści pojawiają się tam, gdzie dominują duże skany, agregacje i raporty analityczne na szerokich tabelach faktów.

In-Memory Column Store od środka

IMCS (In-Memory Column Store) to dedykowany obszar pamięci SGA, którego wielkość definiujesz parametrem INMEMORY_SIZE. Dane są tam organizowane w jednostki zwane IMCU (In-Memory Compression Units), typowo zawierające od pół miliona do miliona wierszy.

Każda kolumna w IMCU jest przechowywana osobno i kompresowana niezależnie. Oracle oferuje kilka poziomów kompresji:

• NO MEMCOMPRESS: brak kompresji, maksymalna szybkość skanowania
• MEMCOMPRESS FOR DML: minimalna kompresja, optymalna dla tabel z częstymi modyfikacjami
• MEMCOMPRESS FOR QUERY LOW/HIGH: kompresja zbalansowana dla typowych analiz
• MEMCOMPRESS FOR CAPACITY LOW/HIGH: maksymalna kompresja kosztem CPU

W moim doświadczeniu MEMCOMPRESS FOR QUERY LOW stanowi najlepszy kompromis dla większości środowisk. Osiągasz kompresję 5-10x przy minimalnym narzucie CPU podczas skanowania.

Storage Index

Każdy IMCU zawiera automatycznie tworzony Storage Index przechowujący wartości minimalne i maksymalne dla każdej kolumny w danym IMCU. Gdy zapytanie zawiera predykat typu WHERE data_sprzedazy BETWEEN '2024-01-01' AND '2024-01-31', Oracle może całkowicie pominąć IMCU, które nie zawierają dat z tego zakresu. To tzw. IMCU pruning, widoczny w statystykach jako IM scan CUs pruned.

Mechanizm wykonywania zapytań In-Memory

Gdy optimizer decyduje o użyciu formatu kolumnowego, w planie wykonania pojawia się operacja TABLE ACCESS INMEMORY FULL. Skanowanie przebiega fundamentalnie inaczej niż klasyczny full table scan.

Po pierwsze, Oracle odczytuje tylko te kolumny, które są faktycznie potrzebne w zapytaniu. Jeśli tabela ma 200 kolumn, a SELECT wymaga tylko 5, oszczędzasz 97.5% operacji I/O. Po drugie, predykaty są ewaluowane bezpośrednio na skompresowanych danych dzięki mechanizmowi SIMD (Single Instruction Multiple Data). Procesor może porównać 8 lub więcej wartości jednocześnie w pojedynczej instrukcji CPU.

Po trzecie, przetwarzanie równoległe w trybie In-Memory jest znacznie efektywniejsze. Każdy proces równoległy operuje na osobnych IMCU, eliminując konflikty dostępu. Parametr PARALLEL_DEGREE_POLICY ustawiony na AUTO pozwala Oracle dynamicznie dobierać stopień równoległości.

In-Memory Expressions

Funkcja dostępna od wersji 12.2 pozwala przechowywać w pamięci wyniki obliczeń, a nie tylko surowe dane. Oracle automatycznie identyfikuje często używane wyrażenia (np. UPPER(nazwisko), cena * ilosc, EXTRACT(YEAR FROM data)) i materializuje je jako wirtualne kolumny w IMCS.

Możesz też ręcznie zdefiniować wyrażenia przez atrybut INMEMORY VIRTUAL COLUMNS. W systemach raportowych, gdzie te same kalkulacje powtarzają się w dziesiątkach raportów, zysk wydajnościowy bywa spektakularny.

In-Memory Join Groups

Join Groups to mechanizm optymalizujący złączenia między tabelami w pamięci. Tradycyjny hash join wymaga budowania struktury hash z jednej tabeli i próbkowania jej wartościami z drugiej. W In-Memory Oracle może zastosować wspólny słownik kompresji dla kolumn uczestniczących w złączeniu.

Definiujesz Join Group poleceniem:

CREATE INMEMORY JOIN GROUP jg_sprzedaz (sprzedaz(id_produktu), produkty(id_produktu));

Po załadowaniu obu tabel do IMCS złączenie sprowadza się do porównywania kodów słownikowych zamiast rzeczywistych wartości. W hurtowniach danych z modelem gwiazdy, gdzie tabela faktów łączy się z wieloma wymiarami, Join Groups potrafią przyspieszyć zapytania 3-5 krotnie ponad sam zysk z formatu kolumnowego.

In-Memory Aggregation

Agregacje (SUM, COUNT, AVG, MIN, MAX) wykonywane na danych kolumnowych korzystają z optymalizacji VECTOR GROUP BY. Oracle przetwarza wiele wartości równocześnie, akumulując wyniki w strukturach wektorowych.

Dla zapytań z GROUP BY na kolumnach o niskiej kardynalności (region, kategoria_produktu, rok) Oracle stosuje technikę Key Vector. Zamiast sortować i grupować miliony wierszy, buduje wektor wyników indeksowany wartościami grupującymi. Operacja, która klasycznie wymagała sortowania, wykonuje się w czasie liniowym.

Konfiguracja i zarządzanie pamięcią

Podstawowa konfiguracja wymaga ustawienia parametru INMEMORY_SIZE. Minimalna wartość to 100 MB, ale w środowisku produkcyjnym rzadko ma sens cokolwiek poniżej kilku gigabajtów. Parametr wymaga restartu instancji.

Wybór tabel do załadowania wykonujesz poleceniem ALTER TABLE:

ALTER TABLE sprzedaz INMEMORY PRIORITY HIGH MEMCOMPRESS FOR QUERY LOW;

Priorytet (NONE, LOW, MEDIUM, HIGH, CRITICAL) określa kolejność ładowania po starcie instancji. Tabele z PRIORITY NONE są ładowane dopiero przy pierwszym dostępie (on-demand population).

Możesz też selektywnie włączać In-Memory dla wybranych kolumn lub partycji. W przypadku tabel historycznych z partycjonowaniem czasowym zazwyczaj ma sens ładowanie tylko ostatnich okresów.

Monitorowanie In-Memory

Podstawowe widoki diagnostyczne to:

• V$IM_SEGMENTS: informacje o obiektach załadowanych do IMCS, stopień zapełnienia, status kompresji
• V$INMEMORY_AREA: wykorzystanie pamięci w obszarze In-Memory (1MB pool i 64KB pool)
• V$IM_COLUMN_LEVEL: ustawienia na poziomie kolumn
• V$IM_USER_SEGMENTS: widok uproszczony dla użytkowników nieadministracyjnych

Kluczowa metryka to BYTES_NOT_POPULATED w V$IM_SEGMENTS. Wartość większa od zera oznacza, że segment nie zmieścił się całkowicie w pamięci. Musisz albo zwiększyć INMEMORY_SIZE, albo zrewidować wybór obiektów.

Kiedy In-Memory przynosi największe korzyści

Technologia sprawdza się najlepiej w środowiskach z intensywną analityką: hurtownie danych, systemy BI, raportowanie operacyjne, analiza ad-hoc. Szczególnie korzystają zapytania skanujące duże zakresy danych z agregacjami i złączeniami wielu tabel.

Systemy mieszane OLTP/OLAP (tzw. HTAP) to kolejny idealny scenariusz. Aplikacja transakcyjna działa bez zmian, a równolegle możesz wykonywać analizy w czasie rzeczywistym bez replikowania danych do osobnej hurtowni.

Kiedy In-Memory nie pomoże

Technologia nie jest panaceum. Jeśli Twoje zapytania są wolne przez brak indeksów, nieefektywne złączenia lub źle napisany SQL z funkcjami na kolumnach indeksowanych, In-Memory nie rozwiąże problemu. Zapytanie, które bez sensu wywołuje funkcję PL/SQL dla każdego wiersza, nadal będzie wolne.

In-Memory nie przyspieszy też operacji DML. Wstawianie, aktualizacja i usuwanie rekordów korzysta z tradycyjnego formatu wierszowego. Jeśli problemem jest wydajność ładowania danych, szukaj rozwiązania gdzie indziej.

Wreszcie, technologia wymaga licencji Oracle Database In-Memory, która nie należy do tanich. Dla małych środowisk koszt może być nieuzasadniony.