Was unterscheidet In-Memory Datagrids von In-Memory-Datenbanken?

Zunehmend mehr Unternehmen generieren große Datensätze, die sie möglichst in Echtzeit verarbeiten wollen. In-Memory Datagrids und -Datenbanken können hierbei für Geschwindigkeit und Skalierbarkeit sorgen. Doch wie unterscheiden sie sich konzeptionell voneinander? Und was passt zu welchem Unternehmen?

Know-how  –  35 Kommentare
Was unterscheidet In-Memory Datagrids von In-Memory-Datenbanken?

Für die digitale Transformation oder für Omnichannel-Strategien benötigen Unternehmen hohe Geschwindigkeit und Skalierbarkeit ihrer Datenbankprozesse. Zunehmend mehr Organisationen setzen dafür auf In-Memory Computing. Die Analysten von Gartner gehen davon aus, dass 75 Prozent der ursprünglichen Cloud-Anwendungsentwicklung bis 2019 In-Memory Computing oder darauf basierende Dienste nutzt. Diese sollen Entwickler in die Lage versetzen, leistungsstarke und massiv skalierbare Anwendungen zu implementieren.

Dass Disk-basierte Plattformen ihre Grenzen haben, wurde bereits vor Jahrzehnten deutlich. So gab es zahlreiche Versuche, Daten in transaktionalen Datenbanken zu analysieren, um deren Leistungsfähigkeit zu verbessern. Separate analytische OLAP-Datenbanken (Online Analytical Processing) wurden entwickelt. Daten in transaktionalen OLTP-Datenbanken (Online Transaction Processing) mussten einen periodischen ETL-Prozess (Extract, Transform, Load) durchlaufen und in OLAP-Datenbanken importiert werden.

Seit etwa fünf Jahren verfolgen Unternehmen zunehmend Initiativen zur digitalen Transformation oder müssen aufgrund bestimmter Regularien spezielle Anforderungen in Echtzeit umsetzen. Marketinganwendungen für eine Omnichannel-Präsenz generieren darüber hinaus große Datensätze. Diese Herausforderungen bedürfen einer verzögerungsfreien Analyse und Reaktion. Echtzeitentscheidungen sind mit den Verzögerungen bei ETL-Prozessen jedoch kaum realisierbar. Als Resultat entstand ein Bedarf an In-Memory-Computing-Produkten mit hybrider transaktionaler beziehungsweise analytischer Verarbeitung (Hybrid Transactional/Analytical Processing = HTAP), die Echtzeitanalysen des Betriebsdatensatzes ermöglichen.

Für Entwickler stellt sich in den meisten Fällen als Erstes die Frage, ob sie ein In-Memory DataGrid oder eine In-Memory-Datenbank einsetzen sollen. Sie müssen die Unterschiede und daraus folgende Strategien beider Ansätze begreifen, bevor sie die Technik in ihre Architektur integrieren. Diese Entscheidung ist in erster Linie davon abhängig, ob das Unternehmen beabsichtigt, eine Anwendung zu beschleunigen, eine neue zu entwickeln oder die bestehende vollständig zu rekonstruieren. Sie müssen ebenfalls entscheiden, wo die Daten gespeichert werden sollen: im In-Memory Computing Layer oder im tiefer liegenden Data Layer.

Was sind In-Memory Datagrids?

Eine der größten Herausforderungen für IT-Abteilungen ist eine kosteneffiziente Skalierung der Rechenleistung, gerade auch für bestehende Anwendungen. In-Memory Data Grids (IMDGs) bieten potenziell hohen Geschwindigkeits- und Skalierbarkeitszuwachs, ohne dass die Anwendungen oder Datenschichten zu verändern und hinzuzufügen sind.

