Vor- und Nachteile dokumentenbasierter Datenbanken gegenüber relationalen Datenbanken


75

Ich habe versucht zu prüfen, ob ich mit einer dokumentbasierten Datenbank, in diesem Fall CouchDB, einige Anforderungen erfüllen kann. Zwei allgemeine Anforderungen:

  • CRUD von Entitäten mit einigen Feldern, die einen eindeutigen Index haben
  • E-Commerce-Web-App wie eBay ( bessere Beschreibung hier ).

Und ich fange an zu denken, dass eine dokumentbasierte Datenbank nicht die beste Wahl ist, um diese Anforderungen zu erfüllen. Außerdem kann ich mir keine Verwendung für eine dokumentbasierte Datenbank vorstellen (vielleicht ist meine Vorstellungskraft zu begrenzt).

Können Sie mir erklären, ob ich Birnen von einer Ulme frage, wenn ich versuche, eine dokumentenorientierte Datenbank für diese Anforderungen zu verwenden?


2
"Birnen * von einer Ulme fragen" = das Unmögliche fragen. (Jasons Link ist tot.)
Dennis

Antworten:


36

Sie müssen darüber nachdenken, wie Sie die Anwendung dokumentenorientiert angehen. Wenn Sie einfach versuchen zu replizieren, wie Sie das Problem in einem RDBMS modellieren würden, schlagen Sie fehl. Es gibt auch verschiedene Kompromisse, die Sie möglicherweise eingehen möchten. ([ed: Ich bin mir nicht sicher, wie dies mit dem Argument zusammenhängt, aber:] Denken Sie daran, dass das Design von CouchDB davon ausgeht, dass Sie einen aktiven Cluster mit vielen Knoten haben, die jederzeit ausfallen können. Wie wird Ihre App mit einem der Datenbankknoten umgehen, aus denen sie verschwindet? darunter?)

Eine Möglichkeit, darüber nachzudenken, besteht darin, sich vorzustellen, Sie hätten keine Computer, nur Papierdokumente. Wie würden Sie einen effizienten Geschäftsprozess erstellen, indem Sie Papierstücke herumreichen? Wie können Sie Engpässe vermeiden? Was ist, wenn etwas schief geht?

Ein weiterer Aspekt, über den Sie nachdenken sollten, ist die eventuelle Konsistenz, bei der Sie schließlich in einen konsistenten Zustand geraten, aber möglicherweise für einen bestimmten Zeitraum inkonsistent sind. Dies ist ein Gräuel im RDBMS-Land, aber in der realen Welt äußerst verbreitet. Das kanonische Transaktionsbeispiel ist die Überweisung von Geld von Bankkonten. Wie geschieht dies tatsächlich in der realen Welt - durch einzelne Atomtransaktionen oder durch verschiedene Banken, die sich gegenseitig Kredit- und Lastschriften ausstellen? Was passiert, wenn Sie einen Scheck ausstellen?

Schauen wir uns also Ihre Beispiele an:

  • CRUD von Entitäten mit einigen Feldern mit einem eindeutigen Index.

Wenn ich dies in CouchDB-Begriffen richtig verstehe, möchten Sie eine Sammlung von Dokumenten haben, bei denen garantiert ist, dass ein benannter Wert in all diesen Dokumenten eindeutig ist? Dieser Fall kann im Allgemeinen nicht unterstützt werden, da Dokumente möglicherweise auf verschiedenen Replikaten erstellt werden.

Wir müssen uns also das Problem der realen Welt ansehen und sehen, ob wir das modellieren können. Brauchen Sie sie wirklich, um einzigartig zu sein? Kann Ihre Anwendung mehrere Dokumente mit demselben Wert verarbeiten? Müssen Sie eine eindeutige Kennung zuweisen? Können Sie das deterministisch tun? Ein häufiges Szenario, in dem dies erforderlich ist, besteht darin, dass Sie eine eindeutige sequentielle Kennung benötigen. Dies ist in einer replizierten Umgebung schwer zu lösen. In der Tat ist es unmöglich, wenn die eindeutige ID in Bezug auf die erstellte Zeit streng sequentiell sein muss, wenn Sie die ID sofort benötigen. Sie müssen mindestens eine dieser Einschränkungen lockern.

  • E-Commerce-Web-App wie ebay

Ich bin mir nicht sicher, was ich hier hinzufügen soll, da der letzte Kommentar, den Sie zu diesem Beitrag abgegeben haben, "sehr nützlich! Danke" war. Fehlt in dem dort beschriebenen Ansatz etwas, das Ihnen immer noch ein Problem bereitet? Ich fand die Antwort von MrKurt ziemlich vollständig und fügte eine kleine Verbesserung hinzu, die den Streit reduzieren würde.


Wie wäre es mit der Verwendung von UUIDs für verteilte, nichts geteilte, global eindeutige Kennungen? Tun dies Menschen normalerweise in der Welt der Dokumentendatenbanken?
Paul Legato

