CouchDB mit PHP

Von Oliver Kurowski

Das Thema NoSQL ist durch Vertreter wie CouchDB auch für den produktiven Masseneinsatz attraktiv geworden. Beim Einstieg in NoSQL müssen Datenbankentwickler herkömmlicher relationaler Datenbanken viele ihrer Gewohnheiten und Denkweisen ändern. CouchDB belohnt sie dafür mit einer Fülle an neuen und ungeahnten Möglichkeiten, die weit über die reine Datenhaltung hinausgehen.

Dieses Buch führt schrittweise in das Thema NoSQL ein und erläutert Vor- und Nachteile dieses Schemas. In unterhaltsamer Weise lernen Sie in ausführlichen Kapiteln die Funktionen der CouchDB schrittweise kennen. Nicht nur die reine Syntax, auch die Denkweise hinter den Funktionen sowie mögliche Einsatzszenarien werden dargestellt und anhand vieler Beispiele erläutert.

Zusätzlich zu den allgemeingültigen Informationen wird Kapitel für Kapitel ein kleines PHP-Framework für die CouchDB entwickelt und in einem Praxisteil angewandt. Da alle Beispiele kommentiert sind, können sie problemlos auch für andere Programmiersprachen angepasst werden.

• Sprache: Deutsch
• Herausgeber: entwickler.press
• Erscheinungsdatum: 5. Juni 2012
• ISBN: 9783868026078

Buchvorschau

dich.

1 Allgemeines

1.1 Aufgaben einer Datenbank

Eine Datenbank hat zumeist zwei grundlegende Aufgaben:

1. Daten erstellen/verändern/löschen

2. Daten abrufen/analysieren/aggregieren

Diese zwei Bereiche nennt man auch OLTP (Online Transaction Processing) und OLAP (Online Analytical Processing). Während beim OLTP die Datenintegrität und Transaktionsfähigkeit im Vordergrund steht, ist beim OLAP die Geschwindigkeit der wichtige Faktor. Das kann jeder nachvollziehen, der eine schnelle Anzeige aller Nachrichten oder Blogeinträge auf seiner Webseite wünscht, den es aber nicht stört, dass nach Verfassen eines Artikels und Klick auf den „Senden"-Button eine kurze Zeit verstreicht. Wir halten also fest, dass der Faktor Zeit beim Lesen eine höhere Rolle spielen kann als beim Schreiben. Ideal für stark frequentierte Nur-Lese-Zugriffe wäre also eine Technik, die ein einfaches Hochskalieren der Leistung einer Datenbank erlaubt. Was dabei auch nicht unberücksichtigt bleiben darf: Lesezugriffe über viele Tabellen mittels Joins sind nicht nur schwer auf mehrere Systeme zu verteilen, sondern auch innerhalb eines Systems teuer, was die Zeit betrifft. Die Datenintegrität, also die Korrektheit der Daten und Beziehungen untereinander, werden klassisch durch das ACID-Prinzip beschrieben.

1.1.1 ACID

Dieser Abschnitt ist weder für Chemiker noch Musikliebhaber. Hier geht es um die Eigenschaften eines Datenbankmanagementsystems zur Sicherung der Datenkonsistenz bei Transaktionen. Dabei stehen die Buchstaben für folgende Eigenschaften:

Atomicity (Atomität): Eine Transaktion auf einer Datenbank wird als kleinste nichtteilbare Aktion behandelt. Entweder alle Stufen dieser Transaktion werden erfolgreich durchlaufen oder keine.

Consistency (Konsistenz): Eine Transaktion hinterlässt nach Beendigung einen konsistenten Datenzustand. Gerade bei referenzieller Integrität, also abhängigen Tabellen, ist es wichtig, dass die Beziehungen untereinander korrekt bleiben. In diesem Punkt ähnelt sich die Konsistenzeigenschaft der Atomität: Entweder das Ergebnis ist konsistent, oder alles wird rückgängig gemacht.

Isolation: Eine Transaktion darf keine Seiteneffekte auf andere Transaktionen haben. So darf eine Änderung einer ID nicht sofort in eine parallel ausgeführte Transaktion mit einfließen.

Durability (Dauerhaftigkeit): Die Auswirkung einer erfolgreich ausgeführten Transaktion bleibt auch nach einem Systemfehler oder Neustart dauerhaft in der Datenbank erhalten.

