Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Modèles de partitionnement SaaS multi-locataires pour PostgreSQL
La meilleure méthode pour réaliser la mutualisation dépend des exigences de votre application SaaS. Les sections suivantes présentent les modèles de partitionnement permettant d'implémenter avec succès la mutualisation dans PostgreSQL.
**Note**
Les modèles présentés dans cette section s'appliquent à la fois à Amazon RDS pour PostgreSQL et à la compatibilité avec Aurora PostgreSQL. Les références à *PostgreSQL* dans cette section s'appliquent aux deux services.
Il existe trois modèles de haut niveau que vous pouvez utiliser dans PostgreSQL pour le partitionnement SaaS : silo, bridge et pool. L'image suivante résume les compromis entre les modèles de silo et de pool. Le modèle de pont est un hybride des modèles de silo et de piscine.
****
| **Modèle de partitionnement** | **Avantages** | **Inconvénients** |
| --- | --- | --- |
| Silo | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/saas-multitenant-managed-postgresql/partitioning-models.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/saas-multitenant-managed-postgresql/partitioning-models.html) |
| Pool | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/saas-multitenant-managed-postgresql/partitioning-models.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/saas-multitenant-managed-postgresql/partitioning-models.html) |
| Pont | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/saas-multitenant-managed-postgresql/partitioning-models.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/saas-multitenant-managed-postgresql/partitioning-models.html) |
Les sections suivantes présentent chaque modèle plus en détail.
**Topics**
+ [
# Modèle de silo PostgreSQL
](silo.md)
+ [
# Modèle de pool PostgreSQL
](pool.md)
+ [
# Modèle de pont PostgreSQL
](bridge.md)
+ [
# Matrice de décision
](matrix.md)
# Modèle de silo PostgreSQL
Le modèle de silo est implémenté en provisionnant une instance PostgreSQL pour chaque locataire d'une application. Le modèle de silo excelle en termes de performance pour les locataires et d'isolation de sécurité, et élimine complètement le phénomène des *voisins bruyants*. Le phénomène de voisinage bruyant se produit lorsque l'utilisation d'un système par un locataire affecte les performances d'un autre locataire. Le modèle de silo vous permet d'adapter les performances spécifiquement à chaque locataire et de limiter potentiellement les pannes au silo d'un locataire spécifique. Cependant, ce sont généralement les contraintes réglementaires et de sécurité strictes qui motivent l'adoption d'un modèle en silo. Ces contraintes peuvent être motivées par les clients du SaaS. Par exemple, les clients du SaaS peuvent exiger que leurs données soient isolées en raison de contraintes internes, et les fournisseurs de SaaS peuvent proposer un tel service moyennant des frais supplémentaires.
![\[SaaS PostgreSQL silo model\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/saas-multitenant-managed-postgresql/images/saas-postgresql-silo.png)
Bien que le modèle de silo puisse être nécessaire dans certains cas, il présente de nombreux inconvénients. Il est souvent difficile d'utiliser le modèle de silo de manière rentable, car la gestion de la consommation de ressources sur plusieurs instances PostgreSQL peut s'avérer complexe. En outre, la nature distribuée des charges de travail des bases de données dans ce modèle complique le maintien d'une vue centralisée de l'activité des locataires. La gestion d'un si grand nombre de charges de travail gérées de manière indépendante augmente les frais opérationnels et administratifs. Le modèle en silo rend également l'intégration des locataires plus complexe et prend plus de temps, car vous devez fournir des ressources spécifiques aux locataires. En outre, l'ensemble du système SaaS peut être plus difficile à adapter, car le nombre toujours croissant d'instances PostgreSQL spécifiques aux locataires exigera plus de temps opérationnel pour les administrer. Une dernière considération est qu'une application ou une couche d'accès aux données devra maintenir un mappage des locataires avec leurs instances PostgreSQL associées, ce qui complique encore la mise en œuvre de ce modèle.
# Modèle de pool PostgreSQL
Le modèle de pool est mis en œuvre en provisionnant une instance PostgreSQL unique (Amazon RDS ou Aurora) [et en utilisant la sécurité au niveau des lignes (RLS) pour maintenir l'isolation](https://aws.amazon.com/blogs/database/multi-tenant-data-isolation-with-postgresql-row-level-security/) des données des locataires. Les politiques RLS limitent les lignes d'une table renvoyées par les `SELECT` requêtes ou les lignes affectées par `DELETE` les commandes `INSERT``UPDATE`, et. Le modèle de pool centralise toutes les données des locataires dans un schéma PostgreSQL unique. Il est donc nettement plus rentable et nécessite moins de frais opérationnels pour sa maintenance. La surveillance de cette solution est également nettement plus simple grâce à sa centralisation. Cependant, la surveillance des impacts spécifiques au locataire dans le modèle de piscine nécessite généralement des instruments supplémentaires dans l'application. Cela est dû au fait que PostgreSQL ne sait pas par défaut quel locataire consomme des ressources. L'intégration des locataires est simplifiée car aucune nouvelle infrastructure n'est requise. Cette agilité facilite la mise en place de flux de travail rapides et automatisés pour l'intégration des locataires.
![\[SaaS PostgreSQL pool model\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/saas-multitenant-managed-postgresql/images/saas-postgresql-pool.png)
Bien que le modèle de pool soit généralement plus rentable et plus simple à administrer, il présente certains inconvénients. Le phénomène de voisinage bruyant ne peut pas être complètement éliminé dans un modèle de piscine. Cependant, il est possible de l'atténuer en s'assurant que les ressources appropriées sont disponibles sur l'instance PostgreSQL et en utilisant des stratégies pour réduire la charge dans PostgreSQL, telles que le transfert des requêtes pour lire des répliques ou vers Amazon. ElastiCache Une surveillance efficace joue également un rôle dans la réponse aux problèmes d'isolation des performances des locataires, car l'instrumentation des applications peut enregistrer et surveiller les activités spécifiques des locataires. Enfin, certains clients du SaaS peuvent ne pas trouver la séparation logique fournie par le RLS suffisante et peuvent demander des mesures d'isolation supplémentaires.
# Modèle de pont PostgreSQL
Le modèle de pont PostgreSQL est une combinaison d'approches groupées et cloisonnées. Comme dans le cas du modèle groupé, vous fournissez une instance PostgreSQL unique pour chaque locataire. Pour maintenir l'isolation des données des locataires, vous utilisez les constructions logiques de PostgreSQL. Dans le schéma suivant, les bases de données PostgreSQL sont utilisées pour séparer les données de manière logique.
**Note**
Une base de données PostgreSQL ne fait pas référence à une instance de base de données Amazon RDS pour PostgreSQL distincte ou compatible avec Aurora PostgreSQL. Il fait plutôt référence à une construction logique du système de gestion de base de données PostgreSQL pour séparer les données.
![\[SaaS PostgreSQL bridge model with separate databases\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/saas-multitenant-managed-postgresql/images/saas-postgresql-bridge-dbs.png)
Vous pouvez également implémenter le modèle de pont en utilisant une seule base de données PostgreSQL, avec des schémas spécifiques au locataire dans chaque base de données, comme illustré dans le schéma suivant.
![\[SaaS PostgreSQL bridge model with separate schemas\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/saas-multitenant-managed-postgresql/images/saas-postgresql-bridge-schemas.png)
Le modèle de pont présente les mêmes problèmes d'isolation des performances des voisins et des locataires bruyants que le modèle de piscine. Cela entraîne également des frais opérationnels et de provisionnement supplémentaires en nécessitant le provisionnement de bases de données ou de schémas distincts pour chaque locataire. Cela nécessite une surveillance efficace pour répondre rapidement aux préoccupations des locataires en matière de performance. Cela nécessite également une instrumentation d'application pour surveiller l'utilisation spécifique au locataire. Dans l'ensemble, le modèle de pont peut être considéré comme une alternative au RLS qui augmente légèrement l'effort d'intégration des locataires en nécessitant de nouvelles bases de données ou de nouveaux schémas PostgreSQL. Comme dans le cas du modèle de silo, une application ou une couche d'accès aux données devra maintenir un mappage des locataires avec leurs bases de données ou schémas PostgreSQL associés.
# Matrice de décision
Pour décider quel modèle de partitionnement SaaS multi-tenant vous devez utiliser avec PostgreSQL, consultez la matrice de décision suivante. La matrice analyse les quatre options de partitionnement suivantes :
+ Silo — Une instance ou un cluster PostgreSQL distinct pour chaque locataire.
+ Pont avec bases de données distinctes : base de données distincte pour chaque locataire dans une instance ou un cluster PostgreSQL unique.
+ Pont avec schémas distincts : schéma distinct pour chaque locataire dans une seule base de données PostgreSQL, dans une instance ou un cluster PostgreSQL unique.
+ Pool : tables partagées pour les locataires dans une instance et un schéma uniques.
****
| **** | **Silo** | **Pont avec bases de données séparées** | **Pont avec schémas séparés** | **Pool** |
| --- | --- | --- | --- | --- |
| Cas d’utilisation | L'isolation des données avec un contrôle total de l'utilisation des ressources est une exigence essentielle, sinon vous avez des clients très importants et très sensibles aux performances. | L'isolation des données est une exigence essentielle, et les références croisées limitées ou inexistantes des données des locataires sont requises. | Nombre modéré de locataires disposant d'une quantité modérée de données. C'est le modèle à privilégier si vous devez croiser les données des locataires. | Grand nombre de locataires avec moins de données par locataire. |
| Agilité d'intégration des nouveaux locataires | Très lent. (Une nouvelle instance ou un nouveau cluster est requis pour chaque locataire.) | Modérément lent. (Nécessite la création d'une nouvelle base de données pour chaque locataire afin de stocker les objets du schéma.) | Modérément lent. (Nécessite la création d'un nouveau schéma pour chaque locataire afin de stocker des objets.) | L'option la plus rapide. (Une configuration minimale est requise.) |
| Effort et efficacité de configuration du pool de connexions à la base de données | Un effort important est requis. (Un pool de connexions par locataire.) Moins efficace. (Aucun partage de connexion à la base de données entre les locataires.) | Un effort important est requis. (Une configuration de pool de connexions par locataire, sauf si vous utilisez le [proxy Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/rds-proxy.html).) Moins efficace. (Aucun partage de connexion à la base de données entre les locataires et nombre total de connexions. L'utilisation par tous les locataires est limitée en fonction de la classe d'instance de base de données.) | Moins d'efforts requis. (Configuration d'un pool de connexions pour tous les locataires.) Moyennement efficace. (Réutilisation de la connexion via la `SET SCHEMA` commande `SET ROLE` ou en mode pool de sessions uniquement. `SET`les commandes entraînent également l'épinglage de session lors de l'utilisation d'Amazon RDS Proxy, mais les pools de connexions clients peuvent être éliminés et des connexions directes peuvent être établies pour chaque demande pour des raisons d'efficacité.) | Le moins d'effort requis. Le plus efficace. (Un pool de connexions pour tous les locataires et une réutilisation efficace des connexions entre tous les locataires. Les limites de connexion à la base de données sont basées sur la classe d'instance de base de données.) |
| Maintenance de base de données ([gestion du vide](https://www.postgresql.org/docs/current/routine-vacuuming.html)) et utilisation des ressources | Gestion simplifiée. | Complexité moyenne. (Cela peut entraîner une consommation de ressources élevée, car un aspirateur doit ensuite être démarré pour chaque base de donnéesvacuum\$1naptime, ce qui entraîne une utilisation élevée du processeur du lanceur Autovacuum. L'élimination des tables du catalogue du système PostgreSQL pour chaque base de données peut également entraîner une surcharge supplémentaire.) | Grandes tables de catalogue du système PostgreSQL. (pg\$1catalogTaille totale en dizaines de GBs, selon le nombre de locataires et de relations. Il faudra probablement modifier les paramètres liés à l'aspiration pour contrôler le gonflement des tables.) | Les tables peuvent être volumineuses, en fonction du nombre de locataires et des données par locataire. (Il faudra probablement modifier les paramètres liés à l'aspiration pour contrôler le gonflement des tables.) |
| Effort de gestion des extensions | Effort important (pour chaque base de données dans des instances distinctes). | Effort important (à chaque niveau de base de données). | Effort minimal (une fois dans la base de données commune). | Effort minimal (une fois dans la base de données commune). |
| Modifier l'effort de déploiement | Effort important. (Connectez-vous à chaque instance distincte et déployez les modifications.) | Effort important. (Connectez-vous à chaque base de données et à chaque schéma, puis déployez les modifications.) | Effort modéré. (Connectez-vous à la base de données commune et déployez les modifications pour chaque schéma.) | Effort minimal. (Connectez-vous à la base de données commune et déployez les modifications.) |
| Déploiement des modifications : portée de l'impact | Minimale. (Locataire unique concerné.) | Minimale. (Locataire unique concerné.) | Minimale. (Locataire unique concerné.) | Très grand (Tous les locataires sont concernés.) |
| Gestion des performances et des efforts liés aux requêtes | Performances de requêtes gérables. | Performances de requêtes gérables. | Performances de requêtes gérables. | Des efforts importants sont probablement nécessaires pour maintenir les performances des requêtes. (Au fil du temps, les requêtes peuvent s'exécuter plus lentement en raison de l'augmentation de la taille des tables. Vous pouvez utiliser le partitionnement des tables et le partitionnement des bases de données pour maintenir les performances.) |
| Impact sur les ressources entre locataires | Aucun impact. (Aucun partage de ressources entre les locataires.) | Incidence modérée. (Les locataires partagent des ressources communes telles que le processeur et la mémoire de l'instance.) | Incidence modérée. (Les locataires partagent des ressources communes telles que le processeur et la mémoire de l'instance.) | Fort impact. (Les locataires s'influencent mutuellement en termes de ressources, de conflits de verrouillage, etc.) |
| Réglage au niveau du locataire (par exemple, création d'index supplémentaires par locataire ou ajustement des paramètres de base de données pour un locataire en particulier) | Possible. | Plutôt possible. (Des modifications au niveau du schéma peuvent être apportées pour chaque locataire, mais les paramètres de base de données sont globaux pour tous les locataires.) | Plutôt possible. (Des modifications au niveau du schéma peuvent être apportées pour chaque locataire, mais les paramètres de base de données sont globaux pour tous les locataires.) | C'est impossible. (Les tables sont partagées par tous les locataires.) |
| Rééquilibrez les efforts pour les locataires sensibles aux performances | Minimale. (Pas besoin de rééquilibrage. Adaptez le serveur et les I/O ressources pour gérer ce scénario.) | Modéré. (Utilisez la réplication logique ou pg\$1dump exportez la base de données, mais les interruptions de service peuvent être longues en fonction de la taille des données. Vous pouvez utiliser la fonctionnalité de base de données transportable d'Amazon RDS for PostgreSQL pour copier des bases de données entre instances plus rapidement.) | Modéré mais susceptible d'entraîner des temps d'arrêt prolongés. (Utilisez la réplication logique ou pg\$1dump exportez le schéma, mais les interruptions de service peuvent être longues en fonction de la taille des données.) | Important, car tous les locataires partagent les mêmes tables. (Le partitionnement de la base de données nécessite de tout copier sur une autre instance et de procéder à une étape supplémentaire pour nettoyer les données des locataires.) Nécessite très probablement une modification de la logique de l'application. |
| Interruption de la base de données pour les mises à niveau majeures | Temps d'arrêt standard. (Cela dépend de la taille du catalogue du système PostgreSQL.) | Des temps d'arrêt plus longs sont probables. (La durée peut varier en fonction de la taille du catalogue du système. (les tables du catalogue du système PostgreSQL sont également dupliquées entre les bases de données) | Des temps d'arrêt plus longs sont probables. (La durée varie en fonction de la taille du catalogue du système PostgreSQL.) | Temps d'arrêt standard. (Cela dépend de la taille du catalogue du système PostgreSQL.) |
| Frais d'administration (par exemple, pour l'analyse des journaux de base de données ou la surveillance des tâches de sauvegarde) | Effort important | Effort minimal. | Effort minimal. | Effort minimal. |
| Disponibilité au niveau du locataire | Le plus élevé. (Chaque locataire échoue et se rétablit indépendamment.) | Champ d'impact plus élevé. (Tous les locataires échouent et se rétablissent ensemble en cas de problèmes matériels ou de ressources.) | Champ d'impact plus élevé. (Tous les locataires échouent et se rétablissent ensemble en cas de problèmes matériels ou de ressources.) | Champ d'impact plus élevé. (Tous les locataires échouent et se rétablissent ensemble en cas de problèmes matériels ou de ressources.) |
| Effort de sauvegarde et de restauration au niveau du locataire | Le moindre effort. (Chaque locataire peut être sauvegardé et restauré indépendamment.) | Effort modéré. (Utilisez l'exportation et l'importation logiques pour chaque locataire. Un certain codage et une certaine automatisation sont nécessaires.) | Effort modéré. (Utilisez l'exportation et l'importation logiques pour chaque locataire. Un certain codage et une certaine automatisation sont nécessaires.) | Effort important. (Tous les locataires partagent les mêmes tables.) |
| Effort de rétablissement au niveau du locataire point-in-time | Effort minimal. (Utilisez la restauration instantanée en utilisant des instantanés, ou utilisez le retour en arrière dans Amazon Aurora.) | Effort modéré. (Utilisez la restauration instantanée, suivie de l'exportation/importation. Cependant, cette opération sera lente.) | Effort modéré. (Utilisez la restauration instantanée, suivie de l'exportation/importation. Cependant, cette opération sera lente.) | Effort et complexité importants. |
| Nom du schéma uniforme | Nom de schéma identique pour chaque locataire. | Nom de schéma identique pour chaque locataire. | Schéma différent pour chaque locataire. | Schéma commun. |
| Personnalisation par locataire (par exemple, colonnes de table supplémentaires pour un locataire spécifique) | Possible. | Possible. | Possible. | Compliqué (car tous les locataires partagent les mêmes tables). |
| Efficacité de la gestion du catalogue au niveau de la couche de mappage relationnel objet (ORM) (par exemple, Ruby) | Efficace (car la connexion client est spécifique à un locataire). | Efficace (car la connexion client est spécifique à une base de données). | Moyennement efficace. (En fonction de l'ORM utilisé, du modèle user/role de sécurité et de la search\$1path configuration, le client met parfois en cache les métadonnées pour tous les locataires, ce qui entraîne une utilisation importante de la mémoire de connexion à la base de données.) | Efficace (car tous les locataires partagent les mêmes tables). |
| Effort consolidé de reporting auprès des locataires | Effort important. (Vous devez utiliser des enveloppeurs de données étrangers [FDWs] pour consolider les données de tous les locataires ou pour extraire, transformer et charger [ETL] dans une autre base de données de rapports.) | Effort important. (Vous devez utiliser FDWs pour consolider les données de tous les locataires ou ETL dans une autre base de données de rapports.) | Effort modéré. (Vous pouvez agréger les données dans tous les schémas à l'aide d'unions.) | Effort minimal. (Toutes les données relatives aux locataires se trouvent dans les mêmes tables, ce qui simplifie les rapports.) |
| Instance en lecture seule spécifique au locataire pour les rapports (par exemple, sur la base d'un abonnement) | Le moindre effort. (Créez une réplique de lecture.) | Effort modéré. (Vous pouvez utiliser la réplication logique ou le AWS Database Migration Service [AWS DMS] pour configurer.) | Effort modéré. (Vous pouvez utiliser la réplication logique ou AWS DMS pour configurer.) | Compliqué (car tous les locataires partagent les mêmes tables). |
| Isolation des données | Meilleur. | Mieux. (Vous pouvez gérer les autorisations au niveau de la base de données à l'aide des rôles PostgreSQL.) | Mieux. (Vous pouvez gérer les autorisations au niveau du schéma à l'aide des rôles PostgreSQL.) | Pire. (Comme tous les locataires partagent les mêmes tables, vous devez implémenter des fonctionnalités telles que la sécurité au niveau des lignes [RLS] pour isoler les locataires.) |
| Clé de chiffrement de stockage spécifique au locataire | Possible. (Chaque cluster PostgreSQL peut avoir sa AWS Key Management Service propre cléAWS KMS[] pour le chiffrement du stockage.) | C'est impossible. (Tous les locataires partagent la même clé KMS pour le chiffrement du stockage.) | C'est impossible. (Tous les locataires partagent la même clé KMS pour le chiffrement du stockage.) | C'est impossible. (Tous les locataires partagent la même clé KMS pour le chiffrement du stockage.) |
| Utilisation de Gestion des identités et des accès AWS (IAM) pour l'authentification de base de données pour chaque locataire | Possible. | Possible. | Possible (en ayant des utilisateurs PostgreSQL distincts pour chaque schéma). | Impossible (car les tables sont partagées par tous les locataires). |
| Coût de l'infrastructure | Au plus haut (car rien n'est partagé). | Modéré. | Modéré. | Le plus bas. |
| Duplication des données et utilisation du stockage | Agrégat le plus élevé parmi tous les locataires. (Les tables du catalogue du système PostgreSQL et les données statiques et communes de l'application sont dupliquées sur tous les locataires.) | Agrégat le plus élevé parmi tous les locataires. (Les tables du catalogue du système PostgreSQL et les données statiques et communes de l'application sont dupliquées sur tous les locataires.) | Modéré. (Les données statiques et communes de l'application peuvent se trouver dans un schéma commun et accessibles aux autres locataires.) | Minimale. (Aucune duplication des données. Les données statiques et communes de l'application peuvent se trouver dans le même schéma.) |
| Surveillance centrée sur le locataire (découvrez rapidement quel locataire est à l'origine des problèmes) | Le moindre effort. (Comme chaque locataire est surveillé séparément, il est facile de vérifier l'activité d'un locataire en particulier.) | Effort modéré. (Comme tous les locataires partagent la même ressource physique, vous devez appliquer un filtrage supplémentaire pour vérifier l'activité d'un locataire spécifique.) | Effort modéré. (Comme tous les locataires partagent la même ressource physique, vous devez appliquer un filtrage supplémentaire pour vérifier l'activité d'un locataire spécifique.) | Effort important. (Comme tous les locataires partagent toutes les ressources, y compris les tables, vous devez utiliser la capture de variables de liaison pour vérifier à quel locataire appartient une requête SQL spécifique.) |
| Gestion et health/activity surveillance centralisées | Effort important (pour mettre en place une surveillance centrale et un centre de commande central). | Effort modéré (car tous les locataires partagent la même instance). | Effort modéré (car tous les locataires partagent la même instance). | Effort minimal (car tous les locataires partagent les mêmes ressources, y compris le schéma). |
| Probabilités d'encapsulation de l'identifiant de l'objet (OID) et de l'identifiant de transaction (XID) | Minimale. | Élevée. (Dans la mesure où OID, XID est un compteur PostgreSQL unique à l'échelle du cluster, il peut être difficile de nettoyer efficacement les bases de données physiques). | Modéré. (Dans la mesure où OID, XID est un seul compteur PostgreSQL à l'échelle du cluster). | Élevée. (Par exemple, une seule table peut atteindre la limite d'OID TOAST de 4 milliards, selon le nombre de out-of-line colonnes.) |