@ Tim Lovell-Smith + kerrr +1 Ich mag den realen Vergleich mit papierbasierten Dokumenten. :) Guter Punkt: CouchDB erfordert / setzt Clustering voraus. Auch ein guter Punkt, dass Konsistenz nicht immer garantiert ist. Für mich als RDB-Unterstützer lautet dies (unter anderem natürlich): "Wenn Konsistenz entscheidend ist, verwenden Sie eine relationale Datenbank". Richtig? (Hinweis: Ich starte gerade ein neues Projekt, bei dem ich mich für NoSQL oder RDB entscheiden möchte.)
try-catch-finally

13

Müssen die Daten normalisiert werden?

  • Ja: Verwenden Sie relational.
  • Nein: Dokument verwenden.

11
Ich weiß, dass Sie dies vor langer Zeit beantwortet haben, aber ich dachte, ich würde fragen ... Wann müssen Sie sich "normalisieren"? Ist Normalisierung nicht eine Wahl / Best Practice?
Matt Grande

1
@Matt, Datennormalisierung ist nur ein Werkzeug. Der Grad der Normalisierung von Daten ist ein Kompromiss zwischen dem Aufwand für das Datenbankdesign und dem Aufwand für die Konsistenzpflege.
pyon

5
Ich würde nicht zustimmen, dass dies ein guter Weg ist, um zu unterscheiden, welches Datenbankmodell verwendet werden soll. Eine Normalisierung ist sowohl in relationalen als auch in dokumentbasierten Datenbanken unvermeidlich. Meiner Meinung nach ist die Größe von Transaktionen eher eine gültige Differenzierung.
Munhitsu

Was meinst du hier mit Normalisierung? Wenn ich Normalisierung als Mittel zum Zweck richtig verstehe, scheint Ihre Antwort unvollständig zu sein ...
Tim Lovell-Smith

Es ist das zweite Mal, dass ich diese Faustregel lese (um die Notwendigkeit einer Normalisierung zu untersuchen). Aber für mich als RDB-Unterstützer, der ständig versucht zu verstehen, ob das nächste Projekt mit einer dokumentbasierten oder einer relationalen Datenbank implementiert werden soll, ist diese "Regel" nicht hilfreich, denn wenn ich möchte, könnte ich meine RDB (sehr) unnormalisiert gestalten (und einige Ingenieure empfehlen dies sogar aus Sicht der Leistung).
Try-Catch-Endlich

8

Ich bin im selben Boot, ich liebe Couchdb im Moment und ich denke, dass der gesamte funktionale Stil großartig ist. Aber wann genau fangen wir an, sie in ernest für Anwendungen zu verwenden. Ich meine, ja, wir können alle extrem schnell damit beginnen, Anwendungen zu entwickeln, ohne Probleme, wenn all diese fiesen Probleme mit der normalen Form auf der Strecke bleiben und keine Schemata verwenden. Aber um einen Satz zu prägen: "Wir stehen auf den Schultern der Riesen". Es gibt einen guten Grund, RDBMS zu verwenden und Schemas zu normalisieren und zu verwenden. Mein alter Orakelkopf schwankt und denkt über Daten ohne Form nach.

Mein Haupt-Wow-Faktor bei couchdb ist das Replikationsmaterial und das Versionssystem, die zusammenarbeiten.

Ich habe mir im letzten Monat den Kopf zerbrochen und versucht, die Speichermechanismen von couchdb zu untersuchen. Anscheinend werden B-Bäume verwendet, aber keine Daten basierend auf der normalen Form gespeichert. Bedeutet dies, dass es wirklich sehr, sehr intelligent ist und erkennt, dass Datenbits repliziert werden, also lassen Sie uns einfach einen Zeiger auf diesen B-Baum-Eintrag machen?

Bisher denke ich an XML-Dokumente, Konfigurationsdateien und Ressourcendateien, die auf base64-Zeichenfolgen gestreamt werden.

Aber würde ich couchdb für strukturelle Daten verwenden. Ich weiß nicht, jede Hilfe wird hier sehr geschätzt.

Kann beim Speichern von RDF-Daten oder sogar von Freiformtext hilfreich sein.


6

Eine Möglichkeit besteht darin, eine relationale Hauptdatenbank zu haben, in der Definitionen von Elementen gespeichert sind, die anhand ihrer IDs abgerufen werden können, sowie eine Dokumentendatenbank für die Beschreibungen und / oder Spezifikationen dieser Elemente. Beispielsweise könnten Sie eine relationale Datenbank mit einer Produkttabelle mit den folgenden Feldern haben:

  • Produkt ID
  • Beschreibung
  • Stückpreis
  • LotSize
  • Spezifikationen

Und dieses Feld Spezifikationen würde tatsächlich einen Verweis auf ein Dokument mit den technischen Spezifikationen des Produkts enthalten. Auf diese Weise haben Sie das Beste aus beiden Welten.


