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 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?


08.02.2019 Unterschiede der Performance-States von SSDs

Gängige Meinung: SSDs sind schnell. In der Praxis gibt es aber dann doch einige Unterschiede, so sind vielen die verschiedenen Performance-States von SSDs und Flash-Speichern nicht bekannt: FOB, steady, burst and transition. Was steckt genau dahinter?


01.02.2019 BSI empfiehlt 200-km-Distanz – 200 km ERNSTHAFT!?

Kurz vor Weihnachten veröffentlichte das BSI neue Kriterien für georedundante RZs. Darin wird der bisher empfohlene Mindestabstand von fünf auf 200 Kilometer hochgesetzt. Aus Praxissicht laut Doc Storage »vollkommener Blödsinn«.


31.01.2019 Nervfaktor digitale Transformation – ein Rant

Die digitale Transformation bzw. Digitalisierung verfolgt uns nun schon geraume Zeit. Mit dem Faktor Mensch kommt nun nochmal ein neues Trendthema hinzu. Doc Storage hat hier eine klare Meinung: »alles Blödsinn – es nervt«. Nichts von dem, was heute diskutiert wird, ist neu und Menschen waren schon immer der Kern eines jeden Geschäftsbetriebs – selbst in der IT.


25.01.2019 SSDs: Was ist mit den Schreibzyklen, wenn SSDs fast voll sind?

Moderne SSDs sorgen mit der Wear-Leveling-Funktion automatisch dafür, dass möglichst gleichmäßig über alle Sektoren geschrieben wird. Wie verhält es sich mit den spezifizierten Schreibzyklen, wenn die SSD nahezu voll ist?


18.01.2019 Wie sinnvoll sind Benchmarks und Performance-Tests?

Welchen Stellenwert haben Benchmarks und Performance-Tests (z.B. SPC-1 und SPC-2) bei der Anschaffung von Storage-Systemen? Man hört ja, dass sich Firmen die Anforderungen nur noch vertraglich garantieren lassen. Ist das wirklich ein gangbarer Weg?

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