Terracotta: In-Memory ohne Appliance

Inhaltsverzeichnis

In-Memory ist in aller Munde. Performanceverbesserungen um Faktoren von 1000 bis 10.000 sowie neue Verarbeitungs- und Datenstrukturen beherrschen die Diskussion. Während viele Anbieter mit aufwendigen Appliances oder anderen Hard- und Softwarekombinationen auf den Markt drängen, gibt es zunehmend mehr auf Standard-Hardware aufsetzende Angebote, die keine oder nur minimale Änderungen an den Anwendungsprogrammen benötigen – beispielsweise Terracotta von der Software AG.

Der In-Memory-Verarbeitung gehört anscheinend die Zukunft. Sowohl Big Data als auch die zunehmenden Forderungen nach Real-Time Processing machen aus Festplatten nur noch Archivierungssysteme. Zu Gartners Liste der gegenwärtig zehn heißesten IT-Techniken gehört ebenfalls In-Memory. Wobei die Gartner Analysten neben den bekannten Geschwindigkeitsvorteilen vor allem auf die Architekturunterschiede bei der Datenorganisation eingehen: "In-Memory erlaubt erstmals die parallele Abarbeitung transaktionsorientierter und analytischer Anwendungen auf demselben Datenbestand", sagt deren Analyst David Cearly.

Doch der wesentliche Vorteil ist sicherlich die extrem schnelle Verarbeitung, die Unternehmen aber nur erreichen, wenn sie alles In-Memory halten. Oder, wie es SAPs Co-Chef Jim Hagemann Snabe formulierte: "Man ist entweder komplett In-Memory – oder man ist es nicht. Es gibt nichts dazwischen, weil bei jedem Mix die langsameren Festplatten das Tempo diktieren." SAPs In-Memory-Plattform ist die Appliance HANA. Inzwischen gibt es sie sowohl in großen Installationen als auch nur scheibchenweise in der AWS-Cloud (Amazon Web Services).

Der große Nachteil von HANA ist, dass sich Programme nicht eins zu eins darauf übertragen lassen. Denn um die Vorteile der Plattform voll auszuschöpfen, muss die Software in SQL Script oder R erstellt sein. Und um nicht nur die schnelle HANA-Datenbank, sondern vor allem auch die Parallelverarbeitung vollends auszuschöpfen, ist die Abarbeitung in viele kleine Prozesse aufzuteilen, die sich dann weitgehend unabhängig voneinander starten lassen.

Es geht auch anders

Diese Einschränkungen rufen zunehmend mehr Anbieter auf den Markt, die ein In-Memory Computing mit Standard-Hard- und -Software realisieren. Hierzu gehören die großen IT-Anbieter IBM, Microsoft, VMware (mit GemFire) und Oracle – aber auch kleine Start-ups, wie McObject, Platfora, QlikTech und Aerospike. Besonders interessant ist die Technik von Terracotta, einem kalifornischen Unternehmen, das im Mai 2011 von der Software AG aufgekauft wurde. Deren BigMemory-Software erlaubt eine unbegrenzte Nutzung des Hauptspeichers eines Servers. Diese Software gibt es in zwei Versionen: BigMemory Go und BigMemory Max. Die Go-Version erlaubt die gesamte Nutzung des Hauptspeichers eines Servers, und mit BigMemory Max lässt sich der Hauptspeicher über mehrere Server hinweg zu einem einzigen In-Memory-Storage-Array verbinden.

Beide BigMemory-Versionen speichern die Daten in Form einfacher Java-Objekte, weil BigMemory zunächst für Java-Applikationen entwickelt wurde. Ziel war es, für eine Java Virtual Machine (JVM) eine bessere Hauptspeicher-Ausnutzung zu erreichen. Zwar akzeptieren die Nodes heute bereits hohe Hauptspeicherwerte von 16, 32 oder noch mehr Gigabytes. Doch die bekannten Probleme von Javas Garbage Collection (GC) begrenzen die effektive Nutzung des verfügbaren Speichers. Je größer die jeweiligen Heaps sind, desto häufiger ist eine GC-Operation durchzuführen. In den meisten Fällen sind zwei Gigabyte die praktische Obergrenze für ein Java-Heap.

BigMemory schafft jetzt eine weitere Ebene zwischen den schnellen Heap-Abrufen und den langsamen Disk-Zugriffen, indem es einen Daten-Cache dazwischen schiebt. Dafür sind zwar alle Daten in der Form Schlüssel/Wert zu serialisieren, doch die damit verbundenen geringen Performanceeinbußen sind im Vergleich zu den sonst erforderlichen Plattenzugriffen vernachlässigbar. Laut Karl-Heiz Streibich, CEO der Terracotta-Muttergesellschaft Software AG, ergeben sich durch diese In-Memory-Technik Performanceverbesserungen um den Faktor 1000.

