Ist die Verwendung von NoSQL-Datenbanken für große Datasets, in denen Sie nach Inhalten suchen müssen, unpraktisch?

51

Ich habe jetzt seit einer Woche etwas über NoSQL-Datenbanken gelernt.

Ich verstehe wirklich die Vorteile von NoSQL-Datenbanken und die vielen Anwendungsfälle, für die sie großartig sind.

Aber oft schreiben Leute ihre Artikel, als ob NoSQL relationale Datenbanken ersetzen könnte . Und da ist der Punkt, an dem ich mich nicht zurechtfinden kann:

NoSQL-Datenbanken sind (oft) Schlüsselwertspeicher.

Natürlich ist es möglich , zu speichern , alles in einen Schlüssel-Wert - Speicher (durch die Daten in JSON codiert, XML, was auch immer), aber das Problem , das ich sehe , ist , dass Sie brauchen , um zu bekommen eine gewisse Menge an Daten , die ein bestimmtes Kriterium übereinstimmt, in vielen Anwendungsfälle. In einer NoSQL-Datenbank gibt es nur ein Kriterium, nach dem Sie effektiv suchen können - den Schlüssel. Relationale Datenbanken werden optimiert, um effektiv nach jedem Wert in der Datenzeile zu suchen.

NoSQL-Datenbanken sind also nicht wirklich eine Wahl für persistente Daten, die nach ihrem Inhalt durchsucht werden müssen. Oder habe ich etwas falsch verstanden?

Ein Beispiel:

Sie müssen Benutzerdaten für einen Webshop speichern.

In einer relationalen Datenbank speichern Sie jeden Benutzer als Zeile in der usersTabelle mit einer ID, dem Namen, seinem Land usw.

In einer NoSQL-Datenbank würden Sie jeden Benutzer mit seiner ID als Schlüssel und all seinen Daten (in JSON usw. codiert) als Wert speichern.

Wenn Sie also alle Benutzer aus einem bestimmten Land abrufen möchten (aus irgendeinem Grund müssen die Marketingmitarbeiter etwas über sie wissen), ist dies in der relationalen Datenbank einfach, in der NoSQL-Datenbank jedoch nicht sehr effektiv, da dies erforderlich ist Holen Sie sich jeden Benutzer, analysieren Sie alle Daten und filtern Sie.

Ich sage nicht, dass es unmöglich ist , aber es wird viel kniffliger und ich denke, es ist nicht so effektiv, wenn Sie in den Daten von NoSQL-Einträgen suchen möchten.

Sie können einen Schlüssel für jedes Land erstellen, in dem die Schlüssel aller in diesem Land lebenden Benutzer gespeichert sind, und die Benutzer eines bestimmten Landes abrufen, indem Sie alle Schlüssel abrufen, die im Schlüssel für dieses Land hinterlegt sind. Aber ich denke, diese Technik macht ein komplexes Dataset noch komplexer - es ist schwieriger zu implementieren und nicht so effektiv wie das Abfragen einer SQL-Datenbank. Ich denke, das ist kein Weg, den Sie in der Produktion verwenden würden. Oder ist es?

Ich bin mir nicht sicher, ob ich etwas missverstanden oder einige Konzepte oder bewährte Methoden zur Behandlung solcher Anwendungsfälle übersehen habe. Vielleicht könnten Sie meine Aussagen korrigieren und meine Fragen beantworten.