Ein IMDG besteht aus einem Server-Cluster mit dessen verfügbaren Speichern und entsprechender CPU-Leistung. IMDGs verteilen die Datensätze gleichmäßig auf die Clusterknoten. Dabei werden parallel die Prozesse auf den Knoten verarbeitet, auf denen sich die relevanten Daten befinden. So ist eine einfache Skalierung durch Hinzufügen weiterer Knoten zum Cluster möglich. Dabei wird das IMDG zwischen Anwendungs- und Datenlayer eingefügt. Es verschiebt eine Kopie der plattenbasierten Daten aus RDBMS-, NoSQL- oder Hadoop-Datenbanken in den Arbeitsspeicher. Das ermöglicht die Verarbeitung ohne Verzögerungen, da das ständige Auslesen und Schreiben der Daten von der Festplatte wegfällt.

Beispielhaftes In-Memory Data Grid (Bild: GridGain)

In einer Public- oder Private-Cloud-Umgebung lassen sich Knoten nach Bedarf hinzufügen oder vom IMDG-Cluster abziehen, um Flexibilität und kostengünstige Skalierung zu ermöglichen. Einige IMDGs bieten zudem Support von ANSI-99-SQL- und ACID-Transaktionen, erweiterte Sicherheitsfeatures, Unterstützung für Stream-Verarbeitung, maschinelles Lernen sowie Spark- und Hadoop-Integration.

Eine Einschränkung vieler In-Memory-Compting-Angebote ist jedoch, dass alle Daten in den Arbeitsspeicher passen müssen. Da Festplatten immer noch billiger sind als RAM, entscheiden sich viele Unternehmen dafür, nicht alle Daten in den Arbeitsspeicher zu legen, sondern den vollständigen Datensatz auf Festplatte zu belassen, was wiederum Geschwindigkeitseinbußen zur Folge hat. Eine speicherzentrische Architektur löst das Problem, indem sie mit ihren zugrunde liegenden Techniken die Verwendung anderer Speichertypen wie Solid-State-Laufwerke (SSDs), Flash-Speicher und 3D XPoint ermöglicht.

Die wichtigsten oder aktuellsten Daten bei Memory-zentrierten Architekturen liegen sowohl auf der Festplatte als auch im Arbeitsspeicher. So lässt sich die In-Memory-Geschwindigkeit erreichen. Durch diese Architektur kann der Datensatz den zur Verfügung stehenden RAM übersteigen – wobei der vollständige Datensatz auf der Festplatte liegt und das System in der Lage ist, Daten im Arbeitsspeicher oder auf dem darunter liegenden Laufwerk mit enormer Leistung zu verarbeiten.

Es besteht ein entscheidender Unterschied zum Caching Disk-basierter Daten im Arbeitsspeicher. Eine Memory-zentrierte Architektur bietet Unternehmen mehr Flexibilität und Kontrolle über mögliche Leistung und Kosten. Daten werden dahingehend optimiert, dass alle Daten auf der Festplatte liegen - wobei sich höherwertige und häufiger benötigte Daten zusätzlich im Arbeitsspeicher befinden. Seltener benötigte Daten bleiben hingegen nur auf der Festplatte. So kann die Datenmenge den Arbeitsspeicher überschreiten, was eine optimale Leistung bei gleichzeitiger Minimierung der Infrastrukturkosten ermöglicht.

Ein weiterer Vorteil von IMDGs mit speicherzentrierter Architektur besteht darin, dass im Falle eines Reboots nicht alle Daten erneut in den Arbeitsspeicher zu laden sind. Diese Verzögerung, die je nach Größe des Datensatzes und der Geschwindigkeit des Netzwerks Stunden dauern kann, führt leicht zur Verletzung von Service Level Agreements (SLAs). Die Möglichkeit, Daten von der Festplatte schon während des Hochfahrens verarbeiten zu können, macht das System schneller wieder einsatzbereit. Während die Systemleistung anfänglich der von laufwerkbasierten Systemen ähnelt, wird das System schnell wieder fast alle Operationen mit In-Memory-Geschwindigkeit ausführen können, sobald die Daten in den Arbeitsspeicher zurückgeladen sind.

