reading

Bibliografische Information der Deutschen Bibliothek
Die Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte Daten sind im Internet über http://dnb.ddb.de abrufbar.

Hinweis: Alle Angaben in diesem Buch wurden vom Autor mit größter Sorgfalt erarbeitet bzw. zusammengestellt und unter Einschaltung wirksamer Kontrollmaßnahmen reproduziert. Trotzdem sind Fehler nicht ganz auszuschließen. Der Verlag und der Autor sehen sich deshalb gezwungen, darauf hinzuweisen, dass sie weder eine Garantie noch die juristische Verantwortung oder irgendeine Haftung für Folgen, die auf fehlerhafte Angaben zurückgehen, übernehmen können. Für die Mitteilung etwaiger Fehler sind Verlag und Autor jederzeit dankbar. Internetadressen oder Versionsnummern stellen den bei Redaktionsschluss verfügbaren Informationsstand dar. Verlag und Autor übernehmen keinerlei Verantwortung oder Haftung für Veränderungen, die sich aus nicht von ihnen zu vertretenden Umständen ergeben. Evtl. beigefügte oder zum Download angebotene Dateien und Informationen dienen ausschließlich der nicht gewerblichen Nutzung. Eine gewerbliche Nutzung ist nur mit Zustimmung des Lizenzinhabers möglich.

Alle Rechte vorbehalten, auch die der fotomechanischen Wiedergabe und der Speicherung in elektronischen Medien. Das Erstellen und Verbreiten von Kopien auf Papier, auf Datenträgern oder im Internet, insbesondere als PDF, ist nur mit ausdrücklicher Genehmigung des Verlags gestattet und wird widrigenfalls strafrechtlich verfolgt.

Die meisten Produktbezeichnungen von Hard- und Software sowie Firmennamen und Firmenlogos, die in diesem Werk genannt werden, sind in der Regel gleichzeitig auch eingetragene Warenzeichen und sollten als solche betrachtet werden. Der Verlag folgt bei den Produktbezeichnungen im Wesentlichen den Schreibweisen der Hersteller.

Lektor: Franz Graser
EPUB-Bearbeitung und Konvertierung: www.goebel-software.com
Coverart & -design: www.ideehoch2.de

Einführung

Worum geht es in diesem Buch?

Dieses Buch ist kein klassisches »Lernbuch«, wie wir es dutzendfach kennen. Aber es ist auch keine Referenz oder ein Kompendium für NoSQL-Datenbanken oder eine bestimmte Programmiersprache. Es ist eine praktische Einführung in das Thema NoSQL im World Wide Web.

Das Buch ist in vier Teile gegliedert. Am Anfang steht eine kurze theoretische Einführung in die Unterschiede der SQL- und NoSQL-Datenbanken. Daraus ergibt sich auch, dass wir die Art der Programmierung von Webseiten überdenken müssen, wenn wir NoSQL-Datenbanken verwenden wollen.

Der zweite Teil befasst sich mit der Installation einer NoSQL-Datenbank auf einem lokalen Computer und der Vorbereitung des Geräts auf den dritten und vierten Teil.

Der dritte Teil ermöglicht Ihnen das Kennenlernen dieser neuen Art von Datenbank und auch die Änderungen in der Programmierung von Web-Applikationen in einfachen Beispielen. Hier legen wir keinen großen Wert auf das Aussehen der Ergebnisse und auch nicht auf die Daten. Sondern es ist uns wichtig, die Funktionalität, die hinter den einzelnen Beispielen steht, zu verstehen.

Im vierten Teil werden wir ein praktisches Beispiel entwickeln. Am besten lernt man einfach aus der Praxis. Alle Dinge, die Sie selbst gemacht haben, bleiben gut in Ihrem Gedächtnis haften. Daher werden wir die meisten Informationen, Techniken und Wissensbestandteile im dritten und vierten Teil kennenlernen.

