MongoDB, GraphDB und die neuen (Produkt-)Datenbanken

Fast 25 Jahre hat sich in der Datenbank-Technologie wenig Spektakuläres getan. MySQL, Oracle und andere relationale (= tabellenbasierte) Datenbank-Systeme galten als gesetzt.

Doch seit ein, zwei Jahren bringt nicht nur die NoSQL-Bewegung (No = Not only) neuen Schwung in den Markt (s. Why NoSQL Matters) und den ein oder anderen Durchbruch, der auch den E-Commerce noch einmal ein gutes Stück voranbringen wird. 

Flashspeicher lösen Festplatten ab

Die Datenbank-Revolution macht auch vor den Dickschiffen nicht halt: Nach der Übernahme von Sybase balgen sich SAP und Oracle um die Vorherrschaft auf mobilen Geräten (Stichwort: In-Memory-Database).

Da die neuen Geräte – angefangen von iPhone, iPad & Co. bis hin zu den Netbooks – zunehmend ohne herkömmliche Festplattentechnologie auskommen, entfallen die mechanischen Beschränkungen bei den Datenbankzugriffen: "Das macht den Zugriff 10 000-mal schneller als bisher."

Die Dynamiken des Realtime-Web

Zugleich kämpfen am andere Ende des Spektrums Web 2.0 Startups – von Facebook bis Twitter – mit den Herausforderungen des Realtime-Web (oder besser: Sametime-Web).

Um (Hundert-)Tausende von Nutzer bei Updates gleichzeitg bedienen zu können, nutzen Startups wie Foursquare MongoDB (s. Video). Andere setzen auf CouchDB, Cassandra oder die GraphDB von Sones.

Wer Ordnung hält, ist nur zu faul …

Der dritte Grund, warum heute auch einfacher strukturierte und damit chaotischere Datenbanksysteme (wieder) eine Chance haben, sind die enormen Fortschritte bei der Suchtechnologie. Aus Performance-Gründen werden die Suchindizes heute ohnehin schon größtenteils in eigene Datenbanken bzw. Datenbankstrukturen ausgelagert.

Experten gehen davon aus, dass auch im Datenbankbereich die Zeit der Alleskönner vorbei ist – und wir künftig unterschiedliche Datenbanksysteme für unterschiedliche Anwendungen sehen werden.

Führende E-Commerce-Häuser wie Amazon setzen schon längst auf eigenentwickelte Datenbanklösungen ("Produktwolken am Horizont?"). Spannend wird es, wenn die neuen Datenbanksysteme auch auf die Shopsysteme übergreifen und die Shopper auch sonst nicht mehr das Gefühl haben, sich von einer Datenbankabfrage zur nächsten zu hangeln und (Produkt-)Datensätze in Tabellenform angezeigt zu bekommen (s. Was kommt nach
den 'Shop'-Systemen?
).

Frühere Beiträge zum Thema:



