Kategorien
NoSQL ist das neue AJAX, oder: Warum brauche ich NoSQL ?
Herzlich Willkommen zu meinen Beiträgen, die hauptsächlich von NoSQL und dem Drumherum handeln werden.
Meine Sicht auf NoSQL ist die eines Datenbankentwicklers der nicht in einer Agentur, sondern in der Firma sitzt, die die Daten produziert und konsumiert. Hierbei handelt es sich um Shopsysteme mit nicht-trivialen Produkten, deren Eigenschaften auch noch je nach Abhängigkeit zu anderen Faktoren veränderbar sind. Kurzum: Wir verkaufen Autoteile.
Warum NoSQL?
NoSQL ist zu einem Oberbegriff von Datenbanksystemen geworden, die weit mehr Eigenschaften haben als nur der Verzicht auf SQL als Abfragesprache. Ich denke, die Eckdaten der am meisten verbreiteten Systeme sind klar:
- Hohe horizontale Skalierbarkeit (horizontal=viele Rechner, vertikal=ein großes, schnelles System)
- Eingeschränkte Verknüpfungen von Datensätzen untereinander (JOIN)
- Keine Tabellen, in die die Daten gezwängt werden
- Kein SQL als Abfragesprache
Warum aber NoSQL?
Warum soll man sich neuer Technik bedienen, wenn die Alte (Technik!) doch bislang immer funktioniert hat ?
Der Grund „weil’s Spaß macht“ ist aus Entwicklersicht einsichtig, aus betriebswirtschaftlicher Sicht eher weniger.
Wer sich die gängigen NoSQL-Beispiele ansieht, kommt recht schnell auf die Idee, daß anscheinend außer Blogs nicht viel mehr mit NoSQL gemacht werden kann. Macht es Sinn, eine relational funktionierende Produktdatenbank mit den NoSQL-Features umzusetzen?
Aus Jux und dollerei wird kaum jemand ein bestehendes Projekt auf die neue Technologie umändern. Ist auch nicht immer nötig, aber wie wäre es damit, Teile zu ersetzen?
Eine Produktdatenbank hat immer zwei Zugriffszenarien: Die Daten werden erstellt, oder gelesen. Anders als bei Twitter und Co sind die Zugriffszahlen beim Lesen immens höher als beim Schreiben. Und was macht SQL? Um dem Kunden Die passenden Produkte anzuzeugen, geht dem meist ein Wust an JOINS voraus. Tabellen mit Fahrzeuginformationen, Produktstamm, Eigenschaften in Abhängigkeit vom Fahrzeugen, Preistabellen, Sperrungen und Abhängigkeiten von anderen Produkten… all das wird einmal erstellt, aber tausendfach abgerufen. Zur Optimierung der Zugriffszeiten beim Lesen müssen Cachingmechanismen herhalten.
Speicher ist billig, Zeit ist teuer.. und da kommen die Schemalosen Datenbanken ins Spiel. So kann, nachdem ein Produkt angelegt und mit seinen Eigenschaften versehen ist, dieses Produkt mit all seinen Eigenschaften und Abhängigkeiten einfach als Dokument in eine NoSQL Datenbank gespeichert werden. Dass nun jedes Produkt auch alle passenden Fahrzeuge beinhaltet (und damit die Fahrzeuge hundertfach in den Produkten vorkommen) ist aus Normierungssicht horrend redundant. Aber aus zeitlicher Sicht ist eine 10000-fache JOIN-Orgie gegenüber einer einmaligen Zusammenstellung aller Daten zu einem Produktdokument ebenso redundant.
Es ist also ein kleiner erster Schritt, die vorhandenen relationalen Daten in einem Exportvorgang zusammenzufassen und als Dokumente in eine Schmalose Datenbank zu packen.
Die Wahl fiel bei uns auf die CouchDB, da sie den Gedanken der Geschwindigkeitsoptimierung beim lesen vor dem des Schreibens durch vordefinierte Abfragen konsequent umsetzt.
Ich werde Ihnen in regelmäßigen Abständen die Ideen und Hürden hinter dieser Umsetzung nahe bringen.
Vielleicht noch erwähnenswert – weil das meiner Meinung nach in vielen dieser „NoSQL ist toll“ Artikeln fehlt:
NoSQL ist kein Allheilmittel. Es hat seine Anwendungsgebiete. Seine Stärke ist das – wie im Artikel beschriebene – vielfache Lesen bei wenigen Schreibzugriffen.
Es hat aber – wie von vielen NoSQL-Fanatikern gerne verschwiegen – auch seine schwächen. SQL bzw. relationale Datenbanken werden nicht plötzlich durch „NoSQL“ ersetzt. Manchmal muss man durch seine Daten einfach mit JOINs durch – wenn man die Daten einfach nicht vorgekaut irgendwo ablegen kann.
Die durchschnittliche Webseite (Blogs, Artikel-Datenbanken, …) ist mit CouchDB, MongoDB oder ähnlichen NoSQLs sicher deutlich besser bedient, aber ehrlichgesagt fühle ich mich deutlich wohler wenn beispielsweise die bestellten Warenkörbe eines Shop-Systems weiter in einer relationalen Datenbank liegen und ich rumJOINen kann wie ich will 🙂 – Hier kommt der „write once, read many“ Vorteil von NoSQL einfach nicht zum Zug.
Hallo Dominik,
genau der Punkt, dass NoSQL kein Ersatz sondern (in manchen Fällen) eine Ergänzung ist, werde ich in meiner Artikelserie versuchen darzustellen.
Ansonsten bestätigst Du mich mit deinem Satz „SQL bzw. relationale Datenbanken werden nicht plötzlich durch “NoSQL” ersetzt“.
Dein Argument „Manchmal muss man mit JOINS durch“, werde ich allerdings in meinen Beiträgen etwas aufweichen.
Unbedingt das Kontrastprogramm lesen:
http://blog.koehntopp.de/archives/2969-Ein-paar-Gedanken-zum-Thema-NoSQL.html
http://gigaom.com/cloud/nosql-is-for-the-birds/
Guten Tag,
eine Frage hätt ich allgemein zu NoSQL:
Wie änderst du denn jetzt, um das Beispiel von oben aufzugreifen, eine Fahrzeugteilbeschreibung für alle „Dokumente“? Ohne durch jedes Dokument zu gehen und die Beschreibung zu ändern? In einer RDBMS gehste in die Teile Tabelle und änderst den einen Eintrag..
Gruß,
Andy
Habe ich das richtig verstanden, dass die Daten in einer relationalen Datenbank gepflegt werden, und dann in gewissen Intervallen in die live Datenbank mitz NoSQL exportiert werden?
Mein Problem mit NoSQL ist bisweilen, dass ich es schwer finde, bestimmte Daten zu aktualisieren.
Sofern ich das Verfahren korrekt verstanden habe, würden ja dann die Aktualisierungsprobleme in NoSQL nicht mehr bestehen => problem solved.
Gruß Sebastian
Mach NoSQL auch noch Sinn, wenn ich in der SQL Variante Tabellen mit 150 Feldern oder mehr habe?
@Andy:
CouchDB kennt kein JOIN… zumindest kein „echtes“.
D.h.: JA, du müsstest über alle Dokumente gehen, und die Daten Client-seitig ändern. Alternativ kannst Du ein Dokument „zubehörteil“ mit einer ID anlegen, und in jedem der Datensätze diese ID speichern (anstelle der Attribute des Zubehörteils). Dann müsstest Du diesen Pseudo-Join auf Clientseite (we love PHP) ausführen. Nur kannst du kein map/reduce mit den Attributen des Ersatzteils ausführen, das referenziert wurde.
@Sebastian
Ich will nicht zu viel vorweg nehmen, aber in unserem Fall liegen alle Stammdaten in einer MySQL-Datenbank, und werden durch den Kunden „freigegeben“. Bei dieser Freigabe werden die Daten in die NoSQL-Datenbanken überführt. Eine Änderung eines STammsatzes erfordert eine erneute „Freigabe“.
@Michael
Es klingt so, als wenn GERADE DANN NoSQL Sinn macht. Ich weiss nicht, warum 150 Felder, aber wenn es sowas wie „Option1 | Option 2 | Option 3 …“ ist.. und vielleicht nicht alle Felder immer gefüllt sind.. definitiv .
Horizontale und vertikale Skalierbarkeit ist in dem Beitrag verwechselt worden.
Eine gute Eselsbrücke ist:
Horizontal => Waagerecht => Rechner daneben stellen
Vertikal => Senkrecht => Komponenten draufpacken
Hier ein wikipedia ( http://de.wikipedia.org/wiki/Skalierbarkeit ) Zitat dazu:
Oft wird zwischen horizontaler und vertikaler Skalierbarkeit von IT-Systemen unterschieden. Bei einer horizontalen Skalierung werden Funktionen auf zusätzliche Server verteilt. Das Blade-Konzept unterstützt einen solchen Ansatz. Bei einer vertikalen Skalierung wird das System durch eine leistungsfähigere Lösung ersetzt.
Und wer hohe Skalierbarkeit sucht, jedoch nicht auf ACID verzichten kann, was heutzutage jede NoSQL-Datenbank vormacht, der sucht mal nach dem HandlerSocket-Plugin für MySQL und ist dann erstaunt wie schnell InnoDB ist, wenn man den SQL-Overhead entfernen kann.
@Lufti
Danke,
das war zu schnell geschrieben.. ich gelobe, bei den nächsten Artikeln besser aufzupassen.
Ich sehe immer noch keinen wirklich sinnvollen Anwendungsfall für NoSQL. Sicherlich ist es cool & trendy und fühlt sich so leichtgewichtig an (auch wegen JSON), aber ich habe noch keinen sinnvollen Vorteil gegenüber relationalen Strukturen gesehen.
Mal ganz abgesehen von dem Nachteilen der Migrationen, Backup, Datensicherheit usw. löst es imo keine wirklichen Probleme der relationalen Welt. Sicherlich ist es nervig x Joins bei einer Artikel-Detailseite zu nutzen. Aber gerade diese Abfragen sind doch meist eh nicht kritisch, da diese direkt den Index abfragen. Kritisch sind doch in der relationen Welt Gruppieren, Sortierungen & Filter auf große Datenmengen, aber dieses Problem löse ich damit auch nicht. Alle Dokumente nach bestimmten Eigenschaften zu durchsuchen ist doch noch langsamer als Ranges in der Datenbank aufzubauen.
Für einen Blog sehe ich das vielleicht noch sinnvoller, da 1 Artikelseite = 1 Dokument, aber da ist doch die Datenbank auch in den seltensten Fällen das Performance-Problem sondern WordPress seine Code-Basis & der VHoster.
Hallo Ulf,
Couchdb durchläuft alle Daten nur einmal,alle weiteren Anfragen liefern nur die gespeicherten Indizes. Sauschnell 😉
Aber ich werde die positiven Eigenschaften von Couchdb schon noch rausstellen
Hallo,
die Bedeutung von der horizontalen und vertikalen Skalierung stimmt im Artikel nicht.
Sehe ich das richtig, dass in diesem Fall die NoSQL DB eigentlich nur ein Cache Layer ist?
NoSQL was yesterday, today is http://www.nuodb.com/ 😉