Single-Server-Datenbanken erfüllen (solange sie einwandfrei funktionieren) das ACID-Konzept. Im Gegensatz zu ERP-Lösungen in Unternehmen, die eine begrenzte Anzahl von Benutzern bedienen müssen, herrschen bei stark frequentierten Webdiensten ganz andere Anforderungen, sodass bei gesteigertem Leistungsbedarf große Unterschiede bei der Erhöhung der Leistung zwischen geschlossenen Firmenanwendungen und (in der Anzahl der Benutzer) offenen Webdiensten bestehen: Vertikale und horizontale Skalierung.

1.1.2 Vertikale und horizontale Skalierung

Vertikale Skalierung ist das „Tuning" einer abgeschlossenen Datenbankeinheit durch Hinzufügen von Rechenleistung oder Speicher, klassisch für firmeninterne Datenbanksysteme, bei denen es eher auf die Konsistenz der Daten als auf die gleichzeitige Bedienung von Tausenden von Nutzern ankommt (Natürlich gibt es auch hier gemischte Formen).

Horizontale Skalierung ist das Hinzufügen von weiteren abgeschlossenen Datenbankeinheiten, die sich nach Außen hin als eine logische Einheit darstellen. Horizontale Skalierung ist das Rückgrat der meisten Webanwendungen, die mithilfe von Load Balancern oder Serverfarmen die Anfragen bewältigen.

Bei Skalierung auf mehrere verteilte Datenbanken tauchen erste Szenarien auf, die das ACID-Konzept aufzuweichen drohen. Was ist, wenn in einem Netz von verbundenen Datenbanken einzelne Systeme oder die Verbindungen zwischen den Datenbanken ausfallen? Es ist heutzutage nicht mehr unüblich, viele Server zur Speicherung von Daten in sozialen Netzwerken oder Suchmaschinen zu verbinden. Im Fehlerfall droht die Dateninkonsistenz des gesamten Systems und unterschiedlichen Datensätzen in Teilen des Datenbanksystems aufgrund von Netzwerkzerteilung (Network Partitioning). Doch wie kann man Datenbanksysteme verlässlich horizontal skalieren?

1.1.3 Das CAP-Theorem

Im Jahr 2000 hielt Prof. Eric Brewer¹ die Keynote auf der PODC2000², einer Konferenz über die Grundlagen der Datenverarbeitung in verteilten Systemen (Principles of Distributed Computing). Auf dieser Keynote stellte er dar, dass es bei der Skalierung von verteilten Datenbanksystemen auf drei grundlegende Eigenschaften ankommt:

Consistency: Die Konsistenz der Daten, bezogen auf Transaktionen. Entweder eine Datenmanipulation wird komplett ausgeführt oder gar nicht. Wenn ein Kunde eines Onlineshops den letzten verfügbaren Artikel bestellt und aus irgendwelchen Gründen der Lagerbestand nach der Bestellung nicht um 1 reduziert werden kann (wir gehen davon aus, dass es im Normalfall funktioniert), so sind die Daten inkonsistent, und bei der nächsten Bestellung dieses Artikels fängt die Suche im Lager nach dem unsichtbaren Buch an. Bezogen auf verteilte Datenbanken, die miteinander kommunizieren, heißt es aber auch, dass alle Systeme die gleichen Datensätze sehen. Wenn die Bestellungen eines Shops auf mehrere Datenbanken verteilt werden, so muss sichergestellt werden, dass die Veränderung des Lagerbestands durch ein System sofort auf alle anderen Datenbanken übertragen wird. Diese Eigenschaft ist für Onlineshops oder andere Dienste, die zum Austausch von Gütern (auch z. B. Aktien) dienen, ein wichtiger Punkt. Nachrichtenbasierte Dienste wie Soziale Netzwerke oder Newsserver sind in der Regel nicht so empfindlich, was die Echtzeit betrifft. Wenn eine Nachricht nicht sofort auf allen Servern angezeigt wird, läuft das System trotzdem ohne Probleme.