In den letzten Abschnitten finden Sie ein Glossar, das Ihnen verschiedene Fachbegriffe nochmals einfach erklärt. Im Index sind die wichtigsten Begriffe zusammengefasst, damit Sie sie schnell nachschlagen können.

Was wird für dieses Buch benötigt?

Natürlich sollten Sie einen Computer nutzen können, der ein fehlerfrei installiertes Betriebssystem hat. Ob Sie Microsoft Windows , Mac OS X oder eine Unix -Variante einsetzen, ist für die Arbeit mit diesem Buch nicht von Belang. Aber denken Sie bitte daran: Sie installieren Software, die das System erweitert. Daher wäre es gut, dass keine wichtigen Daten auf dem System gespeichert sind, wenn im Fall der Fälle doch etwas gravierend schiefgehen sollte.

Zusätzlich benötigen Sie eine funktionierende Internetverbindung. Sie wird hauptsächlich für die Installation der einzelnen Softwareteile verwendet. Aber sie kommt auch im vierten Teil dieses Buches zum Einsatz, um die Applikation entwickeln und testen zu können.

Weitere Voraussetzungen

Sie sollten bereits ein gewisses Grundwissen in der Programmierung und im Umgang mit Daten haben. Jahrelange Programmiererfahrung ist zwar nicht notwendig, aber ein paar Grundkenntnisse sind von Vorteil, um den vollen Nutzen aus dem Buch ziehen zu können. Ich werde versuchen, den Rest für Sie so einfach wie möglich zu erklären und Sie bei den entscheidenden Schritten der Programmierung zu begleiten.

Für die Erstellung der praktischen Anwendung im hinteren Teil des Buchs ist es vorteilhaft, wenn Sie HTML und CSS beherrschen. Denn diese beiden Sprachen sind für die Erstellung einer Web-Applikation zwingend erforderlich. Auch die JavaScript-Bibliothek jQuery sollte Ihnen nicht fremd sein. Denn wir werden sehen, dass CouchDB sehr eng damit zusammenarbeitet und unsere Applikation ebenfalls Nutzen daraus zieht.

Auch bei den Datenbanken müssen Sie kein SQL-Profi sein. Aber die gängigsten Fachausdrücke sollten Sie beherrschen, obwohl Sie sie auch im Glossar am Ende des Buchs nachschlagen können.

Und Sie sollten keine Scheu vor Neuem haben. Denn NoSQL ist möglicherweise eine der grundlegendsten Änderungen in der Entwicklung von Applikationen für und im World Wide Web.

Die Beispielcodes zum Buch

Besuchen Sie unsere Website unter http://www.buch.cd, und geben Sie dort die letzten Ziffern der ISBN dieses Buchs samt Bindestrich ein. Damit können Sie alle Beispielcodes und sonstigen Ressourcen zu diesem Buch herunterladen. Die verfügbaren Dateien werden nach der erfolgreichen Anmeldung angezeigt.

Sie finden dort die Installationsdateien für CouchDB und CouchApp. Ein Teil kann nur online installiert werden, daher habe ich diese Dateien nicht zur Verfügung gestellt. Sie finden dort auch alle verwendeten Bilder und Icons aus diesem Buch. Zusätzlich ist natürlich der gesamte Quelltext vorhanden. Ich habe ihn gegenüber der im Buch veröffentlichten Fassung ein wenig erweitert und manche Ideen, die im Buch nur kurz vorgestellt werden konnten, verwirklicht. Zusätzlich finden Sie auch alle Daten und Dokumente im JSON-Format, damit Sie nicht alles von Hand eingeben müssen.

Berichtigungen

Obwohl alle Beteiligten mit größter Sorgfalt vorgehen, um die Richtigkeit der Inhalte sicherzustellen, passieren Fehler. Wenn Sie einen Fehler in diesem Buch entdecken, egal ob im Text oder im Quellcode, bin ich für eine kurze oder auch längere Mitteilung sehr dankbar. So können Sie anderen Lesern Ärger ersparen und mithelfen, die folgende Version des Buchs zu verbessern. Wenn Sie einen Druckfehler finden, senden Sie mir bitte eine E-Mail an buch@guru-20.info. Ich werde alle Berichtigungen, Änderungen und Verbesserungen auf meinem Blog http://www.guru-20.info veröffentlichen.

