it-swarm.com.de

Wie in Datenspeichern statt Datenbanken denken?

Beispielsweise verwendet Google App Engine Google Datastore, keine Standarddatenbank, um Daten zu speichern. Hat jemand Tipps zur Verwendung von Google Datastore anstelle von Datenbanken? Es scheint, als hätte ich meinen Verstand geschult, 100% in Objektbeziehungen zu denken, die Tabellenstrukturen direkt zugeordnet sind, und jetzt ist es schwierig, etwas anderes zu sehen. Ich kann einige der Vorteile von Google Datastore verstehen (z. B. die Leistung und die Fähigkeit, Daten zu verteilen), aber einige gute Datenbankfunktionen werden geopfert (z. B. Verknüpfungen).

Hat jemand, der mit Google Datastore oder BigTable gearbeitet hat, einen guten Rat für die Arbeit mit ihnen?

181
Jim

An den App Engine-Datenspeicher müssen Sie sich im Vergleich zu 'herkömmlichen' relationalen Datenbanken hauptsächlich an zwei Dinge gewöhnen:

  • Der Datenspeicher unterscheidet nicht zwischen Einfügungen und Aktualisierungen. Wenn Sie put () für eine Entität aufrufen, wird diese Entität mit ihrem eindeutigen Schlüssel im Datenspeicher gespeichert, und alles, was diesen Schlüssel enthält, wird überschrieben. Grundsätzlich verhält sich jede Entitätsart im Datenspeicher wie eine riesige Karte oder sortierte Liste.
  • Das Abfragen ist, wie Sie angedeutet haben, sehr viel eingeschränkter. Zunächst einmal keine Joins.

Der Schlüssel zur Erkenntnis - und der Grund für diese beiden Unterschiede - ist, dass Bigtable im Grunde genommen wie ein riesiges, geordnetes Wörterbuch funktioniert. Somit setzt eine Put-Operation nur den Wert für einen bestimmten Schlüssel - unabhängig von einem vorherigen Wert für diesen Schlüssel, und Abrufoperationen sind auf das Abrufen einzelner Schlüssel oder zusammenhängender Schlüsselbereiche beschränkt. Anspruchsvollere Abfragen werden durch Indizes ermöglicht, bei denen es sich im Grunde genommen nur um eigene Tabellen handelt. Auf diese Weise können Sie komplexere Abfragen als Scans für zusammenhängende Bereiche implementieren.

Sobald Sie dies verstanden haben, verfügen Sie über die Grundkenntnisse, die erforderlich sind, um die Funktionen und Einschränkungen des Datenspeichers zu verstehen. Möglicherweise willkürlich erscheinende Einschränkungen sind wahrscheinlich sinnvoller.

Das Entscheidende dabei ist, dass es sich zwar um Einschränkungen bezüglich der in einer relationalen Datenbank verfügbaren Funktionen handelt, diese jedoch praktisch sind, um eine Skalierung auf die Größenordnung vorzunehmen, für die Bigtable entwickelt wurde. Sie können einfach nicht die Art von Abfrage ausführen, die auf dem Papier gut aussieht, aber in einer SQL-Datenbank schrecklich langsam ist.

Im Hinblick darauf, wie Sie die Darstellung von Daten ändern, ist die Vorberechnung das Wichtigste. Anstatt Verknüpfungen zur Abfragezeit auszuführen, müssen Sie die Daten vorberechnen und im Datenspeicher speichern, wo immer dies möglich ist. Wenn Sie einen zufälligen Datensatz auswählen möchten, generieren Sie eine Zufallszahl und speichern Sie diese mit jedem Datensatz. Es gibt ein ganzes Kochbuch mit solchen Tipps und Tricks hier Bearbeiten: Das Kochbuch existiert nicht mehr.

148
Nick Johnson

Die Art und Weise, wie ich über den Gedankenwechsel nachgedacht habe, besteht darin, die Datenbank insgesamt zu vergessen.

In der relationalen Datenbankwelt müssen Sie sich immer um die Normalisierung der Daten und Ihre Tabellenstruktur kümmern. Schluss mit allem. Gestalten Sie einfach Ihre Webseite. Legen Sie sie alle aus. Nun sieh sie dir an. Du bist schon zu 2/3 da.