Kategorien:Open Source, Optaros

  1. Hallo Jochen,
    mein Techniker-Herz freut sich, dass bei dir MongoDB und Co. drankommen.
    Meine 2 Cents zu diesem Kontext: ich glaube nicht, dass NoSQL „Datenbanken“ (es sind ja häufig Key-Value Stores) die relationalen Datenbanken ersetzen werden. Sie werden sie jedoch sicherlich ergänzen, und das ist eine gute Sache[tm].
    Ich kann mir vorstellen, dass NoSQL Systeme für zB Produktaggregatoren, die mit Abermillionen von Produkten und Produktdaten umgehen und Vergleiche anstellen müssen, eine sinnvolle Sache sind.
    Ansonsten ist es bei Datenbankabfragen wie mit gutem und schlechtem Programmcode: man muss manchmal schon ordentlich Hirnschmalz (und damit Zeit/Geld) reinstecken, um sehr performante Abfragen hinzubekommen und seine Datenbankarchitektur besonders gut planen (ob es strategisch so toll war, dass Magento auf ein Entity-Attribution-Value-Meta-Modell gesetzt hat, sei mal dahin gestellt …).
    Wenn man das nicht besonders gut mache, kann viel Murks raus kommen. Ansonsten sind viele tausend Read-/Write-Queries pro Sekunde auf normaler Commodity-Hardware durchaus möglich, man muss halt wissen wie. Und zwar sowohl auf Herstellerseite als auch auf Dienstleisterseite.
    Letzten Endes kommt es auch auf die Gesamtplanung der Architektur an (Beispiele hier: Solr/Lucene als Suchindexer, memcached als Caching Cluster).
    Hierbei gilt einmal mehr: Open Source is free as in free speech, not free beer. Auch mit OS Software muss man Geld investieren, um was vernünftiges herauszubekommen.
    Grüße zum Wochenende, Björn.

  2. Danke Dir für die ergänzenden Einschätzungen.
    Im den transaktionsnahen Bereichen (Bestellungen, etc.) kann ich mir auch schlecht vorstellen, dass relationale DBs auf absehbare Zeit verschwinden werden.
    Ich bin aber gespannt, was sich in den anderen Bereichen (Multimedia, Social Graph, etc.) tut, die ja im Social Web Kontext zunehmend auch im E-Commerce an Bedeutung gewinnen: Ob sich da ähnlich wie bei der Suche Alternativen durchsetzen – oder ob die relationale DB die Allzweckwaffe bleibt.
    Beim Thema Performance gebe ich Dir recht, da sollte gerade im E-Commerce die Datenbank nicht das Nadelöhr sein. Aber hier sehe ich eher die Evolutions-Sprünge in den Speichertechnologien als Treiber. Wer weiß, was da künftig (in 5+ Jahren) rein aufgrund neuer Speichertechnologien möglich wird.
    Ich verfolge die Entwicklungen im DB-Bereich jedenfalls fasziniert – und bin immer dankbar für Hinweise und Einschätzungen.

  3. Schuster, bleib bei denen Leisten! Ich hoffe, zukünftig hier nicht noch mehr halbherzige Technologieberichte lesen zu müssen, sondern dass der Fokus weiter auf den nicht-technischen eCommerce Themen bleibt…

  4. Aus Techniksicht ist die Pauschalkritik berechtigt, weil wir Technikthemen hier nicht so behandeln können (und auch nicht so behandeln wollen), wie wir sie in einem reinen Techblog behandeln würden.
    Deshalb sträuben sich dem Techie beim Lesen solch „halbherziger“ Beiträge die Haare. Das ist mir bewusst. Und ich war heilfroh, dass Björn ob dieses aus Techie-Sicht unsäglichen Beitrags Gnade hat walten lassen und sich trotzdem an der Debatte beteiligt hat.
    Aber es geht hier ja nicht um die beliebten Techie-Insider-Debatten, sondern darum, auch bei den Anwendern ein Bewusstsein für technologische Entwicklungen/Perspektiven zu schärfen.
    Ich halte es für eine der größten Unsitten der IT-Branche, dass man Anwender aus Technikthemen bewusst ausschließt und gar nicht den Versuch unternimmt, sie ihnen nahezubringen.
    Als solch ein Versuch sind solche Beiträge zu werten. Da ich mich als Informatiker intensiv mit Datenbanken befasst habe, stelle ich mich für derlei Beiträge gerne mal blöd – und vereinfache und banalisiere, bis es schmerzt. Damit verspiele ich zwar jegliche Glaubwürdigkeit bei den Techies. Aber das nehm ich in dem Fall gerne in Kauf.
    Ansonsten würde ich mir wünschen, dass sich auch der ein oder andere Techkundige an der Debatte beteiligt: Was hat es mit den Entwicklungen im Datenbankbereich auf sich und welche Auswirkungen/Perspektiven sind zu erwarten?

  5. Beitrag klasse, weil versucht Brücken zu schlagen. Horizonte öffnen, den Austausch suchen beginnt damit *neue Themen zu platzieren.
    Die Zeit für die oftmals in Lager denkenden WHU’ler () und in ihren Türmen lebenden TH’ler ist doch *längst gekommen, sich aufrichtig und interessiert miteinander über ihre Stammthemen auszutauschen. Und dies nicht nur aus Völkerverständigungsgründen, sondern weil es Produkte langfristig besser macht.
    Damit das *auch ausserhalb der Unternehmen in Gang kommt, brauchts *einfach „halbherzige“ Beiträge, oder positiv formuliert Übersetzungshilfen. Danke.

  6. Danke. Die Formulierungen werde ich mir merken :-)

  7. Hallo Jochen,
    ich greife den Ball auf und moechte konstruktiv dazu beitragen, etwas Halbherzigkeit aus deinem Bericht zu vertreiben:
    Der Absatz „Flashspeicher lösen Festplatten ab“ kann beim technikunkundigen Leser den Eindruck erwecken, dass durch den Einsatz von Flash Technologie auf den Clients die serverseitige DB-Performanz gesteigert werden kann.
    Ich denke der Einsatz von NoSQL Datenbanken wird sich nur dort positiv bemerkbar machen, wo riesige Datenmengen performant geschrieben und mit klar definierten Abfragen wieder gelesen werden muessen. Dieses Datenvolumen wird nur bei den allergroessten eCommerce Shops bei den Produktdaten erreicht, und selbst da bieten relationale DBs zzgl. moderner DB-Caching-Infrastruktur noch viel Spielraum. Ein Shopsystem liest die Produktdaten naemlich fast nur, geschrieben werden (wie von dir auch bereits angesprochen) Warenkoerbe, Kundendaten und Bestellungen. Anders sieht es bei UGC aus: Kommentare, Tags, Bewertungen, Likes etc. koennen gerne mal ein Vielfaches an Datenvolumen annehmen, und hier kann NoSQL evtl. trumpfen.
    Relationale Tabellenstrukturen haben jedoch den grossen Vorteil, dass sie mit sehr flexiblen Abfragen zu sehr vielseitigen Ergebnissen kombiniert werden koennen. Bei dokumentenbasierten Datenbanken ist dies schwer moeglich bzw. es sollte bereits bei der Strukturierung der zu speichernden Datenstrukturen beruecksichtigt werden, mit welchen Queries darauf zugegriffen werden soll. Dies kann bedeuten, dass je nach Anwendungsfall eine weitere, redundante Repraesentation der Daten persistiert werden muss.
    Und dass man die Tabellenform der Daten bereits an der Produktpraesentation erahnen kann, ist schlicht nicht richtig: die Praesentation kann und sollte sowohl bei Tabellen- als auch bei Dokumenten-DBs komplett unabhaengig von der Datenhaltung sein.
    Letztendlich ist es wie ueberall eine Frage der Tradeoffs: was bin ich bereit aufzugeben, um auf die naechste Performancestufe zu kommen?

  8. Danke für die konstruktiven Erläuterungen/Vertiefungen. Sowas freut mich :-)
    Und ich stimme überall zu, bis auf die Tabellen. Das sieht in der Realität leider anders aus – und woran könnte das wohl sonst liegen als an den Datenbankstukturen ;-)
    Wichtig ist mir zu unterstreichen, dass ich so einen Beitrag natürlich nicht vor dem Hintergrund heutiger Shopsysteme schreibe (die sind so wie sie sind, und sie sind größtenteils gut so), sondern um zu überlegen, wie Shoppingsysteme künftig aussehen könnten.
    Ich könnte mir vorstellen, dass die Fortschritte bei den Speicher- und Datenbanktechnologien hier dem E-Commerce einiges an neuen Perspektiven eröffnen … oder andersherum: Ich kann mir einfach nicht vorstellen, dass die heutigen Systeme schon der Weisheit letzter Schluss sind.

  9. Um’s mal wieder auf eine Nicht-Techniker Ebene mit orakelndem Einschlag zu heben: ich kann mir vorstellen, dass die Segnungen des Realtime Web (shameless plug: http://bit.ly/c7Bt0Q ) und die „Big Data“ Diskussion dazu führen, dass man viel mehr mit den im Shop gewonnenen Daten anfangen kann als es bisher der Fall war.
    Und zwar nicht nur bei den riesengroßen Shops, sondern auch den Shops der „mittleren“ Größe.
    Da die großen Shops oftmals in einer Innovationsfalle stecken (zu starr, zu groß, zu wenig wendig, …), können die Schnellboote den Innovationsverlust kompensieren und Trends setzen.

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden /  Ändern )

Google Foto

Du kommentierst mit Deinem Google-Konto. Abmelden /  Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden /  Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden /  Ändern )

Verbinde mit %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d Bloggern gefällt das: