Matrice de décision

Pour décider quel modèle de partitionnement SaaS multi-locataires vous devez utiliser avec PostgreSQL, consultez la matrice de décision suivante. La matrice analyse ces quatre options de partitionnement :

• Silo — instance ou cluster PostgreSQL distinct pour chaque locataire.

• Pont avec bases de données distinctes : une base de données distincte pour chaque tenant dans une instance ou un cluster PostgreSQL unique.

• Pont avec des schémas distincts : schéma distinct pour chaque tenant dans une base de données PostgreSQL unique, dans une instance ou un cluster PostgreSQL unique.

• Pool : tables partagées pour les locataires dans une instance et un schéma uniques.

	Silo	Bridge avec bases de données distinctes	Pont avec schémas séparés	Piscine
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 locataires très importants et très sensibles aux performances.	L'isolation des données est une exigence essentielle, et des références croisées limitées ou inexistantes aux données des locataires sont requises.	Nombre modéré de locataires avec une quantité modérée de données. Il s'agit du modèle préféré 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 (Une nouvelle instance ou un nouveau cluster est requis pour chaque locataire.)	Moyennement (Nécessite la création d'une nouvelle base de données pour que chaque locataire puisse stocker les objets du schéma.)	Moyennement (Nécessite de créer un nouveau schéma pour que chaque locataire puisse stocker des objets.)	Option la plus rapide. (Une configuration minimale est requise.)
Effort et efficacité de configuration du pool de connexions de base de données	Des efforts importants sont nécessaires. (Un pool de connexions par locataire.) Moins efficace. (Aucun partage de connexion à la base de données entre les locataires.)	Des efforts importants sont nécessaires. (Une configuration de pool de connexions par locataire, sauf si vous utilisez le proxy Amazon RDS.) Moins efficace. (Aucun partage de connexion à la base de données entre les locataires et le nombre total de connexions. L'utilisation par tous les locataires est fonction de la classe d'instance de base de données.)	Moins d'efforts requis. (Configuration d'un pool de connexions unique pour tous les locataires.) Modérément efficace. (Réutilisation de la connexion via laSET SCHEMA commandeSET ROLE ou en mode pool de sessions uniquement. SETles commandes provoquent é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. Très 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 fonction de la classe d'instance de base de données.)
Maintenance de la base de données (gestion des vides) et utilisation des ressources	Gestion simplifiée.	Complexité (Cela peut entraîner une forte consommation de ressources, car il faut ensuite démarrer un aspirateur pour chaque base de donnéesvacuum_naptime, ce qui entraîne une utilisation importante du processeur du lanceur automatique. Le nettoyage des tables du catalogue du système PostgreSQL pour chaque base de données peut également entraîner une surcharge supplémentaire.)	Tableaux de catalogue de grande taille pour le système PostgreSQL. (pg_catalogTaille totale en dizaines de Go, en fonction du nombre de locataires et de relations. Il faudra probablement modifier les paramètres liés à l'aspiration pour contrôler le gonflement de la table.)	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 de la table.)
Effort de gestion des extensions	Effort important (pour chaque base de données dans des instances distinctes).	Effort important (au niveau de chaque base de données).	Effort minimal (une seule fois dans la base de données commune).	Effort minimal (une seule fois dans la base de données commune).
Effort de déploiement des modifications	Alertes d'effort (Connect à chaque instance distincte et déployez les modifications.)	Alertes d'effort (Connect à chaque base de données et à chaque schéma, puis déployez les modifications.)	Effort (Connect à une base de données commune et déployez les modifications pour chaque schéma.)	Niveau d'effort (Connect à une base de données commune et déployez les modifications.)
Déploiement du changement — étendue de l'impact	Minimale. (Locataire célibataire concerné.)	Minimale. (Locataire célibataire concerné.)	Minimale. (Locataire célibataire concerné.)	Très grand. (Tous les locataires concernés.)
Gestion et effort des performances des 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	Pas d'impact (Aucun partage de ressources entre les locataires.)	Impact modéré (Les locataires partagent des ressources communes telles que le processeur et la mémoire de l'instance.)	Impact modéré (Les locataires partagent des ressources communes telles que le processeur et la mémoire de l'instance.)	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 modification des paramètres de base de données pour un locataire 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.)	Pas possible (Les tables sont partagées par tous les locataires.)
Rééquilibrer les efforts en faveur des locataires soucieux des performances	Minimale. (Pas besoin de rééquilibrer. Adaptez les ressources du serveur et des E/S pour gérer ce scénario.)	Modéré. (Utilisez la réplication logique oupg_dump pour exporter la base de données, mais les interruptions 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 afin de copier les bases de données entre les instances plus rapidement.)	Modéré mais impliquant probablement de longs temps d'arrêt. (Utilisez la réplication logique oupg_dump exportez le schéma, mais les interruptions 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 vers une autre instance et d'effectuer une étape supplémentaire pour nettoyer les données des locataires.) Nécessite très probablement une modification de la logique de l'application.
Indisponibilité de la base de données des mises à niveau de version	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. (En fonction de la taille du catalogue du système, le délai peut varier. (Les tables du catalogue du système PostgreSQL sont également dupliquées dans les bases de données)	Des temps d'arrêt plus longs sont probables. (En fonction de la taille du catalogue du système PostgreSQL, le délai peut varier.)	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	Niveau d'effort	Niveau d'effort	Niveau d'effort
Disponibilité au niveau du locataire	Au plus haut (Chaque locataire échoue et se rétablit indépendamment.)	Étendue d'impact plus étendue. (Tous les locataires échouent et se rétablissent ensemble en cas de problèmes matériels ou de ressources.)	Étendue d'impact plus étendue. (Tous les locataires échouent et se rétablissent ensemble en cas de problèmes matériels ou de ressources.)	Étendue d'impact plus étendue. (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	Alertes d'effort (Chaque locataire peut être sauvegardé et restauré indépendamment.)	Effort (Utilisez l'exportation et l'importation logiques pour chaque locataire. Un peu de codage et d'automatisation sont nécessaires.)	Effort (Utilisez l'exportation et l'importation logiques pour chaque locataire. Un peu de codage et d'automatisation sont nécessaires.)	Alertes d'effort (Tous les locataires partagent les mêmes tables.)
Effort de point-in-time rétablissement au niveau des locataires	Niveau d'effort (Utilisez la restauration instantanée en utilisant des instantanés, ou utilisez le retour en arrière dans Amazon Aurora.)	Effort (Utilisez la restauration instantanée, suivie de l'exportation/importation. Cependant, cette opération sera lente.)	Effort (Utilisez la restauration instantanée, suivie de l'exportation/importation. Cependant, cette opération sera lente.)	Effort et complexité importants.
Nom de schéma uniforme	Même nom de schéma pour chaque locataire.	Même nom de schéma pour chaque locataire.	Schéma différent pour chaque locataire.	Schéma commun
Personnalisation par locataire (par exemple, colonnes de tableau supplémentaires pour un locataire spécifique)	Possible	Possible	Possible	Compliqué (car tous les locataires partagent les mêmes tables).
Efficacité de la gestion des catalogues 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).	Modérément efficace. (En fonction de l'ORM utilisé, du modèle de sécurité utilisateur/rôle et de lasearch_path configuration, le client met parfois en cache les métadonnées de tous les locataires, ce qui entraîne une utilisation élevée de la mémoire de connexion à la base de données.)	Efficace (car tous les locataires partagent les mêmes tables).
Effort de reporting consolidé des locataires	Alertes d'effort (Vous devez utiliser des wrappers de données étrangers [FDW] pour consolider les données de tous les locataires ou extraire, transformer et charger [ETL] dans une autre base de données de reporting.)	Alertes d'effort (Vous devez utiliser des FDW pour consolider les données de tous les locataires ou des ETL dans une autre base de données de reporting.)	Effort (Vous pouvez agréger les données dans tous les schémas en utilisant des unions.)	Niveau d'effort (Toutes les données des locataires se trouvent dans les mêmes tableaux, ce qui simplifie la création de rapports.)
Instance en lecture seule spécifique au locataire pour les rapports (par exemple, sur la base d'un abonnement)	Alertes d'effort (Créez un réplica en lecture.)	Effort (Vous pouvez utiliser la réplication logique ou leAWS Database Migration Service [AWS DMS] pour effectuer la configuration.)	Effort (Vous pouvez utiliser la réplication logique ouAWS 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 de rôles PostgreSQL.)	Mieux (Vous pouvez gérer les autorisations au niveau du schéma à l'aide de 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 propre cléAWS Key Management Service [AWS KMS] pour le chiffrement du stockage.)	Pas possible (Tous les locataires partagent la même clé KMS pour le chiffrement du stockage.)	Pas possible (Tous les locataires partagent la même clé KMS pour le chiffrement du stockage.)	Pas possible (Tous les locataires partagent la même clé KMS pour le chiffrement du stockage.)
Utilisation deAWS Identity and Access Management (IAM) pour l'authentification de la 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 d'infrastructure	Le plus élevé (car rien n'est partagé).	Modéré.	Modéré.	Au plus bas
Duplication des données et utilisation du stockage	Le total 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.)	Le total 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 être accessibles par d'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)	Alertes d'effort (Comme chaque locataire est surveillé séparément, il est facile de vérifier l'activité d'un locataire spécifique.)	Effort (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 (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.)	Alertes d'effort (Comme tous les locataires partagent toutes les ressources, y compris les tables, vous devez utiliser la capture de la variable bind pour vérifier à quel locataire appartient une requête SQL spécifique.)
Gestion centralisée et surveillance de l'état de santé et des activités	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).
Chances de concordance entre l'identifiant de l'objet (OID) et l'identifiant de la transaction (XID)	Minimale.	Haut (Parce que OID, XID est un compteur PostgreSQL unique à l'échelle du cluster et il peut y avoir des problèmes pour passer l'aspirateur efficacement entre les bases de données physiques).	Modéré. (Parce que OID, XID est un compteur PostgreSQL unique à l'échelle du cluster).	Haut (Par exemple, une seule table peut atteindre la limite TOAST OID de 4 milliards, selon le nombre de out-of-line colonnes.)