Nous créons SAAS où nous aurons au plus 50 000 clients. Nous envisageons de créer un utilisateur dans la base de données Postgres pour chaque client. Nous allons mapper chaque utilisateur qui se connecte à notre service à un utilisateur de la base de données afin d'être sûr qu'ils n'ont accès qu'à leurs propres données. Nous voulons également implémenter une piste d'audit directement dans la base de données par ces solutions , qui utilise des déclencheurs. Si chaque client a son propre utilisateur de base de données, il serait très facile de voir qui a fait quoi, même si deux clients partagent les mêmes données.
Serons-nous confrontés à des problèmes inattendus car nous avons 50 000 utilisateurs dans notre base de données? En termes de performances ou d'administration. Peut-être que la mise en commun des connexions serait plus difficile, mais je ne sais pas vraiment si nous en aurions besoin.
set role actualUser
Réponses:
Oui, ça devrait aller. Vous devez cependant utiliser le regroupement de connexions, car pg utilise une bonne quantité de mémoire par connexion (environ 10 Mo AFAIK).
Plus de 500 connexions simultanées par boîte seront un problème (comme interroger activement la base de données en même temps). Plus de cpus / cœurs, c'est mieux. Utilisez des SSD avec RAID 10.
Votre application SaaS doit se connecter en tant qu'utilisateur unique, puis
set role
au véritable utilisateur. Cela vous permet d'utiliser le regroupement de connexions, car la chaîne de connexion sera la même, mais utilisera des utilisateurs différents. Vous devriezreset role
lors du retour de la connexion au pool.Ce n'est pas vraiment une authentification de base de données. C'est l'authentification proxy (alias Emprunt d'identité).
Vous pouvez également envisager des pools distincts par entreprise ou par rôle.
Pour faciliter l'administration, vous pouvez mettre les utilisateurs en groupes et définir des autorisations via des groupes. C'est ce qu'on appelle RBAC.
Mise à jour: j'ai pu créer 50 000 utilisateurs en 2,4 secondes. PGAdmin est sensiblement plus lent, en raison du nombre d'utilisateurs. Cependant, la connexion via JDBC est aussi rapide qu'auparavant. Je n'ai pas pu supprimer 50 000 utilisateurs à la fois, mais je pouvais en faire 10 000 à la fois.
la source
Performance: des milliers de connexions simultanées mangeront Votre mémoire, une valeur supérieure à 1 000 connexions simultanées conseillées pour utiliser le pool de connexions, pgbouncer est une bonne, développée par skype.
Administration: Administrer 50 000 utilisateurs sera un gros travail de l'OMI. Que diriez-vous de différencier le client avec le même accès aux données en utilisant différents
application_name
, de sorte que chaque client se connecte à la base de données en utilisant le même nom d'utilisateur.Exemple :
en utilisant un autre nom d'utilisateur, la chaîne de connexion de chaque client serait:
--user user1
,--user user2
, etc.Mais en utilisant différents
application_name
, la chaîne de connexion de chaque client serait:--user user1 --application_name costumer1
,--user user1 --aplication_name costumer2
, etc.Le
application_name
est enregistré danspg_stat_activity
et pourrait également être enregistré. Je pense que ce serait plus facile à mettre en œuvre. Et leapplication_name
est également enregistré dans le déclencheur d'audit que vous souhaitez appliquer. Plus de détails ici .J'espère que cela aide.
la source