Availability: Die Verfügbarkeit eines Datenservices. Bedeutet, dass eine Datenbank auch antwortet, wenn eine Aufgabe an sie gestellt wurde. Wenn wir nach dem Bestellen eines Artikels aus dem Shop kein Feedback bekommen (z.B. durch eine leere Internetseite), ist unklar, ob die Bestellung ausgeführt wurde oder nicht. Beziehen wir es wieder auf eine Gruppe von Systemen in einem Netz, so kann auch gesagt werden, dass die Systeme weiter arbeiten müssen, wenn eines der Systeme keine Antwort gibt.

Partition Tolerance: Daten können in verteilten Datenbanken durch äußere Einflüsse partiell unterschiedliche Datenbestände aufweisen. Beispiel: Server A und B bieten die gleichen Datendienste an. Server A kann aufgrund eines Hardwaredefekts (Kabel, Netzwerk) nicht mit B kommunizieren, beide Server sind aber nach außen zu erreichen. Nun kann es passieren, dass auf A und B unterschiedliche Datensätze entstehen. In einem Netzwerk von Datenbanken muss gewährleistet sein, dass das ganze System auch dann funktioniert, wenn einige Nachrichten untereinander verloren gehen.

Eric Brewer vertritt die These, dass bei Skalierung von Datenbanksystemen nur zwei aus den drei CAP-Eigenschaften erreicht werden. Diese Theorie wurde im Jahr 2002 durch einen veröffentlichen Beweis von Seth Gilbert und Nancy Lynch am MIT bestätigt und somit als Theorem verfestigt. Demnach gibt es drei Klassen von Skalierungsszenarien, in die Datenbanken eingeteilt werden können:

CA: (Consistency und Availability): Darunter fallen die meisten relationalen Datenbanksysteme. Bei Replikation kann jedes System lesen und schreiben (A), und alle Datenbanken haben die gleiche Sicht auf die kompletten Daten.

AP: (Availability und Partition Tolerance): Hier finden sich unter anderem die NoSQL-Datenbanksysteme CouchDB, RIAK und Cassandra

CP: (Consistency und Partition Tolerance): MongoDB, MemcacheDB und Rdis sind hier (unter anderem) einzustufen.

Demnach sind AP und CP für die Skalierung auf eine Vielzahl von Datenbanken geeignet. Das klassische relationale Datenbankmodell ist durch die Beziehungen der Tabellen untereinander schwerer horizontal zu skalieren. Einen guten Überblick bekommen Sie bei Nathan Hurst³.

1.1.4 BASE

BASE ist die Abkürzung von Basically Available, Soft-State und Eventual Consistency, und beschreibt die Hauptanforderung an horizontal skalierte Datenbanksysteme, die hauptsächlich der Informationsverarbeitung dienen. Dabei ist es am wichtigsten, dass ein System aus vielen Datenbanken immer erreichbar ist, die Datenkonsistenz ist zweitrangig. Bei Newsservern oder Nachrichtendiensten wie Twitter kommt es nicht drauf an, ob auf allen Teilen der Welt zur gleichen Zeit dieselben Nachrichten sichtbar sind. Verzögerungen von mehreren Minuten bei der Anzeige meines Tweets im australischen Outback sind zu verkraften, solange ich die Nachricht schnell und jederzeit in das System einspielen kann. Dieses Szenario ist hingegen für Finanzdienste nicht tragbar.

Interessanterweise stammt auch das BASE-Theorem von Prof. Brewer, der schon im Jahr 1997 auf das logische Gegenteil von ACID kam. Ganz wie in der Chemie beschreiben nun ACID und BASE die Gegensätzlichkeiten einer Summe von Eigenschaften.

1.2 Einführung in NoSQL

Im Jahr 2009 prägte Johan Oskarsson auf einer Veranstaltung über Techniken für verteilte nichtrelationale Datenbanken den Begriff NoSQL. Damals als klare Abgrenzung zu SQL gedacht, ist er heutzutage nicht mehr glücklich über diese Wortwahl, und so steht NoSQL heute eher für „Not only SQL". Schwerpunkt auf der damaligen Veranstaltung war die Skalierung von Tausenden von Abfragen zur gleichen Zeit.

Die dennoch eingängige Wortwahl „NoSQL sorgte immerhin für eine etwas greifbarere Definition verschiedener alternativer Datenhaltungstechniken. In diesem Punkt kann man Parallelen zu dem Begriff „AJAX erkennen, bei dem die dahinter stehenden Technologien schon lange bekannt waren, aber erst seit diesem Begriff so richtig zum Hype wurden.

