Schémas de PostgreSQL pour les applications multi-locataires
J'apprends multi-tenant applications et comment les schémas de PostgreSQL peuvent être utilisés pour cela.
En recherchant le sujet, j'ai fini par trouver n article dans lequel l'auteur décrit une mauvaise expérience lors de l'utilisation des schémas de PostgreSQL dans des applications multi-locataires. Les principaux problèmes seraient d'avoir de mauvaises performances pour les migrations et une utilisation élevée des ressources de base de données.
Il semble qu'avoir un seul schéma (partager les tables entre les locataires) conduirait à de meilleures performances que d'avoir un schéma séparé pour chaque locataire. Mais cela me semble étrange. Je pense le contraire, car les index sur les petites tables ont tendance à être plus légers que les index sur les grandes tables.
Pourquoi les performances seraient-elles pires lorsque les données sont séparées dans un grand nombre de petites tables (dans plusieurs schémas), plutôt que d'avoir des données séparées dans quelques tables énormes (dans un seul schéma)?
Les performances ne sont pas nécessairement pires. Comme l'article l'explique, il existe des conditions spécifiques qui rendent l'approche du schéma meilleure ou pire en fonction de la conception de votre application et de la charge de travail. Permettez-moi d'expliquer les compromis entre les approches "schéma de locataire" et "table partagée":
schéma-locataire est préférable lorsque vous avez un nombre relativement faible de locataires assez importants. Un exemple de ceci serait une application de comptabilité, avec seulement des utilisateurs d'abonnement payants. Les éléments qui en font l'option la plus performante pour vous incluent:
- un petit nombre de locataires avec beaucoup de données chacun
- un schéma relativement simple sans beaucoup de tables par locataire
- un besoin de personnaliser les schémas de certains locataires
- pouvoir utiliser les rôles de base de données par locataire
- obligation de migrer les données d'un locataire d'un serveur à un autre
- possibilité de faire tourner un serveur d'applications dédié dans votre cloud pour chaque locataire
Les éléments qui en font une option peu performante comprennent:
- beaucoup de locataires avec très peu de données chacun
- approche sans état des connexions où chaque demande peut être n'importe quel locataire
- bibliothèque cliente ou orm qui met en cache les métadonnées pour toutes les tables (comme ActiveRecord)
- une exigence pour la mise en commun et/ou la mise en cache de connexions efficaces et hautes performances
- problèmes avec VACUUM et d'autres opérations administratives PostgreSQL qui évoluent mal sur des milliers de tables.
Que le schéma du locataire soit mauvais pour les migrations/modifications de schéma dépend vraiment de la façon dont vous les effectuez. C'est mauvais pour déployer rapidement un changement de schéma universel, mais bon pour déployer des changements de schéma comme un déploiement progressif entre les locataires.
table partagée fonctionne mieux pour les situations où vous avez beaucoup de locataires et que beaucoup de vos locataires ont très peu de données. Un exemple de ceci serait une application mobile médiale sociale qui permet des comptes gratuits et a donc des milliers de comptes abandonnés. Les autres avantages du modèle de table partagée sont les suivants:
- meilleur pour le pool de connexions, car toutes les connexions peuvent utiliser le même pool
- mieux pour l'administration de PostgreSQL, car le nombre total de tables est inférieur
- mieux pour les migrations et les modifications de schéma, car il n'y a qu'un "ensemble" de tables
Le principal inconvénient de la table partagée est la nécessité d'ajouter la condition de filtre de locataire à chaque requête de la couche application. C'est aussi problématique parce que:
- les requêtes qui joignent de nombreuses tables peuvent mal fonctionner car le filtre de locataire désactive la planification des requêtes
- les tables qui atteignent 100 millions de lignes peuvent entraîner des problèmes de performances et de maintenance spécifiques
- aucun moyen de faire des modifications d'application spécifiques au locataire ou des mises à niveau de schéma
- plus coûteux de migrer les locataires entre les serveurs
Donc, quel modèle "fonctionne mieux" dépend vraiment des compromis qui vous font le plus mal.
Il existe également un modèle hybride, "tenant-view", où les données réelles sont stockées dans des tables partagées, mais chaque connexion d'application utilise vues de barrière de sécurité pour afficher les données. Cela présente certains des compromis de chaque modèle. Principalement, il présente les avantages de sécurité du modèle de schéma de locataire avec certains des inconvénients de performances des deux modèles.