Leo Lindhorst
quelle
16
Das liest sich eher wie ein Schimpfen als wie eine Frage. Sie scheinen die Vor- und Nachteile der Speicherung von Schlüsselwerten im Vergleich zur relationalen Speicherung gut zu verstehen. Was genau ist die Frage?
JacquesB
16
Es ist überhaupt kein Scherz :) NoSQL-Datenbanken sind fantastisch, aber ich denke, relationale Datenbanken sind nicht so schlecht, wie es manche Leute behaupten. Ich möchte nur herausfinden, ob meine These, dass NoSQL-Datenbanken nicht die beste Wahl sind, wenn es um die Suche in 'Datenzeilen' geht ... oder ob ich das Thema nicht richtig verstanden habe.
Leo Lindhorst
2
programmers.stackexchange.com/q/54373/17853
Leichtigkeit Rennen mit Monica
5
Aber MongoDB ist Webscale ! [Warnung: enthält einige NSFW-Sprache]
Jerry Coffin
5
@ DevWurm: Sie sollten Schlüsselwertspeicher im Allgemeinen nicht mit NoSQL in Konflikt bringen. Zum Beispiel wird googles BigTable als NoSQL-Datenbank betrachtet, aber Sie können weiterhin Indizes für mehrere Felder suchen und erstellen. Ein Schlüsselwertspeicher ist geeignet, wenn Sie wissen, dass Sie nur in einem einzigen Feld (dem Schlüssel) suchen müssen.
JacquesB

Antworten:

40

Ich stimme Ihrer Annahme zu, dass NoSQL kein Allheilmittel für alle Datenbankprobleme ist, aber ich denke, Sie verstehen einen wichtigen Punkt falsch.

In der NoSQL-Datenbank gibt es nur ein Kriterium, nach dem Sie effektiv suchen können - den Schlüssel.

Dies ist eindeutig nicht wahr.

