In-Memory — zestaw koncepcji przechowywania danych, gdzie są one przechowywane w pamięci operacyjnej aplikacji, a dysk służy do backupu. W tradycyjnych podejściach dane są przechowywane na dysku, a pamięć pełni funkcję bufora. Na przykład, aplikacja internetowa z backendem do przetwarzania danych pobiera je z magazynu: otrzymuje, przekształca, a przez sieć przesyła dużą ilość danych. W In-Memory obliczenia są przesyłane do danych — do magazynu, gdzie są przetwarzane, przez co sieć jest mniej obciążona.
Jakie jeszcze możliwości daje In-Memory i na czym polega to podejście, opowie Władimir Pligin — inżynier w firmie GridGain. Ten przeglądowy materiał będzie przydatny dla deweloperów backendu aplikacji internetowych, którzy nie pracowali z In-Memory i chcą spróbować, lub interesują się nowoczesnymi trendami w rozwoju rozwiązań programowych i projektowaniu architektury.
Uwaga. Artykuł oparty jest na transkrypcji wystąpienia Władimira na konferencji #GetIT Conf. Przed wprowadzeniem izolacji społecznej regularnie organizowaliśmy spotkania i konferencje dla programistów w Moskwie i Petersburgu: omawialiśmy trendy, aktualne problemy w rozwoju, ich rozwiązania. Teraz nie można zorganizować konferencji, więc to idealny czas, aby podzielić się przydatnymi materiałami z przeszłości.
Kto i jak wykorzystuje In-Memory
In-Memory najczęściej wykorzystuje się tam, gdzie wymagane jest szybkie interakcje z użytkownikiem lub przetwarzanie dużych zbiorów danych.
- Banki wykorzystują In-Memory, na przykład, aby zmniejszyć opóźnienia w dostępie do aplikacji przez klientów lub do analizy klienta przed przyznaniem kredytu.
- Fintech wykorzystuje In-Memory, aby poprawić wydajność usług i aplikacji dla banków, które zlecają przetwarzanie i analizę danych na zewnątrz.
- Firmy ubezpieczeniowe: do oceny ryzyk, na przykład analizując dane klienta z kilku lat.
- Firmy logistyczne. Przetwarzają wiele danych, na przykład, aby obliczać optymalne trasy transportu towarów i pasażerów z tysiącami parametrów, śledzić status przesyłek.
- Handel detaliczny. Rozwiązania In-Memory pomagają szybciej obsługiwać klientów i przetwarzać duże ilości informacji: dostawy, faktury, transakcje, dostępność tysięcy produktów w magazynach, przygotowywać raporty analityczne.
- W IoT In-Memory zastępuje tradycyjne bazy danych.
- Firmy farmaceutyczne używają In-Memory, na przykład, do przeszukiwania kombinacji składu leków.
Przedstawię kilka przykładów, jak nasi klienci wykorzystują rozwiązania In-Memory i jak możesz je wdrożyć u siebie.
In-Memory jako główne magazynowanie
Jednym z naszych klientów jest duży dostawca medycznego sprzętu naukowego z USA. Używają rozwiązania In-Memory jako głównego magazynu danych. Wszystkie dane są przechowywane na dysku, a podzbiór danych, które są aktywnie używane, jest trzymany w pamięci operacyjnej. Metody dostępu do magazynu są standardowe – GDBC (Generic Database Connector) oraz język zapytań SQL.
Wszystko razem nazywa się In-Memory Database (IMDB) lub Memory-Centric Storage. Ta klasa rozwiązań ma wiele nazw, to nie są jedyne.
Cechy IMDB:
- Dane, które są przechowywane w In-Memory i dostępne przez SQL, są takie same jak w innych podejściach. Są synchronizowane, różni się jedynie sposób ich prezentacji oraz sposób dostępu. Między danymi działa transakcyjność.
- IMDB działa szybciej niż relacyjne bazy danych, ponieważ dostęp do informacji z pamięci operacyjnej jest szybszy niż z dysku.
- Wewnętrzne algorytmy optymalizacji mają mniej instrukcji.
- IMDB nadają się do zarządzania danymi, zdarzeniami i transakcjami w aplikacjach.
IMDB częściowo wspierają ACID: atomowość, spójność i izolację. Jednak nie wspierają «trwałości» — przy zgaśnięciu zasilania wszystkie dane znikają. Aby rozwiązać ten problem, można używać zrzutów — «zrzut» bazy danych, analogiczny do kopii zapasowej bazy danych na dysku twardym, lub rejestrować transakcje (logi), aby przywrócić dane po ponownym uruchomieniu.
Do tworzenia aplikacji odpornych na błędy
Przedstawmy klasyczną architekturę odpornego na awarie webowego aplikacji. Działa to tak: wszystkie zapytania są rozdzielane przez balansator obciążenia pomiędzy serwery. Ten system jest odporny, ponieważ serwery duplikują się nawzajem i zabezpieczają w przypadku incydentów.
Balansator kieruje wszystkie zapytania z jednej sesji ściśle do jednego serwera. To jest mechanizm sticky session: każda sesja jest powiązana z serwera, w którym jest lokalnie przechowywana i przetwarzana.
Co się stanie, gdy jeden z serwerów?
Serwis nie ucierpi, ponieważ architektura jest duplikowana. Ale stracimy podzbiór sesji zmarłego serwera,A także użytkowników, którzy są związani z tymi sesjami. Na przykład klient składa zamówienie i nagle zostaje wyrzucony z panelu. Będzie niezadowolony, gdy ponownie się zaloguje i odkryje, że musi wszystko załatwiać od nowa.
Od webowego aplikacji wymaga się, aby obsługiwała dużą liczbę użytkowników i nie "spowalniała", aby było im wygodnie pracować. Ale przy awarii, z każdym kolejnym zapytaniem czas do komunikacji z magazynem sesji będzie coraz dłuższy. To zwiększa średnie opóźnienie (latency) dla pozostałych użytkowników. Ale nie chcą czekać dłużej, niż są przyzwyczajeni.
Ten problem można rozwiązać, jak inny nasz klient — duży dostawca PASS z USA. Używa In-Memory, aby zgrupować sesje webowe. W tym celu przechowuje je nie lokalnie, a centralnie — w klastrze In-Memory. W takim przypadku sesje są dostępne znacznie szybciej, ponieważ znajdują się w pamięci operacyjnej.
Gdy serwer pada, balansator wysyła zapytania zmarłego na inne serwery, podobnie jak w klasycznej architekturze. Ale istnieje istotna różnica: sesje są przechowywane w klastrze In-Memory i serwery mają dostęp do sesji zmarłego serwera.
Taka architektura zwiększa odporność całego systemu. Co więcej, można całkowicie zrezygnować z mechanizmu sticky session.
Hybrydowe przetwarzanie transakcyjno-analityczne (HTAP)
Zazwyczaj systemy transakcyjne i analityczne są oddzielane. Gdy są rozdzielone, główna baza danych jest obciążona. Aby przeprowadzać przetwarzanie analityczne, dane są kopiowane do repliki, aby procesy analityczne nie zakłócały procesów transakcyjnych. Kopiowanie odbywa się jednak z opóźnieniem — nie można replikować bez opóźnienia. Jeśli będziemy to robić synchronicznie, to również spowolni główną bazę i nie uzyskamy żadnych korzyści.
W HTAP wszystko działa inaczej — to samo repozytorium danych jest używane dla obciążenia transakcyjnego z aplikacji oraz dla zapytań analitycznych, które mogą trwać długo. Gdy dane są w pamięci operacyjnej, zapytania analityczne są realizowane szybciej, a serwer bazy danych jest mniej obciążony (średnio).
Hybrdowe podejście „łamie mur” między przetwarzaniem transakcji a analizą. Gdy wykonujemy analitykę na tym samym repozytorium, zapytania analityczne są uruchamiane na danych z pamięci operacyjnej. Są one znacznie bardziej precyzyjne, łatwiejsze do interpretacji i adekwatne.
Integracja rozwiązań In-Memory
Prosty (względnie) sposób — opracować wszystko od zera. Przechowujemy dane na dysku, a te najważniejsze w pamięci. To pomaga przetrwać ponowne uruchomienia serwerów lub ich awarie.
Działają tutaj dwa główne scenariusze, gdy dane są przechowywane na dysku. W pierwszym przypadku chcemy przetrwać awarie lub planowe ponowne uruchomienia klastra lub jego części — chcemy używać go jak podstawowej bazy danych. W drugim scenariuszu, gdy danych jest zbyt dużo, jakaś ich część znajduje się w pamięci.
Jeśli nie ma możliwości zbudowania wszystkiego od podstaw, można zintegrować In-Memory w już istniejącą architekturę. Ale nie wszystkie rozwiązania In-Memory są do tego odpowiednie. Istnieją trzy obowiązkowe warunki. Rozwiązanie In-Memory musi wspierać:
- standardowy sposób łączenia z bazą, która będzie znajdować się pod nim (na przykład MySQL);
- standardowy język zapytań, aby nie przepisywać ani nie zmieniać logiki interakcji z repozytorium;
- transakcyjność — zachowywać semantykę interakcji.
Jeśli wszystkie trzy warunki są spełnione, to integracja jest możliwa. Umieszczamy In-Memory Data Grid między aplikacją a bazą. Teraz zapytania o zapis będą delegowane do niższej bazy, a zapytania o odczyt — do bazy, jeśli danych brakuje w pamięci podręcznej.
Jeśli szybki dostęp do danych i ich przetwarzanie jest dla Ciebie ważne, na przykład do analizy biznesowej — warto rozważyć wdrożenie In-Memory. Przy projektowaniu nowej architektury możesz wykorzystać obie metody.
Źródło: habr.com
