1

Wir haben eine Anforderung in GAE-Datenspeicher zu implementieren. Es gibt eine Reihe von Dokumenten (in Millionen) und jedes Dokument hat einen Eigentümer, einige Kommentare und Revisionen.Verwenden von GAE-Datastore-Beziehung im Vergleich zu flachem Design

Wenn der Eigentümer des Dokuments die Organisation verlässt, müssen wir die Eigentümerschaft des Dokuments auf die Person ändern, die die letzte Überarbeitung durchgeführt hat. Außerdem müssen wir die Überarbeitungen und Kommentare für jedes Dokument beibehalten. Diese Besitzänderung muss von einem Job implementiert werden, der jedes einzelne Dokument einzeln verarbeitet.

Ist es der richtige Ansatz, Eltern-Kind-Beziehungen zwischen den Entitäten Document, Comment und Revision wie Document die Eltern mit Comment und Revision als Kind zu haben? ODER in typischer NoSql Weise müssen wir die Tabelle abflachen und eine einzelne Entität bilden?

Die typische NoSQL-Implementierung muss nur eingefügt und gelesen werden, aber keine Updates. Funktioniert der Google-Datenspeicher? Bitte klären Sie.

Unsere Forschung sagt, dass wir Beziehung haben können, aber das wird mehr wie RDBMS aussehen.

+0

Diese Frage viel zu breit ist, beabsichtigen. Sie sollten versuchen, zu modellieren und zu prototypieren. Die kommen mit einigen spezifischen Implementierungsfragen zurück. Wenn Sie Beziehungen besitzen, die geändert werden können ** Definieren Sie dies nicht mit Eltern, die im Schlüssel definiert sind. Dies bedeutet, dass Sie das Eigentumsrecht nicht ändern können. Sie müssen dann jedoch neue Entitäten kopieren und erstellen. Struktur und Beziehungen sind in Ordnung. Wichtig ist, dass Sie Ihre Zugriffsmuster betrachten und Entitäten für die Aktivität optimieren. Wenn Ihre Abfragen normalerweise Joins bedeuten, werden Zwischenelemente, die alles speichern, was Sie benötigen, wichtig. –

+0

Können wir Ihr Dokumentenformat sehen, das in der Frage bearbeitet wurde?Persönlich denke ich, dass das von NoSQL unterstützte schemafreie Format mehr Probleme verursacht als es löst - wenn Sie also nicht die rohe Geschwindigkeit von NoSQL benötigen, gehen Sie mit einem traditionellen RDBMS und modellieren Sie dieses mit Tabellen. – halfer

+0

@halfer außer ich würde den Datenspeicher nicht als schemafrei klassifizieren –

Antwort

1

Um den richtigen Schemadesign auszuwählen, sollten Sie klarstellen, wie Sie mit Daten arbeiten möchten, und beachten Sie die Einschränkungen des Datenspeichers. In Kürze:

  1. NoSQL-Ansatz (Einheit)

    • eine Aktualisierung pro Sekunde pro Einheit Gruppe
    • Sie jedes Mal, lesen und schreiben die ganze Entität (mit Ausnahme der Projektion Abfragen)
  2. Eltern-Kind-Beziehungen (Vorfahrenbeziehungen)

    • kann nicht in Zukunft
    • Form Einheit-Gruppe geändert werden, so dass Sie starke Konsistenz erreichen, während der Abfragegruppe
    • eine Aktualisierung pro Sekunde pro Einheit beim Lesen! (Also, wenn Sie einen Fall mit vielen Live-Kommentaren dies nicht funktioniert für Sie)
  3. RDBMS Ansatz (Tabellen und Beziehungen)

    • Datenspeicher haben keine auf mehreren Tabellen verknüpft (so nur Split-Daten in Tabellen, in denen Sie nicht abfragen zusammen)
    • schließlich konsistent liest
+0

Dies ist eine gute Antwort eher verdorben durch die Zugabe von txspk. Bitte tun Sie das nicht - Leser, deren erste Sprache nicht Englisch ist, haben es schwer genug, und Leser, deren erste Sprache Englisch ist, könnten beim Lesen genervt sein. Ich kann mir nicht vorstellen, dass viele Millisekunden durch das Eingeben von "Sie" und nicht von "Du" gerettet werden. Vielen Dank! – halfer

+0

@Ramiel, danke für die Antwort, meine Zweifel ist, wenn wir in No Sql Arena sind und wir sollten die Tabelle dann glätten, warum Google Dokumentation für GAE-Datenspeicher von Beziehungen und Hierarchien spricht, obwohl das auch abgeflacht werden kann. [link] (https://cloud.google.com/appengine/docs/java/datastore/jdo/relationships) – AmitS

+0

Da die Abflachung Einschränkungen hat (wie ich erwähnt habe, hat jede Vorgehensweise Vor- und Nachteile): ein Update pro Sekunde (imagine post mit schnell wachsenden Likes oder Smth), Datenduplikation usw. – glmvrml

Verwandte Themen