Zum Beispiel unterstützt MongoDB Indizes. (von https://docs.mongodb.org/v3.0/core/indexes-introduction/ )

Indizes unterstützen die effiziente Ausführung von Abfragen in MongoDB. Ohne Indizes muss MongoDB einen Sammlungsscan durchführen, dh jedes Dokument in einer Sammlung scannen, um die Dokumente auszuwählen, die der Abfrageanweisung entsprechen. Wenn für eine Abfrage ein geeigneter Index vorhanden ist, kann MongoDB den Index verwenden, um die Anzahl der zu überprüfenden Dokumente zu begrenzen.

Indizes sind spezielle Datenstrukturen [1], die einen kleinen Teil des Datensatzes der Sammlung in leicht zu durchsuchender Form speichern. Der Index speichert den Wert eines bestimmten Feldes oder einer Reihe von Feldern, geordnet nach dem Wert des Feldes. Die Reihenfolge der Indexeinträge unterstützt effiziente Gleichheitsübereinstimmungen und bereichsbezogene Abfrageoperationen. Außerdem kann MongoDB sortierte Ergebnisse anhand der Reihenfolge im Index zurückgeben.

Ebenso wie couchbase (von http://docs.couchbase.com/admin/admin/Views/views-intro.html )

Couchbase-Ansichten ermöglichen die Indizierung und Abfrage von Daten.

Eine Ansicht erstellt einen Index für die Daten gemäß dem definierten Format und der definierten Struktur. Die Ansicht besteht aus bestimmten Feldern und Informationen, die aus den Objekten in Couchbase extrahiert wurden.

Tatsächlich sollte alles, was sich selbst als NoSQL- Datenbank und nicht als Schlüsselwertspeicher bezeichnet, eine Art Indexschema unterstützen.

Tatsächlich ist es oft die Flexibilität dieser Indexschemata, die NoSQL zum Leuchten bringt. Meiner Meinung nach ist die Sprache, in der die NoSQL-Indizes definiert werden, oft ausdrucksvoller oder natürlicher als SQL. Da sie normalerweise außerhalb der Tabelle leben, müssen Sie Ihre Tabellenschemata nicht ändern, um sie zu unterstützen. (Um nicht zu sagen, dass Sie in SQL keine ähnlichen Aktionen ausführen können, aber für mich scheint es, dass viel mehr Hoop-Jumping erforderlich ist).

Michael Anderson
quelle
13
"... da sie normalerweise außerhalb der Tabelle leben, müssen Sie Ihre Tabellenschemata nicht ändern, um sie zu unterstützen." Das ist die gleiche Situation zwischen einem nicht gruppierten Index in einer SQL-Datenbank und einem Index für eine noSQL-Datenbank, oder?
Jirka Hanika
Ziemlich solide Antwort. Ich möchte hinzufügen, dass NoSQL in gewisser Weise auf der Idee beruht, dass Sie 90% ++ - Anfragen über einen Primärschlüssel ohne Join stellen sollten, wenn Sie schneller arbeiten möchten, und wenn Sie etwas anderes tun möchten, sind Sie in der Welt der Tabellenscans und Sekundärindizes, für die immer Leistungs- und Skalenbeschränkungen gelten. Sobald Sie einen Index durchsucht oder eine Gruppe erstellt haben, befinden Sie sich einfach nicht mehr in dem Bereich, in dem die Geschwindigkeit erreicht werden kann (mit Ausnahme kleiner Datenmengen von wenigen Millionen Zeilen). Wenn Sie in einem Stil codieren, in dem alternative Suchvorgänge selten sind, erhalten Sie ein sehr solides Betriebssystem.
Brian Bulkowski
40

Wenn Ihr Workflow perfekt zu relationalen Datenbankabfragen passt, sind relationale Datenbanken im Allgemeinen der effizienteste Ansatz. Es ist tautologisch, aber es ist wahr.

Viele NoSQL-Befürworter behaupten, dass viele Workflows tatsächlich in eine relationale Form gebracht wurden und vor einer solchen Massage effektiver gewesen wären. Die Gültigkeit dieses Anspruchs ist nur schwer festzustellen. Offensichtlich gibt es Jobs, die durch SQL-Abfragen sehr gut beschrieben werden. Aus meiner Erfahrung kann ich sagen, dass meine speziellen relationalen Programmieraufgaben mit NoSQL mit nahezu der gleichen Effizienz hätten erledigt werden können, wenn nicht sogar mit mehr. Dies ist jedoch eine sehr subjektive Aussage, die auf engen Erfahrungen basiert.

Ich habe das Gefühl, dass ein Großteil des Verkaufs des NoSQL-Ansatzes auf der Annahme großer Datenbanken beruht. Je größer die Datenbank ist, desto mehr müssen Sie Ihren Workflow optimieren, um die größeren Datasets zu unterstützen. NoSQL scheint diese Bemühungen besser zu unterstützen. Je größer die Datenbank ist, desto wichtiger können die Funktionen von NoSQL sein.

Um das Beispiel zu verwenden, ist die SQL-Abfrage nach Land genauso langsam wie die NoSQL-Abfrage aller Benutzer, es sei denn, Sie haben SQL ausdrücklich angewiesen, die usersTabelle nach Land zu indizieren . NoSQL kann dasselbe tun, indem Sie eine geordnete Schlüsselwertsammlung erstellen, bei der es sich um den Index handelt (genau wie bei SQL unter der Haube) und diesen verwalten.

Der Unterschied? SQL-Engines hatten das Konzept, die Tabelle zu indizieren. Dies bedeutet, dass Sie weniger Arbeit erledigen müssen (alles, was Sie tun müssen, ist, der Tabelle einen Index hinzuzufügen). Dies bedeutet jedoch auch, dass Sie weniger Kontrolle hatten. In den meisten Fällen ist dieser Kontrollverlust akzeptabel, wenn die SQL-Engine die Arbeit für Sie erledigt. In umfangreichen Datasets möchten Sie jedoch möglicherweise ein anderes Konsistenzmodell als das typische SQL ACID-Modell. Möglicherweise möchten Sie das BASE-Modell verwenden, das eine eventuelle Konsistenz unterstützt. Dies kann in SQL sehr schwierig sein, da die SQL-Engine die Arbeit für Sie erledigt, sodass dies nach den Regeln der SQL-Engine erfolgen muss. In NoSQL sind diese Ebenen in der Regel freigelegt, sodass Sie sie angreifen können.

Cort Ammon
quelle
2
In Ihrem Beispiel behaupten Sie, dass die SQL-Abfrage nach Land genauso langsam ist wie der NoSQL-Scan aller Benutzer . Haben Sie Beweise dafür? Das in der Frage beschriebene NoSQL ist ein Schlüssel-Wert-Paar. Sie müssten also den Wert scannen, um den Standort des Landes zu ermitteln, und dann den Vergleich durchführen. SQL weiß bereits, wo sich diese Daten befinden, sodass es sie direkt von der Festplatte auswählen kann (überspringen, was nicht benötigt wird) und dann den Wert überprüfen kann. Wenn das Land ein Fremdschlüssel ist, handelt es sich um einen schnellen Ganzzahlvergleich. Wound't dies wird immer schneller sein, da Sie weniger von der Festplatte ziehen und die Überprüfung schneller ist.
Trisped
1
@Trisped Es ist schwierig, Beweise zu liefern, da NoSQL ein Ansatz ist, kein Produkt (dasselbe gilt für SQL). Beachten Sie jedoch, dass BigTable, eine NoSQL-Implementierung, genau wie SQL-Tabellen über ein Spaltenkonzept verfügt. Es ist das Konzept von Spalten, mit dem Sie Daten überspringen können, indem Sie wissen, wo sie zu suchen sind, und das auf beide Implementierungen angewendet werden kann.
Cort Ammon
16

NoSQL ist ein eher vager Begriff, da er grundsätzlich alle nicht relationalen Datenbanksysteme abdeckt.

Was Sie beschreiben, ist ein Schlüsselwertspeicher , eine Art Datenbank, in der ein Datenblock unter einem Schlüssel gespeichert ist und der schnell nachgeschlagen werden kann, wenn Sie den Schlüssel kennen. Diese Datenbanken sind unglaublich schnell, wenn Sie den genauen Schlüssel kennen. Wenn Sie jedoch, wie Sie selbst sagen, mehrere Eigenschaften der Daten durchsuchen oder filtern müssen, ist dies langsam und umständlich.

Niemand, der bei Verstand ist, würde behaupten, Schlüsselwertspeicher könnten relationale Datenbanken im Allgemeinen ersetzen. Es kann jedoch bestimmte Anwendungsfälle geben, in denen der Schlüsselwertspeicher gut passt. Schlüsselwertspeicher werden häufig zum Zwischenspeichern verwendet, da Sie Elemente in der Regel nach ID zwischenspeichern, jedoch keine Ad-hoc-Abfragen für Caches durchführen müssen. Beispielsweise verwendet die Stackoverflow-Site selbst Redis (einen Schlüsselwert db) in großem Umfang , jedoch nur zum Zwischenspeichern der Ausgabe. Die zugrunde liegenden kanonischen Daten werden weiterhin in einer relationalen Datenbank gespeichert.

Die Antwort liegt auf der Hand: Verwenden Sie einen Schlüsselwertspeicher, wenn Sie nur einen einzigen Schlüssel zum Speichern und Nachschlagen benötigen. Verwenden Sie andernfalls eine andere Art von Datenbank. Und wenn Sie Zweifel haben, verwenden Sie eine relationale Datenbank, da dies die vielseitigste Art von Datenbank ist, während die NoSQL-Datenbanken häufig für ganz bestimmte Anwendungsfälle optimiert sind.

JacquesB
quelle
2
"NoSQL ist ein ziemlich vager Begriff, da er im Grunde alle Datenbanksysteme abdeckt, die nicht relational sind." - Das ist nicht wahr. Es umfasst alle Datenbanksysteme, die keine SQL-Datenbanken sind. Es gibt relationale Datenbanken, die kein SQL verwenden, wie z. B. Rel und Tutorial D (Datenbanken, die so konzipiert sind, dass sie dem relationalen Modell besser folgen, ohne die von SQL verursachte "Erweichung"). Es gibt hyperrelationale Datenbanken. In Wirklichkeit bedeutet NoSQL "Nicht nur SQL", was bedeutet "SQL nicht automatisch übernehmen, das richtige Datenbankmodell auswählen, das der Struktur Ihres Datums entspricht ... das kann sehr gut SQL sein."
Jörg W Mittag
@ JörgWMittag Nach Ihrer Definition ist MySQL eine gültige NoSQL-Lösung, wenn ich mich für MySQL entscheide, weil es die beste Datenbank für meine Daten ist.
1
@ JörgWMittag: Thee ist keine offizielle Definition des Begriffs NoSQL, bezieht sich aber normalerweise auf nicht relationale Datenbanksysteme. Das "Nicht nur Sql" -Backronym ist wirklich ein neueres Retcon, um dem unvermeidlichen Hype-Backlash entgegenzuwirken. Aber im allgemeinen Sprachgebrauch wird NoSQL verwendet, um Systeme wie MongoDb, Bigtable usw. zu beschreiben, nicht etwa Tutorial D (das nicht einmal eine Datenbank ist).
JacquesB
2
@ JörgWMittag NoSQL bedeutete ursprünglich "non SQL" oder "non relational". Das "Nicht nur SQL" wäre NOSQL, da es ein Akronym anstelle der Kombination aus dem Wort "Nein" und dem Akronym "SQL" ist. Es wurde populär als Gegenmaßnahme zur allgemeinen Praxis, alles in eine Datenbank zu stellen (wie im Wikipedia-Artikel angegeben). Wie Sie kommentiert haben, ist das Feld jetzt ziemlich viel komplexer.
Trisped
Stimme voll und ganz zu. Es scheint, dass die Hauptmuster von NoSQL der Schlüsselwert-Dokumentenspeicher (z. B. Redis) (z. B. Mongo) und der Graph (z. B. Neo4J) sind. Ich wünschte, die Leute würden NoSQL fallen lassen und einen dieser Begriffe verwenden.
paj28
10

Ihre Aussagen zu relationalen Datenbanken sind zutreffend, bis zu dem Zeitpunkt, an dem Sie über so viele Daten verfügen, dass Sie keine Kopie mehr auf einem einzelnen Server speichern können. Dann stoßen Sie auf allerlei interessante Probleme. Wie können Sie Ihre Tabellen aufteilen, damit die meisten Ihrer Abfragen auf einem einzelnen Server ausgeführt werden können? Wie viele Kopien der Daten machen Sie? Wie gehen Sie mit Inkonsistenzen zwischen diesen Kopien um? Wie bewahren Sie die Daten eines Benutzers in einem Rechenzentrum auf, das ihm geografisch relativ nahe steht?

Diese Ziele stehen häufig im Widerspruch zueinander. Viele Twitter-Nutzer folgen Leuten aus der ganzen Welt. Sollte die Datenbank von Twitter geografisch optimiert werden, um Tweets zu lesen oder Tweets zu schreiben?

Es stellt sich heraus, dass Sie, wenn Sie sich mit dieser Art von Skalierung befassen, anfangen, Lösungen zu erfinden, Redundanzen hinzuzufügen und Einschränkungen aufzuerlegen, die einer NoSQL-Datenbank sehr ähnlich sind. Wenn Sie alle Ihre Daten in einer Box unterbringen können, gelten nur die Einschränkungen und Sie müssen die Vorteile nicht in Anspruch nehmen.

Karl Bielefeldt
quelle
Das Einlesen von 10 TB in den Arbeitsspeicher dauert eine Weile @Daniel ... Ein paar Stunden wären ein ziemlich gutes Ergebnis. Es würde die Wiederherstellung nach einer Katastrophe relativ katastrophal machen.
Ben
1
Ich würde sagen, dass Big Data sicherlich ein Bereich ist, in dem NoSQL-Datenbanken ins Spiel kommen, aber es ist nur einer. Es gibt auch viele andere Gründe, warum eine NoSQL-Datenbank besser zu einem Problem passt. Wenn Sie über Datendiagramme verfügen, ist die Verwendung einer Diagrammdatenbank sinnvoll. Wenn Sie über XML-Daten verfügen, ist die Verwendung einer XML-Datenbank sinnvoll. Nicht nur Big Data, sondern auch das Datenmodell ist ein wichtiges Kriterium bei der Auswahl einer geeigneten Datenbank (und natürlich sind SQL-Datenbanken je nach Problem
oft
5
Das ist falsch. Sharding als Programmieransatz ist seit Jahren Standard in großen Datenbanken und einige Datenbanken unterstützen Cluster mit transparenter Datenfreigabe (Oracle RAC). Wie denken Sie, arbeiten alle Banken? Und mit einer korrekten Einrichtung stellen Sie SELTEN Backups wieder her - das ist ein echtes Szenario mit "2 abgebrannten Rechenzentren". Und ja, wir haben einmal an einer 30-TB-Datenbank gearbeitet - wir hatten keine Probleme.
TomTom
Ja, relationale Datenbanken führen transparentes Daten-Sharding und Clustering durch, aber es ist eine sehr undichte Abstraktion, wenn Sie die Leistung optimieren möchten.
Karl Bielefeldt
5

NoSQL-Datenbanken haben sehr wenig mit „ No SQL“ zu tun .

Sie sind etwa zugibt , dass Sie nicht eine Datenbank eingegeben haben , in großem Maßstab , die immer konsistent ist und unterstützt komplexe Transaktionen und hat lange Lebensdauer.

In einer normalen relationalen Datenbank werden alle Indizes im Rahmen einer Transaktion automatisch aktualisiert und können für jede Abfrage verwendet werden.

In einer NoSQL-Datenbank ist der Programmierer für die Verwaltung vieler Indizes verantwortlich, und es wird davon ausgegangen, dass Indizes immer veraltet sind.

Zum Beispiel:

  • Ein Index der Personen nach Steuernummer kann einige Personen enthalten, die den Prozess der Steuerregistrierung niemals abschließen.
  • Daher muss Code, der den Index verwendet, in der Lage sein, eine unvollständige Steuerregistrierung zu bewältigen
  • Eine andere Möglichkeit besteht darin, Zeiten zu haben, in denen eine Person, die für Steuern registriert ist, nicht im Index enthalten ist. (Ihr Design muss sich also mit nicht konsistenten Daten auseinandersetzen und entscheiden, wie die Daten nicht konsistent sein sollen.)

Als ein reales Beispiel würde Amazon mir lieber die veraltete Beschreibung eines Buches zeigen, als die Anzeige der Webseite zu verzögern, indem es darauf wartet, dass 106 Computer bestätigen, dass die richtige Sperre aufgehoben wurde.

Deshalb.....

Wenn eine einzelne normale relationale Datenbank alle Ihre Daten enthalten und jede Transaktion so schnell verarbeiten kann, dass das Sperren Ihr System nicht von nützlichen Aufgaben abhält, ist eine relationale Datenbank die beste Option.

Sobald Sie jedoch darüber nachdenken müssen, mehr als eine relationale Datenbank zu verwenden oder Transaktionen aufzuteilen, um Sperrfehler zu vermeiden, müssen Sie sich mit den Problemen befassen, die bei der Verwendung von „NoSQL“ -Datenbanken auftreten.

Da "NoSQL" -Datenbanken diese Probleme nicht verbergen, sind sie möglicherweise die beste Option, wenn Sie ein System skalieren. Beachten Sie jedoch, dass Stackoverflow weiterhin eine relationale Datenbank zum Speichern aller Daten verwendet, wobei NoSQL in der Caching-Ebene nur in begrenztem Umfang verwendet wird. Sie müssen also SEHR groß sein, bevor Sie NoSQL zum Speichern Ihrer Daten verwenden müssen.

Ian
quelle
Dieser letzte Leckerbissen ist sehr interessant - haben Sie einen Link zu einer Meta-SO-Site, auf die interessierte Leser klicken können, um sich über die (nicht) Verwendung von NoSQL durch SO zu informieren? Vielen Dank!
Kcrisman
@kcrisman, siehe highscalability.com/stack-overflow-architecture für Beispiel
Ian
2

Relationale Datenbanken werden optimiert, um effektiv nach jedem Wert in der Datenzeile zu suchen.

Verwechseln Sie nicht die Möglichkeit, nach "jedem" Wert in einer Zeile mit "jedem" Wert in einer Zeile zu suchen. Der effektivste Weg, dies zu tun, erfordert einen oder mehrere Indizes. Sie könnten festlegen, dass Indizes alle Felder enthalten, aber Sie haben nur verhindert, dass Sie Änderungen vornehmen können, die eine Änderung des Index erfordern (Einfügungen, Aktualisierungen, Löschungen). Sie (oder Ihr DBA) müssen die Daten, die Verwendung, Engpässe usw. verstehen.

JeffO
quelle
Ein gutes Beispiel wäre das Speichern von Chats. Möglicherweise müssen sie mit anderen Daten in Beziehung gesetzt und alle Arten von Analysen durchgeführt werden. Während der eigentlichen Chatsitzung werden die Benutzer jedoch etwas Schnelleres zu schätzen wissen, das nicht den gesamten Aufwand eines RDBMS wie eine Transaktion oder eine Einschränkung aufweist.
JeffO
-1

Es gibt bereits viele Antworten, aber ich wollte nur meine Zusammenfassung hinzufügen.

Das NoSQL-Konzept deckt eine Vielzahl unterschiedlicher Ansätze ab, um Daten auf der Festplatte und im Speicher zu organisieren und über eine Abfragesprache verfügbar zu machen (einige sind sogar SQL-ähnlich!). Meiner Ansicht nach liegt die Stärke in dieser Vielzahl von Systemen, sodass Sie das beste Werkzeug für den Job auswählen können. Hoffentlich können Sie ein Dutzend unterschiedlicher Anforderungen mit nur wenigen unterschiedlichen Lösungen abdecken, und Sie möchten nicht ein Dutzend unterschiedlicher Systeme verwalten.

Relationale Datenbanken können Sie sehr weit bringen und sind eine bewährte Technologie, aber genau wie die Datenbank möchten Sie möglicherweise die Programmiersprache basierend auf den Anforderungen jedes Projekts auswählen (wobei auch die Erfahrung des Teams berücksichtigt wird).

NikoNyrh
quelle
-2

Ich benutze jetzt seit zwei Jahren couchdb. Es wird hauptsächlich für die Verwaltung und Konfiguration von Inhalten verwendet.

Hierarchische Beziehungen sind viel einfacher zu verwalten, wenn Sie sie visualisieren können. Bei meistens gelesenen Daten ist es in vielen Fällen einfacher, JSON zu bearbeiten, als eine UPDATE-Anweisung zu schreiben. Benötigt eigentlich keinen Programmierer, um JSON zu bearbeiten. Und SQL gibt Ihnen Zeilen und Spalten, die Sie dann in eine Art Objektstruktur abbilden müssen.

Sie erhalten auch eine Leistungssteigerung, weil Sie bei komplexen Abfragen nicht 10 bis 20 Tabellen beitreten. Couchdb-Ansichten sind sehr schnell, da das JavaScript, auf dem sie basieren, zum Zeitpunkt der Abfrage nicht ausgeführt wird.

Die meisten Programmierer verstehen Javascript, und die meisten Programmierer haben gelegentlich Probleme mit SQL.

In Couchdb kann eine Ansicht als Zusammenfassung eines JSON-Dokuments betrachtet werden. Wie die Ansichtsdaten strukturiert sind, bleibt Ihnen überlassen (Sie sind nicht an die ursprüngliche Hierarchie gebunden).

Ich würde Couchdb nicht für hochgradig transaktionale Daten verwenden, aber für semistatische Daten mit einer Struktur vom Typ Teileexplosion ist die Arbeit mit Couchdb VIEL einfacher als mit SQL.

Beachten Sie jedoch, dass es keine eindeutige 'Normalisierung' gibt, die angewendet werden kann (obwohl das Vermeiden von Datenduplikationen ein würdiges Ziel ist), und dass es im Wesentlichen eine 'optimistische' Aktualisierungsstrategie gibt, die einer optimistischen Sperrung ähnelt.

Jeff Lowery
quelle