Wenn Sie den Gedanken vergessen, dass die Datenbankgröße eine Rolle spielt und Daten nicht dupliziert werden sollten, sind Sie zu 3/4 da und mussten nicht einmal Code schreiben! Lassen Sie Ihre Ansichten Ihre Models bestimmen. Sie müssen Ihre Objekte nicht mehr wie in der relationalen Welt zweidimensional machen. Sie können jetzt Objekte mit Form speichern.

Ja, dies ist eine vereinfachte Erklärung der Tortur, aber sie hat mir geholfen, die Datenbanken zu vergessen und einfach einen Antrag zu stellen. Ich habe bisher 4 App Engine-Apps nach dieser Philosophie erstellt, und es werden noch weitere folgen.

41
user19087

Ich kichere immer, wenn Leute mit herauskommen - es ist nicht relational. Ich habe cellectr in Django und hier ist ein Ausschnitt meines Modells unten. Wie Sie sehen werden, habe ich Ligen, die von Benutzern verwaltet oder trainiert werden. Ich kann aus einer Liga alles bekommen Manager oder von einem bestimmten Benutzer kann ich die Liga zurückgeben, die sie trainiert oder Manager.

Nur weil es keine spezifische Fremdschlüsselunterstützung gibt, heißt das nicht, dass Sie kein Datenbankmodell mit Beziehungen haben können.

Meine zwei Pence.


class League(BaseModel):
    name = db.StringProperty()    
    managers = db.ListProperty(db.Key) #all the users who can view/edit this league
    coaches = db.ListProperty(db.Key) #all the users who are able to view this league

    def get_managers(self):
        # This returns the models themselves, not just the keys that are stored in teams
        return UserPrefs.get(self.managers)

    def get_coaches(self):
        # This returns the models themselves, not just the keys that are stored in teams
        return UserPrefs.get(self.coaches)      

    def __str__(self):
        return self.name

    # Need to delete all the associated games, teams and players
    def delete(self):
        for player in self.leagues_players:
            player.delete()
        for game in self.leagues_games:
            game.delete()
        for team in self.leagues_teams:
            team.delete()            
        super(League, self).delete()

class UserPrefs(db.Model):
    user = db.UserProperty()
    league_ref = db.ReferenceProperty(reference_class=League,
                            collection_name='users') #league the users are managing

    def __str__(self):
        return self.user.nickname

    # many-to-many relationship, a user can coach many leagues, a league can be
    # coached by many users
    @property
    def managing(self):
        return League.gql('WHERE managers = :1', self.key())

    @property
    def coaching(self):
        return League.gql('WHERE coaches = :1', self.key())

    # remove all references to me when I'm deleted
    def delete(self):
        for manager in self.managing:
            manager.managers.remove(self.key())
            manager.put()
        for coach in self.managing:
            coach.coaches.remove(self.key())
            coaches.put()            
        super(UserPrefs, self).delete()    
23
Phil Stollery

Ich kam aus der Welt der relationalen Datenbanken, als ich dieses Datenspeicher-Ding fand. Es dauerte mehrere Tage, um sich daran zu gewöhnen. Nun, es gibt einige meiner Erkenntnisse.

Sie müssen bereits gewusst haben, dass Datastore maßstabsgetreu aufgebaut ist, und genau das unterscheidet ihn von RDMBS. Um die Skalierung bei großen Datenmengen zu verbessern, hat App Engine einige Änderungen vorgenommen (einige sind mit vielen Änderungen verbunden).

RDBMS VS DataStore
Struktur
In Datenbanken strukturieren wir unsere Daten normalerweise in Tabellen, Zeilen, die im Datenspeicher zu Arten und Entitäten werden.

Beziehungen
In RDBMS folgen die meisten Menschen der Eins-zu-Eins-Beziehung, der Viele-zu-Eins-Beziehung, der Viele-zu-Viele-Beziehung Normalisierung mit "ReferenceProperty" zB Eins-zu-Eins-Beziehungsbeispiel .

Indizes
Normalerweise erstellen wir in RDMBS Indizes wie Primärschlüssel, Fremdschlüssel, eindeutiger Schlüssel und Indexschlüssel, um die Suche zu beschleunigen und unsere Datenbankleistung zu steigern. Im Datenspeicher müssen Sie mindestens einen Index pro Art erstellen (es wird automatisch generiert erstellt, ob es Ihnen gefällt oder nicht), da der Datenspeicher Ihre Entität auf der Grundlage dieser Indizes durchsucht und mir glaubt, dass dies der beste Teil ist. In RDBMS können Sie mithilfe von Nicht-Indexfeldern suchen. Dies kann jedoch einige Zeit in Anspruch nehmen. Im Datenspeicher können Sie nicht mit Nicht-Index-Eigenschaften suchen.

