cover.jpg

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.

© 2012 Franzis Verlag GmbH, 85540 Haar

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

ISBN 978-3-645-22022-4

Inhaltsübersicht

Einführung

1  Die Theorie hinter NoSQL

1.1  Die Geschichte

1.2  Arten von NoSQL-Datenbanken

1.3  Grundlagen von CouchDB

2  Installation

2.1  Mac OS X vorbereiten

2.2  Microsoft Windows vorbereiten

2.3  Die Entwicklungsumgebung

3  Erste Übungen mit CouchDB

3.1  Ein einfaches Programm

3.2  Die Arbeit mit der CouchDB

3.3  Futon – das Webinterface von CouchDB

3.4  Eine Abfrage durchführen

3.5  Dokumente der CouchDB

3.6  Arbeiten mit Views

3.7  Dokumente vor dem Speichern überprüfen

3.8  Webseiten anzeigen

4  Die Beispielanwendung MIT – der Métro Information Tracer

4.1  Daten des MIT

4.2  Funktionen des MIT

4.3  Einrichten der Datenbank

4.4  Das Grundgerüst des MIT erzeugen

4.5  Die Dateien für das Benutzerprofil anpassen

4.6  Die Städte des MIT

4.7  Die Linien des MIT

4.8  Die Stationen des MIT

4.9  Das Benutzerinterface erweitern

4.10  U-Bahn-Linien darstellen

4.11  Der Zustand des Métro-Netzes der RATP – Screen Scraping

4.12  Daten von Flickr anzeigen

4.13  Zusätzliche Informationen aus Wikipedia

4.14  Abschluss des Métro Information Tracer

A  Dokumente im JSON-Format

A.1  Städte

A.2  U-Bahn-Linien (ohne Stationen)

A.3  U-Bahn Linien (mit Stationen)

B  Glossar

Stichwortverzeichnis

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

Ihr

Clemens Gull

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.

NoSQL-Datenbanken können folgende Eigenschaften besitzen:

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.

1.1.ERM.tif

Bild 1.1  Daten in einem Referenzmodell

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:

vkarten.tif

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].

  1. Das Netzwerk ist ausfallsicher.
  2. Die Latenzzeit ist gleich null.
  3. Der Datendurchsatz ist unendlich.
  4. Das Netzwerk ist sicher.
  5. Die Netzwerktopologie wird sich nicht ändern.
  6. Es gibt immer nur einen Netzwerkadministrator.
  7. Die Kosten des Datentransports können mit Null angesetzt werden.
  8. Das Netzwerk ist homogen.

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.