10.10.2014 (Doc Storage)
4.7 von 5, (11 Bewertungen)

In-Memory: Riesiger Arbeitsspeicher – droht Desaster?

Leserfrage: Wir haben uns jetzt in unserer feinen mittelständischen Firma prinzipiell für ein In-Memory-Computing-Projekt mit »SAP HANA« entschlossen. Das bedeutet: Toller neuer Server – mit einem Arbeitsspeicher im satten dreistelligen GByte-Bereich. Fiel der Server vor zehn Jahren samt den Daten im Arbeitsspeicher aus, war das verkraftbar. Aber jetzt hab ich angesichts der Masse von Produktions-, Versand- und Bestelldaten, die bei einem Server-Ausfall noch nicht in die Datenbank geschrieben wurden, echte Bauchprobleme.

Das bedeutet doch, dass wir eigentlich eine Art zweite SAP HANA mit echter synchroner Datenspiegelung auch des flüchtigen Hauptspeichers benötigen. Welche vertretbaren Lösungsansätze gäbe es denn hier?

Antwort Doc Storage:

Hier sprechen Sie ein Problem an, das sich viele Anwender von In-Memory-Datenbanken in den meisten Fällen nicht bewusst machen. Für den Schutz größerer Datenmengen im Hauptspeicher der betroffenen Rechner gibt es genau zwei Ansätze. Zum einen das Anlegen eines gespiegelten Speicherbereiches innerhalb eines Clusters, zum anderen das Schreiben aller I/Os nicht nur in den Hauptspeicher, sondern ebenso in ein angeschlossenes Laufwerk, beispielsweise in ein PCIe-SSD.

Beide Lösungen sind extrem teuer: Lösung 1 halbiert Ihnen den verfügbaren Hauptspeicher, Lösung 2 erfordert (theoretisch) mindestens eine SSD in der Größe Ihres Hauptspeichers. Beides zeigt, dass entgegen der durch SAP und andere Anbieter betriebenen Propaganda In-Memory-Datenbanken im Ende wesentlich teurer sind als der herkömmliche Betrieb, wenn man die Daten genauso absichern möchte wie in den herkömmlichen Landschaften.

Ganz davon abgesehen, dass man durch diese Art der Datenverarbeitung die teuerste Ressource im gesamten Server kannibalisiert, bieten heutige PCIe-Lösungen, neuerdings sogar mit der neuen Phase-Change-Technologie, annähernd dieselbe Geschwindigkeit wie die In-Memory-Lösungen und sind durch Replikation oder Spiegelung über herkömmliche Volume-Manager wesentlich einfacher logisch zu schützen. So gesehen ist In-Memory eine Zwischenlösung, deren Lebensdauer bereits heute absehbar ist.

Gruß
Doc Storage

Stellen Sie Ihre Frage
Doc. tec. Storage beantwortet alle Ihre technischen Fragen zu Storage, Backup & Co.

Stellen Sie Ihre Frage an: DocStorage@speicherguide.de
Kommentare (7)
20.10.2014 - kfr

Wenn der Doc eine polarisierende Meinung vertritt, führt das fast immer zu konstruktiven (und z.T. ebenfalls polarisierenden) Kommentaren - und das ist auch gut so! ;)

20.10.2014 - DocMainMemory

Es ist unglaublich, nicht wahr?

19.10.2014 - Godwin

und das von einem rotzläufligen Studenten...

19.10.2014 - DocMainMemory

Leider war das Kommentarlimit erreicht.

Zu PCM: laut Messungen zu einem aktuellen (öffentlichen) Prototyp zeigen sich zwar geringere Leselatenzen, aber höhere Schreiblatenzen sowie ein insgesamt geringerer Lesedurchsatz.
Zu PCIe-SSD: um hier akzeptable Schreibraten zu bekommen werden in den Benchmarks oft Blockgrößen von vielen Megabytes genommen. Die beworbenen IOPS sind in der Regel weitaus geringer für Workloads, wie sie in Datenbanken anfallen (dort sind es aufgrund von Latenzversprechen eher wenige Kilobyte).

