Ich habe eine Webanwendung, die auf große Mengen von JSON-Daten zugreift.
Ich möchte eine Schlüsselwertdatenbank zum Speichern von JSON-Daten verwenden, die verschiedenen Benutzern der Webanwendung (nicht den Benutzern der Datenbank) gehören. Jeder Benutzer sollte nur auf die Datensätze zugreifen können, die er besitzt oder teilt.
In einer relationalen Datenbank würde ich der Record-Tabelle eine Spalte Owner hinzufügen oder Shared Ownerships in einer separaten Tabelle verwalten und den Zugriff auf der Anwendungsseite (Python) überprüfen. Für Schlüsselwertspeicher kommen zwei Ansätze in Frage.
Was passiert, wenn ich Schlüssel wie USERID_RECORDID verwende und dann Code schreibe, um USERID zu prüfen, bevor ich auf den Datensatz zugreife? Ist das eine gute Idee? Es würde nicht mit Datensätzen funktionieren, die zwischen Benutzern geteilt werden.
Ich könnte ein oder mehrere USERIDs in den Wertdaten speichern und prüfen, ob die Daten die ID des Benutzers enthalten, der versucht, auf den Datensatz zuzugreifen. Die Leistung ist wahrscheinlich langsamer als die Benutzer-ID als Teil des Schlüssels, aber gemeinsame Eigentümer sind möglich.
Beide beschriebenen Lösungen haben einige Einschränkungen.
Sie weisen darauf hin, dass das Einschließen der Besitzer-ID in den Schlüssel das Problem der gemeinsamen Daten nicht löst. Diese Lösung ist jedoch möglicherweise akzeptabel, wenn Sie ein weiteres Schlüssel / Wert-Paar hinzufügen, das die IDs der Inhalte enthält, die für diesen Benutzer (key: userId:shared, value: [id1, id2, id3...]) freigegeben sind.
Ihr zweiter Vorschlag, in den Sie die Liste der Benutzer aufnehmen, denen Zugriff auf einen bestimmten Inhalt gewährt wurde, ist nur dann OK, wenn Ihre Anwendung eine Abfrage durchführen muss, um die Liste der Benutzer abzurufen, auf die Zugriff besteht ein bestimmter Inhalt. Wenn Sie alle Inhalte auflisten möchten, auf die ein Benutzer zugreifen kann, führt dies zu schlechten Ergebnissen, da der K / V-Speicher alle Datensätze scannen muss - und diese Art von Datenbank-Engine lässt Sie normalerweise nicht erstellen ein Index, um diese Art von Anfrage zu optimieren.
Aus allgemeinerer Sicht muss das Modell bei NoSQL-Datenbanken und insbesondere bei Schlüssel / Wert-Speichern entsprechend den Anforderungen definiert werden, die von der Anwendung gestellt werden. Es kann dazu führen, dass Sie einige Informationen duplizieren. Die Anwendung hat die Verantwortung, die Konsistenz der Daten zu wahren.
Wenn Sie beispielsweise alle Inhalte für einen bestimmten Benutzer abrufen müssen, ob dieser Benutzer der Eigentümer des Inhalts ist oder diese Inhalte mit ihm geteilt wurden, empfehle ich Ihnen, einen Schlüssel für den Benutzer zu erstellen, der die Liste enthält Inhalts-IDs für diesen Benutzer, wie ich bereits sagte. Wenn Ihre App jedoch auch die Liste der Benutzer abrufen muss, die auf einen bestimmten Inhalt zugreifen dürfen, sollten Sie ihre IDs in einem Feld dieses Inhalts hinzufügen. Dies würde zu etwas führen wie:
key: contentID, value: { ..., [userId1, userID2...]}
Wenn Sie den Zugriff auf einen bestimmten Inhalt für einen Benutzer entfernen, muss Ihre Anwendung (und nicht der Datenspeicher) die userId aus dem Inhaltswert und contentId aus der Liste der Inhalte für diesen Benutzer entfernen.
Dieser Entwurf kann dazu führen, dass Ihre App mehrere Anforderungen stellt: zum Beispiel eine, um die Liste der userIDs zu erhalten, die auf einen bestimmten Inhalt zugreifen dürfen, und eine oder mehrere, um diese Benutzerprofile zu erhalten. Dies sollte jedoch kein wirkliches Problem darstellen, da K / V-Speicher üblicherweise sehr hohe Leistungen aufweisen.
Tags und Links python database authorization nosql key-value