In-Memory-Datenbanken

Welju Grouv

Benutzer
Beiträge
10
Wie wahrscheinlich ist es, dass In-Memory-Datenbanken in den nächsten Jahren so weit verbessert werden, dass sie relationale Datenbanken ersetzen könnten und infolgedessen die Nachfrage nach letzteren zurückgehen wird?

In diesem Zusammenhang beschäftigt mich derzeit auch die Frage, ob diese IMDBs als bisherige Nischenangebote zu den disruptive innovations zu zählen sind. (http://en.wikipedia.org/wiki/Disruptive_technology)

Heute für analytics, morgen für data warehousing und übermorgen ...

Für SAP "the long-term plan is for the in-memory technology to serve as both the analytical database and the transactional database running SAP applications." Dazu auch Plattner im Mai letzten Jahres: "Ich möchte nicht zur Hexenjagd auf traditionelle relationale Datenbanksysteme blasen, aber sie sind einfach überflüssig geworden."

Bei HANA werden die Funktionalitäten von relationalen Datenbanken und OLAP-Würfeln direkt im Arbeitsspeicher abgebildet. Als Backup können zum Beispiel Solid-State-Disks verwendet werden.

Andere In-Memory-Datenbanksysteme sind GemStone (VMware), ASE 15.5 (Sybase/SAP), QlikView (QlikTech), SolidDB (IBM) und TimesTen (Oracle).
 
Werbung:
Ich hab den Begriff In-Memory-DB grade das erste mal nachgelesen und der Wiki Artikel klingt für mich plausibel. Allerdings sehe ich keinen Zusammenhang zwischen den Begriffen. In-Memory beschreibt für mich den Speicherort, relationale Datenbank beschreibt für mich die Informationsstruktur. Alles was eine relationale DB auf der Festplatte ablegt kann sie natürlich rein theoretisch auch im RAM ablegen. Das setzt ja nicht voraus, das die Datenstruktur eine andere ist. Insofern passen auch die beiden von dir gebrachten SAP Zitate in keinen sinnvollen Zusammenhang.
Außerdem: Auch SAP wird seine In-Memory DB auf einem nicht flüchtigen Speicher abbilden / spiegeln müssen, sonst sind ihre Daten irgendwann futsch. Das kann nur aus performancegründen während des Arbeitens oder für temporäre Daten sinnvoll sein. Eine DB auf einer SSD ist nicht flüchtig, aber eine SSD ist auch keim RAM ergo auch keine In-Memory DB.

Zum wirtschaftlichen Aspekt: Ein dermaßen etabliertes Verfahren wie relationale Datenbanken sind nicht einfach weg zu denken. Das Know-How ist da, die Technik ist da, vieles ist darauf ausgelegt. Das kann nicht einfach durch eine andere Form der Datenhaltung abgelöst werden, das geht nur in Berreichen wo Inovationsdruck und die nötigen Finanzen hinter stehen und setzt sich dann vieleicht nach unten durch.
 
"Zum wirtschaftlichen Aspekt: Ein dermaßen etabliertes Verfahren wie relationale Datenbanken sind nicht einfach weg zu denken. Das Know-How ist da, die Technik ist da, vieles ist darauf ausgelegt. Das kann nicht einfach durch eine andere Form der Datenhaltung abgelöst werden, das geht nur in Berreichen wo Inovationsdruck und die nötigen Finanzen hinter stehen und setzt sich dann vieleicht nach unten durch."

Die Wechselkosten wären sicherlich beträchtlich, weshalb sich diese Antwort recht schlüssig liest. Danke.
"Alles was eine relationale DB auf der Festplatte ablegt kann sie natürlich rein theoretisch auch im RAM ablegen."

Da steckte ein Fehler meinerseits. Es hätte natürlich heißen müssen: "dass sie traditionelle relationale Datenbanken ersetzen könnten". Die SAP-Zitate dagegen sind korrekt und gehören auch in jenen Kontext.
"Auch SAP wird seine In-Memory DB auf einem nicht flüchtigen Speicher abbilden / spiegeln müssen, sonst sind ihre Daten irgendwann futsch."

Was derzeit ja so gehandhabt wird, d. h. gespeichert wird jeweils doppelt, also auch in einer traditionellen relationalen DB. Und selbst Oracles Exadata soll demnächst ein In-Memory-Add-on erhalten, oder vielleicht etwas besser ausgedrückt: Oracle 11 g kommt mit einer In-Memory DB Cache-Lösung auf den Markt.
In Walldorf meint man allerdings, dass künftig (Zeiten wurden m. W. nicht genannt) jene traditionellen DBs für BI- und ERP-Anwendungen überflüssig wären Als Sicherungsmedium wurden die erwähnten SSD ins Spiel gebracht.
Neben der höheren Geschwindigkeit wäre laut Snabe ein weiterer Vorteil, dass für Lösungen, die In-memory nutzen, etwa 40 Prozent weniger Code benötigt wird. Applikationen könnten entsprechend effizienter gestaltet werden.
 
Ich würde sagen das das Ganze wie beschrieben als Add-in im DBMS irgendwo im Hintergrund läuft, der "normale" DB-Admin damit also wenig zu tun hat. Ich denke weniger, das es über Abfragen mit TSQL einen Unterschied machen wird, wo die DB liegt. Das würde dann auch den Wirtschaftlichen Faktor stark abschwächen, denn eigentlich kümmert sich das DBMS um alles, der Programmierer / Admin legt nur Cachegrößen fest. Die Implementierung übernimmt der DB Hersteller, der hat die nötigen Ressourcen und Know-How.

Einzig die 40% weniger Code kann ich nicht nachvollziehen, ich bin aber auch kein Anwnedungsentwickler.
 
Dass der Zugriff mittels der gewohnten SQLs möglich ist und es für den "normalen" DB-Admin keinen Unterschied macht, dürfte die Einführung von IMDBs eher erleichtern.

Es geht ja nicht darum, jene etablierten Systeme vollständig wegzudenken, aber auch für IBMs IMS galt wohl einst: "Das Know-How ist da, die Technik ist da, vieles ist darauf ausgelegt. Das kann nicht einfach durch eine andere Form der Datenhaltung abgelöst werden, das geht nur in Bereichen wo Innovationsdruck und die nötigen Finanzen hinter stehen und setzt sich dann vielleicht nach unten durch."

Für mich ist die Frage, ob bei BI-, ERP- und ähnlichen Anwendungen künftig In-Memory-DBs in Verbindung mit Solid-State-Disks (zur persistenten Sicherung) ausreichen könnten, nach wie vor offen.
 
Dass der Zugriff mittels der gewohnten SQLs möglich ist und es für den "normalen" DB-Admin keinen Unterschied macht, dürfte die Einführung von IMDBs eher erleichtern.

Das hab ich auch so gemeint.

Für mich ist die Frage, ob bei BI-, ERP- und ähnlichen Anwendungen künftig In-Memory-DBs in Verbindung mit Solid-State-Disks (zur persistenten Sicherung) ausreichen könnten, nach wie vor offen.

Das reicht genauso wie eine normale DB die auf Festplatte schreibt. Eine Sicherung der Daten ersetzt es nicht.
 
Noch so ein Punkt, der mir zu denken gibt:
Wenn überall dort, wo es – sowohl on-premise als auch in der Cloud – auf hohe Zugriffsgeschwindigkeiten ankommt, eine In-Memory-DB verwendet würde, wären vermutlich fast alle Angebote mit dieser Technik aus Sicht der Anwender schnell genug, d. h. x Millionen Transaktionen pro Sekunde mehr oder weniger wären dann kein entscheidender Wettbewerbsvorteil.

Würde das Mehr an Features bei Oracle 11 und DB2 deren Marktdominanz auch weiterhin langfristig sichern? Eine vergleichbar hohe Datensicherheit (auch bei Serverabstürzen) natürlich vorausgesetzt.
 
Ich setze kein Oracle ein, ich kenne auch Niemanden der das tut, welche Marktdominanz? - Naja gut, Spass bei Seite. Oracle hat seine Marktanteile, aber eben in Segmenten die ganz andere Größenordnungen von DBs fahren. Ich persönlich glaube eher, das Oracle eine ziemliche Seuche sein kann. Wer das einsetzt, sollte wissen warum er mit Oracle besser fährt.
Im Mittelstand sehe ich eher MS vorne, die Integration in MS Produkte, die breite Windows Server Front, das viele Know-How, die kostenlose Express Edition die super für normale Programme wie CMS einsetzbar ist, etc. Natürlich geht das in keinen Marktanteil, weil es nix kostet. Genutzt wird es aber trotzdem auf breiter Front.
Wenn etwas Oracles Dominanz sichert dann vermutlich Inkompatibilität. -.-
 
MS scheint auch dynamischer zu wachsen. Beispiel embedded DBMS (http://www.oracle.com/us/corporate/analystreports/infrastructure/idc-embedded-2009-275127.pdf).
Die erwähnte Integrationsschiene wird allerdings auch von IBM und Oracle gefahren, wenngleich mit anderen Programmen.
Sind IMDBs derzeit die einzige bedeutende Innovation im Datenbank-Markt oder droht dort bereits Kommoditisierung?

Wenn etwas Oracles Dominanz sichert dann vermutlich Inkompatibilität. -.-
Ich vermute mal Im Sinne von "zusätzliche Wechselkosten wegen Kompatibilitätproblemen".
 
Heute in der Computerwoche ein Artikel von Martin Bayer (http://www.computerwoche.de/software/bi-ecm/2494293/index8.html):

[Marco Lenck, von der DSAG:] "In-Memory könne zwar durchaus ein Kandidat dafür sein, relationale Datenbanktechnik abzulösen. Doch da sind wir heute definitiv noch nicht, und wir reden an dieser Stelle nicht von diesem und auch nicht vom nächsten Jahr."

"HANA ein Hybridmodell, das eine zeilen- und spaltenorientierte Datenhaltung erlaubt." "Softwarepaket aus In-Memory-Datenbank und Business-Intelligence-Applikationen".

"Langfristig gesehen könnte damit das Thema Datenbank marginal werden. Mit In-Memory als zentraler Technik sei eine relationale Datenbank nicht mehr so wichtig, prognostiziert der SAP-Manager: 'Diese kann letztlich nicht die erforderliche Leistung bringen.' Das sieht man bei der Konkurrenz, wie nicht anders zu erwarten, etwas differenzierter. In bestimmten Situationen mögen Systeme wie HANA Sinn geben und eine In-Memory-Datenbank notwendig machen, meint Günther Stürner, Vice President für den Bereich Server Technologies bei Oracle in Deutschland. Das seien jedoch sehr spezifische Anwendungen: 'Es ist im Grunde immer eine Art Nische'. Prognosen von SAP, das Ende der Disk-basierenden relationalen Datenbanksysteme sei abzusehen, hält der Oracle-Manager für reichlich übertrieben. Stürner verweist auf Caching-Techniken, die auch für traditionelle Datenbanken genügend Leistungsreserven böten. ... An dieser Stelle müssten noch einige Fragen beantwortet werden, beispielsweise, ob der hier zur Verfügung stehende SQL-Sprachumfang auch für hochkomplexe Abfragen geeignet sei oder die auch hier notwendigen Optimizer gut funktionierten."

"Gerade ein Umbau der Datenbank sei alles andere als trivial. Anpassungen, die mittels möglicherweise herstellerspezifischer SQL-Scripts in die Datenbank eingebaut wurden, ließen sich nicht ohne Weiteres migrieren und in die neue In-Memory-Welt mitnehmen."

"Richtig profitieren würden die Anwendungen allerdings erst dann, wenn sie In-Memory nativ unterstützten, schränkt er ein. 'Doch dazu muss man die Software umschreiben.' Es gebe allerdings nur Sinn, die Performance-kritischen Applikationen anzupassen: 'Kein Mensch wird die Funktion ‚Einen Auftrag anlegen` umprogrammieren.'"

+
SAP bzw. McDermott vor einigen Wochen:
"The Hana appliance has a 400 million Euro ($570 million) sales pipeline, and SAP is counting on about 100 million Euros ($142 million) in completed sales this year." "The pipeline for Hana is the biggest in the history of SAP." "Ich kann Ihnen leider nur Namen von Kunden nennen, die es uns gestattet haben, sie zu erwähnen. Dazu gehören T-Mobile, Medtronic und Colgate. Ingesamt umfasst diese Liste 67 Namen, und bei allen handelt es sich um bemerkenswerte Installationen. Mittlerweile haben wir schon den ersten Kunden, der eine zweite HANA-Maschine bestellt hat. Und auf die ein oder andere Weise setzen HANA bereits 35 Kunden produktiv ein. Damit ist HANA der am schnellsten wachsende Produktbereich in der Geschichte von SAP."
 
Nungut, ich sage mal Mittelstand bis max 200 Arbeitsplätze und ohne internationale Standorte.

Das SAP auf In-Memory abfährt ist klar, anders sind sie zu langsam :) Wenn die DATEV auf den Zug aufspringt, bin ich auch betroffen.

Dennoch verstehe ich nicht, warum sich relationale Datenbank und In-Memory wiedersprechen, vieleicht bin ich nicht genug in der Materie.
 
Dennoch verstehe ich nicht, warum sie [sich?] relationale Datenbank und In-Memory wiedersprechen, vieleicht bin ich nicht genug in der Materie.

Kommt auf die jeweilige IMDB an. Oracle's Times Ten ist eine "zeilenbasierende In-Memory-Datenbank", als eine relationale. Andere IMBDs wie HANA gehen darüber hinaus.
Ich denke, dass M. Bayer die Unterschiede recht gut erklärt.
 
Werbung:
Dazu A. Weininger von IBM in jenem Artikel:
"Zwar lasse sich auch in traditionellen Datenbanksystemen im Grunde vieles In-Memory cachen. Dennoch seien die Lösungen darauf ausgelegt, die Daten blockweise von einer Festplatte zu holen. Dagegen kämen im Zuge von In-Memory-Datenbanken Algorithmen zum Einsatz, die speziell für diese Technik ausgelegt seien und Leistungsvorteile böten."
 
Zurück
Oben