Dokumentendatenbank versus relationale Datenbank: Wie soll man wählen?

Ich bin ein SQL-Typ, aber ich weiß, dass es nicht nur SQL- Datenbanken gibt - hauptsächlich Dokumentendatenbanken. Wie bei den meisten Technologien gibt es Vor- und Nachteile für jede Technologie.

Ich habe einige Artikel gelesen, aber sie waren zu theoretisch. Was ich möchte, sind zwei reale Fälle:

als ein Wechsel von einer relationalen zu einer Dokumentendatenbank eine Verbesserung ergab
als ein Wechsel von einer Dokumenten- zu einer relationalen Datenbank eine Verbesserung brachte

Verbesserung ist alles, was bessere Programme ausmacht - weniger Entwicklungszeit, Skalierbarkeit, Leistung und alles, was mit Programmierung zu tun hat. Es gibt eine Einschränkung für 2.: Geschichten wie "Zurückgreifen auf relationale Datenbanken, weil jeder SQL kennt" sind nicht gut

nosql relational-database

— Johan Buret
quelle

Falscher Ansatz. Es geht nicht um "Leistung" oder "Skalierbarkeit". Es geht darum, welches Modell zu dem Problem passt, das Sie lösen möchten. Möglicherweise möchten Sie Ihre Frage aktualisieren, um der Idee Rechnung zu tragen, dass die relationale Datenbank möglicherweise nicht für zahlreiche Arten von Problemen geeignet ist.

— S.Lott

@ S.lott, die wahl ist oft sehr leistungsorientiert. Bedenken Sie, dass jeder relationale DB als einfacher Dokument-DB verwendet werden kann - nur die Leistung wäre ein Unterscheidungsmerkmal.

— edA-qa mort-ora-y

Ich habe meine Frage so umformuliert, dass sie in keiner Weise geladen wird.

— Johan Buret

@ edA-qa mort-ora-y: "Jeder relationale DB kann als einfacher Dokument-DB verwendet werden". Das muss falsch sein, sonst hätten die Leute keine Alternative erfunden. "Nur die Leistung wäre ein Unterscheidungsmerkmal". Nur wahr, wenn Sie davon ausgehen, dass das relationale Modell alles gleich gut macht. Wenn es alles tun würde, gäbe es keine Alternative. Noch. Wir haben Alternativen. Es gibt viele Probleme (wie Hierarchien), die nicht perfekt zum relationalen Modell passen und clevere Tricks erfordern. Oder ein alternatives Datenmodell.

— S.Lott

"einige Artikel lesen"? Bitte geben Sie einige Links oder Titel oder Verweise oder Zitate an. Wir wissen nicht, was "zu theoretisch" für Sie bedeutet.

— S.Lott

Antworten:

Der Hauptgrund für die Wahl einer NoSQL-Datenbank in den letzten Jahren war die Verfügbarkeit . Für Unternehmen wie Amazon, Google und Facebook ist eine Ausfallzeit von etwa einer Stunde nicht akzeptabel. Um eine hohe Verfügbarkeit zu erreichen, müssen Sie den Single-Point-of-Failure reduzieren. Das bedeutet, dass Sie ein verteiltes System mit mehreren Computern verwenden müssen, falls ein Computer abstürzt. Der Dienst ist weiterhin verfügbar.

Herkömmliche Relatione-Datenbanken sind in einem verteilten Multi-Master-Setup nicht sehr gut. Aus diesem Grund war NoSQL in letzter Zeit so beliebt. Wenn Sie also eine hohe Verfügbarkeit benötigen, können Sie eine NoSQL-Datenbank wie Riak, Cassandra, HBase, S3 oder BigTable auswählen.

Es gibt einen guten Blog-Beitrag über Amazon Dynamo , der eine gute Einführung in verteilte NoSQL-Datenbanken bietet.

Jetzt ist der NoSQL-Begriff sehr weit gefasst, sodass es viele NoSQL-Datenbanken gibt, die nicht verteilt sind. Aber sie lösen andere Probleme. ZB Neo4j - eine Grafikdatenbank eignet sich für eine Art von Abfragen, für die herkömmliche RDBMS nicht optimiert sind. Oder wie in Ihrem Fall in einer Dokumentendatenbank, in der Sie das Schema nicht ändern müssen, um einige Felder für einige Dokumente hinzuzufügen. Mit anderen Worten, eine Dokumentendatenbank ist gut, wenn die meisten Posts (Dokumente) unterschiedliche Felder aufweisen, sodass eine relationale Tabelle mit vordefinierten Spalten nicht verwendet werden kann.