Auswahl eines IMDGs

Unternehmen sollten verschiedene Kriterien beachten, wenn sie sich für ein IMDG entscheiden, um sicherzustellen, dass es ihren Bedürfnissen entspricht. Ein IMDG ist nötig, wenn:

  • die Leistung der Anwendung eines erhöhten Benutzeraufkommens nicht mit akzeptabler Effizienz stemmen kann.
  • Reaktionsfähigkeit in Echtzeit erforderlich ist.
  • die Anwendung vom Zugriff auf Daten aus einer verteilten, hochverfügbaren Datenschicht profitieren würde.
  • die Zeit oder das Budget fehlt, um die Anwendung in eine In-Memory-Datenbank zu überführen.
  • die gesamte Systemarchitektur durch den Umstieg auf HTAP vereinfacht werden würde.
  • eine flexible, skalierbare Architektur benötigt wird, die sich On-Premise, in der Cloud oder in einer hybriden Umgebung einsetzen lässt.
  • geplant ist, die Architektur nach und nach auf eine In-Memory-Datenbank umzustellen. IMDG als Teil einer In-Memory-Computing-Plattform ermöglicht es, ohne Schwierigkeiten umzusteigen, um anschließend eine In-Memory-Datenbank aufzubauen.

Beispiele für In-Memory Data Grids sind Hazelcast, GigaSpaces, Oracle Coherence, Apache Geode/Pivotal GemFire und Infinispan. Manche Anbieter wie GridGain beziehungsweise Open-Source-Projekte wie Apache Ignite bieten Data Grids als Teil einer In-Memory- Computing-Plattform ab.

Was sind In-Memory-Datenbanken?

In-Memory-Datenbanken wie MemSQL oder VoltDB sind wie normale Datenbanken, die jedoch alle ihre Daten (verteilt auf mehrere Server) im RAM halten, um einen schnellen Zugriff zu ermöglichen. Obwohl sie teilweise über Speicherfähigkeiten verfügen, sind sie im Grunde genommen reine Memory-Architekturen. Sie werden als Datenbanken bezeichnet, weil man sie mit SQL und Standarddatenbanktreibern steuert. Nutzer können Schemata erstellen, Abfragen stellen und DDL- oder DML-Anweisungen wie Inserts, Updates und Löschvorgänge verwenden.

Eine In-Memory-Datenbank (IMDB) eignet sich für neue oder neu strukturierte Anwendungen. Es handelt sich um eine vollständige und eigenständige Datenbank, die API-Datenverarbeitung wie ANSI-99 SQL, Key-Value oder Machine Learning unterstützt. Der Vorteil einer In-Memory-Datenbank gegenüber einem In-Memory DataGrid ist die Reduktion der Strukturen von drei Schichten (Anwendung, In-Memory und Daten) auf zwei. Die Systeme haben einen sehr hohen Durchsatz, da auf die Daten im RAM zugegriffen wird. Sie zeichnen sich zudem durch eine gute Skalierbarkeit aus, da sie ihre Daten auf mehrere Server verteilen.

Bei einer In-Memory-Datenbank ist SQL jedoch die einzige Möglichkeit, mit dem System zu kommunizieren, und SQL passt nicht für alle Anwendungsfälle. Manchmal ist es wichtig, Berechnungen direkt mit den Daten durchführen zu können, die sich auf einem bestimmten Server befinden, um die Leistung zu optimieren. Apache Ignite und GridGain als voll funktionsfähige In-Memory-Computing-Plattformen unterstützen ANSI SQL-99 mitsamt DML- und DDL-Support.

Beispielhafte Architektur einer In-Memory-Datenbank