Disclaimer: ich bin Student am HPI (auch direkt am openHPI Projekt beteiligt).

19.10.2014 - DocMainMemory

Bei allem Respekt, diese Antwort lässt leider jegliche Einsicht in Datenbankanwendungen der letzten 10 Jahre vermissen.

Glauben Sie ernsthaft, dass Datenbankhersteller (inzwischen hat nun wirklich jeder größere Hersteller eine Hauptspeicherlösung) verschweigen, dass Daten bei einem Stromausfall verloren gängen?

Ich würde Ihnen hier empfehlen Kurse zu belegen, welche z.B. unter openHPI.de kostenlos angeboten werden. Hier wird sehr einsteigerfreundlich beschrieben, dass auch Hauptspeicherdatenbank Snapshot der aktuellen Daten weiterhin auf Festplatte speichern und Änderungen fortwährend mitgeschrieben werden in ein sogenanntes Log.
Gerade eine Firma die Geschäftsanwendungen schreibt wie die SAP kann sich Datenverlust unmöglich leisten.

Zu Ihren besprochenen Alternativen kurz folgende Anmerkungen:
- Replikate der Datenbanken sind nicht primär zur Datensicherheit gedacht (wie gesagt, es wird ohnehin auf Festplatte persistiert) sondern zur Ausfallsicherheit mit Hinblick auf Ausfallzeiten. Ein repliziertes System ist in Sekunden wieder nutzbar, während ein einzelnes System im Worst Case Hunderte Gigabyte von der Festplatte lesen müsste, bevor es wieder erreichbar ist (wobei es hier auch weitaus klügere Lösungen für das Recovery von Hauptspeicherdatenbanken gibt).
- PCIe-SSD Lösungen sind bei weitem nicht in der Lage an die Geschwindigkeit von Hauptspeicherlösungen heranzureichen. Dazu braucht man nur aktuelle Benchmarks von FusionIO und Intel's XEON 4890 E7 v2 anzugucken. Zumal PCIe-Anschlüsse selber recht limitiert sind. Weiterhin sind die Kosten hier für die schnellsten Lösungen nicht grundliegend geringer als für Hauptspeicher.
Von anderen Problemen wie ungenügende Schreibgeschwindigkeit ganz abgesehen.
PCM mag hier eine Lösung sein in einigen Jahren. Aber nicht in den nächsten 2 Jahren (FAST 14, Kim et al).

10.10.2014 - dunterse

Ich sehe die Zukunft der IMDBs deutlich positiver – da vernünftige Backup/Recovery-Prozesse möglich sind:

IMDBs (wie SAP HANA) (oder besser gesagt deren Hersteller) erkennen so langsam, dass der Backup (für die notwendigen Restore-Prozesse = „Rückwärtsgang auf einen sauberen Stand der Daten“) eben auch bei IMDBs notwendig ist. Ein synchroner Spiegel hilft für einige Fehlerquellen einfach nicht.

Und danach merken sie, dass ein häufiger kompletter Offload der IMDB für Backup-Zwecke nicht sehr effektiv ist. Also arbeiten sie zunehmend an granular Incremental Forever Backups (auch SAP HANA).

Und danach merken diese im dritten Schritt, dass die Harddisk-basierten Backup-Speicher im Falle eines Restores relativ schnell die komplette DB wiederherstellen können sollen. Und siehe da: Dafür sind die etablierten Array-Snapshots eine optimale Technik.

Nach meinem Wissensstand bietet derzeit nur NetApp für SAP HANA über die lizenzkostenfreie SnapCreator Software Backups auf Disk-targets an, welche mit Array-Snapshots die Backup-Stände einfrieren – und das scheint mir die wirtschaftlich sinnvollste Backup-Lösung für IMDBs zu sein (denn man will sich nicht viele TB in Form von Flash / PCM leisten). Selbst wenn da mal PCM Chips die Preise am DP Target später purzeln lassen, ist diese Methode dann immer noch die vermutlich optimalste (weil DP target Kapazität schonendste – und relativ schnell beim Restore).

