Ich habe gerade erst mit nicht relationalen DBs angefangen und versuche immer noch, meinen Kopf darum zu wickeln und herauszufinden, welches das beste Modell wäre. Und ich kann nur für CouchDB sprechen.
Dennoch habe ich einige vorläufige Schlussfolgerungen:
Haben Sie alternative Designs entwickelt, die in der nicht relationalen Welt viel besser funktionieren?
Der Entwurfsfokus verschiebt sich: Der Entwurf des Dokumentmodells (entsprechend DB-Tabellen) wird fast irrelevant, während alles vom Entwurf der Ansichten abhängt (entsprechend Abfragen).
Die Dokument-DB tauscht die Komplexität aus: SQL verfügt über unflexible Daten und flexible Abfragen, Dokument-DBs sind umgekehrt.
Das CouchDB-Modell ist eine Sammlung von "JSON-Dokumenten" (im Grunde verschachtelte Hash-Tabellen). Jedes Dokument hat eine eindeutige ID und kann trivial anhand der ID abgerufen werden. Für jede andere Abfrage schreiben Sie "Ansichten", die als Sätze von Map / Reduce-Funktionen bezeichnet werden. Die Ansichten geben eine Ergebnismenge als Liste von Schlüssel / Wert-Paaren zurück.
Der Trick besteht darin, dass Sie die Datenbank nicht in dem Sinne abfragen, wie Sie eine SQL-Datenbank abfragen: Die Ergebnisse der Ausführung der Ansichtsfunktionen werden in einem Index gespeichert, und nur der Index kann abgefragt werden. (Als "alles abrufen", "Schlüssel abrufen" oder "Schlüsselbereich abrufen".)
Die nächste Analogie in der SQL-Welt wäre, wenn Sie die Datenbank nur mit gespeicherten Prozeduren abfragen könnten - jede Abfrage, die Sie unterstützen möchten, muss vordefiniert sein.
Das Design der Dokumente ist enorm flexibel. Ich habe nur zwei Einschränkungen gefunden:
- Halten Sie verwandte Daten im selben Dokument zusammen, da nichts einem Join entspricht.
- Machen Sie die Dokumente nicht so groß, dass sie zu häufig aktualisiert werden (z. B. wenn alle Unternehmensverkäufe des Jahres in demselben Dokument zusammengefasst werden), da bei jeder Dokumentaktualisierung eine erneute Indizierung ausgelöst wird.
Aber alles hängt von der Gestaltung der Ansichten ab.
Die alternativen Designs, bei denen ich festgestellt habe, dass Arbeitsabläufe mit CouchDB um Größenordnungen besser sind als mit jeder anderen SQL-Datenbank, befinden sich eher auf Systemebene als auf Speicherebene. Wenn Sie Daten haben und diese auf einer Webseite bereitstellen möchten, wird die Komplexität des Gesamtsystems um mindestens 50% reduziert:
- Kein Entwerfen von DB-Tabellen (kleines Problem)
- Keine ODBC / JDBC-Zwischenschicht, alle Abfragen und Transaktionen über http (mäßiges Problem)
- einfache Zuordnung von DB zu Objekt von JSON, die im Vergleich zu SQL fast trivial ist (wichtig!)
- Sie können möglicherweise den gesamten Anwendungsserver überspringen, da Sie Ihre Dokumente so gestalten können, dass sie direkt vom Browser mit AJAX abgerufen werden, und ein wenig JavaScript-Polieren hinzufügen, bevor sie als HTML angezeigt werden. (ENORM!!)
Für normale Webanwendungen sind dokument- / JSON-basierte DBs ein enormer Gewinn, und die Nachteile weniger flexibler Abfragen und zusätzlichen Codes für die Datenvalidierung scheinen ein geringer Preis zu sein.
Haben Sie Ihren Kopf gegen etwas geschlagen, das unmöglich erscheint?
Noch nicht. Das Zuordnen / Reduzieren als Mittel zum Abfragen einer Datenbank ist unbekannt und erfordert viel mehr Nachdenken als das Schreiben von SQL. Es gibt eine relativ kleine Anzahl von Grundelementen. Daher ist es in erster Linie eine Frage der Kreativität, wie Sie die Schlüssel angeben, um die gewünschten Ergebnisse zu erzielen.
Es gibt eine Einschränkung darin, dass Abfragen nicht zwei oder mehr Dokumente gleichzeitig anzeigen können - keine Verknüpfungen oder andere Arten von Beziehungen mit mehreren Dokumenten, aber bisher war nichts unüberwindbar.
Als Beispiel sind Einschränkungen und Summen einfach, aber Durchschnittswerte können nicht von einer CouchDB-Ansicht / Abfrage berechnet werden. Fix: Summe zurückgeben und separat zählen und den Durchschnitt auf dem Client berechnen.
Haben Sie die Lücke mit Designmustern geschlossen, z. B. um von einem zum anderen zu übersetzen?
Ich bin mir nicht sicher, ob das machbar ist. Es ist eher eine vollständige Neugestaltung, wie die Übersetzung eines funktionalen Stilprogramms in einen objektorientierten Stil. Im Allgemeinen gibt es weit weniger Dokumenttypen als SQL-Tabellen und mehr Daten in jedem Dokument.
Eine Möglichkeit, sich das vorzustellen, besteht darin, in Ihrem SQL nach Einfügungen und allgemeinen Abfragen zu suchen: Welche Tabellen und Spalten werden beispielsweise aktualisiert, wenn ein Kunde eine Bestellung aufgibt? Und welche für monatliche Verkaufsberichte? Diese Informationen sollten wahrscheinlich im selben Dokument enthalten sein.
Das heißt: Ein Dokument für die Bestellung, das Kunden- und Produkt-IDs enthält, mit nach Bedarf replizierten Feldern, um die Abfragen zu vereinfachen. Alles innerhalb eines Dokuments kann einfach abgefragt werden. Alles, was einen Querverweis zwischen Bestellung und Kunde erfordert, muss vom Kunden erledigt werden. Wenn Sie also einen Bericht über Verkäufe nach Regionen wünschen, sollten Sie wahrscheinlich einen Regionalcode in die Bestellung einfügen.
Machen Sie jetzt überhaupt explizite Datenmodelle (zB in UML)?
Entschuldigung, ich habe auch noch nie viel UML vor Dokument-DBs gemacht :)
Sie benötigen jedoch ein Modell, das angibt, welche Felder zu welchen Dokumenten gehören und welche Arten von Werten sie enthalten. Sowohl zu Ihrer späteren Referenz als auch um sicherzustellen, dass jeder, der die Datenbank verwendet, die Konventionen kennt. Da Sie keine Fehlermeldung mehr erhalten, wenn Sie beispielsweise ein Datum in einem Textfeld speichern und jeder ein beliebiges Feld hinzufügen oder entfernen kann, benötigen Sie sowohl Validierungscode als auch Konventionen, um die Lücke zu schließen. Vor allem, wenn Sie mit externen Ressourcen arbeiten.
Vermissen Sie einen der wichtigsten zusätzlichen Dienste, die RDBMS anbieten?
Nee. Aber mein Hintergrund ist Webanwendungsentwickler, wir beschäftigen uns mit Datenbanken nur in dem Maße, wie wir müssen :)
Ein Unternehmen, für das ich früher gearbeitet habe, hat ein Produkt (eine Webanwendung) entwickelt, das für die Ausführung in SQL-Datenbanken mehrerer Anbieter konzipiert wurde. Die "zusätzlichen Dienste" unterscheiden sich von Datenbank zu Datenbank so stark, dass sie für jede Datenbank separat implementiert werden mussten. Daher war es für uns weniger Arbeit, die Funktionalität aus dem RDBMS zu entfernen. Dies wurde sogar auf die Volltextsuche ausgeweitet.
Was immer ich aufgebe, ist etwas, das ich nie wirklich hatte. Offensichtlich kann Ihre Erfahrung abweichen.
Eine Einschränkung: Ich arbeite gerade an einer Webanwendung für Finanzdaten, Börsenkurse und dergleichen. Dies passt sehr gut zu einer Dokument-Datenbank. Aus meiner Sicht bekomme ich alle Vorteile einer Datenbank (Persistenz und Abfragen) ohne Probleme.
Diese Daten sind jedoch ziemlich unabhängig voneinander, es gibt keine komplexen relationalen Abfragen. Erhalten Sie die neuesten Angebote per Ticker, erhalten Sie Angebote nach Ticker und Datumsbereich, erhalten Sie Unternehmens-Meta-Informationen, das ist so ziemlich alles. Ein anderes Beispiel, das ich gesehen habe, war eine Blog-Anwendung, und Blogs sind auch nicht durch massiv komplizierte Datenbankschemata gekennzeichnet.
Ich versuche zu sagen, dass alle mir bekannten erfolgreichen Anwendungen von Dokument-DBs Daten enthielten, die in erster Linie nicht viel miteinander zu tun hatten: Dokumente (wie in der Google-Suche), Blog-Beiträge, Nachrichtenartikel, Finanzdaten .
Ich gehe davon aus, dass es Datasets gibt, die SQL besser zuordnen als dem Dokumentmodell. Daher kann ich mir vorstellen, dass SQL überleben wird.
Aber für diejenigen von uns, die nur eine einfache Möglichkeit zum Speichern und Abrufen von Daten suchen - und ich vermute, dass es viele von uns gibt - sind Dokumentendatenbanken (wie in CouchDB) ein Glücksfall.