Erreicht wird die Leistung von BigMemory durch eine komplette Speicherverwaltung, die das gesamte RAM eines Servers managt – egal wie groß es ist. Da Server mit einem Terabyte RAM zunehmend populärer werden, bedeutet das, dass für viele Anwendungen alle erforderlichen Daten direkt hauptspeicherresident bereitstehen können. Für die Nutzung von BigMemory Go sind auch keine Änderungen an den bestehenden Java-Anwendungen erforderlich, denn zum Angebot gehören de facto Java APIs, die alle GET- und PUT-Anweisungen auf das eigene Memory-Management umlenken. Damit entfallen alle mit Java einhergehenden Datenmanagement-Beschränkungen, und die Anwendungen können sofort den gesamten Hauptspeicher vollends für sich nutzen. Hinzu kommen bei BigMemory Go noch administrative Tools, wie automatisches Disk-Backup, Datenkompression, Verschlüsselung, Suchfunktionen und Restart-Features.

Neuester Stand

Es geht auch mehr

BigMemory Max ist dann die Erweiterung von BigMemory Go in der Form, dass hierbei ein Storage-Array aus allen RAM-Bereichen von mehreren Servern entsteht. Das heißt, jeder einzelnen Java-Anwendung auf einem der angeschlossenen Server steht praktisch die Summe aller freien RAM-Bereiche zur Verfügung. Wie immer, hat jedoch jede Vereinfachung ihren Preis. Hier in Form von etwas längeren Zugriffszeiten, da der Zugriff auf die RAM-Bereiche außerhalb des eigenen Servers zwangsweise übers Netz geht und somit langsamer ist als der direkte Zugriff auf den eigenen Speicher. Doch auch hier sind die Performanceeinbußen im Vergleich zu einem Festplattenzugriff vernachlässigbar.

Damit stehen für die In-Memory-Datenverwaltung drei Geschwindigkeitskategorien zur Verfügung: erstens der direkte Zugriff auf die Java-Heaps im Bereich von Mikrosekunden. Zweitens die Daten innerhalb der Verwaltung von BigMemory Go, die ebenfalls im Hauptspeicher des Servers abgelegt und auch in Mikrosekunden abrufbar sind. Und drittens die Daten, die im Hauptspeicher eines angeschlossenen Servers zu finden sind (bei BigMemory Max). Hier erfolgt der Zugriff im Bereich von Millisekunden. Eine Ebene darunter liegen dann externen Datenquellen wie Datenbanken, Hadoop oder Data-Warehouse.

Der Hauptnachteil der Terracotta-Technik ist die Bindung an Java. Zwar ist die Programmiersprache bei der Anwendungsprogrammierung weit verbreitet – aber es gibt auch viele andere Programmierplattformen. Zur Lösung der Einseitigkeit hat Terracotta eine breite Palette an APIs entwickelt, sodass sich BigMemory auch aus anderen Anwendungen heraus aufrufen lässt – wenn auch nicht so einfach und nicht so schnell.

Kürzlich hat der neue Eigentümer die jüngste technische Erweiterung für die Terracotta-Software bekannt gegeben. So wurde BigMemory mit dem SOA-Produkt webMethods 9.0 integriert. Dabei handelt es sich aber nicht um eine direkte Verzahnung der beiden Softwarepakete, sondern um eine Anbindung über den Enterprise Service Bus von webMethods. Das heißt, die Terracotta APIs wurden zu Services erweitert, die sich dann – wie jede andere Anwendung auch – über den Bus aufrufen lassen.

Das Interesse an Terracottas In-Memory-Technik nimmt bei großen Anwendern und der Entwickler-Gemeinde offenbar rasant zu. Insgesamt gibt es laut Terracotta mehr als eine Million BigMemory-Installationen. Für den weiteren Ausbau wurde jüngst ein Partner-Programm aufgelegt. Damit soll es den Softwareentwicklern erleichtert werden, BigMemory Go schnell bei ihren Kunden zu installieren und damit die Performanceprobleme von deren Anwendungen erheblich zu verbessern.

Harald Weiss
ist seit über zehn Jahren freier Fachjournalist in New York und berichtet regelmäßig von vielen bedeutenden IT-Events in den USA. Er begann seine Berufslaufbahn als Softwareentwickler und System-Ingenieur, bevor er über die Stationen Marketing und PR zur schreibenden Zunft kam. (ane)