Danke!

Herrn Franz Graser, meinem Lektor und Betreuer beim Franzis Verlag: Danke für die kompetente Betreuung bei der Umsetzung der Bücher, die Korrekturen und die Möglichkeit, als Autor zu arbeiten.

Danke auch an das komplette Team im Franzis Verlag. Ohne die vielen im Hintergrund arbeitenden, helfenden Hände wäre dieses Buch nicht erschienen.

Feedback

Ich würde mich über Reaktionen und Anregungen sehr freuen. Sie erreichen mich unter folgender Adresse: gull@guru-20.info

1 Die Theorie hinter NoSQL

In diesem Kapitel lernen Sie die Hintergründe von NoSQL kennen. Falls Sie direkt ins kalte Wasser springen wollen, können Sie dieses Kapitel auch überspringen. Falls Sie sich aber mit Datenbanken und den dahinter stehenden Konzepten noch nicht so gut auskennen sollten, empfehle ich Ihnen, diesen Abschnitt in Ruhe durchzuarbeiten. Denn hier werde ich einige Dinge erklären, die später verwendet werden. Damit Sie aber die einzelnen Fachbegriffe schnell und einfach finden, habe ich die entsprechenden Definitionen am Ende des Buchs in einem Glossar zusammengefasst.

Nach mehr als 15 Jahren einer fast uneingeschränkten Herrschaft der SQL-basierten Datenbanken (SQL steht für Structured Query Language, also zu Deutsch »strukturierte Abfragesprache«) findet nun ein Wechsel in der Landschaft der Web-Applikationen statt. Und genau diese neuen Sichtweisen und Techniken werden Sie hier kennenlernen. Natürlich werden nicht alle SQL-Datenbanken über Nacht verschwinden, aber bei einigen großen Unternehmen vollzieht sich der Wandel dahingehend, dass in den einzelnen Nischen die entsprechenden und idealen Datenbanksysteme (auch parallel zueinander) eingesetzt werden.

1.1 Die Geschichte

Der Begriff NoSQL (eine Abkürzung für not only SQL) wurde zum ersten Mal 1998 verwendet. Carlo Strozzi[1] entwickelte zu dieser Zeit eine leichtgewichtige Open-Source-Datenbank, die bewusst keine Zugriffsmöglichkeit unter dem Standard SQL zur Verfügung stellte. Strozzi unterscheidet aber zwischen seiner NoSQL-Datenbank und der NoSQL-Bewegung. Diese verfolgt ein Konzept, das vom relationalen Datenbankmodell abstammt.

Erst mehr als zehn Jahre später wurde der Begriff NoSQL bekannter. Denn Johan Oskarsson verwendete ihn Anfang 2009 bei einem Treffen zum Thema strukturierte, verteilte Datenspeicher . Er bezeichnete damit Datenbanken, die nicht relational sind, auf verteilten Systemen liegen und meistens auf ACID-Eigenschaften XE„ACID“(Englisch für atomicity, consistency, isolation, durability) verzichten.

Das Konzept NoSQL

Diese Technologie hat prinzipiell ein Ziel: die Nachteile bestehender, eingeführter Datenbanksysteme auszugleichen. Die Technik soll besser skalierbar sein und eine bessere Performance bei hoher Datenlast mit vielen umfangreichen Transaktionen bieten. NoSQL-Datenbanken haben im Gegensatz zu relationalen Datenbanksystemen kein festes Schema zur Speicherung der Daten. Dies ist eine radikale Änderung zu SQL-Datenbanken, die auf eine strenge Struktur (oder ein strenges Schema) der gespeicherten Daten achten.

BASE – Basically Available, Soft State und Eventual Consistent

