DiplomarbeitUmsetzung einer verteilten Anwendungmit der
dokumentenorientiertenDatenbank CouchDBEin Gliederungseditor als
replizierbares Verteiltes SystemLena HerrmannBeuth Hochschule fr
Technik BerlinUniversity of Applied SciencesUpstream-Agile
GmbHFachbereich VI Informatik und MedienStudiengang
Medieninformatik, Schwerpunkt SoftwareMatrikelnummer
720742Betreuer: Prof. Dr. Stefan EdlichGutachter: Prof. Dr. Frank
SteyerEingereicht am 14. Juli 2010For most of mankinds history we
have lived in very small communities in which we kneweverybody and
everybody knew us. But gradually [...] our communities became too
large anddisparate [...], and our technologies were unequal to the
task of drawing us together. But thatis changing.Interactivity.
Many-to-many communications. Pervasive networking. ese are
cumbersomenew terms for elements in our lives so fundamental that,
before we lost them, we didnt evenknow to have names for
them.(Douglas Adams, )AbstractAuf heutigen Webbrowsern und mobilen
Endgerten knnen komplexe Anwendungenausgefhrt werden. Diese
ermglichen Zusammenarbeit und Datenaustausch zwischenBenutzerInnen.
Bei Laptops und Mobilfunkgerten kann keine kontinuierliche
Internetver-bindung vorausgesetzt werden. Um dieses Problem zu
bercksichtigen kann Datenreplika-tion eingesetzt werden, wobei die
Daten regelmig synchronisiert und dabei konsistentgehalten werden
mssen. In dieser Arbeit wird die Konzeption und prototypische
Erstel-lung einer JavaScript-Anwendung beschrieben, die mithilfe
der dokumentenorientiertenDatenbank CouchDB einen verteilten
Gliederungseditor umsetzt. Mit einem Gliederungs-editor knnen z. B.
Gedanken oder Konzepte hierarchisch geordnet aufgeschrieben
werden.Neben der Einordnung des zu erstellenden Systems und einer
Analyse der in Frage kom-menden Lsungsmglichkeiten werden die
verwendeten Technologien beschrieben. Genauvorgestellt werden dabei
CouchDB mit der eingebauten Master-Master-Replikation und
derMglichkeit, eine komplexe Applikation ohne Middleware zu
implementieren. Die erstellteAnwendung lu lokal imBrowser und ist
dadurch auch oine benutzbar. Konikte werdenbei der Synchronisation
vom System, teilweise mit Benutzeruntersttzung, aufgelst. In
derArbeit wird abschlieend die Einsetzbarkeit von CouchDB fr eine
verteilte Anwendungund speziell fr den gewhlten Anwendungsfall
beurteilt.Gliederung1 Einleitung 1. Motivation . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . Textauszeichnung. . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . 2 Aufgabenstellung
43 Analyse 6. Anforderungen an einen Gliederungseditor . . . . . .
. . . . . . . . . . . . . . . . .. Denition . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . ..
Einsatzmglichkeiten. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . Anforderungen an Verteilte Systeme. . . . . . . . . .
. . . . . . . . . . . . . . . . . Anforderungen an Groupware . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . Verschiedene
Lsungsanstze . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . .. Manueller Austausch von Dokumenten . . . . . . . . . . . .
. . . . . . . .. Echtzeit-Texteditoren. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .. Versionsverwaltungssysteme . . . .
. . . . . . . . . . . . . . . . . . . . . . .. Datenbanken. . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Beschreibung des gewhlten Lsungsansatzes . . . . . . . . . . . . .
. . . . . . . 4 CouchDB - eine Datenbank fr Verteilte Systeme 15.
eoretische Einordnung . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . .. Einordnung der Datenbankarchitektur . . . . .
. . . . . . . . . . . . . . . .. Das CAP-eorem . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .. Transaktionen und
Nebenlugkeit . . . . . . . . . . . . . . . . . . . . . . ..
Replikation. . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . .. HTTP-Schnittstelle . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .. Abgrenzung zu relationalen
Datenbanksystemen . . . . . . . . . . . . . . . Beschreibung . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . .. Dokumente und Koniktbehandlung . . . . . . . . . . . . . .
. . . . . . . .. HTTP-Schnittstelle . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .. Replikation. . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . .. Change
Notications . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . .. Anwendungen mit CouchDB . . . . . . . . . . . . . . . . . .
. . . . . . . .. Views . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .. Implementierung . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . 5 Technische
Grundlagen 32. Webtechnologien . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .. CouchApp . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .. HTML . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. .. JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . .. Sammy.js . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . .. Mustache.js. . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..
Weitere Bibliotheken . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . Cloud Computing . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .. Denition . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Stile .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . .. Vor- und Nachteile . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . Methoden und Mittel. . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . ..
Vorgehensmodelle . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . .. Testing Frameworks . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .. Entwicklungsumgebungen. . . . . .
. . . . . . . . . . . . . . . . . . . . . 6 Anforderungen an das
System 53. Funktionale Anforderungen. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .. Muss-Kriterien . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . .. Kann-Kriterien .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.. Abgrenzungs-Kriterien. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . Nichtfunktionale Anforderungen . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .. Einsatz . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..
Umgebung . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . .. Benutzeroberche . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .. Qualittsziele . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . 7 Systemarchitektur
62. Gesamtberblick ber die Architektur. . . . . . . . . . . . . . .
. . . . . . . . . . . Modellierung der Datenstruktur . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .. Anforderungen . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..
Problemstellung . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . .. Speicherung in einem JSON-Dokument . . . . . . . .
. . . . . . . . . . . .. System Prevalence. . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .. Speicherung der
Versionshistorie . . . . . . . . . . . . . . . . . . . . . . . ..
Ausgliedern der Zeilen in einzelne JSON-Dokumente . . . . . . . . .
. . .. Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . Umsetzung der Zeilensortierung und
-einrckung . . . . . . . . . . . . . . . . . . .. Indiziertes Array
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.. Verkettete Liste . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . .. Baumstruktur . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .. Fazit . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Koniktbehandlung . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . .. Gleichzeitiges Einfgen einer Zeile . . . .
. . . . . . . . . . . . . . . . . . .. Gleichzeitiges ndern einer
Zeile. . . . . . . . . . . . . . . . . . . . . . . .. Weitere
Koniktarten. . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . .. Benachrichtigung . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . Benutzeroberche . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .. Strategien. . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..
Seitenaufbau . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . .. Editor . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .. Interaktion . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Systemdokumentation 80. Projektstruktur . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . Routing. . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . Datenstrukturen . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .. Outline . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .. Note . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . Benutzeroberche . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .. Umsetzung des Gliederungseditors. .
. . . . . . . . . . . . . . . . . . . . .. Modizierung des DOM. . .
. . . . . . . . . . . . . . . . . . . . . . . . . .. Rendern der
Baumstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . .
. Replikation. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .. Starten der Replikation. . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .. Benachrichtigung bei
nderungen. . . . . . . . . . . . . . . . . . . . . . .
Konikterkennung . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . Koniktbehandlung . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .. Append-Konikte . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..
Write-Konikte . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . .. Kombination aus beiden Koniktarten . . . . . . . . .
. . . . . . . . . . . . Systemtest . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .. Unit Tests . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. .. Integration Tests . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . .. Testsuite fr die CouchDB HTTP-API . . . .
. . . . . . . . . . . . . . . . . Deployment mit Amazon Web
Services . . . . . . . . . . . . . . . . . . . . . . . . .
Clustering mit Couchdb-Lounge . . . . . . . . . . . . . . . . . . .
. . . . . . . . . .. Funktionsweise . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .. Konguration . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . 9 Anwendung
102. Installation. . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .. CouchDB. . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . .. Deployment . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Bedienung . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . .. Grundfunktionen . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . .. Replikation. . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..
Koniktbehandlung. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . .. Hilfestellung zur Erzeugung der Konikte . . . . . . .
. . . . . . . . . . . 10Bewertung und Ausblick 113. Bewertung des
Ergebnisses . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . Die Zukun der eingesetzten Technologien . . . . . . . . .
. . . . . . . . . . . . . . Empfehlungen fr die Weiterentwicklung.
. . . . . . . . . . . . . . . . . . . . . . Anhang iA. Abkrzungen .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . iA. Ergnzungen zur Analyse . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . iiA. Ergnzungen zum Technischen
Hintergrund. . . . . . . . . . . . . . . . . . . . . ivA.
Ergnzungen zu den Systemanforderungen. . . . . . . . . . . . . . .
. . . . . . . viA. Ergnzungen zur Systemdokumentation . . . . . . .
. . . . . . . . . . . . . . . . . viiiA. Inhalt der CD-ROM . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
xxiVerzeichnisse xxiiLiteraturverzeichnis . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
xxviiInternetquellen. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . xxxviiAbbildungsverzeichnis . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . xxxixVerzeichnis der Quelltextauszge . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . xli
1Einleitung1.1MotivationWere at the dawn of a new age on the
web, or maybe on a horizon, or a precipice; themetaphor doesnt
matter, the point is, things are changing. Specically, as
browsersbecome more and more powerful, as developers were given new
opportunities torethink how we architect web applications. [Qui]Das
Internet wird mehr und mehr ein Bestandteil des alltglichen Lebens.
Der Anteil der regel-migen Internetnutzer in Deutschland liegt im
JahrbeiProzent und steigt stetig an.Unter denbis jhrigen betrgt der
Anteil der Menschen, die das Internet nie nutzen, nurnochProzent
[Ini, S. ]. Mit der Anzahl der Benutzer nimmt die Normalitt zu, mit
derWebanwendungen fr Zusammenarbeit, Kommunikation und
Datenaustausch benutzt werden.Dabei mssen diese Webanwendungen
einer steigenden Anzahl von Benutzern zeitgleichenZugri erlauben.
Dem Webbrowser kommt dabei als Plattform fr Anwendungen eine
immergrere Bedeutung zu [Pau, S. )]. Kaum eine Soware hat sich in
den letzten zehn Jahrenso weiterentwickelt wie der Webbrowser [GJ].
Dadurch entstehen auch neue Mglichkeiten,Webanwendungen zu
entwickeln: Es knnen immer hhere Anforderungen an
Bedienbarkeit,Einsetzbarkeit und Verfgbarkeit der Anwendungen
gestellt und auch erfllt werden.Ein weiterer Trend ist die
zunehmende Verbreitung von mobilen Endgerten [Ini, S. ]. In[Kot, S.
] wird vorausgesagt, dass durch das Wachstumder Angebote imInternet
in Verbindungmit der Weiterentwicklung der Informationstechnologien
die Anzahl der Zugangsgerte starkansteigen wird. Mobile Endgerte
sind heute vor allem Laptops und Mobiltelefone. Diese habeno eine
schlechtere Konnektivitt als stationre Endgerte. Lange Phasen ohne
Verbindung sinddie Norm, weitere Herausforderungen sind hohe
Latenzen und limitierte Bandbreite [Guy].Es besteht also ein groer
Bedarf an Technologien, die die oben aufgefhrten Ansprche
anZusammenarbeit und Datenaustausch erfllen. Diese mssen die
Umsetzung von Systemenermglichen, die in groem Rahmen skalieren.
Gleichzeitig sollen sie aber auch den Bedarf ankontinuierlicher
Konnektivitt stark reduzieren. Eine mgliche Lsung fr diese Art
Problem istDatenreplikation. Diese wird bei [Guy] so
umrissen:Copies of data are placed at various hosts in the overall
network, [...] oen local tousers. In the extreme, a data replica is
stored on each mobile computer that desires toaccess that data, so
all user data access is local..Aufbau der Arbeit Die Schwierigkeit
hierbei ist, die Daten regelmig zu synchronisieren und konsistent
zu halten.Die berwachung der Konsistenz ist Aufgabe des Systems,
das die Replikation durchfhrt. Zieleeines solchen Systems sind hohe
Verfgbarkeit und Kontrolle ber die eigenen Daten. Eine solcheLsung
kann gleichzeitig den hohen Ansprchen an Datenschutz gengen, die
Benutzer anmoderne Webanwendungen stellen [Kraa, Krab]. Bei
Systemen, die Replikation umsetzen,knnen die Benutzer selbst
entscheiden, mit wem sie ihre Daten teilen. Bei
entsprechenderImplementierung des Systems ist die Benutzung auerdem
zumindest zeitweise unabhngigvon zentralen Servern. Der Ausfall des
Netzwerks oder einzelner Knoten ist von vornherein miteingeplant.In
dieser Arbeit wird die Konzeption und Umsetzung einer Soware
beschrieben, die die Daten-bank CouchDB verwendet. Mit CouchDB
knnen Anwendungen umgesetzt werden, die sowohlnach oben als auch
nach unten skalieren: Anwendungen sollen sich auf beliebig viele
Kno-ten verteilen lassen, um Verfgbarkeit und Performance Leistung)
zu gewhrleisten. Sie sollenaber auch auf mobilen Endgerten
einsetzbar sein und Synchronisierung von Benutzerdatenermglichen
[Leh].1.2Aufbau der ArbeitZu Beginn wird die zentrale Fragestellung
der Arbeit deniert (Kapitel ). Das Ziel dieser Arbeitist die
fundierte Beantwortung dieser Frage. Um dies zu ermglichen, wird in
Kapitelzunchsteine Einordnung des zu erstellenden Systems und eine
Analyse der in Frage kommenden L-sungsmglichkeiten
vorgenommen.Kapitelwidmet sich der Datenbank CouchDB. In Abschnitt
. wird diese theoretisch ein-geordnet, in Abschnitt . werden die
Umsetzungsdetails erklrt. In Kapitelwerden weitereTechnologien
vorgestellt, die in die Umsetzung der Anwendung eingeossen sind.
Beschrie-ben werden nacheinander die verwendeten Webtechnologien
(Abschnitt .), Cloud Computing(Abschnitt .) sowie die
untersttzenden Werkzeuge (Abschnitt .).Die Anforderungen an die
Anwendung werden in Kapitelspeziziert. In Kapitelwird dieStruktur
der Anwendung umrissen, auch hierbei werden verschiedene
Designalternativen ge-geneinander abgewogen. Die technischen
Details des fertigen Systems sind in Kapitelskizziert,ergnzt von
Quelltextauszgen im Anhang. Eine Bedienungsanleitung fr die
Anwendung inKapitelschliet den praktischen Teil der Arbeit ab. Eine
Beurteilung des Ergebnisses der Arbeitwird abschlieend in
Kapitelvorgenommen.. Textauszeichnung 1.3TextauszeichnungDie
Informatik ist ein Gebiet, in dem sich viele englische Begrie im
Deutschen eingebrgerthaben. Fr viele dieser englischen Begrie gibt
es noch keine Entsprechung, fr manche werden inder Literatur
unterschiedliche deutsche bersetzungen verwendet. In dieser Arbeit
wird dort, woder englische Begri im Deutschen blicherweise
verwendet wird, der englische Originalbegribeibehalten. Eine
Neubersetzung von englischen Begrien wurde bewusst vermieden. Eine
deut-sche bersetzung ist fr bessere Verstndlichkeit beim ersten
Aureten des Begris in Klammernangegeben. Gibt es im Deutschen einen
passenden Begri, wird die englische Bedeutung beimersten Aureten
des Begris in Klammern angegeben.Zur besseren bersichtlichkeit und
Lesbarkeit dieser Arbeit werden manche Begrie
besondershervorgehoben. Im Text erklrte Fachbegrie sowie Namen von
eingesetzten Technologienwerden bei ihrem ersten Aureten kursiv
gesetzt. Bei erneutem Aureten werden solche Begrienicht besonders
ausgezeichnet. Im Abkrzungsverzeichnis im Anhang A. knnen
verwendeteAbkrzungen nachgeschlagen werden. Begrie aus dem
Quelltext werden bei jedem Vorkommendurch die Verwendung der
Schriart Courier gekennzeichnet. Quelltextauszge sind in
einerTypewriter-Schri gesetzt, als Block gesetzte Quelltextauszge
sind auerdem hell hinterlegt undmit einem Rahmen versehen.
Zitatblcke sind rechts und links eingerckt. Zitate im Flietextsind
in Apostrophe gesetzt.
2AufgabenstellungIn der Einleitung wurde auf die vernderten
Gegebenheiten und erhhten Ansprche an An-wendungsprogramme in der
heutigen Zeit (Juni ) hingewiesen. Mehr Menschen nutzengleichzeitig
mit immer mehr mobilen Endgerten immer grere Systeme und stellen
dabeiimmer hhere Ansprche an Benutzbarkeit und
Verfgbarkeit.Gleichzeitig schreitet die Entwicklung von
Technologien voran, mit der diese gestiegenen Anforde-rungen immer
besser umgesetzt werden knnen. Im Bereich der Datenbanksysteme
entwickeltesich im letzten Jahrzehnt eine Bewegung mit dem Namen
^oSOL [Str]. NoSQL ist einenicht nher eingegrenzte Bezeichnung fr
eine Reihe nichtrelationaler Datenbanksysteme bzw.Key-Value-Stores.
Sie haben gemeinsam, dass sie im Gegensatz zu relationalen
Datenbanken meistkeine festen Tabellenschemata bentigen. Besonderen
Schwerpunkt setzen sie auf Verteilbarkeitund eignen sich dadurch
meist fr die Skalierung im groen Mastab. Die Vorzge
traditionellerDatenbanksysteme, insbesondere die Konsistenz zu
jedem Zeitpunkt, werden o gegen einebessere Verfgbarkeit oder
Partitionstoleranz (s. Abschnitt ..) getauscht.Diese neuen
Datenbanksysteme wurden jeweils fr spezische Anwendungsflle
entwickelt.Ein umfassender Vergleich von NoSQL-Datenbanksystemen
ist nicht Gegenstand dieser Ar-beit. Stattdessen soll die
Einsetzbarkeit eines bestimmten NoSQL-Datenbanksystems anhandeines
konkreten Anwendungsfalles berpr werden. Kann nach eingehender
Analyse mit derausgewhlten Technologie eine funktionsfhige Soware
umgesetzt werden?Die dokumentenorientierte Datenbank CouchDB [Apac]
wurde in der Einleitung bereitskurz vorgestellt. Bei einer mit
CouchDB implementierten Anwendung kann der Einsatz vonMiddleware
vllig entfallen. Master-Master-Replikation ist eine Kernfunktion,
was CouchDBbesonders geeignet fr verteiltes Arbeiten macht.
CouchDB-Anwendungen laufen direkt aus demWebbrowser heraus, deshalb
ist die Anzahl der fr den Betrieb zu installierenden
Programmeminimal. So kann das Systemauf einer mglichst hohen Anzahl
von Endgerten eingesetzt werden.Die Wahl gerade dieses
Datenbanksystems wird in den Kapitelnundgenauer begrndet.Als
Anwendungsfall fr den Einsatz von CouchDB wurde ein Outliner
Gliederungseditor) gewhlt.Mit einem Outliner knnen z. B. Gedanken
oder Konzepte hierarchisch geordnet aufgeschriebenwerden. Als
Vorlage dient das ProgrammOmniOutliner [Omn], ein lokales
Desktop-Programmfr Mac OS X. Ziel ist, einen Gliederungseditor mit
hnlicher, aber eingeschrnkter Funktionalittprototypisch zu
erstellen und dadurch die Einsetzbarkeit von CouchDB zu
analysieren.Die hier konzipierte Anwendung unterscheidet sich in
einem zentralen Punkt von der Vorlage:Mit ihr soll gemeinschaliches
Arbeiten an Dokumenten auch verteilt ber Netzwerke
ermg-Aufgabenstellung licht werden, selbst wenn der Benutzer
zwischenzeitlich vom Internet getrennt ist. Die fr dieArbeit
erstellte Anwendung wird lokal im Browser laufen und oine benutzbar
sein. ber ei-ne Internetverbindung werden Daten von mehreren
Benutzern gleichzeitig bearbeitet werdenknnen.In dieser
Diplomarbeit soll also untersucht werden, ob sich CouchDB dafr
eignet, verteilte An-wendungen zu erstellen. Um dies zu prfen, wird
der Prototyp eines verteilten Gliederungseditorsentworfen und
umgesetzt.
3AnalyseIn Kapitelwurden Anforderungen an ein System grob
skizziert. Entwurf und Implementie-rung dieser Anwendung sowie die
Auswertung des Ergebnisses sind Gegenstand dieser Arbeit.Im
folgenden Kapitel werden die Problemstellungen, die die Anwendung
lsen soll, sowie diewissenschaliche Einordnung der Anwendung noch
einmal nher untersucht. Dann werdenunterschiedliche Lsungsanstze
daraufhin analysiert, mit welchen Mitteln ein solches Systemam
besten umzusetzen ist. Dabei wird auf alternative Anstze
eingegangen.3.1Anforderungen an einen GliederungseditorBevor der
hier gewhlte Lsungsweg von anderen Mglichkeiten abgegrenzt wird,
werden zu-nchst die Eigenschaen und Anforderungen der umzusetzenden
Anwendung genauer festgelegt.3.1.1DefinitionEin Gliederungseditor
oder Outliner wird bei Wikipedia als eine Mischung aus einer
Freiform-Datenbank und einem Texteditor beschrieben [Wika]:An
outliner is a computer program that allows one to organize text
into discretesections that are related in a tree structure or
hierarchy. Text may be collapsed into anode, or expanded and
edited. [Wikc]Manche Gliederungseditoren ermglichen auerdem eine
Formatierung der Eintrge und dasEinbinden von verschiedenen
Medientypen. Es gibt eine Vielzahl von Implementierungen dieserArt
Programm.Eine der am hchsten bewerteten Umsetzungen [Mac] ist die
kommerzielle Soware Om-niOutliner [Omn] (Screenshot s. Abb. A.).
Dieses Programm wird von der Firma OmniGroup fr das Betriebssystem
Mac OS X entwickelt. Es hat neben den blichen Eigenschaeneines
Gliederungseditors noch weitere spezielle Features. OmniOutliner
soll beim Entwurf derAnwendung als Vorlage dienen, wenn auch in
diesemPrototypen lngst nicht alle seine Merkmaleumgesetzt werden
knnen..Anforderungen an Verteilte Systeme
3.1.2EinsatzmglichkeitenDie Einsatzmglichkeiten eines Outliners
sind sehr vielfltig, hnlich wie beispielsweise dieeines
Texteditors. Im Folgenden werden nur einige der mglichen Szenarien
fr die Benutzungeines Outliners vorgestellt. Einige Szenarien sind
an [Wika] angelehnt, einige wurden von derAutorin selbst
festgelegt. Den Entwurfsentscheidungen bei der Sowareentwicklung
liegen dieseAnwendungsflle zugrunde.Der ursprngliche Zweck eines
Gliederungseditors wird in [Wika] als der von
Geisteswissen-schalern hug verwendete Zettelkasten beschrieben:Mehr
oder weniger groe Textabschnitte (z. B. Zitate) werden in einer
nach Kategori-en sortierten und verschlagworteten Datei abgelegt
und stehen so zur Verfgung. [...]Auf diese Weise lsst sich schnell
einumfangreiches Archiv anwichtigenTextpassagenaufbauen.Ein hug
zitierter Anwendungsfall fr Gliederungseditoren ist das Verfassen
von literarischen,journalistischen oder wissenschalichen Texten.
Zuerst kann der Umriss der Handlung struktu-riert nach Kapiteln und
Szenen eingegeben werden. Anschlieend kann der Benutzer Details
indie ste des Gliederungsbaums einpegen. Spter knnen Teile des
Textes verschoben werden,in dem man die Knoten in der Baumstruktur
hin- und herbewegt. Dies ist bei einem Texteditoroder auch einem
Textverarbeitungsprogramm wesentlich schwieriger
umzusetzen.Gliederungseditoren knnen auch immer dann eingesetzt
werden, wenn eine grere Mengekrzerer Textpassagen gespeichert
werden sollen. Dies kann z. B. Aufgaben, Ideen,
Protokolle,Tagebcher oder Einkaufslisten umfassen.3.2Anforderungen
an Verteilte SystemeIn diesem Abschnitt wird zunchst eine Denition
von Verteilten Systemen vorgenommen. Eswird gezeigt, dass es sich
bei der zu erstellenden Anwendung um ein Verteiltes System handelt.
Inden darauolgenden Abschnitten wird dann begrndet, warum CouchDB
fr die Umsetzungeines solchen Systems gewhlt wurde.Eine
vielzitierte Denition ndet sich in [Tan, Kap. .]:Ein Verteiltes
System ist eine Ansammlung unabhngiger Computer, die den Benut-zern
wie ein einzelnes kohrentes System erscheinen.Diese Beschreibung
kann sich auf eine beliebig groe Anzahl von Rechnern beziehen. So
werdenin [Cou, Kap. .] und in [Ben, S. ] auch das Internet bzw. das
World Wide Web als Verteilte.Anforderungen an Verteilte Systeme
Systeme bezeichnet. Es existieren aber auch weitergefasste
Denitionen, in denen nicht nur diepysikalisch verteilte Hardware,
sondern auch logisch verteilte Anwendungen als Verteiltes
Systembezeichnet werden [Ben, S. ]. Nach [Cou, Kap. .] ist es die
grundlegende Eigenscha einesVerteilten Systems, ausschlielich ber
Message Passing zu kommunizieren. Allgemein kanngesagt
werden:Adistributed systemis a systemwhich operates robustly over a
wide network. [And,Kap. ]Ein Systemist demnach ein Verteiltes
System, wenn es in mehrere Komponenten getrennt werdenkann, die
autonom sind - das heit, sie mssen jeweils fr sich wieder ein
vollstndiges Systembilden. Die einzelnen Subsysteme knnen hierbei
sehr inhomogen sein, was Implementierungbzw. Betriebssysteme und
Hardware angeht. Die Art der Verbindung kann ebenfalls
beliebigumgesetzt sein. Auerdem sollte fr Benutzer wie fr
Programme, die das System benutzen, derEindruck entstehen, es mit
einemeinzigen Systemzu tun zu haben. Bei der Entwicklung
VerteilterSysteme stellt sich die Aufgabe festzulegen, wie die
Komponenten des Systems transparent frden Benutzer
zusammenarbeiten. Der innere Aufbau des Systems soll fr den
Benutzer nichtersichtlich sein. Weiterhin soll mit dem System
konsistent und einheitlich gearbeitet werdenknnen, unabhngig von
Zeitpunkt und Ort des Zugris [Tan, Kap. .].Nach [Cou, Kap. .] und
[Tan, Kap. .] mssen beim Entwurf von Verteilten Systemenfolgende
Herausforderungen beachtet werden:Nebenlufigkeit (Concurrency):
Komponenten eines Systems fhren Programmcode neben-lug aus, wenn
sie auf gemeinsam genutzte Ressourcen gleichzeitig lesend und
schreibendzugreifen, sich aber gegenseitig nicht beeinussen. Bei
einem Verteilten System mssendaher auf nebenluge Prozesse
ausgerichtete Algorithmen verwendet werden.Keine globale Uhr: Die
Uhren der Subsysteme lassen sich nicht synchron halten. Fr
Ausungvon Bearbeitungskonikten knnen daher keine Zeitstempel
verwendet werden. MVCCMulti Version Concurrency Control) verwendet
stattdessen o Vektoruhren [Lam] oderandere eindeutige
Identikationsmechanismen wie UUIDs Universally Unique
Identifer)[Lea].Ausfall von Subsystemen: Der Ausfall einer einzigen
Komponente oder eine Strung im Netz-werk drfen das Gesamtsystem
nicht beeintrchtigen. Die Subsysteme mssen unabhngigvoneinander
funktionieren, auch wenn die Verbindung zwischen ihnen zeitweise
oderlnger abbricht, oder eines von ihnen nicht mehr funktioniert.In
Kapitel . wird auf diese Probleme im Detail eingegangen..
Anforderungen an Groupware 3.3Anforderungen an
GroupwareGroupware-Systeme sind nach [Ell] ...... computer-based
systems that support two or more users engaged in a commontask, and
that provide an interface to a shared environment. ese systems
frequentlyrequire ne-granularity sharing of data and fast response
times.Wie bei jedemSoware-Projekt drfenbeimEntwurf eines
VerteiltenSystems nicht nur technischeMglichkeiten eine Rolle
spielen. Ebenso mssen die realen Anforderungen der
angestrebtenBenutzergruppen bei der Planung miteinbezogen werden.
So soll hier der Frage nachgegangenwerden, was die spezischen
Fragen und Probleme bei der Benutzung einer Groupware sind, undwas
demzufolge bei Entwurf, Entwicklung und Schulung besonders zu
beachten ist.Die in dieser Arbeit eingesetzte Datenbank CouchDB
wird o mit Lotus Notes verglichen. DamienKatz, der Ernder von
CouchDB, ist ehemaliger Notes-Entwickler und war nach eigenen
Aussa-gen bei der Entwicklung von CouchDB von Notes stark
inspiriert [Sch]. Notes ist CouchDBinsofern hnlich, als dass eine
Datenbank in Notes eine Sammlung von halbstrukturierten Doku-menten
ist, die durch Views organisiert sind [Kaw, Kap. ]. Nach [Kaw] ist
Lotus Notes einKommunikationssystem, das es Gruppen erlaubt,
unterschiedliche Informationen wie Texte undNotizen zu teilen und
gemeinsam zu bearbeiten:e system supports groups of people working
on shared sets of documents and isintended for use in a personal
computer network environment in which the databaseservers are
rarely connected. [Kaw, Kap. ]Die Parallelen zwischen Lotus Notes
und der hier entwickelten Anwendung liegen also darin, dassletztere
zumindest gleiche Teilaufgaben von Notes erfllen soll. Auerdem
erfolgt die Synchroni-sierung der Dokumente ebenfalls durch
Datenbank-Replikation. Demnach sind wissenschalicheErkenntnisse ber
die Benutzung von Lotus Notes fr die Konzeption der Anwendung
durchausinteressant.Mehrere Studien haben die Auswirkungen der
Einfhrung von Lotus Notes auf die Zusammenar-beit in verteilten
Gruppen untersucht.In [Van] wurde der Einuss von Notes auf die
Zusammenarbeit in einer groen Versicherungs-gesellscha analysiert.
Obwohl die Mitarbeiter mit dem Produkt sehr zufrieden waren,
wurdekeine verstrktere oder bessere Zusammenarbeit unter ihnen
festgestellt. Die Studie kommt zudemSchluss, dass ein Systemsehr
genau zu der Zielgruppe passen muss, und dass der
grndlichenSchulung in dieser neuen Technologie eine zentrale
Bedeutung beikommt.Die Autorin von [Kar] stellt fest, dass
Benutzer, die noch nie vorher mit einer Groupwaregearbeitet haben,
das neue Programm meist wie ein ihnen vertrautes (also lokales
Single-User-).Verschiedene Lsungsanstze Programm benutzen:[e]
ndings suggest that when people neither understand nor appreciate
the co-operative nature of groupware, it will be interpreted as an
instance of some morefamiliar technology and used accordingly. is
can result in counter-productive anduncooperative practice and low
levels of use. [Kar, S. ]Dies wird von einer anderen Untersuchung
besttigt:e ndings suggest that where peoples mental models do not
understand or ap-preciate the collaborative nature of groupware,
such technologies will be intepretedand used as if they were more
familiar technologies, such as personal, stand-alonesoware (e.g., a
spreadsheet or word processing program). [Orl, S. ]Wenn die
Konstruktion der Soware von der Organisationskultur der Gruppe
abweicht, wirddie Soware mit hoher Wahrscheinlichkeit nicht dazu
beitragen, sinnvoll kollektiv genutzt zuwerden. Eine Groupware muss
vielmehr auf die bestehenden Arbeitsablufe innerhalb einerGruppe
angepasst werden, um Arbeitsprozesse zu verbessern. Umfasst die
Aufgabe der SowareKoniktbearbeitung, ist es fr einen Erfolg der
Soware ebenfalls wichtig, dass diese die
blichenKoniktlsungsstrategien des Teams untersttzt. [Mon]Es bleibt
festzustellen, dass eine Soware, mit deren zentralen
Charakteristika die Benutzer nochnicht vertraut sind, zum einen
genau an die Zielgruppe angepasst werden muss. Dies ist beidieser
Aufgabenstellung schwierig, da der Prototyp fr die geplante
Anwendung fr keine genauabgegrenzte Zielgruppe entwickelt wird. Die
Aufgabe der Eingrenzung der Zielgruppe verbleibtfr eine sptere
Entwicklungsphase. Zum anderen muss der Schulung bzw. der
Dokumentationfr die Benutzer eine hohe Bedeutung zu kommen. Die
hier entwickelte Arbeit soll einen Beitragdazu leisten, Menschen an
die verstrkte Kooperation mithilfe von Soware zu
gewhnen.3.4Verschiedene LsungsanstzeIm Folgenden werden
unterschiedliche Lsungsanstze fr die Bearbeitung der
Aufgabenstellungvorgestellt. Vor- und Nachteile bestehender Lsungen
werden diskutiert und die angestrebteAlternative wird
herausgehoben.Das zu lsende Problem ist: Wie knnen Dokumente von
mehreren Benutzern gemeinsambearbeitet werden, auch wenn manche von
ihnen fr lngere Zeit vom Internet getrennt sind?Wie kann das System
auretende Bearbeitungskonikte mglichst automatisch behandeln
odersie in einer fr den Benutzer geeigneten Form zur Lsung
aufbereiten?.Verschiedene Lsungsanstze 3.4.1Manueller Austausch von
DokumentenDas trivialste Verfahren ist das manuelle
Synchronisieren. Dabei werden Dokumente direkt zwi-schen den
einzelnen Benutzern ausgetauscht, z. B. per Email oder FTP, und
nebenlug bearbeitet.Verschiedene Versionen mssen von einem Benutzer
umstndlich per Hand zusammengefhrtwerden, das Resultat dessen muss
selbst wieder ausgetauscht werden. Details knnen hierbeileicht
verlorengehen.Manche Webdienste stellen Netzwerkdateisysteme
bereit, mit dem das Synchronisieren der Datenautomatisch erledigt
werden kann. Der Anbieter Dropbox [Dro] beispielsweise erlaubt
es,Verzeichnisse und Dateien zwischen verschiedenen Rechnern auf
einem Stand zu halten. Trittzwischenzeitlich ein Konikt auf, werden
die verschiedenen Revisionen als einzelne Dateienabgelegt. Es ist
dann wieder Sache des Benutzers, die Konikte
aufzulsen.3.4.2Echtzeit-TexteditorenEin anderer Ansatz, der
zunehmend Verbreitung ndet, sind zentralisierte
Kooperationssystemeber das Internet. Benutzer knnen mit solchen
Webanwendungen meist in Echtzeit gemeinsaman Dokumenten arbeiten.
Beispiele sind Etherpad [Fou], Google Docs [Bel] und das
neuereGoogle Wave [Goo]. In letzterem steht der
Kommunikationscharakter im Vordergrund, dochknnen auch hiermit
lngere Texte gleichzeitig bearbeitet werden. Google Docs hat im
Vergleichzu Google Wave mehr die Eigenschaen eines
Textverarbeitungsprogramms.Desktop-Programme wie der Texteditor
SubEthaEdit [e] zeigen ihre Vorteile auch nur beifunktionierender
Netzwerkverbindung. Mit SubEthaEdit knnen sich Benutzer ber das
Bonjour-Protokoll imlokalen Netz oder ber das Internet nden und
gegenseitig dazu einladen, gemeinsamein Dokument zu bearbeiten.Die
in den beiden vorhergehenden Abstzen vorgestellten Anstze haben
gemeinsam, dass sieentweder nur mit einer Internetverbindung
funktionieren, oder die Koniktbehandlung nuruntersttzt wird, wenn
von allen Clients gleichzeitig eine Verbindung zu einem Server
hergestelltwird. Ansonsten muss das Zusammenfhren der konikthaen
Versionen auch hier wiedermanuell geschehen.Bei manchen hier
vorgestellten Programmen knnen die Tastaturanschlge der anderen
Autorenlive mitverfolgt werden. Dies wird nicht nur positiv
bewertet. In [Man] wird das Arbeiten mitGoogle Wave als like
talking to an overcurious mind reader beschrieben - das
Bewusstsein,dass andere Benutzer einem direkt beim Denken zusehen,
lhmt hierbei den eigenen Gedanken-und Arbeitsuss. Auch bei
Anwendungsfllen, bei denen Benutzer lnger an einem
einzelnenDokument arbeiten und dadurch eine Art Besitzanspruch
entsteht, fllt es unter Umstndenschwer, die nderungen am eigenen
Text live mitansehen zu mssen [Edl]..Verschiedene Lsungsanstze Da
die zu entwickelnde Anwendung durchaus auch fr das Arbeiten an
lngeren Texten vorgese-hen ist, kann auf das Feature Live-Typing
verzichtet werden.3.4.3VersionsverwaltungssystemeIm Bereich der
Sowareentwicklung ist schon lange der Einsatz von
Versionsverwaltungssyste-men wie Subversion [Apab] oder Git [Cha]
weit verbreitet. Mit solchen Systemen werdennderungen an Dokumenten
mitsamt Autor und Zeitstempel erfasst und in einzelnen
Commitsgespeichert. Die Versionen knnen spter wiederhergestellt
werden. Ebenfalls knnen mehrerenderungen von unterschiedlichen
Benutzern an einer einzigen Datei vom System
automatischzusammengefhrt werden.Ein solches System ist fr reine
Textdateien sehr zweckmig. Deshalb werden solche
Programmehauptschlich fr Soware-Verwaltung eingesetzt. Gngige
Implementierungen haben aber keinInterface, das sich auch an
weniger technisch versierte Menschen richtet. Die Umsetzung
einerAnwendung mit beispielsweise einem Git-Backend ist aber eine
erwgenswerte Option.3.4.4DatenbankenEs liegt nahe, einen Ansatz mit
Datenbanken, insbesondere den in Kapitelvorgestellten
neuenschemalosen Datenspeicher in Betracht zu ziehen. Einige
Datenbanken oder Key-Value-Stores un-tersttzen
Master-Master-Replikation und speichern die Daten auf der
Festplatte. Diese kommengrundstzlich fr die Lsung der Aufgabe in
Betracht.Die dokumentenorientierte Datenbank CouchDB unterscheidet
sich von den Alternativen da-durch, dass sie einen eigenen
Webserver mitbringt. Mit diesem knnen nicht nur die
Datenausgeliefert, sondern auch in der Datenbank gespeicherte
JavaScript-Dateien direkt ausgefhrtwerden. Dadurch kann die gesamte
Anwendung in der Datenbank laufen. Das resultierende Pro-gramm ist
dadurch automatisch von jedem Rechner bedienbar, auf dem CouchDB
installiert ist,und der ber einen Browser verfgt. Diese Eigenschaen
bringt keine der anderen untersuchtenDatenbanken mit.Die freien
relationalen Datenbanken PostgreSQL [Groa] und MySQL [Cora] knnen
fr Master-Master-Replikation zwischen zwei Mastern konguriert
werden. Fr PostgreSQL existieren eineVielzahl an Erweiterungen
[Grob], mit denen sich unter anderem ein
Master-Master-Setupeinrichten lsst. MySQL bedient sich dazu der
Technik MySQL-Cluster [Cord], die Master-Master-Replikation mit
einer Shared-Nothing-Architektur ermglicht [Sto, Kap. ]. Unter
[Max] istbeschrieben, wie eine Replikation auch zwischen mehreren
Knoten umgesetzt werden kann.. Beschreibung des gewhlten
Lsungsansatzes Der Key-Value-Store Riak [Bas] hat ebenfalls ein
HTTP-Interface und speichert seine Datenverteilt - es handelt sich
dabei aber nicht um Peer-to-Peer-Replikation wie in CouchDB,
sondernumein Autobalancing fr bessere Verfgbarkeit und Performance
Leistung) in greren Systemen.MongoDB [g] untersttzt beschrnkt
Master-Master-Replikation und ermglicht EventualConsistency (vgl.
Abschnitt ..), was sich fr ein verteiltes Konzept anbietet. Die
Fhigkeit vonCouchDB, Anwendungslogik direkt in der Datenbank bzw.
im Browser auszufhren, ist aberauch hier nicht vorhanden. Beide
Technologien sind deshalb weniger gut als CouchDB fr dieUmsetzung
der geplanten Anwendung geeignet.Replikation und Clustering in den
beschriebenen Systemen sind in etwa vergleichbar mit
derFunktionalitt von CouchDB-Lounge, die in Abschnitt . beschrieben
ist. Automatische Markie-rung von Konikten untersttzt ebenfalls
keines der Systeme. Fr die Umsetzung der Replikationinnerhalb der
Anwendungslogik bietet sich deshalb keiner dieser Anstze an.Im
direkten Vergleich wird deutlich, dass sich CouchDB am besten fr
die Lsung der obengenannten Probleme eignet, da es Mglichkeiten zur
Master-Master-Replikation, Koniktbe-handlung sowie ein passendes
Konsistenz-Modell mitbringt, und Anwendungen direkt von
derDatenbank ausgeliefert werden knnen. Im nchsten Abschnitt wird
der gewhlte Lsungsansatznoch nher beschrieben.3.5Beschreibung des
gewhlten LsungsansatzesDie Anwendung wird als lokales, aber
netzwerkfhiges Programm erstellt. Die Daten werdendabei in einer
CouchDB-Datenbank gespeichert, die Anwendungslogik wird als
clientseitigesJavaScript im Browser ausgefhrt. Der Funktionsumfang
des Gliederungseditors wird mindestensdas Erstellen und Lschen von
Outlines umfassen; zeilenbasiert kann Text eingetragen und
editiertwerden; Zeilen werden beim Verlassen automatisch
gespeichert und knnen ein- und ausgercktwerden.Der Austausch der
Daten sowie der Anwendung geschieht ber die in CouchDB
eingebauteMaster-Master-Replikation. Hierbei drfen die Daten auf
allen Rechnern, die eine Kopie haben,gleichberechtigt verndert
werden. Auf einem Server lu eine weitere CouchDB-Instanz.
DieReplikation zu diesem Server erfolgt automatisch, sobald von
einem Benutzer dem Dokumentetwas hinzugefgt wird. Weitere Benutzer
knnen die gesamte Anwendung in die CouchDB-Installation auf ihrem
Rechner herunterladen. Wenn eine Internetverbindung besteht,
werdenUpdates an den Daten automatisch zum Server repliziert, und
von ihm an weitere Benutzerweitergegeben, die gerade online sind.
Die Anwendung benachrichtigt den Benutzer, sobaldnderungen
vorliegen. Er kann sich diese dann durch ein Neuladen der Seite
anzeigen lassen.Die zentrale Aufgabe wird der Umgang mit
Bearbeitungskonikten in den Daten sein, die durch. Beschreibung des
gewhlten Lsungsansatzes das gleichzeitige Bearbeiten entstehen
knnen. Gerade wenn ein Benutzer lngere Zeit oine istund dann
repliziert, mssen durch Andere vernderte oder neu dazugekommene
Zeilen eingefgtoder aktualisiert werden. CouchDB kann von sich aus
auf aufgetretene Konikte hinweisen. DieEntscheidung, wie diese
Konikte angezeigt und/oder automatisch gelst werden knnen, mussaber
beim Design der Anwendung getroen werden. Da der begrenzte
Bearbeitungszeitraum diesnicht zulsst, werden nicht alle
mglicherweise auretenden Konikte bercksichtigt. Stattdessenwerden
einige Koniktarten exemplarisch untersucht.Des Weiteren werden
Deployment und Skalierungsmglichkeiten mit dem Clustering
Frame-work CouchDB-Lounge und Amazon Elastic Compute Cloud (Amazon
EC) untersucht. DieAnwendung wird prototypisch deployt,
Mglichkeiten zur Umsetzung einer hohen Verfgbarkeitdes Servers
werden beschrieben.
4CouchDB - eine Datenbank frVerteilte SystemeNachdem der gewhlte
Lsungsansatz im vorherigen Kapitel begrndet und kurz skizziert
wurde,sollen in diesem und im nchsten Teil die fr die Umsetzung der
Aufgabenstellung verwendetenTechnologien und Konzepte vorgestellt
werden.Im Mittelpunkt des Kapitels steht die ausfhrliche
Darstellung der verwendeten DatenbankCouchDB. Apache CouchDB
Cluster of unreliable commodity hardware Data Base) ist ein
doku-mentenorientiertes Datenbanksystem[Apac]. CouchDB wird seitals
Open-Source Projektentwickelt und ist seit Novemberein ozielles
Projekt der Apache Soware Foundation[Apad]. CouchDB wurde
ursprnglich in C++ geschrieben, wird aber seitgrtenteils inder
Programmiersprache Erlang [Eri] entwickelt. Erlang wurde Ende der
er Jahre des letztenJahrhunderts fr Echtzeitsysteme wie
Telefonanlagen entworfen und zeichnet sich infolgedessendurch hohe
Fehlertoleranz, Parallelitt und Stabilitt aus [Len]. Das
Erlang/OTP-System (THeOpen Telecom Platform) umfasst neben der
Programmiersprache Erlang auch Bibliotheken unddas
Laufzeitsystem.Im ersten Teil dieses Kapitels werden die
theoretischen Grundprinzipien von CouchDB erlutert.Der zweite Teil
ist der Beschreibung der Datenbank aus der Sicht der
Anwendungsentwickleringewidmet.4.1Theoretische EinordnungUm die
Motivation fr die Entwicklung von CouchDB zu verstehen, wird
zunchst kurz aufdie jngere Geschichte der Datenbanksysteme
eingegangen und CouchDB im Hinblick auf dieDrei-Schema-Architektur
(s. Abschnitt ..) eingeordnet. Danach werden das CAP-eorem undder
Umgang von CouchDB mit nebenlugen Transaktionen vorgestellt sowie
die RESTfulnessder HTTP-Schnittstelle untersucht. Des Weiteren wird
der Unterschied im Ansatz von CouchDBim Vergleich zu traditionellen
relationalen Datenbanken dargestellt. Dabei werden die
einzelnenAspekte von Aufbau, Eigenschaen und Funktionen angerissen,
die dann im weiteren Verlaufdieses Kapitels ausfhrlich beschrieben
werden.. eoretische Einordnung 4.1.1Einordnung der
Datenbankarchitektur entwarf das Standards Planning and
Requirements Committee SPARC) des American ^ationalStandards
Institute A^SI) ein Modell, das Anforderungen an den Aufbau eines
Datenbanksys-tems beschreibt [H]). Dieses Modell wird
A^SI-SPARC-Architektur oder auch Drei-Schema-Architektur genannt.Fr
die Benutzer einer Datenbank sollten nderungen in den unteren
Ebenen, also von Hardware,interner Speicherstruktur oder logischer
Struktur, keine Auswirkungen haben [Cod, S. ]. Isteine Datenbank
nach der Drei-Schema-Architektur aufgebaut, wird die Sicht der
Benutzer aufdie Datenbank von der technischen Umsetzung getrennt.
Die interne Datenspeicherung wirdalso transparent fr die
Benutzer.Nach [Mat, Kap. .], lassen sich die drei Ebenen des
Schemas wie folgt unterteilen:Externe Schemata/Benutzersichten:
Teilbereiche der Datenbank sind fr verschiedene Be-nutzergruppen
freigegeben. Hier knnen abgeleitete Daten eingetragen werden, ohne
dassdie zugehrigen Grunddaten sichtbar gemacht werden
mssen.Konzeptionelles Schema: Diese Ebene enthlt die Beschreibung
aller Datenstrukturen fr dieDatenbank, also die Datentypen und
-verknpfungen. Dabei ist unerheblich, auf welcheWeise die Daten
abgelegt werden. Das konzeptionelle Schema ist sehr stark von
Datenbank-entwurf und benutztem Datenmodell abhngig.Internes
Schema: Hier sind die Einzelheiten der physischen Datenspeicherung
festgelegt, alsodie Aueilung der Datenbank auf verschiedene Rechner
oder Festplatten, oder Indizes zurBeschleunigung der Zugrie.Diese
Architektur kann unabhngig von der Frage angewendet werden, ob das
dem Datenbank-system zugrunde liegende Datenbankmodell relational,
objektorientiert, netzwerkartig oder aneinem anderen Modell
orientiert ist.CouchDB lsst sich ebenfalls dem ANSI-SPARC-Standard
gem beschreiben. Den externenSchemata entsprechen dabei die
CouchDB-Views. Das konzeptionelle Schema ist hier die
Repr-sentation der Dokumente als JSON-Objekte, also die
Gesamtansicht der Datenbank. Das interneSchema ist die Art und
Weise der Datenspeicherung, die bei CouchDB ber einen
B+-BaumB+-Tree) umgesetzt wird. Diese drei Schichten werden in
spteren Abschnitten dieses Kapitelsdetailliert beschrieben..
eoretische Einordnung 4.1.2Das CAP-TheoremCAP steht fr Consistency
Konsistenz), Availability Verfgbarkeit) und Partition Tolerance
Parti-tionstoleranz). Bei der Modellierung von Verteilten Systemen
ist der Begri der Partitionstoleranzvon groer Bedeutung [Var, S. ].
Er besagt, dass Subsysteme auch bei physikalischer Tren-nung und
Verlust einzelner Nachrichten untereinander autonom weiter
funktionieren knnenmssen. Eine Operation auf dem System muss auch
dann erfolgreich durchgefhrt werden, wennein Teil der Komponenten
nicht erreichbar ist. Ein Verteiltes System muss jedoch noch
zweiweitere Anforderungen erfllen: Konsistenz ist gegeben, wenn
alle Komponenten zur selben Zeitdie gleichen Daten sehen.
Verfgbarkeit bedeutet, dass das System auf jede Anfrage eine
Antwortsendet, mit einer denierten und niedrigen Latenz. Die
folgende Darstellung, sofern nicht andersangegeben, basiert auf
[Gil, S. -] und [And, Kap. ].Professor Brewer von der University of
California hat mit dem CAP-eorem die Annahmeformuliert, dass die
drei Eigenschaen Konsistenz, Verfgbarkeit und Partitionstoleranz
zwar vonWeb Services erwartet werden, es aber in der Realitt nur
mglich ist, zwei der drei Ansprchezu erfllen [Bre]. Da
Partitionstoleranz bei Verteilten Systemen unabdingbar ist, muss
beimEntwurf die Entscheidung zwischen Konsistenz und Verfgbarkeit
getroen werden.In traditionellen Relationalen Datenbanksystemen
(RDBMS) kann Konsistenz meist vorausgesetztwerden, da diese
standardmig die ACID-Kriterien (Atomizitt, Konsistenz, Isolation,
Dauerhaf-tigkeit) erfllen. Vollstndige Konsistenz meint in diesem
Kontext die Eigenscha, dass auf einenSchreibzugri folgende
Lesezugrie sofort auf die aktuellen Daten zugreifen knnen. Dies
wirdals One-Copy-Serializability oder auch Strong Consistency
bezeichnet [Mos]. In RDBMS wirddies durch Locking-Mechanismen
erzwungen (s. Abschnitt ..). In einem Verteilten System, indem
Daten auf mehr als einem Rechner verteilt sind, gestaltet sich die
Umsetzung von Konsistenzschwieriger. Verschiedene in den letzten
Jahren entwickelte nichtrelationale Datenspeicher wie et-wa
Bigtable [Cha], Hypertable [Hyp], HBase [Apai], MongoDB [g] und
MemcacheDB[Mem] entscheiden sich trotzdem fr die absolute
Konsistenz und gegen eine Optimierungder Verfgbarkeit.Andere
Projekte wie Cassandra [Apaa], Dynamo [Vog], Project Voldemort
[Pro] undCouchDBlegen ihre Schwerpunkte stattdessen auf
Verfgbarkeit. Dabei greifen sie auf unterschiedlicheStrategien
zurck, wie Konsistenz trotzdem umgesetzt werden kann. Durch einen
sog. ConsensusAlgorithm wie Paxos [Lam] kann garantiert werden,
dass Komponenten auch dann zur gleichenLsung fr einen Konikt
kommen, wenn keine Verbindung zwischen ihnen besteht [Pea].Ein
anderer Ansatz ist der Einsatz von Time-Clocks, mit denen eine
Sortierung von Daten inVerteilten Systemen umgesetzt werden kann
[Lam].Die Strategie von CouchDB unterscheidet sich von den meisten
anderen, weil sie neben Ver-fgbarkeit und Partitionstoleranz
Eventual Consistency vorsieht. Diese besagt, dass in einem.
eoretische Einordnung beschrnkten Zeitfenster zwischen Schreib- und
Lesezugri auf ein DatumInkonsistenzen (Wider-sprche) aureten knnen.
Innerhalb dieses Zeitraums werden womglich noch die alten
Datenausgegeben, danach jedoch spiegeln alle Lesezugrie das
Resultat des Schreibzugris wieder. Beiauretenden Fehlern oder hoher
Latenz knnen Datenstze also zeitweise inkonsistent erscheinen,die
Konsistenz der Daten ist nur schlussendlich gegeben:e storage
systemguarantees that if no newupdates are made to the object,
eventuallyall accesses will return the last updated value.
[Vog]Eventual Consistency ist nicht fr alle Bereiche ein
praktikables Konzept. Wenn Benutzereingabenstark aufeinander
aufbauen, also die Eingaben voneinander abhngen und die Benutzer
zeitweiseauf veralteten Daten arbeiten, knnen sich Fehler kumulativ
fortpanzen und die Konsistenzdes Gesamtsystems ist kompromittiert
(bspw. im Finanzsektor). Mit CouchDB knnen daherebenfalls Systeme
mit Strong Consistency umgesetzt werden. Bei vielen Anwendungen
jedochist es von grerer Bedeutung, dass ein Update jederzeit
erfolgreich durchgefhrt werden kann,ohne dass die Datenbank
blockiert ist (bspw. bei einem Social ^etwork oder beim
vorliegendenAnwendungsfall).4.1.3Transaktionen und
NebenlufigkeitJedes Datenbanksystem, das fr mehrere Benutzer
ausgelegt ist, muss sich mit Fragen der Neben-lugkeit beschigen.
Beantwortet werden muss die Frage was passiert, wenn zwei
Benutzergleichzeitig versuchen, denselben Wert zu verndern.
Gleichzeitig meint hier nicht den exaktselben Zeitpunkt. Eine
Operation, die Lesen, ndern und Zurckspeichern eines Datums
umfasstund die eine gewisse Zeit dauert, kann ein Problem mit
Nebenlugkeit verursachen, wenn einanderer Benutzer eine ebensolche
Operation innerhalb dieser Zeitspanne beginnt und dabei denvom
ersten Benutzer zwischenzeitlich genderten Wert berschreibt. Die
Aufgabe der Datenbankist es, eine solche Operation serialisierbar
zu machen: Die beiden beschriebenen Operationensollen dasselbe
Ergebnis haben, wie wenn sie nacheinander stattgefunden htten [Var,
S. ].Auch wenn es hier um sehr kurze Intervalle geht und Koniktflle
in der Praxis unwahrscheinlichscheinen, mssen diese von vornherein
in Design und Architektur einbezogen werden [Vog].Bei dem von RDBMS
hauptschlich benutzten Locking belegt eine Operation die
Ressourcen,die sie ndern mchte, mit einer Sperre. Andere
Operationen mssen auf die Aufhebung dieserSperre warten, dann haben
sie exklusiven Zugri auf die Daten. Locking ist fr
nichtverteilteDatenbanksysteme eine Herangehensweise mit guter
Performance [Var, S. ]. Operationenmssennicht warten, nur weil sie
nebenlug sind. Andererseits ist Locking voneinigemOverheadbegleitet
und schwer umzusetzen, wenn die Teilnehmer der Transaktion verteilt
sind. Es existierenProtokolle, die auch in Verteilten Systemen
Sperren setzen und ausen knnen [Ber], diesesind allerdings langsam
und fr die umzusetzende Anwendung unpraktikabel.. eoretische
Einordnung CouchDB verwendet daher zur Kontrolle von Nebenlugkeit
eine Umsetzung von OptimisticConcurrency, die sogenannte
Multi-Version Concurrency Control MVCC):MVCC takes snapshots of the
contents of the database, and only these snapshots arevisible to a
transaction. Once the transaction is complete, the modications that
weredone are applied to the newest copy of the relation and the
snapshot is discarded.is means that in any given time multiple
dierent versions of the same data exists.[Par, Kap. .]MVCC bringt
Vorteile bei Verfgbarkeit und Performance, dafr sehen Benutzer
teilweise in-konsistente Daten. Es gibt mehrere Wege, diesen
Mechanismus umzusetzen. Entweder knnenmit Zeitstempeln oder
Vektoruhren die Modikationszeiten von Transaktionen und dadurchdie
Gltigkeit eines Updates bestimmt werden. Das Update wird dann
entweder zugelassen oderzurckgewiesen. In [Lam] ist dies nher
beschrieben. Bei CouchDB werden den Objekten keineVektoren
zugewiesen, sondern eine UUID und eine Revisionsnummer. Auerdem
verwendetCouchDB das Copy-On-Vrite-Verfahren, bei dem zwei Prozesse
nie auf einen Eintrag zugreifen,sondern ihn hintereinander in ein
Log schreiben. Felix Hupfeld beschreibt in [Hup, Kap. .]einen
Log-based Storage Mechanismus, siehe auch [Joh]:e basic
organization of a log structured storage system is, as the name
implies, alog - that is, an append-only sequence of data entries.
Whenever you have new datato write, instead of nding a location for
it on disk, you simply append it to the endof the log.Genau dieser
Mechanismus wird in CouchDB angewendet, wenn die Versionen von
Dokumentenin Revisionen oder auch die Daten im B+-Baum gespeichert
werden. Dies wird in Abschnitt ..genauer erklrt.Der Nachteil von
MVCC ist, dass zustzliche Schichten von Komplexitt in der
Anwendungslo-gik bearbeitet werden mssen, die ein RDBMS still
behandeln wrde. CouchDB bietet hierfrMglichkeiten, die in Abschnitt
.. erklrt werden. In [Var, S. ] wird dies jedoch als
Vorteildiskutiert: Mit RDBMS werden Anwendungen so entworfen, dass
bei steigendem Durchsatzleicht Bottlenecks (Engpsse) entstehen, die
dann nicht mehr beseitigt werden knnen. MVCCuntersttzt die
Entwickler darin, von Anfang an mgliche Koniktquellen sauber zu
behandeln.Dadurch wird ein Zuwachs der Zugriszahlen die Performance
der Anwendung weniger wahr-scheinlich beeintrchtigen. Auch unter
hoher Last kann die Rechenleistung des Servers vollausgelastet
werden, ohne dass auf gesperrte Ressourcen gewartet werden muss,
Requests werdenparallel ausgefhrt.. eoretische Einordnung
4.1.4ReplikationAllgemein werden mithilfe von Replikation Daten
zwischen Komponenten eines Verteilten Sys-tems synchronisiert. Bei
CouchDB bedeutet dies, dass der Inhalt einer Datenbank in eine
anderebertragen wird; Dokumente, die in beiden Datenbanken
existieren, werden auf denselben Standgebracht. Replikation lsst
sich anhand mehrerer Dimensionen einteilen:4.1.4.1Conservative oder
Optimistic ReplicationDie vielleicht wichtigste Designentscheidung,
die bei dem Konzept Replikation getroen werdenmuss, ist die Frage
nach dem Umgang mit nebenlugen Updates: Wie soll sich das
Systemverhalten, wenn verschiedene Repliken dasselbe Datum
gleichzeitig aktualisieren wollen? Aufdiese Frage wurde bereits in
Abschnitt .. nher eingangen. [Guy, Kap. ] nennt zwei
Her-angehensweisen: Bei Conservative oder nach [Sai] Pessimistic
Replication muss die Konsistenzvor jedem Update berpr werden. Ein
Update wird abgelehnt, wenn es nebenlug stattndet.Fr den
vorliegenden Anwendungsfall ist diese Strategie nicht umsetzbar, da
die Repliken nichtdauerha verbunden sind. Stattdessen setzt CouchDB
eine Optimistic Replication um [Sai, S.].Bei Optimistic Replication
werden nderungen an replizierten Datensets akzeptiert, ohne dass
dieRepliken sich im gleichen Moment darber abstimmen mssen oder ein
Locking-Mechanismuseingesetzt wird. Die dadurch entstehenden
Konikte an den replizierten Daten zu bearbeitenist Sache des
Systems. CouchDB untersttzt dies durch automatische Konikterkennung
und-markierung, dies wird in Abschnitt ..
beschrieben.4.1.4.2Client-Server- oder Peer-to-Peer-ModellNach
[Guy, Kap. ] wird bei Replikation nach dem Client-Server-Modell ein
Update zuersteinem Server mitgeteilt, der es dann an alle Clients
ausliefert. Das System wird dadurch simpler.Allerdings ist das
System an einen nie ausfallenden Server gebunden. Replikation nach
demPeer-to-Peer-Modell erlaubt es den Repliken, sich gegenseitig
ihre Updates mitzuteilen. Dadurchknnen Updates zum einen schneller
verbreitet werden: Sobald Konnektivitt vorhanden ist, egalzwischen
welchen Komponenten, kann diese genutzt werden. Eine
CouchDB-Installation kannmit jeder anderen CouchDB-Instanz in beide
Richtungen Master-Master-Replikation betreibenund ist daher fr
beide Modelle geeignet. Welche Strategie umgesetzt werden soll,
hngt vomkonkreten Anwendungsfall ab.. eoretische Einordnung
4.1.4.3BenachrichtigungstrategienBei den Benachrichtigungstrategien
[Guy, Kap. ] wird zwischen Immediate Propagation undPeriodic
Reconsiliation unterschieden. Bei Immediate Propagation werden die
anderen Repli-ken sofort nach einem Update benachrichtigt. Bei
Periodic Reconsiliation werden die Replikenregelmig, zu einer
passenden Zeit, ber stattgefundene Updates benachrichtigt.
CouchDBuntersttzt beide Benachrichtigungstrategien. Da das hier zu
erstellende System einen Betriebauch ohne Netzverbindung erlaubt,
muss es eine Form von Periodic Reconsiliation untersttzen,da
Immediate Propagation fehlschlagen wird, wenn Knoten oine
sind.4.1.4.4Eager oder Lazy ReplicationWeiterhin nimmt Jim Gray in
[Gra, Kap. ] eine Einteilung in Eager Replication und
LazyReplication vor. Bei ersterer werden alle Repliken immer sofort
aktualisiert, sie mssen also immerverbunden sein. Dies ist fr den
in dieser Arbeit behandelten Anwendungsfall nicht praktikabel:In
Systemen, die ber Weitverkehrsnetze kommunizieren oder mobile
Endgerteeinschlieen, mu das Replikationssystem mit groen
Kommunikationslatenzenumgehen knnen. Deshalb werden in solchen
Systemen in der Regel nur asynchroneReplikationsalgorithmen [...]
eingesetzt. [Hup, S. IV]Die Replikation von CouchDB ist demnach
lazy - Updates werden asynchron verbreitet. Durchden
Replikationsalgorithmus von CouchDB kann eine CouchDB-Instanz die
nderungen eineranderen dann anfordern, wenn zwischen beiden eine
Verbindung besteht.4.1.5HTTP-SchnittstelleIn [KT] wird fr
dezentrale und unabhngige Verteilte Systeme der Architekturstil
RESTRepresentational State Transfer) empfohlen. REST-konform oder
RESTful ist eine Schnittstelle,mit der ber HTTP [Fie] Daten
bertragen werden knnen, wenn jede Ressource mit einereigenen URL
angesprochen werden kann [Fie]. Weitere Vorgaben sind die
Zustandslosigkeit desProtokolls, wohldenierte Operationen, und die
Mglichkeit, unterschiedliche Reprsentationeneiner Ressource
anzufordern.Nicht alle APIs Programmierschnittstellen), die RESTful
genannt werden, die also angeblichdem REST-Architekturstil
entsprechen, sind zurecht so eingeordnet. In der von NORD
SowareConsulting vorgenommenen Klassizierung von HTTP-basierten
APIs [NOR] wird zwischenverschiedenen Stufen von RESTfulness
unterschieden. Die meisten APIs fallen demnach in dieKategorien
HTTP-based Type I, HTTP-based Type II oder REST. APIS, die in die
ersten. eoretische Einordnung beiden Kategorien eingeordnet sind,
verletzen eine der REST-Einschrnkungen, da Client undServer durch
das Schnittstellendesign fest aneinander gekoppelt sind.Dies tri
auch auf die API von CouchDB zu, obwohl diese z. B. in [Apab] als
RESTful be-zeichnet wird. Nach [NOR] muss eine RESTful API keine
dierenzierte Dokumentation ent-halten, stattdessen wrde eine
Aufzhlung der verfgbaren Medientypen und Felder gengen.Die
CouchDB-API kann nach dieser Studie auch nicht in die Kategorie
HTTP-based Type IIeingeordnet werden, da ein generischer Medientyp
verwendet wird, der die Ressourcen nichtselbsterklrend macht. Da
die API allerdings korrekt bezeichnete Methodennamen in den
URIsverwendet, kann sie als HTTP-based Type I bezeichnet werden.In
[And, Kap. ] wird die eingeschrnkte RESTfulness von manchen Teilen
der API besttigt.Beispielsweise hnelt die API fr die Replikation
traditionellen Remote Procedure Calls. Eineausschlielich lose
Kopplung, wie es die REST-Architektur vorsieht, ist bei einer
Datenbank-API jedoch nicht unbedingt ntig [NOR]. Trotzdem kann die
API von CouchDB mithilfeder in Abschnitt .. erwhnten show- und
list-Funktionen auch HTTP-based Type II- undREST-konform gemacht
machen.4.1.6Abgrenzung zu relationalen DatenbanksystemenDas
relationale Datenmodell wurde Anfang der er Jahre von Edgar Codd
[Cod] erstmals wis-senschalich beschrieben. IBMund Oracle
implementierten Ende der er Jahre die ersten daraufbasierenden
Datenbanksysteme. Datenbanken liefen zu dieser Zeit noch auf
einzelnen, nichtvernetzten Grorechnern. Diese mussten regelmig
grere Operationen ausfhren, die vielDatenbanklogik erforderten
[Leh]. Bei jeder dieser Operationen datenbankweit die Konsistenzzu
berprfen stellte kein Problem dar, da die Operationen einfach
nacheinander abgearbeitetwurden [And, Kap. ]. Daten wurden durch
physische Backups gegen Verlust abgesichert,Replikation kam erst
spter auf. RDBMS sind fr eine solche Nutzungsweise
optimiert.4.1.6.1Replikation und KonfliktbehandlungAb Anfang der er
Jahre setzten sich relationale Datenbanksysteme auch in anderen
Anwen-dungsbereichen immer mehr durch. Die Einsatzszenarien sehen
allerdings heute o anders ausals damals: Im Bereich der
Internetanwendungen mssen Server meist eine Vielzahl
einzelnerAbfragen gleichzeitig abarbeiten. Das Verhltnis zwischen
Komplexitt der Abfragen und Anzahlder Zugrie hat sich stark
verndert. Hinzu kommt die bei Verteilten Systemen
unweigerlichaufkommende Frage nach der Umsetzung von Replikation
und Koniktlsungsstrategien.Trotz dieser Nachteile wird zur
Implementierung von Webanwendungen heute die relationaleDatenbank
MySQL [Cora] mit Abstand am hugsten eingesetzt [Alf, S. ].
Replikation bei. eoretische Einordnung MySQL ist nach dem Prinzip
des Log Replay aufgebaut [Corc]. In einem Master-Master-Setuptreten
jedoch regelmig nebenluge, sich widersprechende Schreibzugrie auf.
Wenn die Da-tenbank Inkonsistenzen nicht deniert behandelt, mssen
die Konikte mit selbst zu erstellendenDatenbankfunktionen oder
Anwendungslogik gelst werden [Max]. Die Replikationsstrategievon
CouchDB dagegen ist inkrementell, auch bei Verbindungsabbruch
whrend des Replikati-onsvorgangs bleiben die Daten stets in einem
konstanten Zustand. Dies wird in Abschnitt ..erlutert. Die Fhigkeit
von CouchDB, mit nebenlugen Updates und entstandenen
Koniktenumzugehen, wird in Abschnitt .. dargelegt, und ist in
Abschnitt .. durch die Darstellungder Implementierung von CouchDB
erklrt.4.1.6.2Keine MiddlewareCouchDB wurde entwickelt, um den
vernderten Ansprchen und heutigen Anforderungen aneine Datenbank fr
Webanwendungen gerecht zu werden - [it is] built of the web
[Kap].Die mit CouchDB umgesetzten Konzepte sind nicht neu. In [Ass,
S. ] wurde beschrieben,wie sich statische Webanwendungen der ersten
Generation zum bisher verbreiteten Modellweiterentwickelten:
Datenbank- und Anwendungsentwicklung wird vllig getrennt
vorgenommen,zur Kommunikation mit den Anwendern werden Interfaces
wie CGI [WC] eingesetzt. DerEinsatz von Middleware ist dabei ntig,
um ...... ausgehend von den vorhandenen Schnittstellen gngiger
Web-Server und Daten-banksysteme den bergang zwischen den Systemen
fr einen Entwickler so einfachund transparent wie mglich [zu]
gestalten. [Ass, S. ]Fr die Zukunder sog. Internetdatenbankenwurde
in[Ass, S. ] vorausgesagt, dass diese nichtnur Zugri auf die Daten
ermglichen, sondern auch die Interaktion mit
demAnwendungssystemeinbeziehen mssen. Bei einer mit CouchDB
erstellten Anwendung kann diese Middlewareentfallen. Stattdessen
kann ein Anwendungsprogrammdirekt mit der Datenbank
kommunizieren.Dies geschieht ber eine HTTP-API, die in Abschnitt ..
vorgestellt wird. Auf diese Weiseknnen stabile Anwendungen mit
vergleichsweise geringem Aufwand umgesetzt
werden.4.1.6.3SchemalosigkeitViele der Probleme beimEntwurf einer
modernen Webanwendung (vgl. Kapitelund .) beinhal-ten
unvorhersehbares Verhalten der Benutzer und Input von einer groen
Menge von Menschenmit einer groen Menge von Daten [Var, S. ]. Dies
umfasst beispielsweise die Suche imInternet, das Erstellen von
Graphen in Social Networks, Auswertung von Kaufgewohnheiten
etc.Diese Aufgaben bringen o unbersichtliche Datenstrukturen mit
sich, die vorher nur schwer. eoretische Einordnung genau deniert
und modelliert werden knnen. Laut [Bar] sind solche Daten fr die
Abbildungals relationale Datenstrukturen nicht gut geeignet:RDBMSs
are designed to model very highly and statically structured data
which hasbeen modeled with mathematical precision. Data and designs
that do not meet thesecriteria, such as data designed for direct
human consumption, lose the advantagesof the relational model, and
result in poorer maintainability than with less
stringentmodels.Eine dokumentenorienterte Datenbank besteht aus
einer Reihe von unabhngigen Dokumenten;alle Daten fr ein Dokument
sind in diesem selbst enthalten:In fact, there are no tables, rows,
columns or relationships in a document-orienteddatabase at all. is
means that they are schema-free; no strict schema needs to bedened
in advance of actually using the database. If a document needs to
add a neweld, it can simply include that eld, without adversely
aecting other documents inthe database. [Len]Die Schemalosigkeit
von CouchDB ist fr die Umsetzung des Prototypen zwar relevant, fr
dieKonzeption aber nicht zentral. Dies kann sich aber in spteren
Versionen der Anwendung andersdarstellen, wenn der
Gliederungseditor mehrere Spalten mit unterschiedlichen Datentypen
undMedien enthalten wird (vgl. Kapitel ).4.1.6.4Unique
IdentifiersIn relationalen Datenbanken werden Zeilen einer Tabelle
blicherweise mit einemPrimrschlsselidentiziert, der o durch eine
auto-increment-Funktion bestimmt wird [Len]. Eindeutigsind diese
Schlssel jedoch nur fr die Datenbank und die Tabelle, in der sie
erzeugt wurden.Wenn auf zwei unterschiedlichen Datenbanken, die
spter synchronisiert werden, ein Eintraghinzugefgt wird, wird hier
ein Konikt aureten [Corb]. In CouchDB wird jedem Dokumentbei der
Erstellung eine UUID Universally Unique Identifer) zugewiesen. Auf
diese Weise wirdein Konikt statistisch nahezu unmglich. Ein
berblick ber Dokumente in CouchDB ndetsich in Abschnitt
...4.1.6.5Views statt JoinsEiner der wichtigsten Unterschiede
zwischen dokumentenorienterten und relationalen Daten-banken ist
die Art und Weise, wie Abfragen an die Datenbank gestellt werden.
Da CouchDBkeine Primr- und Fremdschlssel kennt, knnen Daten nicht
direkt verknp und ber Joinsabgerufen werden. Stattdessen kann
mithilfe von Views eine Beziehung zwischen beliebigen.Beschreibung
Dokumenten der Datenbank hergestellt werden, ohne dass diese
Beziehung in der Datenbankvordeniert sein muss. Views werden in
Abschnitt .. erklrt. O werden Joins auch schondurch die
Modellierung der Daten in Dokumenten berssig
gemacht.4.2BeschreibungIn diesem Abschnitt werden die Features und
einige Implementierungsdetails von CouchDBvorgestellt. In einem
CouchDB-Datenbanksystem knnen beliebig viele Datenbanken
angelegtwerden, in denen Dokumente enthalten sind. Die
Administrationsoberche Futon kann in einemBrowser unter der URL
http://localhost:5984/_utils besucht werden. In Abbildung A.ndet
sich ein Screenshot von einer CouchDB-Instanz und den darin
enthaltenen Datenbanken,Abbildung A. zeigt den Inhalt einer
Datenbank. Operationen auf der Datenbank werden entwederber diese
Oberche oder programmatisch vorgenommen.Mit CouchDB lsst sich eine
dierenzierte Zugriskontrolle mit Benutzerverwaltung und
Rech-tevergabe umsetzen. Dies wird aus Platzgrnden in dieser Arbeit
nicht behandelt. Ebenfallswerden in dieser Darstellung manche
Datenbank-Funktionen sowie einige Teile der HTTP-APIausgespart. Die
Informationen in den folgenden Abschnitten, soweit nicht anders
angegeben,knnen in [And], [Apab] und [Len] nachgelesen
werden.4.2.1Dokumente und KonfliktbehandlungIn CouchDB-Dokumenten
werden die eigentlichen Datenstze als JSON-Objekte (siehe
auchAbschnitt ...) gespeichert. Ein Dokument kann eine beliebige
Anzahl von beliebig groenFeldern haben, die einen innerhalb des
Dokuments eindeutigen Namen tragen mssen. BinreAttachments knnen
ebenfalls an ein Dokument angehngt werden. Ein Dokument ist mit
einereindeutigen ID (_id) versehen, die beim Erstellen angegeben
oder als UUID zu mathematischnahezuProzent eindeutig erzeugt wird.
Abbildung A. zeigt beispielha ein Dokument.Als weiteres Metadatum
enthlt das Dokument eine Revisionsnummer, genannt _rev.
Werdennderungen an einem Dokument vorgenommen, wird dieses nicht
verndert; stattdessen wirdeine neue Version des gesamten Dokuments
erzeugt, das bis auf die vorgenommenen nderungenund die neue
Revisionsnummer identisch ist. Auf diese Weise beinhaltet die
Datenbank eine kom-plette Versionsgeschichte jedes Dokuments. Mit
dieser Art der Datenspeicherung implementiertCouchDB ein lockless
and optimistic document update model (s. Abschnitt ..).Ein Dokument
wird nach dem folgenden Muster gendert: Das Dokument wird vom
Clientgeladen, verndert und mit Angabe von ID und Revision in der
Datenbank gespeichert. Wenn einanderer Client inzwischen seine
nderungen amselben Dokument gespeichert hat, wird der
erste.Beschreibung Client beim Speichern eine Fehlermeldung
bekommen (HTTP Status-Code : conict). Umdiesen aufzulsen, muss die
aktuelle Version des Dokuments noch einmal geladen und
modiziertwerden, bevor ein neuer Speicherversuch gemacht werden
kann. Dieser schlgt entweder komplettfehl oder wird vollstndig
durchgefhrt, zu keinem Zeitpunkt werden unvollstndige
Dokumentegespeichert.Das Lschen eines Dokuments verlu auf eine
hnliche Weise. Vor dem Lschen muss dieaktuellste Version des
Dokuments vorliegen. Der eigentliche Lschvorgang besteht darin,
demDokument das Feld _deleted=true hinzuzufgen. Gelschte Dokumente
werden genau wieltere Versionen aufbewahrt, bis die Datenbank
kompaktiert wird.Konikte knnen dennoch aureten, wenn an einem
replizierten Datenset unabhngig von-einander Updates vorgenommen
wurden. CouchDB verfgt allerdings ber eine
automatischeKonikterkennung, wodurch die Koniktbehandlung
vereinfacht wird. Die in beiden Kopien gen-derten Dokumente werden
hnlich wie in einem Versionskontrollsystem beim
Zusammenfhrenautomatisch als koniktha gekennzeichnet. Dafr wird
ihnen ein Array namens _conflictshinzugefgt, in dem alle konikthaen
Revisionen gespeichert sind. Durch einen deterministi-schen
Algorithmus wird eine der Revisionen als die Gewinnerversion
gespeichert. Nur diesewird in den Views angezeigt. Die andere
Revision wird in der Geschichte des Dokuments gespei-chert, auf sie
kann noch zugegrien werden. Es ist Aufgabe der Anwendung bzw. der
Benutzer, dieKonikte aufzulsen; dies kann durch Zusammenfhren,
Rckgngig machen oder Akzeptierender nderungen geschehen. Auf
welcher Replik dies geschieht, ist unerheblich, solange am Endeder
gelste Konikt durch Replikation allen Kopien bekannt gemacht
wird.4.2.2HTTP-SchnittstelleDie Daten aus einer CouchDB-Datenbank
knnen ber eine API abgefragt und geschrieben wer-den. Diese API ist
ber die HTTP-Methoden GET, POSTund PUTansprechbar. Die Daten
werdenals JSON-Objekte zurckgegeben. Da JSON und HTTP von vielen
Sprachen und Bibliotheken un-tersttzt werden, knnen von einer
beliebig umgesetzten Anwendung aus Datenbankoperationenauf CouchDB
vorgenommen werden.Fr die JavaScript-HTTP-API von CouchDB wurde im
Verlauf dieser Arbeit eine Testsuite erstellt,dies wird in
Abschnitt .. erlutert.Die CouchDB-API verfgt ber eine Reihe von
Funktionen, die sich nach [And, Kap. ] in vierBereiche unterteilen
lassen. Fr jeden der Bereiche werden einige Einsatzmglichkeiten und
einBeispiel fr die Abfrage mit dem Kommandozeilen-Werkzeug cURL
genannt..Beschreibung 4.2.2.1Server-APIWird ein einfacher
GET-Request an die URI des CouchDB-Servers gerichtet, sendet dieser
die Ver-sionsnummer der CouchDB-Installation:
curlhttp://localhost:5984/ liefert das
JSON-Objekt{"couchdb":"Welcome","version":"0.11.0b902479"} zurck.
Mit anderen Funktionen knnen ei-ne Liste aller Datenbanken
abgefragt oder Kongurationseinstellungen vorgenommen
werden.Benutzeridentikation wird ebenfalls direkt ber den Server
abgewickelt, Benutzer knnen sichgegenber dem Server identizieren
oder ausloggen.4.2.2.2Datenbanken-APIMit dem
Befehlcurl-XPUThttp://localhost:5984/exampledb kann eine Datenbank
erstelltwerden. Im Erfolgsfall wird hier{"ok":true} zurckgegeben.
Schlgt das Anlegen fehl, weileine Datenbank mit diesem Namen
bereits existiert, erhlt man eine Fehlermeldung. Datenban-ken knnen
ebenfalls gelscht, kompaktiert oder es knnen Informationen ber sie
abgefragtwerden. Ein neues Dokument kann durch
curl-XPOSThttp://localhost:5984/exampledb-d{"foo":"bar"} angelegt
werden. CouchDB gibt als Antwort die ID und die Revision
desangelegten Dokuments zurck:
{"ok":true,"id":"6651b95e15b411dbab3d2a7a7d000452","rev":"1-303d5e305201766b21a42747173681d6"}.
Wird statt POST die Methode PUT verwendet, kann dieID des zu
erstellenden Dokuments selbst gewhlt
werden.4.2.2.3Dokumenten-APIMit einem GET-Request auf die URI des
Dokuments
(http://localhost:5984/exampledb/6651b95e15b411dbab3d2a7a7d000452)
kann das Dokument aus dem obigen Beispiel wieder angefordertwerden.
Das Dokument kann durch einen PUT-Request gendert werden. Dabei
muss die ID, daskomplette genderte Dokument und die letzte Revision
des Dokuments mit angegeben werden.Fehlt die Revision oder ist sie
unkorrekt, schlgt das Update fehl.4.2.2.4Replikations-APIMit dem
Befehl
curl-XPOSThttp://127.0.0.1:5984/_replicate-d{"source":"exampledb","target":"exampledb-replica"}
wird Replikation zwischen zwei Datenbanken gestartet. Solleine
Replikation in beide Richtungen realisiert werden, wird der Befehl
ein zweites mal mitvertauschter Quelle und Ziel aufgerufen. Auf
Parameter wird im nchsten Abschnitt nher einge-gangen..Beschreibung
4.2.3ReplikationDamit eine Replik sofort von Updates auf anderen
Repliken erfhrt, kann die Replikation mit derOption continuous=true
gestartet werden. Dieser Mechanismus wird Continuous Replicati-on
genannt. Dadurch wird die HTTP-Verbindung oen gehalten, und jede
nderung an einemDokument wird automatisch sofort repliziert.
Continuous Replication muss explizit neu gestartetwerden, wenn eine
Netzwerkverbindung wieder verfgbar wird. Auch nach
einemServer-Neustartwird sie nicht automatisch fortgesetzt.Es
werden nur die Daten repliziert, die seit dem letzten
Replikationsvorgang gendert wurden.Der Prozess ist also
inkrementell. Wenn die Replikation durch Netzwerkprobleme oder
pltzlicheAusflle von Knoten fehlschlgt, wird der nchste
Replikationsvorgang an der Stelle fortgesetzt,an der der letzte
unterbrochen wurde. Replikation kann durch sogenannte
Filter-Funktionengeltert werden, so dass nur bestimmte Dokumente
repliziert werden.4.2.4Change NotificationsCouchDB-Datenbanken
haben eine Sequenznummer, die bei jedem Schreibzugri an die
Da-tenbank inkrementiert wird. Gespeichert werden auch die
nderungen zwischen zwei Sequenz-nummern. Dadurch knnen Unterschiede
zwischen Datenbanken ezient festgestellt werden,wenn Replikation
nach einer Pause wieder aufgenommen wird. Diese Unterschiede
werdennicht nur intern fr die Replikation benutzt, sie knnen in
Form des Changes-Feeds auch frAnwendungslogik benutzt werden.Mit
dem Changes-Feed kann die Datenbank auf nderungen berwacht werden.
Die Abfragevon http://localhost:5984/exampledb/_changes gibt ein
JSON-Objekt zurck, das sowohl dieaktuelle Sequenznummer als auch
eine Liste aller nderungen der Datenbank enthlt: {"results":[
{"seq":1,"id":"test","changes":[{"rev":"1-aaa8e2a031bca334f50b48b6682fb486"}]},
{"seq":2,"id":"test2","changes":[{"rev":"1-e18422e6a82d0f2157d74b5dcf457997"}]}
], "last_seq":2}Der Changes-Feed kann mit unterschiedlichen
Parametern versehen werden. So knnen mitsince=n nur nderungen seit
einer bestimmten Sequenznummer angefordert werden.
Mitfeed=continuous kann der Feed, hnlich wie die Replikation, so
konguriert werden, dasser nach jeder nderung in der Datenbank einen
Eintrag zurckgibt. Die bereits erwhntenFilter-Funktionen
ermglichen, nur Dokumente mit bestimmten nderungen
zurckzugeben..Beschreibung 4.2.5Anwendungen mit CouchDBIn
Dokumenten kann auch Programmcode enthalten sein, der von CouchDB
ausgefhrt werdenkann. Solche Dokumente werden Designdokumente
genannt. blicherweise ist jeder Anwendung,die von CouchDB
ausgeliefert werden soll, ein Designdokument zugeordnet.Ein
Designdokument ist nach festen Vorgaben strukturiert. Im Folgenden
ndet sich eine Auis-tung der in einem Designdokument typischerweise
enthaltenen Dokumente:_id: Enthlt das Prx _design/ und den Namen
des Designdokuments bzw. der Anwendung,z. B.
_design/doingnotes._rev: Von Replikation und Koniktbehandlung
werden Designdokumente behandelt wie nor-male Dokumente, deswegen
enthalten sie eine Revisionsnummer._attachments: In diesem Feld
enthaltener Programmcode kann clientseitig im Browser ausge-fhrt
werden. Hier kann die Anwendungslogik fr eine CouchDB-Applikation
enthaltensein._views: Ebenso wie list-, show- und filter-Felder
enthlt dieses Feld Funktionen, mitdenen der Inhalt einer Datenbank
geltert, strukturiert und/oder modiziert ausgegebenwerden kann.
Dieser Code wird serverseitig, also von der Datenbank
ausgefhrt.Abbildung A. enthlt einen Screenshot von einem in Futon
geneten Designdokument.4.2.6ViewsIn relationalen Datenbanken werden
die Beziehungen zwischen Daten ausgedrckt, in dem glei-che Daten in
einer Tabelle gespeichert werden, und zusammengehrige Daten mit
Primr- undFremdschlsseln verknp sind. Aufgrund dieser Beziehungen
knnen dann durch dynamischeAbfragen aggregierte Datensets
angefordert werden. CouchDB whlt hier einen gegenteiligenAnsatz.
Auf Datenbankebene sind keine Verknpfungen realisiert. Verbindungen
zwischen Doku-menten knnen auch dann noch gezogen werden, wenn die
Daten schon vorhanden sind. Dafrwerden die Abfragen dieser Daten
und ihre Ergebnisse statisch in der Datenbank gespeichert. Siehaben
keine Auswirkungen auf die Dokumente in der Datenbank. Diese
Abfragen werden alsIndizes gespeichert, die Views genannt
werden.Views werden in Designdokumenten abgelegt und beinhalten
JavaScript-Funktionen, die Abfra-gen mithilfe von MapReduce [Yan]
formulieren. Eine Map-Funktion bekommt nacheinanderalle Dokumente
als Argument bergeben und bestimmt anhand dessen, ob es oder
einzelneFelder durch den View verfgbar gemacht werden sollen. Wenn
eine View eine Reduce-Funktionenthlt, wird diese zum Aggregieren
der Ergebnisse verwendet. Listing . zeigt eine View,
mit.Beschreibung der alle Dokumente auf das Feld kind mit dem Wert
Outline berpr werden. Wenn einDokument solch ein Feld enthlt, wird
dem resultierenden JSON-Objekt ein Eintrag hinzugefgt,der als
Schlssel die Dokumenten-ID und als Wert das Dokument enthlt.
function(doc){ if(doc.kind==Outline){ emit(doc._id,doc); } }Listing
.: View: Map-Funktion zum Ausgeben aller OutlinesWird diese View
unter dem Namenoutlines in einem
Designdokumentdesignnamegespeichert, kann sie mithilfe eines HTTP
GET-Requests auf die URI
http://localhost:5984/exampledb/_design/designname/outlines
abgerufen werden. Views werden bei ih-rem ersten Abrufen erstellt
und dann mitsamt ihrem Index, wie auch normale Dokumente, ineinem
B+-Baum gespeichert. Werden weitere Dokumente hinzugefgt, die im
Ergebnis der Viewenthalten sind, werden sie automatisch zur
gespeicherten View hinzugefgt, wenn diese dasnchste mal abgerufen
wird.Der Zugri auf eine View kann ber Schlssel Keys) und
Schlsselbereiche Key Ranges) einge-grenzt werden. Die Abfrage
vonhttp://localhost:5984/exampledb/design/designname/outlines?key="5"
gibt nur das Outline mit der ID 5 zurck. Mit
http://localhost:5984/exampledb/design/designname/outlines?startkey="2"&endkey="7"
knnen alle Out-lines angefordert werden, deren ID zwischen 2 und 7
liegt. Es existieren eine Vielzahl weitererParameter, mit denen die
Abfrage weiter przisiert werden kann. Die Schlssel bzw.
Schlsselberei-che werden direkt auf den Datenbankengine gemappt,
dadurch sind die Zugrie sehr performant.Dies wird im nchsten
Abschnitt erklrt.4.2.7ImplementierungEine CouchDB-Datenbank ist
immer in einem konsistenten Zustand, auch wenn der CouchDB-Server
mitten in einem Speichervorgang abstrzen sollte. Dies wird in
diesem Abschnitt mit einerCharakterisierung des verwendeten
Datenbankengines begrndet. Die Darstellung sttzt sich auf[Ho,] und
[And, Kap. G].Die eingesetzte Datenstruktur ist ein B+-Baum, eine
Variation des B-Baums. Ein B+-Baum ist aufdie Speicherung von groen
Datenmengen und schneller Abfrage dieser ausgerichtet. Auch
frextremely large datasets wird eine Zugriszeit von
unterMillisekunden garantiert [Bay].B+-Bume wachsen in die Breite;
auch mit mehreren Millionen Eintrgen haben sie gewhnlicheine
einstellige Tiefe. Dies ist vorteilha, da CouchDB als
Speichermedium Festplatten verwendet,wo jeder Traversierungsschritt
ein zeitintensiver Vorgang ist..Beschreibung Ein B+-Baum ist ein
vollstndig balancierter Suchbaum, in dem Daten nach Schlsseln
sortiertgespeichert werden [Bay]. In einem Knoten knnen mehrere
Schlsselwerte enthalten sein.Jeder Knoten verweist auf mehrere
Kindknoten. Bei CouchDB sind die eigentlichen Daten aus-schlielich
in den Blttern gespeichert. In den B+-Bumen werden sowohl die
Dokumente alsauch die Views indiziert. Dabei wird fr jede Datenbank
und jede View ein eigener B+-Baumangelegt.Pro Datenbank ist nur ein
gleichzeitiger Schreibzugri erlaubt, die Schreibzugrie werden
seriali-siert. Lesezugrie knnen nebenlug zueinander und zu
Schreibzugrien stattnden. Daten-banken und Views knnen demnach
gleichzeitig abgefragt und erneuert werden. Da CouchDBseine Daten
im Append-Only-Modus ablegt, enthlt die Datenbankdatei eine
komplette Versions-geschichte aller Dokumente. MVCC kann dadurch
eektiv umgesetzt werden.Wie in Abschnitt .. beschrieben, wird beim
ndern eines Dokuments dieses nicht berschrie-ben, sondern eine neue
Revision erstellt. Danach werden die Knoten des B+-Baums
nacheinanderaktualisiert, bis sie alle auf den Speicherort der
neusten Version des Dokuments verweisen. Diesgeschieht ausgehend
vom Blatt des Baums, der das Dokument enthlt, bis hoch zum
Wurzel-knoten. Dieser wird also am Ende jedes Schreibzugris
modiziert. Wenn ein Lesezugri nochdie Referenz auf den alten
Wurzelknoten hat, verweist dieser zu einer veralteten, aber
konsisten-ten Momentaufnahme der Datenbank. Alte Revisionen der
Dokumente werden erst bei einervom Benutzer eingeleiteten
Compaction Verdichtung) gelscht. Deshalb knnen Lesezugrie
ihrErgebnis fertig abfragen, auch wenn gleichzeitig eine neue
Version des Dokuments erstellt wird.Wenn ein B+-Baumauf die
Festplatte geschrieben wird, werden die nderungen stets an das
Endeder Datei angehngt. Dadurch wird die Zugriszeit beim Schreiben
auf die Festplatte minimiert.Auerdem wird verhindert, dass
unvorhergesehene Beendigung des Prozesses oder Stromausflleden
Index korrumpieren:If a crash occurs while updating a view index,
the incomplete index updates aresimply lost and rebuilt
incrementally from its previously committed state. [Apab]
5Technische GrundlagenIn diesem Kapitel werden zunchst die
einzelnen Webtechnologien dargestellt, die in die An-wendung
eingeossen sind. Anschlieend wird auf die Hintergrnde von Cloud
Computingeingegangen, das zum Deployment der Anwendung verwendet
wurde. Der letzte Abschnitt stelltdie Methoden und Mittel dar, die
zur Entwicklung der Anwendung untersttzend
beigetragenhaben.5.1WebtechnologienDie Interaktionsmglichkeiten mit
der Oberche der zu erstellenden Anwendung fallen geringaus. Der
Einsatz eines aufwndigen ViewFrameworks ist deshalb nicht
notwendig; die Umsetzungkann mit den vergleichsweise einfachen
Technologien, Frameworks und Programmiersprachenerfolgen, die hier
im Einzelnen vorgestellt werden.5.1.1CouchAppDie zu entwickelnde
Anwendung wird als sogenannte CouchApp [Che] umgesetzt. Das
ProjektCouchApp stellt eine Reihe von untersttzenden Komponenten
zur Verfgung, die die Entwick-lung einer Standalone-Anwendung mit
CouchDB erleichtern. Das Design sieht vor, dass jederBenutzer eine
eigene CouchDB-Instanz oine auf seinem Endgert installiert hat, in
der dieAnwendung lu. Dadurch ist die Verfgbarkeit auch ohne
Internetanbindung gegeben.Damien Katz, der Urheber von CouchDB,
erklrt in [Kat] CouchApps in folgenden Worten:CouchDB, being an
HTTP server, can host applications directly, so you can
writeapplications and forward the HTML, CSS, and JavaScript through
CouchDB. Whenyou point your browser at it, the browser comes alive
and starts the JavaScript. Itbecomes interactive as you query and
update the server and everything. When every-thing is served from
CouchDB, thats a CouchApp and you can replicate it around,just like
the data.Eine CouchApp kann auf dem lokalen Rechner, einem
Mobiltelefon, einem lokalen Server oderin der Cloud deployt sein,
immer wird sie ber einen Browser angesprochen. Durch
Replikationknnen die Daten und auch das Programm immer wieder auf
einen Stand gebracht werden.. Webtechnologien Nach der Installation
von CouchApp (erklrt in Abschnitt ..) kann das Gerst fr eineneue
Beispiel-Applikation von der Kommandozeile mit dem Befehl
couchappgenerateexample-couchapp erzeugt werden. Dies generiert ein
Verzeichnis example-couchapp, das eine Ver-zeichnisstruktur vorgibt
(s. Abb. .). Dieses Verzeichnis entspricht
einemCouchDB-Designdokument,wie es in Abschnitt .. beschrieben
ist.Abbildung .: Generierte Beispiel-CouchappDas Verzeichnis
_attachments enthlt alle JavaScript-, HTML- und CSS-Dateien, die
frAnwendungslogik und Darstellung bentigt werden. In der
Beispiel-Anwendung ist eine einfacheHTML-Startseite sowie ein
Stylesheet vorgegeben. Die Verzeichnisse lists, show, views
undfilters enthalten entsprechend die List-, Show- bzw.
Filter-Funktionen von CouchDB bzw. dieViews. Imvendor-Verzeichnis
werden externe Bibliotheken abgelegt, die fr die Entwicklungbentigt
werden.Die Einstellungen fr das Deployment werden in der Datei
.couchapprc vorgenommen. Dieseist folgendermaen formatiert: {
"env":{ "default":{. Webtechnologien
"db":"http://user:password@localhost:5984/example-couchapp-dev" },
"production":{
"db":"http:///user:[email protected]/example-couchapp" } }
}Listing .: Couchapp: .couchapprcDabei mssen fr die Entwicklungs-
und ggf. Produktionsumgebung Benutzername und Passwortdes
CouchDB-Administrators angegeben werden. Diese Information kann
weggelassen werden,wenn sie nicht gesetzt sind. Mit dem Befehl
couchapppush bzw. couchapppushproduction wirdder Inhalt des
CouchApp-Verzeichnisses in die CouchDB-Instanz kopiert.Das
URL-Schema einer CouchApp wird in Abschnitt . erlutert. In
Abschnitt .. wird erklrt,wie die in der Arbeit erstellte Anwendung
mithilfe von CouchApp deployt wird.5.1.2HTML5HTML Hypertext Markup
Language) ist das Hypertextformat im World Wide Web. HTML,[Hica]
ist eine vom WC entworfene Spezikation, die in Zukun die bisherigen
HTML- undXHTML-Standards ersetzen soll. HTML wird mittlerweile von
den meistbenutzten Browsernin den aktuellsten Versionen weitgehend
untersttzt, mit der Ausnahme des Microso InternetExplorer [Smi].
Diese Einschrnkung verhindert bisher noch die Entwicklung der
meistenWebanwendungen, da im Normalfall auf ltere oder nicht
standardkonforme Browser Rcksichtgenommen werden muss.Wegen in
Abschnitt .. nher ausgefhrten Einschrnkungen ist die Anwendung auf
denBrowser Firefox ab der Version . festgelegt (siehe Release Notes
[Mozb]). Dies erlaubt es, auchbei zentralen Anwendungseigenschaen
auf die Funktionen zuzugreifen, die HTML mit sichbringt. So bietet
HTML neben vielen Verbesserungen die Mglichkeit, Custom Data
Attributeszu denieren. Diese Technik wird in der Arbeit verwendet
und wird deshalb kurz erklrt.Laut Spezikation [Hicb] ist ein Custom
Data Attribute ein Attribut ohne Namespace, dessenName mit dem
String data- beginnt und nach dem Bindestrich mindestens einen
Buchstabenhat, der keine Grobuchstaben enthlt. In Custom Data
Attributes knnen eigene private Datenfr die Seite oder die
Anwendung gespeichert werden, wenn es keine passenden Attribute
oderElemente dafr gibt. Die Attribute sind dafr gedacht, von den
eigenen Skripten der Seite benutztzu werden, nicht als entlich
nutzbare Metadaten. Jedes HTML-Element kann beliebig vieleCustom
Data Attributes haben.. Webtechnologien 5.1.3JavaScriptJavaScript
ist eine vielseitige Skriptsprache, deren Assoziation mit dem
Webbrowser sie zu einerder populrsten Programmiersprachen der Welt
macht [Cro, S. ]. ber das DOM DocumentObject Model) [WC] knnen
mi