In-Memory to zbiór koncepcji przechowywania danych, gdy są one przechowywane w pamięci RAM aplikacji, a dysk służy do tworzenia kopii zapasowych. W klasycznym podejściu dane są przechowywane na dysku, a pamięć w pamięci podręcznej. Na przykład aplikacja internetowa z zapleczem do przetwarzania danych żąda ich do przechowywania: odbiera je, przetwarza, a duża część danych jest przesyłana przez sieć. W In-Memory obliczenia przesyłane są do danych – do pamięci, gdzie są przetwarzane, a sieć jest mniej obciążona.
Jakie inne możliwości oferuje In-Memory i jakiego rodzaju jest to podejście? Włodzimierz Pligin - inżynier w GridGain. Ten materiał przeglądowy będzie przydatny dla twórców zaplecza aplikacji internetowych, którzy nie pracowali z In-Memory, a chcą spróbować lub są zainteresowani nowoczesnymi trendami w tworzeniu oprogramowania i projektowaniu architektury.
Operacja. Artykuł powstał na podstawie transkrypcji raportu Vladimira z konferencji #GetIT. Przed wprowadzeniem samoizolacji regularnie organizowaliśmy spotkania i konferencje dla deweloperów w Moskwie i St. Petersburgu: omawialiśmy trendy, aktualne problemy rozwojowe, problemy i ich rozwiązania. Nie ma teraz możliwości zorganizowania konferencji, ale nadszedł czas, aby podzielić się przydatnymi materiałami z poprzednich.
Kto i jak korzysta z In-Memory
In-Memory jest najczęściej używany tam, gdzie wymagana jest szybka interakcja użytkownika lub przetwarzanie dużych ilości danych.
- Banki użyj In-Memory, na przykład, aby zmniejszyć opóźnienia, gdy klienci korzystają z aplikacji lub analizować klienta przed udzieleniem pożyczki.
- интех wykorzystuje In-Memory w celu poprawy wydajności usług i aplikacji dla banków zlecających przetwarzanie i analizę danych na zewnątrz.
- Firmy ubezpieczeniowe: w celu obliczenia ryzyka, na przykład poprzez analizę danych klientów na przestrzeni kilku lat.
- Firmy logistyczne. Przetwarzają wiele danych, na przykład w celu obliczenia optymalnych tras transportu towarowego i pasażerskiego z tysiącami parametrów oraz śledzą status przesyłek.
- Sprzedaż detaliczna. Rozwiązania In-Memory pomagają szybciej obsługiwać klientów i przetwarzać duże wolumeny informacji: przesyłki, faktury, transakcje, obecność tysięcy towarów w magazynach oraz przygotowywać raporty analityczne.
- В Internet przedmiotów In-Memory zastępuje tradycyjne bazy danych.
- Farmaceutyczny firmy używają na przykład In-Memory do sortowania kombinacji składów leków.
Opowiem Ci kilka przykładów jak nasi klienci korzystają z rozwiązań In-Memory i jak możesz je wdrożyć samodzielnie.
In-Memory jako pamięć podstawowa
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óry jest aktywnie używany, jest przechowywany w pamięci RAM. Metody dostępu do magazynu są standardowe - GDBC (Generic Database Connector) i język zapytań SQL.
Łącznie nazywa się to bazą danych w pamięci (IMDB) lub pamięcią zorientowaną na pamięć. Ta klasa rozwiązań ma wiele nazw, nie są to jedyne nazwy.
Funkcje IMDB:
- Dane przechowywane w pamięci In-Memory i dostępne za pośrednictwem SQL są takie same, jak w przypadku innych podejść. Są zsynchronizowane, inny jest tylko sposób ich prezentacji, sposób adresowania. Transakcyjność działa pomiędzy danymi.
- IMDB jest szybszy niż relacyjne bazy danych, ponieważ szybciej można uzyskać informacje z pamięci RAM niż z dysku.
- Algorytmy optymalizacji wewnętrznej mają mniej instrukcji.
- Bazy IMDB nadają się do zarządzania danymi, zdarzeniami i transakcjami w aplikacjach.
IMDB częściowo obsługują ACID: atomowość, spójność i izolacja. Ale nie obsługują „trwałości” - po wyłączeniu zasilania wszystkie dane zostaną utracone. Aby rozwiązać problem, można zastosować migawki - „migawkę” bazy danych, analogicznie do kopii zapasowej bazy danych na dysku twardym, lub zapisać transakcje (logi) w celu przywrócenia danych po ponownym uruchomieniu.
Aby stworzyć aplikacje odporne na awarie
Wyobraźmy sobie klasyczną architekturę odpornej na awarie aplikacji internetowej. Działa to w ten sposób: wszystkie żądania są rozdzielane pomiędzy serwerami za pomocą modułu równoważącego sieci. System ten jest stabilny, ponieważ serwery duplikują się nawzajem i wykonują kopie zapasowe w przypadku incydentów.
Balancer kieruje wszystkie żądania z jednej sesji wyłącznie do jednego serwera. Jest to mechanizm sesji typu stick: każda sesja jest powiązana z serwerem, na którym jest lokalnie przechowywana i przetwarzana.
Co się stanie, gdy jeden z serwerów ulegnie awarii?
Nie będzie to miało wpływu na usługę, ponieważ architektura zostanie zduplikowana. Ale stracimy podzbiór sesji martwego serwera. A jednocześnie użytkownicy powiązani z tymi sesjami. Na przykład klient składa zamówienie i nagle wyrzuca go z biura. Będzie niezadowolony, gdy zaloguje się ponownie i stwierdzi, że trzeba będzie wszystko zrobić od nowa.
Aplikacja internetowa jest wymagana, aby obsłużyć dużą liczbę użytkowników i nie spowalniać, aby mogli wygodnie pracować. Jeśli jednak zostanie odrzucone, z każdym kolejnym żądaniem czas potrzebny na komunikację ze sklepem sesyjnym będzie się zwiększał. Zwiększa to średnie opóźnienie dla innych użytkowników. Nie chcą jednak czekać dłużej, niż są do tego przyzwyczajeni.
Ten problem można rozwiązać podobnie jak nasz inny klient, duży dostawca PASS z USA. Wykorzystuje In-Memory do grupowania sesji internetowych. W tym celu przechowuje je nie lokalnie, ale centralnie – w klastrze In-Memory. W tym przypadku sesje są dostępne znacznie szybciej, ponieważ znajdują się już w pamięci RAM.
Kiedy serwer ulegnie awarii, moduł równoważący wysyła żądania z uszkodzonego serwera do innych serwerów, tak jak w architekturze klasycznej. Ale jest istotna różnica: sesje są przechowywane w klastrze w pamięci a serwery mają dostęp do sesji upadłego serwera.
Architektura ta zwiększa odporność całego systemu na awarie. Co więcej, możliwa jest całkowita rezygnacja z mechanizmu sesji stick.
Hybrydowe transakcyjne przetwarzanie analityczne (HTAP)
Zazwyczaj systemy transakcyjne i analityczne są trzymane oddzielnie. Kiedy się rozdzielą, główna podstawa zostanie obciążona. Do przetwarzania analitycznego dane są kopiowane do repliki, dzięki czemu przetwarzanie analityczne nie zakłóca procesów transakcyjnych. Kopiowanie następuje jednak z opóźnieniem — replikacja bez opóźnienia jest niemożliwa. Jeśli zrobimy to synchronicznie, spowolni to także główną bazę i nie uzyskamy żadnej wygranej.
W HTAP wszystko działa inaczej – ten sam magazyn danych wykorzystywany jest do obciążenia transakcyjnego z aplikacji oraz do zapytań analitycznych, których realizacja może zająć dużo czasu. Gdy dane znajdują się w pamięci RAM, zapytania analityczne są wykonywane szybciej, a serwer z bazą danych jest mniej obciążony (średnio).
Podejście hybrydowe burzy mur pomiędzy przetwarzaniem transakcji a analityką. Jeśli przeprowadzamy analitykę na tej samej pamięci, wówczas uruchamiane są zapytania analityczne o dane z pamięci RAM. Są znacznie dokładniejsze, bardziej zrozumiałe i adekwatne.
Integracja rozwiązań In-Memory
(Względny) prosty sposób - opracować wszystko od zera. Przechowujemy dane na dysku i przechowujemy gorące dane w pamięci. Pomaga to przetrwać ponowne uruchomienie serwera lub awarię.
Istnieją dwa główne scenariusze, gdy dane są przechowywane na dysku. W pierwszym chcemy przetrwać awarie czy regularne restarty klastra lub jego części – chcemy wykorzystać go jako prostą bazę danych. W drugim scenariuszu, gdy danych jest za dużo, część z nich znajduje się w pamięci.
Jeśli nie jest możliwe zbudowanie wszystkiego od zera, możliwa jest integracja In-Memory z już istniejącą architekturę. Jednak nie wszystkie rozwiązania In-Memory nadają się do tego. Istnieją trzy obowiązkowe warunki. Rozwiązanie In-Memory musi obsługiwać:
- standardowy sposób łączenia się z bazą danych, która będzie się pod nim znajdować (np. MySQL);
- standardowy język zapytań, aby nie przepisywać i nie zmieniać logiki interakcji z magazynem;
- transakcyjne - zachowują semantykę interakcji.
Jeśli wszystkie trzy warunki zostaną spełnione, integracja jest możliwa. Umieszczamy siatkę danych w pamięci pomiędzy aplikacją a bazą danych. Teraz żądania zapisu zostaną delegowane do bazowej bazy danych, a żądania odczytu zostaną delegowane do bazowej bazy danych, jeśli dane nie znajdują się w pamięci podręcznej.
Jeżeli ważny jest dla Ciebie szybki dostęp do danych i ich przetwarzanie, np. do celów analityki biznesowej, możesz pomyśleć o wdrożeniu In-Memory. A do wdrożenia możesz zastosować obie metody podczas projektowania nowej architektury.
Źródło: www.habr.com