Da RDBMS (relationale Datenbankmanagementsysteme, also konventionelle Datenbanken) sehr streng auf die Konsistenz der Daten achten, kann es hier zu Problemen mit der Performance und Verfügbarkeit kommen. Dieses Konzept wird bei NoSQL zugunsten der besseren Skalierbarkeit und auch Verfügbarkeit aufgeweicht.

Man akzeptiert die »lose Konsistenz«. Dabei wird die Datenkonsistenz von nachfolgenden Datenoperationen immer wieder neu hergestellt. Die Datenbank wechselt dadurch immer wieder zwischen einem konsistenten und inkonsistenten Zustand. Im Gegensatz dazu müssen sich SQL-Datenbanken dauerhaft in einem konsistenten Zustand befinden. Werden durch verschiedene Datenbankoperationen Duplikate im Datenbestand angelegt, so wird die Datenbank durch eine zeitversetzte Synchronisierung immer wieder in einen konsistenten Teilzustand versetzt. Wobei der Begriff Eventual Consistent festlegt, dass alle Clients, die die Daten nutzen, nur in einem bestimmten Zeitfenster einen konsistenten (denselben) Datenbestand sehen.

CAP – Consistency, Availability und Partition Tolerance

Der Informatiker Eric Brewer vermutete im Jahr 2000, dass Systeme zum verteilten Rechnen nicht alle drei genannten Eigenschaften gleichzeitig erfüllen können. Diese Überlegung war und ist besonders wichtig für das Erstellen von Applikationen mit NoSQL-Datenbanken, denn sie sind verteilte Systeme.

Im Jahr 2002 lieferten Seth Gilbert und Nancy Lynch einen axiomatischen Beweis, dass Brewers Vermutung richtig ist und nur zwei der drei Eigenschaften gleichzeitig erfüllt werden können. Dieses Theorem wirkt sich, wie wir später sehen werden, entscheidend auf das Design von NoSQL-Datenbanken aus.

1.2 Arten von NoSQL-Datenbanken

Datenbanken lassen sich in verschiedene Klassifikationssysteme einordnen. Am einfachsten gehen wir dabei vor, wenn wir die Art der Datenspeicherung betrachten. Für jede der folgenden Arten gibt es typische Vertreter und auch Anwendungsgebiete. Daher muss man sich vor der Wahl der Datenbank über das Anwendungsgebiet oder auch die zu verwaltenden Daten klar werden.

Dokumentenorientiert

Diese Datenbanken speichern Textdaten von beliebiger Größe in unstrukturierter Form. Der Zugriff auf die Daten erfolgt hier über die Dokumentinhalte. Hierzu gehören Apache CouchDB [2], MongoDB [3] oder auch Lotus Notes [4].

Key-Value-orientiert

Hier werden definierte Schlüssel verwendet, die auf einen bestimmten Wert verweisen. Diese Werte können aus beliebigen Zeichenfolgen bestehen. Die Key-Value-Datenbanken können entweder als In-Memory- oder als On-Disk-Version implementiert werden. Die Implementierung In-Memory eignet sich zum Beispiel sehr gut für Cache-Speichersysteme, da sie speicherresistent ist. Dies ist zum Beispiel das System memcached [5]. Die On-Disk-Version ist für große Datenmengen vorgesehen und wird beispielsweise von Google BigTable [6] oder Amazon SimpleDB [7] implementiert. Eine Kombination der beiden Versionen vereint – so gut es geht – die Vorteile beider Implementierungen miteinander. Eine Implementierung ist zum Beispiel Redis [8] und wird aktiv von GitHub [9] eingesetzt.

Spaltenorientiert

Hier werden die Daten als Schlüssel-Wert-Relation, auch Key/Value oder Tupel genannt, abgelegt. Das Hauptaugenmerk liegt hier auf der Verminderung der Ein-/Ausgabe-Aktivität bei der Berechnung der Datensätze. Ein Vertreter ist beispielsweise die Datenbank Cassandra [10] der Apache Foundation [11]. Diese Art von Datenbanken ist beispielsweise bei Facebook [12], Digg [13] oder Twitter [14] im Einsatz.