Nötig geworden sind Alternativen zu den bisherigen tabellenorientierten Datenbanken durch die Anforderungen im Internet. Datendurchsatzstarke Dienste wie Onlineshops, Blogs, News und Foren und natürlich in erster Linie Social Networks sind gierig nach vielfältigen Daten und Strukturen, die einem steten Wandel unterliegen. Firmensoftware, deren erste Gebote die Sicherheit und Integrität der Daten und die Abläufe im Betrieb darstellen, sind sicherlich nicht die Kernzielgruppe der NoSQL-Bewegung.

1.2.1 Unterschiedliche Arbeitsweise zu SQL

Für eine erste Betrachtung der Unterschiede zwischen SQL und NoSQL entführe ich Sie zunächst in ein Autohaus. Ich hoffe, auch Sie können sich der Faszination neuer Autos nicht entziehen.

Stellen Sie sich also ein Autohaus vor, das mehrere Marken vertritt. Auf dem Schreibtisch eines Verkäufers stapeln sich Prospekte von Fahrzeugen und Tabellen mit technischen Daten. Eine Zubehörliste für jede Marke gehört ebenso dazu wie eine Erklärung der Abkürzungen aller Sonderausstattungen.

Nun gibt es wie in jeder Branche alte Hasen, die Ihrem System seit Jahren treu sind, und junge Wilde, die neue Wege gehen. So finden Sie im Autohaus Müller nur erfahrenes, alteingesessenes Verkaufspersonal: Herr S. Q. Lamberts verkauft seit 20 Jahren Fahrzeuge dieser Marken, während im Autopark „Speedy Gonzales" der junge C. Ouch in der Kundenberatung neue Wege geht.

Wie immer sind auch die Kunden nicht immer alle gleich: Was für den einen wichtig ist, ist dem anderen völlig egal. Betrachten wir einmal zwei unterschiedliche Kunden am Tisch von Herrn S. Q. Lamberts:

Kunde Schumacher: „Ich suche ein Auto mit möglichst vielen PS, auf dem ich die breitesten Reifen montieren kann, die Sie anbieten, und es sollte schwarz sein."

Herr S. Q. Lamberts fängt an, die Prospekte aller Modelle durchzugehen und die höchsten Leistungen aus den Datenblättern der Modelle zu notieren. In einem weiteren Zubehörprospekt sucht er die passenden Reifenbreiten heraus und notiert sie ebenso. Während sich Kunde Schumacher den Kaffe schmecken lässt, sortiert Herr S. Q. Lamberts alle gefundenen Daten und schreibt sie in einer Tabelle nieder. Glücklich mit dieser Aufstellung verlässt Kunde Schumacher den Tisch in Richtung Ausstellungsraum, um die Fahrzeuge genauer zu betrachten.

Kurz darauf nimmt Kundin Grünwald Platz. Auch sie hat ihre ganz besonderen Vorstellungen: „Ich suche ein Auto mit einem geringen Verbrauch, bei dem ich aber hinten drei vollwertige Gurte inklusive Kindersitzbefestigung habe." Was für ein Glück hat der Verkäufer doch, denn von dem Suchauftrag des vorigen Kunden liegt der Prospekt- und Datenblattstapel noch auf seinem Tisch. Und wieder fängt er an, alle Fahrzeuginformationen zusammenzusuchen und zu präsentieren. Am Ende des Tages wird Herr S. Q. Lamberts stolz darauf sein, innerhalb von nur einer Stunde zwei Kunden die perfekten Angebote unterbreitet zu haben.

Im Autopark „Speedy Gonzales" hingegen bereitet sich der Verkäufer C. Ouch auf eine andere Art und Weise auf seine Besucher vor.

Jedes Mal bei Eintreffen eines neuen Fahrzeugs schreibt C. Ouch ein Datenblatt inklusive aller möglichen Extras für genau dieses Fahrzeug. Statt eines Katalogs mit den Modellen und der Ausstattungsmöglichkeiten, eines Katalogs mit den Extras und eines Datenblatts für alle Motorvarianten liegt auf seinem Schreibtisch eine Vielzahl von Fahrzugdatenblättern, jedes mit einer eindeutigen Nummer für das zu verkaufende Fahrzeug und allen Informationen, die zum Bestellen notwendig sind:

