mongodb - tutorial - nosql database example




NoSQL Referenzdaten (4)

Dieser Beitrag ist seit einiger Zeit hier, aber ich dachte, ich würde auf eine andere Methode hinweisen, um Joins zu behandeln und Referenzen mit CouchDB zu dokumentieren. Dies ist eine Methode, die ich im CMS verwende, das ich (re) schreibe, um CouchDB zu verwenden (früher wurde es für MySQL geschrieben).

Das CMS heißt BlueInk und kann auf Github unter http://github.com/BigBlueHat/BlueInk gefunden werden. Derzeit konzentriert sich das Neuschreiben auf den Dokumententwurf und den "Rendering-Engine" -Teil, also gibt es kein UI, von dem man sprechen könnte - Sie muss alle JSON von Hand fertigen. Das ist etwas, was ich hoffentlich bald beheben kann, aber es gibt schon genug im Repo (sobald es in CouchDB installiert wurde), um dir eine Vorstellung davon zu geben, wie "Joins" gemacht werden.

In BlueInk verweist eine Seite auf Inhaltselemente, die selbst auf einer oder mehreren Seiten (oder derselben Seite mehrmals) enthalten sein können. Die Seite verweist auf die Seitenelemente über ihre ID (wie in Ihrem zweiten JSON-Beispiel). Wenn es über die "page_and_items" -Ansicht ausgeführt wird, erzeugt es eine Ausgabe, die mit dem Abfrageparameter " ?include_docs=true CouchDB verwendet werden kann, um den vollständigen Inhalt der Referenzen der Inhaltselemente innerhalb des ?include_docs=true .

Die View-Ausgabe wird dann über eine _list -Funktion übergeben und über eine Moustache-Vorlage formatiert und als HTML-Seite ausgegeben - alles in einer einzigen GET-Anfrage.

Das gleiche Muster der Verwendung referenzierter IDs mit ?include_docs=true kann in Ihrem obigen Anwendungsfall verwendet werden. Die Verwendung einer _list Funktion ist vollständig "kosmetisch", kann aber hilfreich sein, um die Ausgabeansicht JSON zu restrukturieren oder zu templatieren und HTML, CSV, XML usw. auszugeben.

Disclaimer: Mit referenziellen Daten meine ich nicht referentielle Integrität

Ich lerne nosql und würde gerne verstehen, wie Daten modelliert werden sollten. In einer typischen relationalen Datenbank für eine CMS-Anwendung können Sie beispielsweise zwei Tabellen haben: Artikel und Autor, wobei Artikel einen Verweis auf den Autor haben.

Im nosql-System können Sie ein Artikeldokument auf diese Weise erstellen, da es sich nur um ein verschleiertes Objektdiagramm handelt

