W epoce technologii chmurowych pojawiają się czasem sprzętowe perełki, które zachwycają administratorów i programistów, przedkładających twarde fakty nad eteryczne byty. Jednym z takich rozwiązań jest nowy procesor SPARC M7 dostarczony przez dział engineered systems firmy Oracle.

Pierwszy rzut oka na testową konfigurację wystarczył, żeby poczuć ekscytację – jak często macie okazję pracować na komputerze z 256 rdzeniami na pokładzie i pół terabajta pamięci RAM? Jednak nie liczba corów jest największą zaletą procesora Sparc M7. Są nią koprocesory DAX (Data Analytics Accelerator). Żeby jednak dobrze zrozumieć ich rolę, przyjrzyjmy się najpierw nowej funkcjonalności bazy Oracle 12.1.0.2 – In-Memory.

> IN-MEMORY DATABASE W PRAKTYCE

Wielkość wykorzystywanych obecnie relacyjnych baz danych wymaga stosowania elastycznych rozwiązań pozwalających na przechowywanie danych zarówno w postaci wierszowej, jak i kolumnowej. Systemy OLTP nadal korzystają na postaci wierszowej, podczas gdy duże zapytania analityczne wiele zyskują na przechowywaniu danych w postaci kolumnowej.

Coraz częściej jednak ciężko jest jednoznacznie określić charakterystykę danego systemu – w wielu przypadkach mamy bowiem do czynienia z systemami mieszanymi. Niby jest to system transakcyjny, ale na bieżąco musimy wykonywać bardzo dużo zapytań analitycznych. Na pierwszy rzut oka sprawa wydaje się łatwa do rozwiązania w związku z dostępem do coraz tańszych kości pamięci RAM i możliwości obsługi dużej ilości pamięci w nowych serwerach. Problem jest jednak bardziej złożony – pojemna pamięć współdzielona oznacza konieczność istnienia mechanizmów chroniących takie obszary, takich jak np. latche i mutexy. W efekcie ciągłe zwiększanie wielkości pamięci SGA (a w ramach niej bufora BUFFER CACHE) prowadzi często do sytuacji nieco absurdalnej – zapytania wykonywane z wielu sesji jednocześnie odpowiadają szybciej, kiedy czytają z dysku, niż kiedy walczą o blokady na poziomie dużych obszarów pamięci współdzielonej! Firma Oracle zaadresowała ten problem w funkcjonalności In-Memory, dostępnej za dodatkową opłatą wraz z bazą 12.1.0.2 EE (patrz schematy).

Opcja In-Memory pozwala trzymać w pamięci kolumnową reprezentację tabel w postaci skompresowanej, co zdecydowanie przyspiesza wszelkie zapytania analityczne, wykonywane równolegle. Bardzo istotny z punktu widzenia administratorów i programistów jest fakt, że umieszczenie tabeli w pamięci jest przezroczyste dla zapytań SQL – nie wymaga więc żadnych dodatkowych działań od programistów. Cała procedura sprowadza się do wydania pojedynczego polecenia ALTER dla tabeli, np.:

• ALTER TABLE skiper INMEMORY MEMCOMPRESS FOR CAPACITY LOW;
• ALTER TABLE kowalsky INMEMORY MEMCOMPRESS FOR CAPACITY HIGH;
• ALTER TABLE szeregowy INMEMORY MEMCOMPRESS FOR QUERY LOW;
• ALTER TABLE rico INMEMORY MEMCOMPRESS FOR QUERY HIGH;

Od tej pory tabele SKIPER, KOWALSKY, SZEREGOWY i RICO będą załadowane do pamięci przy pierwszym odczycie z odpowiednimi stopniami kompresji, zdefiniowanymi w powyższych atrybutach. Będą też istniały w dwóch typach reprezentacji jednocześnie – na dysku w reprezentacji wierszowej, a w pamięci w kolumnowej.