Der Nachteil ist, dass sich In-Memory-Datenbanken nicht für bestehende Anwendungen verwenden lassen, ohne Teile der Daten aus einer Datenbank zu entfernen und neu einzufügen (Rip & Replace). Die meisten Unternehmen haben eine Menge Infrastrukturcode um ihre bestehenden Datenbanken herum, sodass die Migration auf eine neue Datenbank einen enormen Aufwand erfordert. Aus diesem Grund sind In-Memory-Datenbanken am besten für Unternehmen geeignet, die entweder eine erste Datenbank auswählen oder ihre bestehende Datenbank vollständig ersetzen müssen.

Da eine In-Memory-Datenbank als Aufzeichnungssystem dient, muss zusätzlich die Umsetzung einer Strategie für den Schutz der Daten im Fall eines Ausfalls umfassen. Die Strategie könnte ähnlich zu der beständigen Speicherkapazität von In-Memory DataGrids sein, oder es könnte die Nutzung von nichtflüchtigem RAM, also RAM, dass seine Daten speichern kann, auch wenn der Speicherchip keinen Strom mehr erhält, enthalten.

Datenbankstrategien

Organisationen, die eine langfristige Strategie entwickeln, die auf die Beschleunigung bestehender und die Einführung neuer Anwendungen hinausläuft, können sich für eine In-Memory-Computing-Plattform entscheiden, die die Skalierbarkeit eines IMDG mit den vollen relationalen Datenbanken einer IMDB umfasst. Sie kann demnach bestehende Anwendungen beschleunigen oder die Grundlage für das Erstellen neuer oder neu strukturierter Anwendungen bilden, die die Vorteile eines verbreiteten Computings und eines dauerhaften Speichers besitzen.

Unternehmen sollten zu der Entscheidung, welche Technologie am besten den eigenen Anforderungen entspricht, außerdem in Erwägung ziehen, ob sie zusätzliche Unterstützung durch In-Memory-Techniken benötigen, etwa folgende:

  • eine Streaming-Analyse, die die gesamte Komplexität des Datenflusses und der Ereignisverarbeitung verwaltet.
  • ein Framework für kontinuierliches Lernen als Baustein für ein In-Prozess-HTAP (Hybrid Transactional/-Analytical Processing), der Machine Learning oder vertiefende Analysen der Betriebsdaten in Echtzeit anwendet.

Unternehmen sollten bei der Evaluierung von IMDGs vor allem In-Memory-Computing-Plattformen in Betracht ziehen, die ein IMDG und eine In-Memory-Datenbank enthalten. So können sie zu einem späteren Zeitpunkt eine deutlich einfachere Migration durchführen. Zudem sollten folgende Punkte beachtet werden:

  • Support für ANSI-99-SQL, sodass sich das IMDG einfach in SQL-Architekturen einfügen lässt.
  • Support von ACID-Transaktionen, sodass die Plattform als Aufzeichnungssystem für wertvolle Anwendungen in Produktionsumgebungen verwendet werden kann.
  • Plattform- und Sprachflexibilität für einfache Integration und maximalen Return on Invest.

Fazit

Entwickler sollten bei der Implementierung von In-Memory-Computing-Techniken ein genaues Verständnis von Strategien und Fähigkeiten von In-Memory Computing haben und davon, wie ihre Datenbank aufgebaut sein soll. Dann ist IMC eine leistungsstarke Möglichkeit, die Geschwindigkeit und Skalierbarkeit von Applikationen deutlich zu erhöhen. In Zeiten, in denen zunehmend größere Datensätze immer schneller verarbeitet werden sollen, ein enormer Vorteil. (ane)

Nikita Ivanov
ist Gründer des Apache-Ignite-Projekts und CTO von GridGain Systems. Er begann bei GridGain mit der Entwicklung verteilter In-Memory-Datenverarbeitungstechniken. Ivanovd verfügt über mehr als 20 Jahre Erfahrung in der Entwicklung von Softwareanwendungen sowie von HPC- und Middleware-Plattformen.