Count
In RDMBS ist es viel einfacher zu zählen (*), aber im Datenspeicher, bitte denken Sie es nicht einmal auf normale Weise (Ja, es gibt eine Zählfunktion), da es 1000 Limit und es hat kostet so viel kleine Operation wie die Entität, die nicht gut ist, aber wir haben immer gute Entscheidungen, wir können Splitterzähler verwenden.

nique Constraints
In RDMBS lieben wir diese Funktion, oder? Aber Datastore hat seinen eigenen Weg. Sie können eine Eigenschaft nicht als eindeutig definieren :(.

Abfrage
GAE-Datenspeicher bietet eine bessere Funktion als WIE (Oh nein! Datenspeicher hat kein LIKE-Schlüsselwort) SQL, das [~ # ~) ist ] gql [~ # ~] .

Daten einfügen/aktualisieren/löschen/auswählen
Dies ist für uns alle von Interesse, da wir in RDMBS eine Abfrage für Einfügen, Aktualisieren, Löschen und Auswählen benötigen, genau wie bei RDBMS, hat Datastore Put, Delete, Get (nicht zu aufgeregt), weil Datastore Put oder Get in Bezug auf Schreiben, Lesen, kleine Operationen (Lesen Kosten für Datenspeicheraufrufe) und genau hier setzt die Datenmodellierung an. Sie müssen diese Vorgänge minimieren und Ihre App am Laufen halten. Zum Reduzieren von Lesevorgang können Sie Memcache verwenden.

12
sanjay kushwah

Schauen Sie sich die Objectify-Dokumentation an. Der erste Kommentar am Ende der Seite lautet:

"Schön, obwohl Sie dies geschrieben haben, um Objectify zu beschreiben, ist es auch eine der prägnantesten Erklärungen für den Appengine-Datenspeicher selbst, den ich je gelesen habe. Vielen Dank."

https://github.com/objectify/objectify/wiki/Concepts

6
Jon Stevens

Wenn Sie es gewohnt sind, über ORM-zugeordnete Entitäten nachzudenken, funktioniert ein entitätsbasierter Datenspeicher wie die App Engine von Google im Grunde genommen so. Für so etwas wie Joins können Sie sich Referenzeigenschaften ansehen. Sie müssen sich keine Gedanken darüber machen, ob BigTable für das Backend oder etwas anderes verwendet wird, da das Backend von den GQL- und Datastore-API-Schnittstellen abstrahiert wird.

3
Mark Cidade

Die Art und Weise, wie ich Datenspeicher betrachte, ist, identifiziert Art Tabelle an sich und Entität ist einzelne Zeile in Tabelle. Wenn Google nicht nur eine einzige große Tabelle ohne Struktur erstellt, können Sie alles, was Sie wollen, in einer Entität ablegen. Mit anderen Worten, wenn Entitäten nicht an eine Art gebunden sind, können Sie so ziemlich jede Struktur zu einer Entität haben und an einem Ort speichern (eine Art große Datei ohne Struktur, jede Zeile hat ihre eigene Struktur).

Zurück zum ursprünglichen Kommentar, Google Datastore und Bigtable sind zwei verschiedene Dinge, also verwechseln Sie Google Datastore nicht mit Datastore Data Storage Sense. Bigtable ist teurer als BigQuery (Hauptgrund, warum wir es nicht gemacht haben). Bigquery hat richtige Joins und RDBMS wie SQL-Sprache und es ist billiger, warum nicht Bigquery verwenden. Abgesehen davon hat BigQuery einige Einschränkungen, abhängig von der Größe Ihrer Daten, auf die Sie möglicherweise stoßen oder nicht.

Auch in Bezug auf das Denken in Bezug auf Datenspeicher, denke ich, dass richtige Aussage "Denken in Bezug auf NoSQL-Datenbanken" gewesen wäre. Heutzutage gibt es zu viele von ihnen, aber wenn es um Google-Produkte geht, mit Ausnahme von Google Cloud SQL (das ist mySQL), ist alles andere NoSQL.

0
ringadingding