2
SQL Server 2008 ist ein Beispiel für eine Datenbank, die beides kann (unter Verwendung des Datentyps FILESTREAM).
John Saunders

Beeindruckend. Fantastisches Feature. (Ich habe SQL Server 2008 noch nie verwendet.)
pyon

Nur in der Lage zu sein, ein loses 'Dokument' oder eine Datei zu speichern, macht es nicht zu einem dokumentenorientierten Datenbanksystem. Echte dokumentenorientierte Datenbanken bieten Ihnen Funktionen zum Indexieren und effizienten Arbeiten mit Dokumenten.
Tim Lovell-Smith

@ TimLovell-Smith Wenn es eine Struktur gibt, wird die Verwendung einer relationalen Datenbank (oder noch besser einer kategorialen Datenbank: math.mit.edu/~dspivak/informatics/talks/CTDBIntroductoryTalk ) am profitabelsten genutzt . Ich befürworte die Schaffung einer sauberen Trennung zwischen strukturierten und unstrukturierten Teilen der Daten.
Pyon

@ TimLovell-Smith Wie so? Sie haben "Funktionen zum Indizieren und Arbeiten mit Dokumenten" erwähnt. Indizes sind Strukturen und werden daher, wie gesagt, "am profitabelsten von der Verwendung einer relationalen Datenbank ausgenutzt", selbst wenn der tatsächliche Inhalt der Dokumente nicht vorhanden ist.
Pyon

4

Dokumentbasierte DBs eignen sich am besten zum Speichern von Dokumenten. Lotus Notes ist eine gängige Implementierung und Notes E-Mail ist ein Beispiel. Für das, was Sie beschreiben, E-Commerce, CRUD usw., sind Realtional-DBs besser zum Speichern und Abrufen von indizierten Datenelementen / Elementen (im Gegensatz zu Dokumenten) geeignet.


9
Ich stimme nicht zu Eine Dokumentendatenbank dient nicht in erster Linie zum Speichern von Dokumenten. Es dient zum Speichern hierarchischer Daten (entweder JSON oder XML). Sie können verschachtelte JSON-Felder und JSON-Arrays beispielsweise mit MongoDB indizieren. Sie können Dokumente (Dateien) in MongoDB (gridfs) speichern, aber MongoDB wäre immer noch nützlich, wenn Sie Dokumente (Dateien) nicht mit MongoDB speichern könnten. Ich denke, dass MongoDb als JSON-Datenbank und nicht als Dokument-Datenbank bezeichnet werden sollte.
Theo

1
Laut dem Wikipedia-Eintrag für "Dokumentorientierte Datenbank" hat "... die Verwendung von XML, YAML oder JSON zur Informationsspeicherung ähnliche Vorteile wie die dokumentenorientierte Datenbank", aber sie sind nicht dasselbe. Dokumentendatenbanken wurden ursprünglich so konzipiert, dass Dokumente gespeichert werden. Wenn Sie sie für andere Daten verwenden, erzielen Sie nicht die beste Leistung / Nutzung, genauso wie wenn Sie Dokumente in einer relationalen Datenbank speichern. Das passiert sehr oft. Menschen speichern relationale Daten in Dokumentendatenbanken und beschweren sich dann darüber, wie schlecht Dokumentdatenbanken sind. Wenn Sie sie missbrauchen, ja.
Jim Anderson

1
Der Wikipedia-Eintrag en.wikipedia.org/wiki/Document-oriented_database wurde seitdem aktualisiert, um zu bestätigen, dass dokumentenorientierte Datenbanken in der Tat mehr sind als Aktenschränke für tatsächliche Dokumente.
Zsolt Török

Interessant. Es scheint, dass sich dokumentenorientierte Datenbanken in den letzten Jahren mehr "entwickelt" haben, als ich ursprünglich gedacht hatte.
Jim Anderson

2

Zu CRUD: Das gesamte REST-Paradigma wird direkt auf CRUD abgebildet (oder umgekehrt). Wenn Sie also wissen, dass Sie Ihre Anforderungen mit Ressourcen (über URIs identifizierbar) und einer Reihe grundlegender Operationen (nämlich CRUD) modellieren können, sind Sie möglicherweise einem REST-basierten System sehr nahe, das einige dokumentenorientierte Systeme bereitstellen der Box.


1
Ich denke nicht, dass der Vergleich von CRUD mit REST ausreicht, um über die Verwendung dokumentenorientierter Datenbanken nachzudenken. Es gibt noch viel mehr zu beachten, REST <> CRUD ist nur ein kleiner Teil davon.
igorsantos07

1
Ich habe dies positiv bewertet, da es mir so schien, als würde ich schräg auf das verweisen, was als "objektrelationale Impedanzfehlanpassung" bekannt ist (siehe blogs.tedneward.com/post/the-vietnam-of-computer-science ).
Tom Russell
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.