Do­ku­men­ten­ori­en­tier­te Datenbank: Wie funk­tio­niert der Document Store?

Da­ten­ban­ken sind notwendig, um In­for­ma­tio­nen ver­nünf­tig or­ga­ni­sie­ren zu können. Doch es gibt un­ter­schied­li­che Methoden, wie Da­ten­ban­ken aufgebaut sein können. In der EDV sind vor allem re­la­tio­na­le Da­ten­ban­ken üblich und weit ver­brei­tet. Daneben gibt es aber auch so­ge­nann­te do­ku­men­ten­ori­en­tier­te Da­ten­ban­ken. Diese bauen auf eine einfache Ta­bel­len­struk­tur und Do­ku­men­ten zur Spei­che­rung von In­for­ma­tio­nen auf. Wie funk­tio­nie­ren diese Da­ten­ban­ken und was sind die Vorteile?

Do­ku­men­ten­ori­en­tier­te Da­ten­ban­ken – auch Document Store genannt – werden für die Ver­wal­tung von se­mi­struk­tu­rier­ten Daten verwendet. Dabei handelt es sich um Daten, die keiner festen Struktur folgen, sondern die Struktur quasi in sich selbst tragen. Anhand von Mar­kie­run­gen innerhalb der se­mi­struk­tu­rier­ten Daten kann dennoch eine Ordnung der In­for­ma­tio­nen vor­ge­nom­men werden. Aufgrund der fehlenden klaren Struktur sind diese Daten nicht für re­la­tio­na­le Da­ten­ban­ken geeignet, da sich ihre In­for­ma­tio­nen nicht in Tabellen einordnen lassen.

Die do­ku­men­ten­ori­en­tier­te Datenbank erstellt ein einfaches Paar: Einem Schlüssel wird ein spe­zi­fi­sches Dokument zu­ge­ord­net. In diesem Dokument, das zum Beispiel mit XML, JSON oder YAML for­ma­tiert sein kann, sind dann die ei­gent­li­chen In­for­ma­tio­nen zu finden. Da die Datenbank kein be­stimm­tes Schema verlangt, kann man auch un­ter­schied­li­che Do­ku­men­ten­ty­pen gemeinsam in einen Document Store einbinden. Än­de­run­gen an den Do­ku­men­ten müssen der Datenbank nicht mit­ge­teilt werden.

Theo­re­tisch kann man Daten un­ter­schied­lichs­ter Formate und ohne ein durch­gän­gi­ges Schema in einer do­ku­men­ten­ori­en­tier­ten Datenbank un­ter­brin­gen. In der Praxis ver­wen­de­tet man aber in der Regel ein Da­tei­for­mat für die Dokumente und baut die In­for­ma­tio­nen in einer festen Struktur auf. Das er­leich­tert die Arbeit mit den In­for­ma­tio­nen und der Datenbank. Durch die Ordnung können bei­spiels­wei­se Such­an­fra­gen an die Datenbank besser ver­ar­bei­tet werden. Generell kann man mit einer do­ku­men­ten­ba­sier­ten Datenbank die gleichen Aktionen durch­füh­ren wie auch mit einem re­la­tio­na­len System: In­for­ma­tio­nen lassen sich einfügen, ändern, löschen und abfragen.

Damit sich die Aktionen durch­füh­ren lassen, erhält jedes Dokument eine ein­deu­ti­ge ID. Wie diese gestaltet ist, ist prin­zi­pi­ell nicht wichtig. Sowohl eine einfache Zei­chen­fol­ge als auch der komplette Pfad können genutzt werden, um das Dokument zu adres­sie­ren. Bei einer Suche nach In­for­ma­tio­nen werden die Dokumente selbst überprüft: Es werden also nicht innerhalb der Datenbank mehrere Spalten mit ent­spre­chen­den Daten durch­sucht, sondern statt­des­sen die Daten direkt aus dem Dokument gezogen.

