Kategorien
Gibt es ein Leben nach SQL?
Wenn in der Webentwicklung etwas so gemacht wird, weil es schon immer so gemacht wurde, ist das im Allgemeinen ein guter Moment aufzuhorchen. Ich frage mich, von welchem „schon immer“ da die Rede ist? Das „schon immer“ von vor 10 Jahren, als alle Schichten einer Anwendung noch ein trautes Beisammensein in einer PHP-SQL-HTML-Datei zelebrierten oder das von vor 20 Jahren, als ein smarter Typ am CERN auf die Idee kam, Dokumente mittels einfachem Markup zu strukturieren und miteinander zu verlinken (und Anwendungen monolithische Felsklötze auf unseren stationären Desktopcomputern waren)?
Seitdem ist zum Glück viel passiert und die Strategien zur Planung und Implementierung von Webanwendungen sind kontinuierlich vielfältiger geworden. Nur die Grundannahme, dass für die Implementierung der Persistenzschicht ein relationales Datenbankbetriebssystem zum Einsatz kommt, scheint als unverrückbarer Pfeiler alle Entwicklungen zu überdauern. – Auch bei mir. Das habe ich schließlich schon immer so gemacht.
If it ain’t broken, …?
Aber warum sollte ich denn überhaupt etwas anderes wollen? Relationale Datenbankbetriebssysteme sind stabil, ausgereift und in mannigfaltiger Ausprägung erhältlich.
In Chaosradio Express, Folge 125, wird in meinen Augen ziemlich gut erklärt, was das Problem ist: relationale Datenbankbetriebssysteme lösen Probleme, die so in vielen (Web-) Anwendungen gar nicht vorhanden sind – und das Potential komplexere Probleme zu lösen bringt zumeist eine komplexere Bedienung mit sich. Konkret bedeutet das, dass es in vielen Fällen nicht nötig ist, Daten bis in die Letzte Normalform zu zerlegen, weil alles, was uns interessiert ein User-Objekt mit ein paar Eigenschaften und seine Beziehung zu anderen Usern ist.
Hinzu kommt, dass relationale Datenstukturen in einer objekt-orientierten Welt oftmals ein Fremdkörper sind. Zugegeben, für die Überbrückung dieser Unterschiede gibt es dank vielfältiger Objekt-Relationaler-Mapping-Frameworks mittlerweile überzeugende Lösungen. Am Ende des Tages bleiben sie jedoch der Versuch, Dinge anzugleichen, die eigentlich nicht gleich sind. Und das kostet in der Regel. Und zwar Performance.
Und nicht zuletzt sind Web-Anwendungen oftmals dynamischen Entwicklungen unterworfen und es ist anfangs nicht immer möglich, die finale Datenstruktur bis ins letzte zu definieren. Datenschemata machen daher nur bedingt Sinn, da sie etwas formalisieren, das an dieser Stelle so gar nicht gebraucht wird. Wird beispielsweise zu irgendeinem Zeitpunkt im Lebenszyklus einer Anwendung beschlossen, dass Nutzer jetzt auch eine Lieblingsfarbe haben können, ist es nicht wünschenswert in die Struktur einer produktiv genutzten Datenbank einzugreifen, in der entsprechenden Tabelle ein Feld hinzuzufügen, um dann eine Vielzahl von leeren Feldern zu haben.
Öfter mal was Neues
Zeit also mal einen Blick auf alternative Ansätze zu werfen, denn es kommt durchaus Bewegung in die Sache. Mehr und mehr Alternativen betreten die Arena. Sei es das von Facebook entwickelte Cassandra, MongoDB oder das altbekannte MemcacheDB. Allen gemein ist der Verzicht auf das Paradigma des Strukturieren von Daten mittels Relationen. Im Allgemeinen handelt es sich um einfache Key => Value Speicher für strukturierte und semi-strukturierte Daten. Das aber außerordentlich leistungsfähig. Laut einer Präsentation von Avinash Lakshman (Facebook) schreibt Cassandra beispielsweise mehr als 2500 Mal schneller als MySQL!
Welche Anwendung die beste, leistungsfähigste und sexieste ist, ist wie immer ein heiss diskutiertes Thema. Felix Geisendörfer von Debuggable hat sich mit Insert Benchmarks in CouchDB beschäftigt, die anschliessend mit MongoDB verglichen wurden. Ein wirklich lesenswerter Artikel zum Thema ist Alternatives to SQL Databases von Ian Ward.
CouchDB
Der Shooting-Star am nicht-relationalen Datenbankhimmel hört auf den prägnanten Namen CouchDb und wird von der Apache Software Foundation betreut. Die Software wird beschrieben als „verteilte, fehlertolerante und schemafreie, dokumentenorientierte Datenbank“. Statt SQL erfolgt die Kommunikation mit CouchDB über eine RESTful JSON API. Das bedeutet, dass man beispielsweise für eine einfache Abfrage eine URI via HTTP aufruft und als Antwort kein Rowset, sondern ein JSON formatiertes Objekt erhält. Ähnlich funktioniert das Anlegen und Aktualisieren von Datensätzen. Hier wird ein JSON-Objekt an eine URL geschickt. Die Arbeit mit CouchDB hat daher weniger etwas von einer traditionellen Datenbank, sondern fühlt sich vielmehr an, als würde man mit einem WebService kommunizieren.
Da ein Datenspeicher jedoch mehr beherrschen sollte, als einfache CRUD-Operationen, ist es zudem möglich Views zu definieren. Dabei handelt es sich um JavaScript-Funktionen. Was sich im ersten Moment ein wenig merkwürdig anhört, entpuppt sich bei genauerer Betrachtung als extrem mächtiges Werkzeug. Eine solche Funktion definiert welche Key => Value Paare aus der Datenbank geholt werden sollen und wie sie sortiert sein sollen. Der SQL-Befehl
SELECT LastName, FirstName, FirstName, Address FROM table WHERE type = 'customer'entspricht dabei ungefähr folgendem Beispiel aus dem CouchDB-Wiki
function(doc) {
if (doc.Type == "customer") {
emit(doc.LastName, {FirstName: doc.FirstName, Address: doc.Address});
}
}Die Funktion definiert für jede Zeile eine einen Key und einen Value und sortiert das Ergebnis an Hand des Keys. Der Trick: der Key muss nicht, wie hier, aus einem einfachen Strung bestehen. „CouchDB allows arbitrary JSON structures to be used as keys. You can use complex keys for fine-grained control over sorting and grouping.“
PHP-Integration
Da die Kommunikation über HTTP und REST erfolgt, ist zunächst einmal jede Form von HTTP-Request geeignet, um mit CouchDB zu arbeiten. Im einfachsten Fall kann das sogar ein Aufruf mittels file_get_contents() sein. Üblicherweise empfiehlt es sich aber natürlich ein wenig grundsätzlicher an die Sache heranzugehen und sich einen REST-Client selber zu schreiben oder eine geeignete Bibliothek zu nutzen.
Glücklicherweise gibt es mittlerweile Bestrebungen, CouchDB weitergehend in PHP-Anwendungen zu integrieren. Unter Anderem liegt im Zend Community Wiki seit einiger Zeit ein vielversprechendes Proposal namens Zend_Couch von Matthew Weier O’Phinney vor, Shahar Evron von PrematureOptimization hat mit Sopha eine ziemlich schlanke Abstraktion veröffentlicht und neben einigen weiteren Bibliotheken gibt es PHPillow. Im Gegensatz zu einigen anderen Ansätzen, macht diese Bibliothek bereits einen relativ ausgereiften Eindruck (sofern man bei Alpha-Releases von Reife sprechen kann). Aus diesem Grund soll im nächsten Teil die grundsätzliche Arbeitsweise mit CouchDB an Hand von PHPillow demonstriert werden.
So heute ein wenig später, dafür aber was spannendes 🙂 Danke an Alexander für seinen Artikel.
Darf ich ganz unverbindlich auf XML-Datenbanken hinweisen? Die gehören definitiv allgemein und eXist speziell mit in deine Aufzählung der SQL-Alternativen. http://www.xmldb.de/ 🙂
Nochmal allgemein zu SQL. Ich bin wirklich am Verzweifeln. Bei SQL-Datenbanken hat sich seit Jahrzehnten nichts wirklich neues getan. Wie du sehr schön schreibst lösen sie Probleme die man ohne sie meist gar nicht hätte. Mein Verdacht ist, dass sie für die Excel-Verwöhnten „Entwicklungs-Kinder“ einfach der Weg des geringsten Widerstandes sind. Im Bereich komplexer professioneller Anwendungen (Dokumentenmanagement, CRM) wird häufig XML verwendet, da damit Datenaustausch und vor allem die Umwandlung zwischen Schnittstellen stark vereinfacht werden.
Whao, Danke dafür! Mir geht es ähnlich. SQL-Server (egal welcher Firma) sind eigentlich ohne Frage die Persistenzschicht. Man weiß zwar, dass es da etwas neues, anderes gibt. Aber mehr als 1-2 Artikel gelesen habe ich dann auch nicht.
Übrigens ist der Link „Präsentation von Avinash Lakshman“ defekt, da sind einige Zeichen am Ende zuviel…
Super Artikel, danke! Der macht definitiv Appetit, sich mal mit dem Thema auseinanderzusetzen 😉
Vielen Dank für die netten Rückmeldungen bis hierher.
@Bastian Zu XML-DBs habe ich irgendwie nie so recht eine Meinung entwickeln können. Wir haben in der Uni mal damit herumgespielt und es fühlte sich ein wenig – well – zäh an. Liegt aber vielleicht auch nur an meiner „Begeisterung“ für XSL, denn du hast natürlich recht, dass es eine legitime SQL-Alternative ist!
@PHP Gangsta Den Link habe ich gefixt. Danke für den Hinweis. Das PDF ist glücklicherweise noch verfügbar.
Mit CouchDB habe ich mich noch nie auseinandergesetzt … Ich hab damals SQL mit Oracle 9g gelernt und heute verwende ich MySQL – vor allem aus Gewohnheit. Ich kann mich darauf verlassen, dass der Datenspeicher funktioniert 😉 Aber MySQL krankt auch an vielen stellen, gerade die Optimierung kann mitunter sehr lästig werden und noch immer ist der Standard „latin1“ statt „utf8“ – muss man nicht verstehen, oder?
Hallo,
das Thema interessiert auch mich brennend, ich komme ursprünglich aus der Lotus Notes (atnotes.de) Welt, dort ist das Ablegen von Daten in Form von Dokumenten schon immer üblich gewesen.
@Alexander: Das tolle an XML-Datenbanken wie eXist ist, dass man nicht nur mit XSL arbeiten kann, sondern beispielsweise auch direkt auf den Daten mit XQuery. Damit habe ich beispielsweise eine einfach Bildergalerie mit Upload/Verschlagwortung/Darstellung/Suche erstellt.
Und wieder wurde mein Tellerrand durch Dich ein wenig vergrößert ;o)
merci!
@Arne: Damien Katz (der Erfinder von CouchDB) hat früher bei Lotus gearbeitet, was diese Parallele erklären dürfte. 🙂
Ein sehr guter Artikel, freue mich schon auf den nächsten Teil :o)
danke für die erste Einleitung. das ganze thema „nicht-sql-datenbanken“ ist ja schon sehr spannend. habe mich letztens mit persevere oberflächlich beschäftigt und war erstmal total begeistert. ein großer vorteil bei der json-basierten ausgabe ist nämlich beispielsweise auch für javascript RIAs gegeben. die Rest-API braucht man sich nicht mehr selber zu schreiben, sondern die wird ganz einfach über die „neue“ datenbank generiert.
nur so als Anregung: bei Persevere (sowas ähnliches wie CouchDB) kann man bspw. auch die tabelle eines MySql-Servers als REST-Table angeben – die daten werden dann automatisch über persevere ausgelesen und bei Änderungen in die sql-db zurückgeschrieben. so können bspw. auch ältere datenbanken erstmal „übernommen“ werden ohne die alten sql-dbs gleich in die tonne zu kippen.
bin schon gespannt auf das „Leben nach dem SQL“
Bin etwas irritiert. Du fängst an, dass du Objekte verwalten willst, gehst aber dann nicht weiter zu objekt-relationen Datenbanken, sondern sogar zurück zu Schlüssel-Wert-Speicher?
interessanter artikel, hatte mich bis jetzt nur oberflächlich damit befasst und festgestellt, dass es wohl sehr komfortabel sein müsste.
ich frage mich nur ob wann es sinn macht z.b. couchDB einzusetzen?
für ein cms zb. wohl kaum oder?
(mal ganz abgesehen von den anforderungen die couchDB & Co. an den Server stellen)
Hier sind ja echt eine ganze Menge toller Kommentare aufgelaufen. Ich bin begeistert!
@Lukas Persevere ab ich mir angeschaut, aber irgendwie noch nicht ganz verstanden. Das klingt irgendwie ganz extrem nach CouchDB. Was ist das genau?
@KingCrunch Das sind nicht Schlüssel-Wert-Speicher im üblichen Sinne. CouchDB speichert zwar Schlüssel-Wert-Paare, das sind aber keine String. Schlüssel und Werte in CouchDB können beliebig komplexe JSON-encodete Objekte sein – und da geht dann plötzlich einiges!
@martin Es gibt tatsächlich schon ein CMS, das CouchDB nutzt. Grundsätzlich sind diese neuen Datenbanken als vollwertige Persistenzschicht konzipiert und können bzw. sollen deswegen auch als solche eingesetzt werden. Ein echt toller Aspekt ist Replikation, die bei CouchDB mitgeliefert wird. Da könnte ich eigentlich auch noch mal drauf eingehen. Krasse Referenzprojekte gibt es ob des Alters der Software natürlich noch nicht, aber da ist Bewegung drin!
@kingcrunch da hab ich mich wohl ein wenig zu undeutlich ausgedrückt – der freundliche Herr ober mir hats aber eh schon richtig gestellt.
@Alexander Thomas: was Persevere ist, da bin ich grade selber noch am Erkunden. Erstmal ist es eine Persistenzschicht, was u.a. dadurch ersichtlich ist, dass man eben auch im Hintergrund eine klassische SQL- oder andere DB laufen lassen kann. Entwickelt wurde Persevere – soweit ich das jetzt verstanden habe – als Backend für Javascript Frameworks, insbesondere Dojo (kommt auch aus den Sitepen Labs). Was dann halt noch dazukommt, ist, dass man per Javascript eigene „views“ (in etwa vergleichbar mit mysql-views) spezifizieren, die dann direkt abgefragt werden. Auch Dinge wie Benutzerauthentifizierung und Zugriffskontrolle sind bei Persevere schon mit inkludiert. Vielleicht gibts ja bald nen Post hier, der CouchDB/Persevere mal näher vorstellt bzw. einige der Einsatzmöglichkeiten beschreibt.
Zu CouchDB gibt es bei Chaosradio Express einen interessanten Podcast, über den ich auch erst auf das Thema aufmerksam geworden bin (hier der Link: http://chaosradio.ccc.de/cre125.html)
Ob es ein Leben nach dem SQL wirklich gibt? Ich bezweifle es. die „Klassiker“ MySQL/Oracle sind zwar für viele heutige Anwendungfälle nicht mehr optimal (siehe Facebook), allerdings gilt selbiges auch für die „Neuen“. Ich glaube also, dass relationale Datenbanken durchaus ihre Berechtigung haben und aufgrund der großen Verbreitung halt auch noch lange in Szenarien eingesetzt werden, die eigentlich für andere Datenbanksysteme besser geeignet wären.
Was meint ihr dazu?
@alexander:
Ok, ich war nur verwundert, da im Zusammenhang immer wieder von riesigen Clustern gesprochen wird…
Habe mir soeben eine Sendung des Chaos Radio Express‘ anghört die sich ganze 2h43m mit couchDB und der Idee dahinter auseinander setzt. [1]
Kann sogar sein, dass ich den Link von hier irgendwo hab 🙂
Aufjedenfall ein sehr interessantes Thema.
Referenzprojekte im PHP-Umfeld wären natürlich auch sehr Interessant.
Heute war übrigens in Berlin das NOSQLBerlin. [2]
Eine andere, soweit ich das verstanden habe, couchDB-ähnliche Datenbank ist übrigens Riak[3]
_____________
[2]http://chaosradio.ccc.de/cre125.html
[3]http://nosqlberlin.de/
[4]http://riak.basho.com/
Hach, so ne Editier Funktion wär schon praktisch Nils…
CouchDB ist eine wirklich interessante Sache, insbesondere ist halt einfach praktisch zu nutzen. Wir setzen bei uns in der Firma hauptsächlich das Zend Framework ein. Die gelieferte HTTP Client Klasse eignet sich wunderbar zum Zugriff auf eine CouchDB.
Wobei die Frage natürlich bleibt, wie schnell das ganze ist? Bisher haben wir keine negativen Erfahrungen gemacht. Allerdings sind die meisten Anwendungen auch mehr kleinerer Natur. Wer sich auch noch für das Thema CouchDB & Zend Framework interessiert: Ein nettes Tutorial für vollkommene Anfänger findet sich hier hier: http://www.limespace.de/2009/11/16/experimente-mit-zend-framework-und-couchdb-1/
Sogar in deutsch 😉