Graphenorientiert

Diese Datenbanken spiegeln die Beziehungen der Daten zueinander wieder. Dazu werden die Daten in einer Art Baumstruktur gespeichert. Sie eignen sich ideal zur Darstellung von Beziehungen in sozialen Netzwerken. Dabei werden die Daten als einzelne Knoten und die Beziehungen als Verbindungen zwischen diesen dargestellt. Beispiele für diese Art der Datenbank sind FlockDB [15] (wie sie Twitter verwendet), AllegroGraph [16] oder Neo4j [17].

Übersicht von NoSQL-Datenbanken

In diesem Abschnitt erhalten Sie einen – nicht vollständigen – Überblick über verschiedene NoSQL-Datenbanken, ihre Funktionen, Vor- und Nachteile sowie Einsatzgebiete.

	CouchDB	MongoDB	Redis	Cassandra	Riak	HBase
Programmiert in	Erlang	C++	C/C++	Java	Erlang & C	Java
Lizenz	Apache[18]	AGPL[19]/Apache	BSD[20]	Apache	Apache	Apache
Hauptvorteil	DB-Konsistenz & einfache Benutzung	Verwendet Abfragen und Indizierung auf SQL-Basis	Geschwindigkeit	Große Tabellen	Fehlertoleranz	Riesige Tabellenstrukturen
Protokoll	HTTP/REST	proprietär	Ähnlich Telnet	Proprietär und Thrift	HTTP/REST	HTTP/REST und Thrift
Art	Dokumentorientiert	Dokumentorientiert	In-Memory	spaltenorientiert	spaltenorientiert	Key-Value-orientiert
Besonderheiten	bidirektionale Replikation	Master-Slave-Replikation	Master-Slave-Replikation	Trade-offs für Verteilung und Replikation	Trade-offs für Verteilung und Replikation	Entworfen wie Google BigTable
Konflikterkennung	Abfragen sind JavaScript-Ausdrücke	Einfache Schlüsselwerte	Trade-offs anpassbar	Trade-offs anpassbar	Vordefinierte Abfragen
MVCC blockieren keine Lesezugriffe	Komplexe Datenoperationen	Datenüberprüfung	Optimierung von Echtzeitabfragen
Versionierung der Daten	Serverseitiges JavaScript	Verwendet Sets, Lists und Hashes	Abfrage nach Spalten	Datensicherheit	Performanter Thrift-Gateway
serverseitige Validierung der Dokumente	Unterstützt Transaktionen
Authentifizierung	Verteilte Daten (Sharding)	Ablaufdatum für Daten	Abfrage nach Indexbereichen	Volltextsuche	XML mit HTTP-Unterstützung
Echtzeit-Updates	Sortierte Sets
Attachment-Verwaltung	Teilweise Ablage der Daten im Speicher	Überwachen von Datenänderungen	Schreibt schneller als es liest	Commits	Wahlfreier Zugriff auf Daten
jQuery-Bibliothek
Nachteile	Wiederholte Komprimierung notwendig	Nach einem Crash müssen die Tabellen repariert werden	Erst Version 2.0 kann auf die Disk auslagern	Schreibt schneller als es liest	Enterprise- und Open-Source-Version	Performance des wahlfreien Zugriffs ähnlich SQL
Datenbankgröße sollte vorhersehbar sein	Übernimmt Komplexität von Java	Verteilte Daten nur mit der Enterprise-Version
Einsatzgebiete	CRM	Dynamische Abfragen	Häufige Schreibzugriffe	Echtzeit-Datenanalyse	Hochverfügbarkeit	Große Tabellen mit Milliarden Datensätzen und Millionen von Datenfeldern
Wenig Schreibzugriffe	Indizierung der Daten	Schnelle Änderung der Daten	Alle Systembestandteile in Java sein sollen	Schnelle Schreibzugriffe
Häufige Lesezugriffe	Große DB mit Performance	Echtzeitverarbeitung	Seltene Lesezugriffe	Echtzeitzugriff auf die Daten
Versionierung	Ähnlich SQL ohne definierte Spalten	Statistiken	Logging	Datenanalyse	Wahlfreier Datenzugriff