Es wird also auch hier alles gut werden, wenn man die Backup-/Recovery-Prozesse modernisiert. IMDBs sind aus meiner Sicht längerfristig im kommen und dürften dann PCM als RAM-Erweiterung auf den Server Motherboards benutzen.

10.10.2014 - Schniefus

Ich kenne die innere Struktur von SAP HANA nicht. Wir werden hier in der Firma wohl auch nicht so schnell in Datenmengendimensionen vorstoßen, die Systeme mit In-Memory-DB erforderlich machen.
Allerdings interessiert mich die Thematik schon etwas länger. Als am HPI Potsdam der Kurs "In-Memory Data Management" angeboten wurde, habe ich deshalb gleich zugeschlagen. Der Kurs läuft noch, aber ich kann so viel sagen, dass die dort entwickelte "Sanssouci DB" (als eine In-Memory-DB) durchaus Implementierungen besitzt, die die von Ihnen angesprochenen Nachteile nicht aufweist. Lange Rede kurzer Sinn, ich glaube nicht, dass das Ende von In-Memory-DBs schon da ist, bevor es überhaupt richtig angefangen hat. Es gibt in diesem Bereich Ansätze, die ein "Weiterleben" meiner Meinung nach rechtfertigen.


Mehr von Doc. tec. Storage 02.08.2019 Soft-/Hardware: Wie Daten richtig verschlüsseln?

Eine Software-Verschlüsselung soll weniger Probleme verursachen, als eine Hardware-Verschlüsselung. Stimmt das? Was passiert, wenn der gewählte Verschlüsselungsanbieter nicht mehr verfügbar ist, wie kommt man dann an seine Daten?


12.07.2019 Analysten-Prognosen sind verschwendete Lebenszeit

Diesmal nimmt sich Doc Storage die Trendvorhersagen von Marktforschern vor. Seiner Ansicht nach ist vieles nur ein Blick in die Glaskugel, anderes dagegen so offensichtlich, dass es keine weitere Betrachtung benötige. Er hält diese Art von Info für verschwendete Lebenszeit.


28.06.2019 DSGVO bleibt aus DV-Sicht ein unsägliches Thema

Kolumne: Unser Doc Storage ist kein Freund der DSGVO. Dies hat er in mehreren Kolumnen klar formuliert. In seinem zweiten Teil zu »Ein Jahr DSGVO« fasst er nochmal zusammen, warum die Thematik aus seiner DV-Sicht für Firmen unsäglich ist.


14.06.2019 Ein Jahr DSGVO: Aufwand unerträglich hoch

Kolumne: Zur Einführung der DSGVO hat Doc Storage mächtig Dampf abgelassen. Ein Jahr später lässt kaum ein Verband ein gutes Haar an der Datenschutz-Grundverordnung. Der Aufwand für Firmen und IT-Abteilungen sei unerträglich hoch.


07.06.2019 Welchen Flash für welche Anwendung?

Vor rund sechs Jahren schickten sich Flash-Speicher an, sich in Computern und Storage-Systemen zu etablieren. Damals galten die Lösungen aber noch als proprietär. Wo steht die Technik heute und welcher Flash eignet sich für welchen Einsatzzweck?


17.05.2019 NAS-Caching oder Tiering für VMs multiple Zugriffe?

In einer Lehrumgebung werden virtuellen Maschinen auf einem NAS mit 10GbE-Anbindung gespeichert. Nachdem eine Erweiterung mit NVMe-Flash ansteht, stellt sich die Frage, ob eine Caching- oder eine Tiering-Konfiguration die sinnvollere Wahl ist?

powered by
Boston Server & Storage Solutions Itiso GmbH
Fujitsu Technology Solutions GmbH Infortrend
N-TEC GmbH FAST LTA AG
Datacore Software Seagate Technology
Folgen Sie speicherguide.de auch auf unseren Social-Media-Kanälen
Folgen Sie und auf Facebook Folgen Sie und auf YouTube Folgen Sie und auf Twitter