In klas­si­schen re­la­tio­na­len Da­ten­ban­ken muss für jede In­for­ma­ti­on ein Feld exis­tie­ren – und zwar in jedem Eintrag. Wenn die In­for­ma­ti­on nicht zur Verfügung steht, bleibt die Zelle leer, muss aber angelegt sein. Do­ku­men­ten­ori­en­tier­te Da­ten­ban­ken sind sehr viel flexibler: Die Struktur der einzelnen Dokumente muss nicht kon­sis­tent sein. Auch große un­struk­tu­rier­te Da­ten­men­gen können so in der Datenbank un­ter­ge­bracht werden.

Außerdem ist es einfacher, neue In­for­ma­tio­nen ein­zu­glie­dern: Während man bei einer re­la­tio­na­len Datenbank einen neuen In­for­ma­ti­ons­punkt in alle Da­ten­sät­ze einfügen muss, reicht es bei einem Document Store, die Neuheit in nur wenige Da­ten­sät­ze zu in­te­grie­ren. In weitere Dokumente kann der zu­sätz­li­che Inhalt eingefügt werden – muss er aber nicht.

Zu­sätz­lich werden die In­for­ma­tio­nen bei Document Stores nicht über mehrere un­ter­ein­an­der ver­knüpf­te Tabellen verteilt. Alles befindet sich an einem Ort, was zu einer besseren Per­for­mance führen kann. Diesen Ge­schwin­dig­keits­vor­teil können do­ku­men­ten­ori­en­tier­te Da­ten­ban­ken al­ler­dings nur aus­spie­len, solange man nicht versucht, sie mit re­la­tio­na­len Elementen zu versehen: Re­fe­ren­zen passen ei­gent­lich nicht in das Konzept von Document Stores. Versucht man dennoch, die Dokumente un­ter­ein­an­der zu vernetzen, wird das System sehr komplex und sperrig. Bei stark ver­netz­ten Da­ten­men­gen ist also ein re­la­tio­na­les Da­ten­bank­sys­tem vor­zu­zie­hen.

Besonders für die Ent­wick­lung von Web-Apps haben Da­ten­ban­ken für Dokumente eine große Bedeutung. Aufgrund des hohen Bedarfs, der sich durch die Web­ent­wick­lung ergibt, sind in­zwi­schen auch zahl­rei­che Da­ten­bank­ma­nage­ment­sys­te­me (DBMS) auf dem Markt verfügbar. Die nach­fol­gen­de Auswahl stellt Ihnen die be­kann­tes­ten vor:

• BaseX: Das Open-Source-Projekt nutzt Java und XML. BaseX wird mit einer gra­fi­schen Be­nut­zer­ober­flä­che aus­ge­lie­fert.
• CouchDB: Die Apache Software Foun­da­ti­on ver­öf­fent­lich­te die Open-Source-Software CouchDB. Das Da­ten­bank­ma­nage­ment­sys­tem ist in Erlang ge­schrie­ben, nutzt Ja­va­Script und kommt unter anderem in Ubuntu und in Facebook-An­wen­dun­gen zum Einsatz.
• Ela­s­tic­se­arch: Die Such­ma­schi­ne arbeitet auf Basis einer do­ku­men­ten­ori­en­tier­ten Datenbank. Dafür kommen JSON-Dokumente zum Einsatz.
• eXist: Das quell­of­fe­ne DBMS eXist läuft über eine Java Virtual Machine und lässt sich deshalb un­ab­hän­gig vom Be­triebs­sys­tem verwenden. Zum Einsatz kommen vor allem XML-Dokumente.
• MongoDB: MongoDB ist die am weitesten ver­brei­te­te NoSQL-Datenbank. Die Software ist in C++ ge­schrie­ben und verwendet JSON-ähnliche Dokumente.
• SimpleDB: Amazon hat mit SimpleDB (in Erlang verfasst) für die un­ter­neh­mens­ei­ge­nen Cloud-Dienste ein eigenes DBMS ent­wi­ckelt. Für die Nutzung verlangt der Anbieter eine Gebühr.