In diesem Buch wird die Entscheidung nicht direkt vom Einsatzgebiet bestimmt. Aus didaktischen Gründen, und wegen dem leichteren Handling auf einem lokalen Computersystem entscheiden wir uns für den Einsatz der CouchDB als Vertreter der dokumentenorientierten NoSQL-Datenbanken.

1.3 Grundlagen von CouchDB

Be Relaxed! oder Entspann Dich! ist der Leitspruch von Apache CouchDB, und genau dieses Motto müssen wir verinnerlichen. Eine der Grundlagen ist die Einfachheit, mit der CouchDB erstellt wurde. Die Datenbank versucht sich so weit wie möglich im Hintergrund zu halten und den Administrator nicht zu »belästigen«.

Dazu gehört, dass die interne Architektur sehr fehlertolerant ist. Einzelne Fehler beziehungsweise Ausnahmen treten in einer kontrollierten Umgebung auf und werden dort auch behandelt. Wenn üblicherweise eine Ausnahme auftritt, läuft sie durch das ganze System, wo sie an der Spitze behandelt wird. Bei CouchDB betrifft ein Fehler nur eine einzelne Anfrage (Request), wird dort behandelt und beeinflusst den Rest des Systems nicht.

Außerdem ist CouchDB auf Lastwechsel ausgerichtet. Wir kennen das Problem, dass es auf einmal viele Requests bei einer Web-Applikation geben kann. CouchDB reagiert zwar mit einer höheren Latenzzeit darauf, aber sie vergisst keine Anfrage, sondern beantwortet alle. Ist das hohe Lastaufkommen wieder vorbei, reagiert die Datenbank wieder mit der gewohnten Geschwindigkeit.

Normalerweise wird eine Anwendung so erstellt, dass sie bereits die maximalen Hardwareanforderungen abdeckt. Einer der offensichtlichen Nachteile dieses Ansatzes sind die hohen Investitionskosten, die am Beginn des Projekts stehen. Weiters ist das Lastaufkommen oft viel zu gering, um die Hardware auszulasten und ihre Vorteile wirklich zu nutzen.

Auch ist die Programmierung viel aufwendiger, da bereits Fälle abgebildet werden müssen, die erst in der Zukunft auftreten werden. CouchDB verfolgt hier einen anderen Ansatz: Es besitzt eine eingebaute Skalierbarkeit. Damit diese auch funktioniert, setzt die Datenbank dem Programmierer eindeutige Grenzen und macht nicht alles möglich, was umsetzbar wäre. Dies ist zwar etwas unflexibel, und wir müssen lieb gewonnene Gewohnheiten über Bord werfen. Aber durch das Fehlen mancher Funktionen kann der Programmierer – also Sie und ich – keine Anwendung schreiben, die der Skalierung im Wege steht oder diese unmöglich macht.

Daten müssen modelliert werden!

Dieser Ansatz besteht seit dem Beginn der IT und ist sicherlich richtig. Aber die Art und Weise kann sich je nach Gedankenmodell und Herangehensweise unterscheiden. In der klassischen Anwendung werden Daten im ER-Modell , kurz ERM (Entity-Relationship-Modell), dargestellt. Dies ist zwar eine sehr effektive Art, Daten für Computer aufzubereiten, aber auch eine sehr schwer skalierbare und für Menschen nicht leicht zu verstehende Art.

Im klassischen Modell – nehmen wir als Beispiel eine Rechnung – stellt sich die Datenmodellierung als Referenzmodell schon sehr aufwendig dar. Und dabei sind noch gar nicht alle Möglichkeiten berücksichtigt. Werfen Sie einen Blick auf die folgende Abbildung. Sie ist schon komplex, obwohl es nur ein einfaches, schematisches ERM ist und viele Punkte nicht berücksichtigt sind.