Die meisten NoSQL-Datenbanken sind jedoch nicht so flexibel wie herkömmliche RDBMS-Datenbanken. Daher ist es eine gute Wahl, eine herkömmliche RDBMS-Datenbank zu verwenden, bis sie Ihre Probleme nicht mehr lösen kann.

— Jonas
quelle

+1, Einverstanden, die Flexibilität ist ein enormer Preis, den Sie zahlen müssen, wenn Sie nicht müssen.

— maple_shaft

Ich habe einen einfachen Ansatz, um die Datenbank zu bestimmen, die am besten zu den Daten passt.

Ich frage mich nur: Angenommen, ich hätte keine Datenbank, würde ich lieber die meisten und wichtigsten Daten als Dokument speichern oder sie in einer Tabelle speichern.

Wenn die Antwort "Tabellenkalkulation" lautet, ist dies ein klares Zeichen dafür, dass ein relationales Modell und ein traditionelles RDBMS den Aufgaben meistens am besten entsprechen. Wenn die Daten wirklich einfach sind, wie nur Schlüsselwertpaare oder einfache Tabellen, und die referenzielle Integrität kein Thema ist, ist eine NoSQL-Datenbank wahrscheinlich am besten für diese Aufgabe geeignet und kann die Leistung erheblich steigern!

Wenn Sie überhaupt keine gemeinsame Struktur finden, ist eine NoSQL-Datenbank am besten für diese Aufgabe geeignet.

Wenn die Daten eher dokumentenähnlich sind, z. B. hierarchisch strukturierte Textdaten ohne eindeutige Relationen, dann denke ich sofort an eine XML-Datenbank, mit der Sie auf einfache Weise hierarchisch strukturierte Dokumente speichern können. Manchmal ist es jedoch am besten, eine Dokumentenverwaltungssoftware zu verwenden.

Um also beide Fragen konkret und einfach zu beantworten: Es kommt auf die Daten an.

als ein Wechsel von einer relationalen zu einer Dokumentendatenbank eine Verbesserung ergab

Wenn Sie hierarchisch strukturierte Textdaten beibehalten müssen, kann eine XML-Datenbank eine große Verbesserung in Bezug auf Wartbarkeit und wahrscheinlich auch Skalierbarkeit darstellen.

als ein Wechsel von einer Dokumenten- zu einer relationalen Datenbank eine Verbesserung brachte

Nun, zum Beispiel, wenn die Daten meist tabellarisch mit eindeutigen Beziehungen vorliegen und Sie die Integrität gewährleisten müssen.

— Falke
quelle

+1 für die Tabellenkalkulation im Vergleich zur Dokumentenanalogie - große Hilfe - danke.

— HDave

Wir mussten das relationale Modell aufgeben, weil die Daten, die wir erhielten, kein einfaches, offensichtliches, festes, statisches Schema hatten.

Die Benutzer - und die User Stories - hatten kein festes statisches Schema.

Wir haben versucht, ein festes, statisches RDBMS-Schema einzuführen, aber es war ein Fehler.

Jede Datenlieferung von Drittanbietern (von Kunden und Lieferanten) war ähnlich, aber nicht identisch. Wir haben versucht, es einem festen relationalen Schema zuzuordnen, aber die Variabilität war zu groß. Entweder mussten wir mit jeder Datei Felder hinzufügen (mehrere pro Woche) oder wir mussten uns vom festen, statischen relationalen Schema entfernen.

Wenn wir jeden Datensatz als "Dokument" mit einer gemeinsamen Teilmenge betrachten von Elementen und einer eindeutigen (und auch schlecht definierten) Sammlung zusätzlicher Datenelemente betrachteten, waren wir sehr viel glücklicher.

Die schlecht definierte Sammlung von Datenelementen ist das, was die Benutzer tatsächlich für ihre Anwendungsfälle benötigten.

Das feste statische Schema des relationalen Modells passte nicht zu unseren Anwendungsfällen.

— S.Lott
quelle

Ich habe gesehen, dass andere Projekte die Anforderungen aufgrund der von Ihnen beschriebenen Anforderungen nicht erfüllen. Dafür waren Dokumentendatenbanken gedacht.

— maple_shaft