Architecture mutualisée

Vous pouvez intégrer l'architecture mutualisée à votre application en fournissant des partitions de données séparées pour plusieurs entreprises clientes, connues sous le nom de locataires. Ainsi, vous pouvez personnaliser les valeurs de données pour chaque locataire, tout en conservant le même schéma de données pour tous les locataires. Cela permet de provisionner de manière plus efficace les nouveaux locataires, car la structure des données n'a pas besoin d'être modifiée lors de l'ajout d'un locataire.

Avantages de l'architecture mutualisée

Cloud Firestore en mode Datastore autorise une application à architecture mutualisée à exploiter des données cloisonnées séparées pour chaque locataire tout en utilisant :

  • un seul projet ;
  • une seule structure logique pour les genres ;
  • un seul ensemble de définitions d'index, car les genres sont logiquement les mêmes pour chaque locataire.

Le mode Datastore permet l'architecture mutualisée en fournissant des espaces de noms.

Architecture mutualisée et données partitionnées

Le mode Datastore utilise des partitions afin de cloisonner les données pour chaque locataire. La combinaison d'un ID de projet et d'un ID de l'espace de noms forme un ID de partition, permettant d'identifier chaque partition. Une entité appartient à une seule partition et les requêtes sont appliquées à une seule partition.

Spécifier un espace de noms pour une entité

Vous spécifiez l'espace de noms au moment de la création de l'entité. Vous ne pouvez plus le modifier une fois l'entité créée. Si vous ne spécifiez pas explicitement d'espace de noms pour une entité, elle sera automatiquement associée à l'espace de noms par défaut, qui ne possède pas d'identifiant de chaîne.

Utiliser des espaces de noms avec des entités parentes

Une entité et tous ses ancêtres appartiennent à un seul et même espace de noms. Cela signifie que lorsque vous créez une entité avec une autre entité désignée comme parente, l'entité enfant se trouve dans le même espace de noms que son parent. Par conséquent, vous ne pouvez pas spécifier d'espace de noms différent.

Exemple de cas d'utilisation

Le fait que la même application desserve plusieurs entreprises clientes constitue un avantage clé de l'architecture mutualisée. Pour tirer parti de cet avantage, votre application doit, pour un genre donné, adopter le même comportement indépendamment de l'espace de nom. Par exemple, du point de vue de l'application, une entité de genre Task dans un espace de noms doit logiquement être identique à une entité de genre Task dans tous les autres espaces de noms. Votre application peut ensuite utiliser un seul ensemble de définitions d'index pour accepter les requêtes de genre Task, quels que soient les espaces de noms contenant des entités de genre Task.

Prenons l'exemple d'une application de liste de tâches qui cloisonne les données par utilisateur. L'application peut définir des espaces de noms basés sur le nom de l'utilisateur, ce qui entraîne les partitions suivantes :

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

L'application peut définir une structure logique de genre Task comme suit, à utiliser pour tous les espaces de noms :

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

Lorsqu'un utilisateur crée une entité de genre Task, l'entité est stockée dans la partition de l'utilisateur, ce qui génère des données cloisonnées. L'application traite les entités de genre Task de manière cohérente sur les espaces de noms, car un seul schéma est utilisé pour le genre Task. Une application avec des données cloisonnées et un comportement cohérent est associée à une architecture mutualisée.

Si la structure logique d'un genre Task diffère selon les espaces de noms, l'application n'est pas à architecture mutualisée, car elle traite les entités de genre Task différemment en fonction des espaces de noms. Par exemple, considérons des genres Task ayant un schéma différent basé sur un espace de noms :

  • Les entités Task de l'espace de noms Joe excluent la propriété description de l'index.
  • Les entités Task de l'espace de nom Alice incluent la propriété description de l'index.

L'application a pu interroger la propriété description pour les entités Task d'Alice, mais elle n'a pas été en mesure d'interroger la propriété description pour les entités Task de Joe. Elle n'est donc pas à architecture mutualisée.

Afficher les espaces de noms dans la console

Pour consulter les statistiques des espaces de noms utilisés dans votre projet, accédez à la page Tableau de bord Datastore de la console Google Cloud. Pour déterminer de manière automatisée les espaces de noms utilisés dans votre projet, consultez la section Requêtes d'espace de noms.

Si vous souhaitez regrouper des données dans un locataire, vous pouvez les classer par genres et organiser les données étroitement liées dans des groupes d'entités.

Étapes suivantes