Im ER-Modell versuchen wir die Daten atomar[21] , eindeutig und nach Typ definiert[22], in einer Datenbank abzulegen. Um dies zu erreichen, müssen wir alle Redundanzen vermeiden und die einzelnen Datensätze in eigene Tabellen ablegen. In unserem Beispiel sind das bereits sechs. Aber dies widerspricht unserem natürlichen Denken. Denn wir hätten gern alle Daten auf einen Blick und nicht in kleine Häppchen aufgeteilt, die wir später wieder zusammensuchen müssen. Außerdem hat dieses Modell noch einen weiteren Haken: Durch das schemaorientierte Modellieren müssen alle möglichen Datenfelder bereits vorhergesehen werden, späteres Hinzufügen (Skalieren) ist oft mit einem beträchtlichen Aufwand verbunden. Dieser Aufwand kann so groß sein, dass eine Anwendung komplett neu entwickelt werden muss, damit sie auf größere Systeme skaliert werden kann. Und was ist, wenn Daten nicht erfasst werden, weil sie entweder nicht vorhanden oder nicht bekannt sind? Auch dafür müssen eigene Mechanismen im Schema vorgesehen werden. Denn leere Datenfelder können eine klassische relationale Datenbank aus dem Tritt bringen.

Dies sind aber keine Gründe, relationale Datenbanken zu verteufeln und nicht mehr einzusetzen. Sie werden sehr häufig verwendet und sind auch für viele Arten der Datenverarbeitung sehr geeignet. Aber manchmal können SQL-Datenbanken die Dokumente der realen Welt nur sehr schwer abbilden. Und hier kommen dokumentenorientierte Datenbanken wie CouchDB ins Spiel. Diese sehen die Daten als eine Einheit und speichern und präsentieren sie auch so. Betrachten wir zum Beispiel Visitenkarten – sie kommen oft vor und wir haben alle welche auf dem Schreibtisch liegen:

Bild 1.2 Verschiedene Visitenkarten

Jede Visitenkarte enthält und präsentiert die für uns entscheidenden Informationen auf einen Blick. Es sind also in sich geschlossene Daten, eine der Grundlagen einer dokumentorientierten Datenbank.

Wenn wir die obigen Karten betrachten, sehen wir, dass sie alle ähnliche Daten enthalten, aber eben nicht exakt die gleichen. Denn bei Elisa Schmidt fehlt die Webseitenadresse, die Max Muster angeführt hat. Und Herr Meier hat nur eine Telefonnummer und Postanschrift, keine Mailadresse. Die fehlenden Daten werden von uns Menschen einfach ignoriert, denn wir haben das Konzept verinnerlicht. Durch einfaches Weglassen der Mailadresse gibt Herr Meier zu verstehen, dass er keine hat. Er muss nicht E-Mail: keine vorhanden auf die Karte schreiben.

Und hier liegt auch der grundlegende Unterschied zwischen SQL- und NoSQL-Datenbanken. Für die SQL-Variante müssen die Daten vorher strukturiert in ein Schema gebracht werden, sie sind daher schemaorientiert. Erst dann sind sie zu verarbeiten. Die NoSQL-Variante hingegen strukturiert die Daten erst nach dem Speichern, genauso wie wir Menschen. Diese Datenbanken sind schemafrei.

Grundlegende Irrtümer!

Programmierer gehen oft von falschen Annahmen aus. Dies wurde schon vor fast 20 Jahren erkannt, wird aber heute noch oft und gern ignoriert. Die meisten Programmierer verteilter Systeme gehen von Annahmen aus, die der Hausverstand verneint. Sie wurden bekannt unter der Bezeichnung »Fallacies of Distributed Computing«[23].

Die CouchDB versucht nicht, wie andere Werkzeuge diese Punkte zu ignorieren oder zu verstecken. Im Gegensatz dazu sind im grundlegenden Konzept diese acht Punkte enthalten, und das System versucht danach zu arbeiten. Am besten sieht man das bei der Replikation der Datenbanken durch CouchDB.

