Les performances ne sont pas pires, nécessairement. Comme l'explique l'article, il existe des conditions spécifiques qui rendent l'approche schématique 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 "tenant-schema" et "shared-table":
schéma locataire est préférable lorsque vous avez un nombre relativement restreint de locataires assez importants. Un exemple de ceci serait une application de comptabilité, avec uniquement des utilisateurs 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
- possibilité d'utiliser les rôles de base de données par locataire
- nécessité de migrer les données d'un locataire d'un serveur à un autre
- possibilité de créer un serveur d'applications dédié dans votre cloud pour chaque locataire
Les éléments qui en font une option peu performante incluent :
- 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 de toutes les tables (comme ActiveRecord)
- une exigence pour un regroupement et/ou une mise en cache de connexions efficaces et performants
- problèmes avec VACUUM et d'autres opérations administratives PostgreSQL qui évoluent mal sur des milliers de tables.
Si locataire-schema est mauvais pour les migrations/changements de schéma dépend vraiment de la façon dont vous les faites. C'est mauvais pour le déploiement rapide d'un changement de schéma universel, mais bon pour le déploiement des changements de schéma en tant que déploiement progressif entre les locataires.
table partagée fonctionne mieux dans 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 de médias sociaux qui permet des comptes gratuits et a donc des milliers de comptes abandonnés. Les autres éléments qui rendent le modèle de table partagée avantageux sont :
- meilleur pour le regroupement de connexions, car toutes les connexions peuvent utiliser le même pool
- meilleur pour l'administration PostgreSQL, car il y a moins de tables au total
- mieux pour les migrations et les modifications de schéma, car il n'y a qu'un seul "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 avoir des performances médiocres car le filtre de locataire perturbe 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 d'apporter des modifications d'application ou des mises à niveau de schéma spécifiques au locataire
- plus coûteux de migrer les locataires entre les serveurs
Ainsi, quel modèle "fonctionne le mieux" dépend vraiment des compromis qui vous nuisent le plus.
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 a 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.
