Mehrinstanzenfähigkeit

Sie können Mehrinstanzenfähigkeit in Ihrer Anwendung unterstützen, indem Sie separate Datenpartitionen für mehrere Clientorganisationen bereitstellen, die als Mandanten bezeichnet werden. Auf diese Weise können Sie Datenwerte für jeden Mandanten anpassen und dabei das Datenschema für alle Mandanten beibehalten. Dadurch wird die Nutzerverwaltung neuer Mandanten effizienter, weil Sie die Datenstruktur nicht ändern müssen, wenn Sie einen Mandanten hinzufügen.

Vorteile der Mehrinstanzenfähigkeit

Mit Firestore im Datastore-Modus kann eine mehrinstanzenfähige Anwendung separate Datensilos für jeden Mandanten verwenden. Dabei werden weiterhin folgende Elemente genutzt:

  • Ein einzelnes Projekt
  • Eine einzelne logische Struktur für die Typen
  • Ein einzelnes Set von Indexdefinitionen, weil die Arten für jeden Mandanten logisch identisch sind

Im Datastore-Modus wird die Mehrinstanzenfähigkeit durch Bereitstellung von Namespaces aktiviert.

Mehrinstanzenfähigkeit und partitionierte Daten

Im Datastore-Modus werden Partitionen verwendet, um Daten für jeden Mandanten in einem Silo zu speichern. Die Kombination einer Projekt-ID und einer Namespace-ID bildet eine Partitions-ID, die jede Partition identifiziert. Eine Entität gehört zu einer einzelnen Partition und Abfragen sind auf eine einzelne Partition beschränkt.

Namespace für eine Entität angeben

Sie geben den Namespace beim Erstellen der Entität an. Wenn Sie die Entität erstellt haben, können Sie den Namespace nicht mehr ändern. Wenn Sie nicht explizit einen Namespace für eine Entität angeben, wird diese automatisch dem Standard-Namespace zugewiesen, der keine String-ID hat.

Namespaces mit übergeordneten Entitäten verwenden

Eine Entität und alle zugehörigen Ancestors gehören zu einem einzigen Namespace. Wenn Sie also eine Entität mit einer anderen Entität erstellen, die als übergeordnete Entität angegeben wird, ist die untergeordnete Entität in demselben Namespace wie die übergeordnete Entität enthalten. Sie können keinen anderen Namespace angeben.

Beispielanwendungsfall

Ein wichtiger Vorteil der Mehrinstanzenfähigkeit besteht darin, dass dieselbe Anwendung mehrere Clientorganisationen bereitstellen kann. Um diesen Vorteil für eine bestimmte Art nutzen zu können, muss das Verhalten Ihrer Anwendung ungeachtet des Namespace immer gleich sein. Beispiel: Aus Sicht der Anwendung muss eine Entität von der Art Task in einem Namespace logisch identisch mit einer Entität von der Art Task in allen anderen Namespaces sein. Die Anwendung könnte dann ein einzelnes Set von Indexdefinitionen zur Unterstützung von Task-Abfragen verwenden, unabhängig davon, welche Namespaces Task-Entitäten enthalten.

Beispiel: Betrachten wir eine Aufgabenlistenanwendung, die Daten pro Nutzer in einem Silo speichert. Die Anwendung könnte Namespaces basierend auf Nutzernamen definieren, was folgende Partitionen ergibt:

    Partition ID: project:"my_project_id"/namespace:"Joe"
    Partition ID: project:"my_project_id"/namespace:"Alice"
    Partition ID: project:"my_project_id"/namespace:"Charlie"
    

Die Anwendung könnte eine logische Struktur der Art Task folgendermaßen definieren, die für alle Namespaces verwendet wird:

    kind: Task
    properties:
     - "done", Boolean
     - "created", DateTime
     - "description", String, excluded from index
    

Wenn ein Nutzer eine Entität der Art Task erstellt, wird die Entität in der eigenen Partition des Nutzers gespeichert, sodass die Daten in einem Silo gespeichert sind. Die Anwendung verarbeitet Task-Entitäten konsistent über Namespaces hinweg, weil nur ein Schema für die ARt Task verwendet wird. Eine Anwendung mit Daten in Silos und übereinstimmendem Verhalten wäre mehrinstanzenfähig.

Wenn sich die logische Struktur einer Task-Art nach Namespace unterscheidet, wäre die Anwendung nicht mehrinstanzenfähig, weil sie Task-Entitäten in den Namespaces unterschiedlich verarbeitet. Beispiel: Betrachten Sie Task-Arten, die unterschiedliche Schemas basierend auf einem Namespace haben:

  • Bei Task-Entitäten im Namespace "Joe" wird das Attribut description aus dem Index ausgeschlossen.
  • Bei Task-Entitäten im Index "Alice" wird das Attribut description in den Index eingeschlossen.

Die Anwendung könnte das Attribut description für die Task-Entitäten von Alice abfragen, könnte jedoch das Attribut description für die Task-Entitäten von Joe nicht abfragen, sodass die Anwendung nicht mehrinstanzenfähig wäre.

Namespaces in der Console ansehen

Statistiken zu den Namespaces in Ihrem Projekt finden Sie in der Google Cloud Console auf der Seite Datastore-Dashboard. In Namespace-Abfragen wird beschrieben, wie programmatisch bestimmt wird, welche Namespaces in Ihrem Projekt verwendet werden.

Wenn das Gruppieren von Daten innerhalb eines Mandanten erforderlich ist, können Sie die Daten nach Arten kategorisieren. Eng zusammenhängende Daten können auch in Entitätengruppen organisiert werden.

Weitere Informationen