{
title: "Learn nosql in 5 minutes",
slug: "nosql_is_easy", 
author: {firstName: "Smarty"
          lastName: "Pants"
}

{
title: "Death to RDBMS",
slug: "rdbms_sucks", 
author: {firstName: "Smarty"
          lastName: "Pants"
}

und so weiter...

Eines Tages beschloss Mr. Smarty Pants, seinen Namen in Regular Joe zu ändern, weil Nosql allgegenwärtig geworden ist. In diesem Fall müsste jeder Artikel gescannt und der Name des Autors aktualisiert werden.

Meine Frage ist also, wie sollten die Daten in nosql modelliert werden, damit sie zu den grundlegenden Anwendungsfällen für ein CMS passen, so dass die Leistung gleich oder schneller ist als RDBMS ? Zum Beispiel beansprucht mongodb CMS als Anwendungsfall ...

Bearbeiten :

Nur wenige Leute haben bereits vorgeschlagen, die Daten wie folgt zu normalisieren:

article 
{
title: "Death to RDBMS",
slug: "rdbms_sucks", 
author: {id: "10000001"}
}

author
{
name: "Big Brother",
id: "10000001"
}

Da nosql jedoch konstruktionsbedingt keine Joins enthält, müssten Sie mapreduce-ähnliche Funktionen verwenden, um die Daten zusammenzuführen. Wenn dies Ihr Vorschlag ist, kommentieren Sie bitte die Durchführung eines solchen Vorgangs.

Bearbeiten 2:

Wenn Sie denken, dass nosql keine geeignete Lösung für Daten ist, die referenzielle Daten benötigen, erläutern Sie bitte auch warum. Dies scheint den Anwendungsfall für Nosql eher begrenzt zu machen, da jede vernünftige Anwendung relationale Daten enthalten würde.

Bearbeiten 3:

Nosql bedeutet nicht nicht-relational


Gestatten Sie mir, dass ich mit NoSQL kein Experte bin. Stattdessen ist mein Wissen darüber meist theoretisch.

Das heißt, ich bin fest davon überzeugt, dass die Implementierung eines solchen CMS-ähnlichen Systems in NoSQL wahrscheinlich nicht der beste Weg ist, etwas zu unternehmen, da die Daten hauptsächlich relational sind.

Meine Annahme dieses Problems basiert auf der Annahme, dass das von Ihnen verwendete NoSQL-System das Laden von Datensätzen über eine Struktur vom Typ "Primärschlüssel" ermöglicht. Ich denke, die meisten tun, aber ich bin mir sicher, dass es einige gibt, die das nicht tun.

Das heißt, ich würde vorschlagen, die Daten in der folgenden Weise zu speichern.

Für den Autor:

{
_KEY: $AUTHOR_GUID,
firstName: "Smarty",
lastName: "Pants",
}

Und für die Post selbst:

{
title: "Learn nosql in 5 minutes",
slug: "nosql_is_easy", 
author: $AUTHOR_GUID,
}

Beachten Sie, dass ich oben _KEY verwende, um darzustellen, dass dies der "Primärschlüssel" -Typ-Wert ist.

Nach dem Laden des Posts können Sie den Autor dann mit seiner GUID laden.


Ihre Daten sind eindeutig relational: Ein Artikel hat einen Autor. Sie können Ihre Daten in einem NOSQL-Speicher wie MongoDB genau so modellieren wie in einem relationalen Speicher. ABER weil es keine Joins in der Datenbank gibt, müssen Sie zwei Aufrufe an die Datenbank machen, so dass Sie nichts gewonnen haben.

ABER ... was Sie mit einem NOSQL-Speicher tun können, ist es, die Daten etwas zu denormalisieren, um eine verbesserte Leistung zu erhalten (eine einzige Runde, um alles zu bekommen, was Sie brauchen, um den Artikel anzuzeigen) ABER auf Kosten sofortiger Konsistenz: Handeln immer korrekt Autor Namen für eventuell genaue Autorennamen.

Sie könnten dies zum Beispiel in Ihrem Artikel verwenden:

author: {firstName: "Smarty", lastName: "Pants", _id:DE342624EF }

Jetzt können Sie den Artikel wirklich schnell anzeigen, und wenn jemand seinen Namen ändert, können Sie entweder eine Hintergrundaufgabe starten, um alle vorhandenen Artikel zu aktualisieren, oder Sie können auf eine periodische Konsistenzfindung warten, um sie zu beheben.

Viele große Websites geben Ihnen nicht mehr sofort Konsistenz. Es gibt Änderungen, die Sie vornehmen, die nur von den anderen Benutzern auf der Website schließlich angezeigt werden.


Sie können Ihre Daten mit playOrm AND modellieren und Joins in einem NoSQL-Speicher machen. playOrm hat S-SQL (Scalable SQL), was eine Wendung in SQL darstellt, indem Sie angeben, welche Partitionen Sie abfragen. Auf diese Weise können Sie von DBMS zu noSQL wechseln und haben immer noch dieselben vertrauten Werkzeuge, die Sie auch verwendet haben.





nosql