In-Memory — ein Konzept zur Datenspeicherung, bei dem Daten im Arbeitsspeicher der Anwendung gespeichert werden und die Festplatte für Backups verwendet wird. In traditionellen Ansätzen werden Daten auf der Festplatte gespeichert, während der Arbeitsspeicher als Cache dient. Beispielsweise fragt eine Web-Anwendung mit einem Backend zur Datenverarbeitung im Speicher nach Daten: sie erhält sie, transformiert sie und überträgt eine große Menge an Daten über das Netzwerk. Bei In-Memory-Berechnungen werden die Anfragen direkt an die Daten im Speicher geschickt, wo sie verarbeitet werden und die Netzwerkbelastung geringer ist.
Welche weiteren Möglichkeiten bietet In-Memory und was genau ist dieser Ansatz, wird Wladimir Pligin — Ingenieur bei GridGain. Dieses Übersichtsmaterial ist für Backend-Entwickler von Webanwendungen nützlich, die noch nicht mit In-Memory gearbeitet haben und es ausprobieren möchten oder an modernen Trends in der Softwareentwicklung und Architekturdesign interessiert sind.
Hinweis. Der Artikel basiert auf der Zusammenfassung des Vortrags von Wladimir auf der Konferenz #GetIT Conf. Vor der Einführung der Selbstisolation haben wir regelmäßig Meetups und Konferenzen für Entwickler in Moskau und St. Petersburg organisiert: Wir haben Trends, aktuelle Fragen der Entwicklung, Probleme und deren Lösungen diskutiert. Jetzt können keine Konferenzen stattfinden, aber es ist der perfekte Zeitpunkt, um nützliche Materialien aus der Vergangenheit zu teilen.
Wer und wie nutzt In-Memory
In-Memory wird häufig dort eingesetzt, wo eine schnelle Interaktion mit dem Nutzer oder die Verarbeitung großer Datenmengen erforderlich ist.
- Banken nutzen In-Memory, um beispielsweise die Latenzzeiten bei der Nutzung von Anwendungen durch Kunden zu verringern oder um Analysen der Kunden vor der Kreditvergabe durchzuführen.
- Fintech setzt In-Memory ein, um die Leistung von Dienstleistungen und Anwendungen für Banken zu verbessern, die die Datenverarbeitung und -analyse outsourcen.
- Versicherungsunternehmen: zur Risikobewertung, indem beispielsweise die Daten eines Kunden über mehrere Jahre analysiert werden.
- Logistikunternehmen. Sie verarbeiten große Datenmengen, um etwa die optimalen Routen für Fracht- und Passagiertransporte unter Berücksichtigung tausender Parameter zu berechnen und den Status von Sendungen zu verfolgen.
- Einzelhandel. In-Memory-Lösungen helfen, die Kunden schneller zu bedienen und große Informationsmengen zu verarbeiten: Lieferungen, Rechnungen, Transaktionen, Verfügbarkeit tausender Produkte in Lagern und die Erstellung von Analyseberichten.
- In IoT In-Memory ersetzt traditionelle Datenbanken.
- Pharmazeutische Unternehmen nutzen In-Memory beispielsweise zur Durchprobierung von Kombinationen in der Arzneimittelzusammensetzung.
Ich werde Ihnen einige Beispiele geben, wie unsere Kunden In-Memory-Lösungen nutzen und wie Sie diese auch in Ihrem Unternehmen implementieren können.
In-Memory als primärer Speicher
Einer unserer Kunden ist ein großer Anbieter medizinischer wissenschaftlicher Geräte aus den USA. Sie nutzen eine In-Memory-Lösung als primären Datenspeicher. Alle Daten werden auf einer Festplatte gespeichert, während eine Teilmenge der aktiven Daten im Arbeitsspeicher gehalten wird. Die Zugriffsweisen auf den Speicher sind standardmäßig: GDBC (Generic Database Connector) und SQL-Abfragesprache.
Alles zusammen wird als In-Memory-Datenbank (IMDB) oder speicherzentrierte Speicherung bezeichnet. Diese Klasse von Lösungen hat viele Namen, das sind nicht die einzigen.
Eigenschaften von IMDB:
- Die Daten, die in In-Memory gespeichert sind und über SQL zugänglich sind, sind die gleichen wie in anderen Ansätzen. Sie sind synchronisiert, der einzige Unterschied besteht in der Art der Darstellung und dem Zugriff darauf. Zwischen den Daten besteht Transaktionsfähigkeit.
- IMDB sind schneller als relationale Datenbanken, da der Zugriff auf Informationen aus dem Arbeitsspeicher schneller ist als von der Festplatte.
- Die internen Optimierungsalgorithmen haben weniger Anweisungen.
- IMDB eignen sich zur Verwaltung von Daten, Ereignissen und Transaktionen in Anwendungen.
IMDB unterstützen teilweise ACID: Atomarität, Konsistenz und Isolation. Sie unterstützen jedoch nicht die „Dauerhaftigkeit“ – bei einem Stromausfall gehen alle Daten verloren. Um dieses Problem zu lösen, können Snapshots verwendet werden – ein „Snapshot“ der Datenbank, ähnlich einem Backup auf der Festplatte, oder um Transaktionen (Logs) aufzuzeichnen, um die Daten nach einem Neustart wiederherzustellen.
Für die Erstellung fehlertoleranter Anwendungen.
Stellen Sie sich die klassische Architektur einer ausfallsicheren Webanwendung vor. Sie funktioniert so: Ein Web-Load-Balancer verteilt alle Anfragen auf verschiedene Server. Dieses System ist stabil, da die Server sich gegenseitig duplizieren und bei Vorfällen absichern.
Der Load-Balancer leitet alle Anfragen einer Sitzung strikt an einen einzigen Server. Dies ist der Mechanismus der Sticky-Sessions: Jede Sitzung wird an Server, wo sie lokal gespeichert und verarbeitet wird.
Was passiert, wenn einer der Server?
Server ausfällt? Der Dienst wird nicht beeinträchtigt, da die Architektur redundant ist. Aber wir verlieren eine Teilmenge der Sitzungen des ausgefallenen Servers. Und damit auch die Nutzer, die an diesen Sitzungen hängen. Zum Beispiel könnte ein Kunde eine Bestellung aufgeben und plötzlich aus dem System geworfen werden. Er wird unzufrieden sein, wenn er sich erneut anmeldet und feststellen muss, dass alles von neuem beantragt werden muss.
Webanwendungen müssen eine große Anzahl von Benutzern unterstützen und dabei reibungslos funktionieren, damit die Nutzerkomfort haben. Bei einem Ausfall wird jedoch die Kommunikationszeit mit dem Sitzungsspeicher bei jedem weiteren Request länger. Dies erhöht die durchschnittliche Latenz für die anderen Benutzer. Sie möchten nicht länger warten als gewohnt.
Dieses Problem wurde von einem anderen Kunden, einem großen PASS-Anbieter aus den USA, gelöst. Er nutzt In-Memory-Technologie, um Web-Sitzungen zu clusterieren. Dabei speichert er sie nicht lokal, sondern zentral in einem In-Memory-Cluster. In diesem Fall sind die Sitzungen viel schneller verfügbar, da sie im RAM gespeichert sind.
Wenn ein Server ausfällt, leitet der Load-Balancer die Anfragen des ausgefallenen Servers an andere Server weiter, wie in einer klassischen Architektur. Doch es gibt einen wichtigen Unterschied: Sitzungen werden im 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 sogar möglich, ganz auf den Mechanismus der Sticky-Sitzungen zu verzichten.
Hybride transaktionale und analytische Verarbeitung (HTAP)
In der Regel werden transaktionale und analytische Systeme separat gehalten. Wenn sie getrennt sind, wird die Hauptdatenbank belastet. Für die analytische Verarbeitung werden die Daten in eine Replikation kopiert, damit die analytischen Prozesse die transaktionalen Vorgänge nicht stören. Allerdings geschieht die Kopierung mit einer Verzögerung – eine reibungslose Replikation ist unmöglich. Wenn wir dies synchron durchführen, wird auch die Hauptdatenbank langsamer, und es gibt keinen Gewinn.
Bei HTAP funktioniert alles anders – dasselbe Datenspeicher wird sowohl für transaktionale Lasten von Anwendungen als auch für analytische Abfragen verwendet, die lange dauern können. Wenn die Daten im Arbeitsspeicher liegen, werden analytische Abfragen schneller ausgeführt und der Datenbankserver wird weniger belastet (im Durchschnitt).
Der hybride Ansatz „durchbricht die Wand“ zwischen Transaktionsverarbeitung und Analytik. Wenn wir die Analytik im selben Speicher durchführen, werden analytische Abfragen auf den im Arbeitsspeicher befindlichen Daten initiiert. Sie sind viel genauer, besser interpretierbar und adäquater.
Integration von In-Memory-Lösungen
Ein einfacher (relativer) Weg – alles von Grund auf neu zu entwickeln. Wir speichern Daten auf der Festplatte und halten heiße Daten im Speicher. Dies hilft, Serverneustarts oder -ausfälle zu überstehen.
Hier gibt es zwei Hauptszenarien, in denen Daten auf der Festplatte gespeichert werden. Im ersten Szenario möchten wir Ausfälle oder geplante Neustarts des Clusters oder seiner Teile überstehen – wir verwenden es wie eine einfache Datenbank. Im zweiten Szenario, wenn die Datenmenge zu groß ist, wird ein Teil im Speicher gehalten.
Wenn es nicht möglich ist, alles von Grund auf neu zu erstellen, ist es vielleicht möglich, In-Memory in die bereits bestehende Architektur. Aber nicht alle In-Memory-Lösungen eignen sich dafür. Es gibt drei grundlegende Bedingungen. Die In-Memory-Lösung muss unterstützen:
- eine standardisierte Verbindung zur darunterliegenden Datenbank (zum Beispiel MySQL);
- eine standardisierte Abfragesprache, um die Logik der Interaktion mit dem Speicher nicht umschreiben oder ändern zu müssen;
- Transaktionsfähigkeit – die Semantik der Interaktion zu bewahren.
Wenn alle drei Bedingungen erfüllt sind, ist die 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 an die Datenbank, wenn die Daten nicht im Cache vorhanden sind.
Wenn Ihnen schneller Zugriff auf Daten und deren Verarbeitung wichtig ist, beispielsweise für Geschäftsanalysen, sollten Sie die Implementierung von In-Memory in Betracht ziehen. Bei der Umsetzung können beide Ansätze bei der Planung einer neuen Architektur verwendet werden.
Quelle: habr.com