Abbildung 1.1: Fahrzeugliste

Aus seiner Erfahrung mit Kunden weiß er, dass es eigentlich nur eine kleine Anzahl unterschiedlicher Autokäufertypen gibt. Da gibt es die PS-Freaks und die umweltbewussten Käufer, es gibt die Sparsamen und die Ästheten. Natürlich weiß er auch, dass die Übergänge manchmal fließend sind. Er teilt die Kunden in folgende Kategorien ein:

Die PS-Freaks: Hier sortiert er alle Fahrzeuge anhand der Leistung. Die Nummern der passenden Fahrzeuge werden in einer Liste notiert.

Die Umweltbewussten: Hier steht ganz klar der Verbrauch an erster Stelle. Alle Fahrzeuge, sortiert nach dem Verbrauch, landen auf der zweiten Liste.

Abbildung 1.2: Sortierung mit Listen

Auch er bekommt Besuch von unseren beiden Kunden. Während Kunde Schumacher mit Blick auf das riesige Angebot an Fahrzeugen in diesem Autopark schon mal den Kaffeeautomat in Augenschein nehmen will, ist er doch recht überrascht, dass er nach einem kurzen Gespräch bereits eine Liste aller Fahrzeugmodelle in der Hand hält, die ihm gefallen könnten, sortiert nach der Leistung. Sofort erkennt er, dass nur die ersten beiden in Frage kommen und lässt sich die Datenblätter der beiden Fahrzeuge geben. Er nutzt die so gewonnene Zeit, um sich intensiver mit den ausgestellten Modellen beschäftigen zu können.

Genauso ergeht es Frau Grünwald. Zwar hat sie in Ihrer Liste keinen Hinweis über die Kindersitzbefestigung gefunden, nachdem sie aber anhand des Verbrauchs ihre Favoriten bereits gefunden hat, war es ein Leichtes für Herrn C. Ouch, in den Fahrzeugspezifikationen der gewünschten Modelle nach der Option zu schauen.

Ist der Groschen bei Ihnen bereits gefallen?

Ein Großteil der Beratungszeit von Verkäufer S. Q. Lamberts geht für das Zusammentragen der Daten aus verschiedenen Quellen drauf. Natürlich ist er sehr flexibel bezüglich der Kundenwünsche, kann anhand seiner vielen Listen genau das passende Fahrzeug zusammensuchen. Aber für jeden Wunsch müssen die Listen erneut bis zum Ende durchgegangen werden.

Wesentlich effektiver arbeitet in diesem Punkt der Verkäufer C. Ouch. Als zusätzlichen Arbeitsschritt muss er bei jedem neuen Fahrzeug, das zum Verkauf steht, das Datenblatt erstellen und dieses Datenblatt in die vorhandenen Listen der verschiedenen Käufertypen eintragen. Sein Vorteil ist aber ganz klar: Er kann das in Zeiten tun, in denen keine Käufer mehr anwesend sind. Verkäufer C. Ouch hat selbstverständlich einen größeren Papierstapel mit all den Modellen auf dem Tisch liegen, aber die Tatsache, dass nun auch Informationen wie Ausstattungsmerkmale enthalten sind, erlauben einen Verzicht auf eine Suche in weiteren Listen. Da jedes Datenblatt eindeutig beschriftet und in den vorgefertigten Listen für die Käufertypen vermerkt ist, ist C. Ouch in der Lage, die Daten mehrerer Fahrzeuge anhand einer Liste sofort auszuhändigen. Das ermöglicht es ihm, auch bei einem Ansturm von Käufern für ein neues Modell allen die gewünschte Information zu liefern.

Sollte es eine völlig neue Generation von Autokäufern geben, die viel Wert auf Entertainment im Auto legt, reicht es C. Ouch, anhand der vorhandenen Fahrzeugdaten eine neue Liste zu erstellen, sortiert nach den multimedialen Eigenschaften der Fahrzeuge.

In diesem Beispiel haben Sie bereits zwei Eigenschaften von CouchDB kennen gelernt:

Die Schemalosigkeit: Das Datenblatt beinhaltet alle Daten eines