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 ferons mapper chaque utilisateur qui se connecte à notre service à un utilisateur de la base de données afin d'être très sûr qu'ils n'ont accès qu'à leurs propres données. Nous souhaitons également mettre en œuvre 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.
Allons-nous courir dans certains problèmes inattendus car nous avons 50 000 utilisateurs dans notre base de données? Performance-sage ou administration-sage. Peut-être que la mise en commun de la connexion serait plus difficile, mais je ne sais pas vraiment si nous en aurions besoin.
Oui, ça devrait aller. Vous devez utiliser la mise en commun de la connexion, car PG utilise une belle quantité de mémoire par connexion (environ 10 Mo Afaik).
Plus de 500 connexions simultanées par boîte seront un problème cependant (comme activement interroger la base de données à la même heure). Plus de processeurs/cœurs sont meilleurs. Utilisez des SSD avec RAID 10.
Votre SaaS application doit être connecté en tant qu'utilisateur, puis set role
à l'utilisateur réel. Cela vous permet d'utiliser la mise en commun de la connexion, car la chaîne de connexion sera identique, mais utilisez différents utilisateurs. Vous devriez reset 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 impersonnation).
Vous pouvez également envisager des pools séparés par entreprise ou par rôle.
Pour faciliter l'administrateur, vous pouvez mettre les utilisateurs en groupes et définir des autorisations via des groupes. Ceci s'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 laisser tomber 50 000 utilisateurs à la fois, mais cela pourrait faire environ 10 000 à la fois.
Performance: Des milliers de personnes concurrentes mangeront votre mémoire, environ 1 000 connexions simultanées recommandées d'utiliser la mise en commun de la connexion, PGBouncer est une bonne, développée par Skype.
Administration: administrer 50 000 utilisateurs sera un gros travail imo. Que diriez-vous de différencier le costuteur avec le même accès de données à l'aide de différents application_name
, chaque client se connectera à la base de données en utilisant le même nom d'utilisateur.
Exemple :
en utilisant un nom d'utilisateur différent, 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é dans pg_stat_activity
et pourrait aussi être enregistré. Je pense que cela serait plus facile à mettre en œuvre. Et le application_name
est également connecté à la gâchette d'audit que vous souhaitez appliquer. Plus de détails ici .
J'espère que ça aide.