Wszystkie bazy danych do niedawna korzystały wyłącznie z jednego rodzaju pamięci masowej: dysków mechanicznych, i rozwój motorów bazodanowych związany był głównie z tym nośnikiem. Baza Oracle nie była wyjątkiem. Aby przyspieszyć operacje na najgorętszych (czyli najczęściej wykorzystywanych) porcjach danych, stosuje się bufor w pamięci RAM serwera, zawierający dane pod postacią bloków pobierany na podstawie ich zawartości na dysku, oraz pamięć podręczną (cache). Najniższym poziomem są dyski mechaniczne, niekiedy podzielone dodatkowo na partycje, woluminy i klasy urządzeń, zależnie od potrzeb w dziedzinie prędkości dostępu. Jest to klasyczny przykład bazy optymalizowanej pod kątem operacji dyskowych. Chociaż stawia duże wymagania pod względem utrzymania i strojenia wydajnościowego, to najlepszy sposób długoterminowego przechowywania informacji.

Aby zmniejszyć liczbę operacji wejścia-wyjścia przy odczycie, wprowadzono indeksy, które podlegają aktualizacji, gdy dane są wstawiane lub modyfikowane. Zamiast analizować całą tabelę (full table scan), by wykonać operację na kolumnie, baza może korzystać z indeksów dla tej kolumny. Opcja in-memory idzie znacznie dalej, gdyż odpowiednio przygotowany zasób (column store) jest przechowywany w całości w pamięci operacyjnej serwera, a to najszybsze dostępne medium. Nie ma potrzeby stosowania klasycznych indeksów, gdyż taki zasób jest bardzo szybki i podlega automatycznej aktualizacji, która nie niesie ze sobą dodatkowych operacji dyskowych.

W połączeniu z formatem wierszowym, również przechowywanym w pamięci, baza może wykonać skomplikowane zapytania przy znacznie mniejszej liczbie kosztownych operacji dyskowych. Przy bardzo dużych, partycjonowanych tabelach opcję in-memory można włączyć np. na jednej partycji: tej, która najczęściej jest używana przy zapytaniach. Zatem dane najgorętsze, najczęściej przetwarzane, znajdą się w pamięci operacyjnej, rzadziej używane – w pamięci podręcznej, a zimne, dla których prawdopodobieństwo dostępu jest niskie – na dyskach mechanicznych.

Jak przyspieszyć transakcje i raporty

Wąskim gardłem klasycznej bazy danych są operacje wejścia-wyjścia, a zatem od dawna wprowadzono mechanizmy optymalizacji, które minimalizują operacje dyskowe. Stosuje się indeksy, które usprawniają pracę raportów, dane się kompresuje, a część najgorętszych danych kopiuje się do pamięci półprzewodnikowej.

Andy Mendelsohn, Senior Vice President Server Technologies w firmie Oracle, wyjaśnia: „Opcja in-memory umożliwia użycie informacji w kolumnowym formacie już w pamięci. Indeksy nie są potrzebne, dlatego nie trzeba ich aktualizować przy operacjach transakcyjnych. W efekcie raporty wykonywane są przeciętnie 100 razy szybciej, operacje łączenia JOIN odbywają się 10 razy szybciej, w praktyce notuje się także dwukrotne przyspieszenie pracy stricte transakcyjnej”.

Najważniejsza różnica w praktycznym zastosowaniu dotyczy zapytań, do których tworzenie indeksów nie ma sensu. Przykładem są zapytania, w których analizowana jest zawartość różnych kolumn, przy czym nie można ustalić a priori, jakie kolumny zawierają najważniejszą informację dla danego zapytania. Właśnie taki przypadek wystąpił w CERN.

Wykorzystanie instrukcji wektorowych obecnych w dzisiejszych procesorach na platformach x86 i SPARC sprawia, że pojedynczy rdzeń procesora platformy x86 może skanować miliardy wierszy na sekundę, a na wysoko wydajnej maszynie Oracle Server M6-32 (najmocniejszy obecnie sprzedawany serwer tej firmy, 32 procesory SPARC po 12 rdzeni każdy, 32 TB RAM) można osiągać tryliony wierszy na sekundę. Opcja in-memory wymaga bazy Oracle 12c w wydaniu Enterprise, jest licencjonowana osobno i dostępna na wszystkich platformach, które wspiera baza.