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 12.04.2019 Dateisysteme für den PByte-Bereich

Datenberge jenseits des PByte-Bereichs, Cloud-Anbindungen und Analytics-Szenarien stellen Dateiysteme vor neue Herausforderungen. Der Markt bietet einige Optionen wie GPFS, Gluster FS, OneFS oder QF2. Worauf gilt es zu achten?


05.04.2019 Neuordnung des Storage-Tiering

Nachdem sich Flash und SSDs mittlerweile auch in mehrere Leistungsklassen unterteilen, steht die Technik nicht mehr nur für Tier 0. 15k-HDDs scheinen vor dem Aus zu stehen. Gilt dies auch für alle SAS-Platten? Wie sieht die Neuordnung des Storage-Tiering aktuell aus?


15.03.2019 30 Jahre World Wide Web: Was gibt es zu feiern?

Das World Wide Web feiert seinen 30. Geburtstag. Ohne dem Internet ist unser heutiges Leben nicht mehr vorstellbar. Für Doc Storage hat das Netz aber auch genug Schattenseiten. An Regulierungen bzw. an das vom Erfinder erhoffte bessere Internet, glaubt er nicht.


08.03.2019 Datenanordnung im RAID 10 mit 8 Platten

In einem Server wird ein RAID 10 mit acht Festplatten unter Windows 2008 R2 betrieben. Nun ist ein Laufwerk ausgefallen. Da sich nur wenige Daten auf den HDDs befinden, besteht die Möglichkeit, dass die defekte Platte eventuell gar keine Daten enthält?


22.02.2019 Welcher RAID-Level für welche Anwendung?

Gibt es eigentliche eine Faustregel, welches RAID-Level für welche Anwendung am besten geeignet ist? Ich denke da zum Beispiel an Datenbanken mit sehr vielen Zugriffen bei relativ kleinen Datenmengen oder an Webserver und als Extrem auf der anderen Seite Bild-Datenbanken, Audio-Server beim Rundfunk, Video-Archive mit sehr hohen Datenvolumen.


15.02.2019 Was sagt DWPD über SSDs aus?

Im Zusammenhang mit (Enterprise-)SSDs wird oft die Qualitätsgröße DWPD (Drive Writes Per Day) genutzt. Meist wird die Angabe auch für einen Zeitraum von fünf Jahren spezifiziert. Was sagt DWPD genau aus und mit welcher Standard-Lebensdauer darf man rechnen?

powered by
Boston Server & Storage Solutions Datacore Software
Fujitsu Technology Solutions GmbH Seagate Technology
N-TEC GmbH FAST LTA AG