Ein wichtiger Punkt der Skalierbarkeit ist, dass Daten an verschiedenen Orten präsent sind. Dies können verschiedene Server im selben Raum oder auch an geografisch weit auseinander liegenden Orten sein. Damit die Daten von einem Server zum anderen kommen, müssen sie repliziert (kopiert) werden. Bei CouchDB passiert dies mit dem im Internet üblichen Protokoll HTTP und als inkrementelle Replikation. Das Protokoll ist schließlich vorhanden und funktioniert (meistens). Aber wie der erste Punkt der Irrtümer zeigt, das Netz wird ausfallen! Und das wird nach Murphys Gesetz [24] genau während der Replikation passieren. Dann ist die Datenbank bei CouchDB trotzdem verfügbar. Irgendwann ist eine Netzwerkverbindung wieder verfügbar, und dann beginnt das System nicht von vorne mit der gesamten Replikation, sondern setzt genau dort fort, wo die Unterbrechung stattfand.

Die Wartezeit entscheidet!

Dies ist bei allen Anwendungen so. Sobald der Anwender warten muss, nimmt die Unzufriedenheit zu – beobachten Sie sich selbst bei der Arbeit mit lokal installierten Applikationen oder auch beim Surfen im World Wide Web. Nicht umsonst versuchen alle Webseiten, noch das letzte Quäntchen an Geschwindigkeit herauszuholen. Aber das Web hat eben keinen unendlichen Datendurchsatz und auch keine hundertprozentige Verfügbarkeit. Denken wir nur an unsere geliebten Smartphones, Tablets und anderen mobilen Geräte. Wie oft ist die Verbindung zum Anbieter nicht verfügbar? Und was ist, wenn wir im Ausland sind, wollen wir die hohen Kosten für Datenverbindungen wirklich zahlen?

Und hier ist ein anderer Ansatz der CouchDB: Wieso versucht man nicht, eine Skalierung nach unten vorzunehmen und eine lokale Kopie der Datenbank zu erzeugen und zu verwenden? Da die Datenbank in der Sprache Erlang [25] geschrieben ist, kann sie auch auf sehr einfachen Geräten mit geringer Hardwareausstattung laufen. Und warum nicht eine Datenbank auf einem Smartphone installieren, die sich – sobald eine Datenleitung verfügbar ist – automatisch mit anderen Instanzen synchronisiert? Dieser Ansatz bietet den Vorteil einer geringen Latenzzeit, denn eine lokal vorhandene Datenbank antwortet in Tausendstelsekunden. Zusätzlich wird das Problem des fehlenden Mobilfunknetzes umgangen. Denn die Daten sind jetzt offline verfügbar.

Mit oder gegen die CouchDB arbeiten?

In der Welt der Programmierung hat sich eine Phrase eingebürgert: »Wir programmieren gegen eine Schnittstelle/Datenbank/API.« Und dieser Satz drückt auch die grundlegende Denkweise der Programmierung aus. Wir arbeiten gegen etwas und versuchen es in unsere Anforderung zu zwingen. Die Philosophie der CouchDB ist aber, mit der Datenbank zu arbeiten und nicht Dinge zu erzwingen. So erhalten wir automatisch einfache, skalierbare und verteilte Systeme.

Bei der Arbeit mit der Datenbank müssen Sie aber einen der grundlegenden Ansätze von SQL über Bord werfen: Daten sind immer konsistent! Bei der CouchDB lautet der Ansatz: Die Daten sind am Ende irgendwann konsistent![26] Dies ist ein entscheidender Ansatz beim Hinzufügen von mehreren Datenbankservern zu einem bestehenden System. Denn hier müssen Entscheidungen über die Konsistenz der Daten und auch der Verfügbarkeit getroffen werden. Und hier kommt das erwähnte CAP-Theorem ins Spiel. Dabei legt die CouchDB das Hauptaugenmerk auf Verfügbarkeit und Partitionstoleranz und stellt die Konsistenz hintan.