In-Memory ist eine Reihe von Konzepten zum Speichern von Daten, wenn diese im RAM der Anwendung gespeichert werden und die Festplatte für die Sicherung verwendet wird. Bei klassischen Ansätzen werden Daten auf der Festplatte und der Speicher im Cache gespeichert. Beispielsweise fordert eine Webanwendung mit einem Backend zur Verarbeitung von Daten diese zum Speichern an: Sie empfängt sie, wandelt sie um und viele Daten werden über das Netzwerk übertragen. Im In-Memory werden Berechnungen an die Daten gesendet – an den Speicher, wo sie verarbeitet werden und das Netzwerk weniger belastet wird.
Welche weiteren Möglichkeiten gibt es mit In-Memory und was für ein Ansatz ist das? Wladimir Pligin - Ingenieur bei GridGain. Dieses Rezensionsmaterial wird für Webanwendungs-Backend-Entwickler nützlich sein, die noch nicht mit In-Memory gearbeitet haben und es ausprobieren möchten oder sich für moderne Trends in der Softwareentwicklung und dem Architekturdesign interessieren.
Beachten. Der Artikel basiert auf der Abschrift von Vladimirs Bericht auf der #GetIT Conf. Vor der Einführung der Selbstisolation haben wir regelmäßig Treffen und Konferenzen für Entwickler in Moskau und St. Petersburg abgehalten: Wir haben Trends, aktuelle Entwicklungsthemen, Probleme und deren Lösungen diskutiert. Es ist derzeit nicht möglich, eine Konferenz abzuhalten, aber es ist an der Zeit, nützliche Materialien vergangener Konferenzen auszutauschen.
Wer nutzt In-Memory und wie
In-Memory wird am häufigsten dort eingesetzt, wo eine schnelle Benutzerinteraktion oder die Verarbeitung großer Datenmengen erforderlich ist.
- Banks Nutzen Sie In-Memory beispielsweise, um Verzögerungen bei der Nutzung von Anträgen durch Kunden zu reduzieren oder um den Kunden vor der Kreditvergabe zu analysieren.
- Fintech nutzt In-Memory, um die Leistung von Diensten und Anwendungen für Banken zu verbessern, die Datenverarbeitung und -analyse auslagern.
- Versicherungsgesellschaften: um Risiken zu berechnen, beispielsweise durch die Analyse von Kundendaten über mehrere Jahre.
- Logistikunternehmen. Sie verarbeiten viele Daten, um beispielsweise mit Tausenden von Parametern optimale Routen für den Güter- und Personentransport zu berechnen und den Status von Sendungen zu verfolgen.
- Einzelhandel. In-Memory-Lösungen helfen dabei, Kunden schneller zu bedienen und große Informationsmengen zu verarbeiten: Sendungen, Rechnungen, Transaktionen, das Vorhandensein von Tausenden von Waren in Lagern und analytische Berichte zu erstellen.
- В IoT In-Memory ersetzt herkömmliche Datenbanken.
- Pharmazeutisch Unternehmen nutzen In-Memory beispielsweise, um Kombinationen von Arzneimittelzusammensetzungen zu sortieren.
Ich erzähle Ihnen einige Beispiele, wie unsere Kunden In-Memory-Lösungen nutzen und wie Sie diese selbst implementieren können.
In-Memory als Primärspeicher
Einer unserer Kunden ist ein großer Anbieter medizinisch-wissenschaftlicher Geräte aus den USA. Als Hauptdatenspeicher nutzen sie eine In-Memory-Lösung. Alle Daten werden auf der Festplatte gespeichert und die aktiv genutzte Teilmenge der Daten wird im RAM gehalten. Die Speicherzugriffsmethoden sind Standard – GDBC (Generic Database Connector) und SQL-Abfragesprache.
Zusammenfassend wird dies als In-Memory Database (IMDB) oder Memory-Centric Storage bezeichnet. Diese Lösungsklasse hat viele Namen, diese sind jedoch nicht die einzigen.
IMDB-Funktionen:
- Die Daten, die im In-Memory gespeichert werden und auf die über SQL zugegriffen wird, sind die gleichen wie bei anderen Ansätzen. Sie sind synchron, nur die Art der Darstellung, die Art der Ansprache ist unterschiedlich. Transaktionalität funktioniert zwischen Daten.
- IMDB ist schneller als relationale Datenbanken, da Informationen schneller aus dem RAM als von der Festplatte abgerufen werden können.
- Interne Optimierungsalgorithmen haben weniger Anweisungen.
- IMDBs eignen sich zur Verwaltung von Daten, Ereignissen und Transaktionen in Anwendungen.
IMDBs unterstützen teilweise ACID: Atomicity, Consistency und Isolation. Sie unterstützen jedoch keine „Haltbarkeit“ – wenn der Strom ausgeschaltet wird, gehen alle Daten verloren. Um das Problem zu lösen, können Sie Snapshots verwenden – einen „Schnappschuss“ der Datenbank, analog zu einem Datenbank-Backup auf einer Festplatte – oder Transaktionen (Protokolle) aufzeichnen, um Daten nach einem Neustart wiederherzustellen.
Um fehlertolerante Anwendungen zu erstellen
Stellen wir uns die klassische Architektur einer fehlertoleranten Webanwendung vor. Das funktioniert so: Alle Anfragen werden von einem Web-Balancer zwischen den Servern verteilt. Dieses System ist stabil, da sich die Server gegenseitig duplizieren und bei Vorfällen ein Backup erstellen.
Der Balancer leitet alle Anfragen einer Sitzung ausschließlich an einen Server. Dabei handelt es sich um einen Stick-Session-Mechanismus: Jede Sitzung ist einem Server zugeordnet, auf dem sie lokal gespeichert und verarbeitet wird.
Was passiert, wenn einer der Server ausfällt?
Der Dienst wird nicht beeinträchtigt, da die Architektur dupliziert ist. Aber wir werden einen Teil der Sitzungen des toten Servers verlieren. Und gleichzeitig die Benutzer, die an diese Sitzungen gebunden sind. Zum Beispiel gibt ein Kunde eine Bestellung auf und wirft ihn plötzlich aus dem Büro. Er wird unzufrieden sein, wenn er sich erneut anmeldet und feststellt, dass alles noch einmal gemacht werden muss.
Eine Webanwendung muss eine große Anzahl von Benutzern unterstützen und darf nicht langsamer werden, damit diese komfortabel arbeiten können. Wenn dies jedoch abgelehnt wird, erhöht sich mit jeder weiteren Anfrage die Zeit, die für die Kommunikation mit dem Sitzungsspeicher benötigt wird. Dadurch erhöht sich die durchschnittliche Latenz für andere Benutzer. Aber sie wollen nicht länger warten, als sie es gewohnt sind.
Dieses Problem kann wie bei unserem anderen Kunden, einem großen PASS-Anbieter aus den USA, gelöst werden. Es verwendet In-Memory, um Websitzungen zu gruppieren. Dazu speichert es diese nicht lokal, sondern zentral – in einem In-Memory-Cluster. In diesem Fall stehen Sitzungen viel schneller zur Verfügung, da sie bereits im RAM liegen.
Wenn ein Server abstürzt, sendet der Balancer wie in der klassischen Architektur Anfragen vom abgestürzten Server an andere Server. Aber es gibt einen wichtigen Unterschied: Sitzungen werden in einem In-Memory-Cluster gespeichert und die Server haben Zugriff auf die Sitzungen des ausgefallenen Servers.
Diese Architektur erhöht die Fehlertoleranz des gesamten Systems. Darüber hinaus ist es möglich, ganz auf den Stick-Session-Mechanismus zu verzichten.
Hybride transaktionale analytische Verarbeitung (HTAP)
Typischerweise werden Transaktions- und Analysesysteme getrennt gehalten. Wenn sie sich trennen, wird die Hauptbasis belastet. Für die analytische Verarbeitung werden Daten in ein Replikat kopiert, sodass die analytische Verarbeitung die Transaktionsprozesse nicht beeinträchtigt. Das Kopieren erfolgt jedoch mit einer Verzögerung – es ist unmöglich, ohne Verzögerung zu replizieren. Wenn wir das synchron machen, verlangsamt es auch die Hauptbasis und wir erhalten keine Gewinne.
Bei HTAP funktioniert alles anders – derselbe Datenspeicher wird für die Transaktionslast von Anwendungen und für analytische Abfragen verwendet, deren Abschluss lange dauern kann. Wenn sich die Daten im RAM befinden, werden analytische Abfragen schneller ausgeführt und der Server mit der Datenbank wird (im Durchschnitt) weniger belastet.
Ein hybrider Ansatz überwindet die Grenze zwischen Transaktionsverarbeitung und Analyse. Wenn wir Analysen für denselben Speicher durchführen, werden Analyseabfragen für Daten aus dem RAM gestartet. Sie sind viel genauer, interpretierbarer und angemessener.
Integration von In-Memory-Lösungen
Ein (relativ) einfacher Weg - alles von Grund auf entwickeln. Wir speichern Daten auf der Festplatte und speichern heiße Daten im Speicher. Dies hilft, Serverneustarts oder Ausfälle zu überstehen.
Hier gibt es zwei Hauptszenarien, wenn Daten auf der Festplatte gespeichert werden. Im ersten Fall möchten wir Abstürze oder regelmäßige Neustarts des Clusters oder von Teilen überstehen – wir möchten ihn als einfache Datenbank verwenden. Wenn im zweiten Szenario zu viele Daten vorhanden sind, befinden sich einige davon im Speicher.
Wenn es nicht möglich ist, alles von Grund auf neu zu erstellen, besteht die Möglichkeit, In-Memory in ein bereits vorhandenes zu integrieren bestehende Architektur. Doch nicht alle In-Memory-Lösungen sind dafür geeignet. Es gibt drei zwingende Bedingungen. Die In-Memory-Lösung muss Folgendes unterstützen:
- Standardmethode zum Herstellen einer Verbindung mit der Datenbank, die sich darunter befindet (z. B. MySQL);
- eine Standardabfragesprache, um die Logik der Interaktion mit dem Speicher nicht neu zu schreiben und zu ändern;
- transaktional – Bewahren Sie die Semantik der Interaktion.
Wenn alle drei Bedingungen erfüllt sind, ist eine Integration möglich. Wir platzieren das In-Memory Data Grid zwischen der Anwendung und der Datenbank. Jetzt werden Schreibanforderungen an die zugrunde liegende Datenbank delegiert, und Leseanforderungen werden an die zugrunde liegende Datenbank delegiert, wenn sich die Daten nicht im Cache befinden.
Wenn Ihnen ein schneller Zugriff auf Daten und deren Verarbeitung wichtig ist, beispielsweise für Business Analytics, können Sie über die Implementierung von In-Memory nachdenken. Und für die Umsetzung können Sie beim Entwurf einer neuen Architektur beide Methoden nutzen.
Source: habr.com