Nombre maximum de bases de données pour une seule instance de PostgreSQL 9

9

En développant une application multiclient, nous prévoyons d'utiliser une base de données différente pour chaque client. Mais cela pourrait être plus de 1000 clients (applications).

PostgreSQL le gérera-t-il sans aucun problème?

Quelqu'un a-t-il essayé quelque chose de similaire?

Remarque: 35 tableaux pour chacun, avec jusqu'à 3000 enregistrements en moyenne, pour chaque base de données.

postgresql postgresql-9.1 Juanin
la source

Réponses:

5

Je ne l'ai pas essayé moi-même, mais il y en a d'autres autour qui l'ont fait. Ici, vous pouvez voir que même 10 000 bases de données s'exécutent sans problème sur une seule instance. Vous pouvez même trouver des aspects pratiques sur ServerFault également.

Étant donné que vos bases de données sont assez petites, vous ne rencontrerez aucune sorte de limitation du nombre de fichiers du système d'exploitation hôte. Le seul problème auquel je peux penser est que lorsque toutes ces bases de données seront accessibles simultanément, la gestion de toutes ces connexions sera délicate.

Et, pour finir: vous êtes les bienvenus sur ce site. Nous espérons que vous resterez longtemps avec nous.

dezso
la source
Merci pour vos commentaires. Oui, les connectios simultanés pourraient être un casse-tête, mais l'autre option est une table partagée pour chaque application, incroyablement plus complexe (besoin d'une reprogrammation pour l'application).
Juanin
2

Cela ressemble à une chose désordonnée à faire du point de vue de la gestion. Comment prévoyez-vous de sauvegarder autant de bases de données? avec un script qui boucle dans chacun?

Sauf si vous avez une très bonne raison, pourquoi ne pas avoir une seule base de données où la structure est conçue pour que toutes les données soient liées à un identifiant client. Ajoutez des index / clé étrangère / clés primaires en fonction de ce champ, ce qui garantira l'intégrité des données.

Ensuite, il vous suffit d'avoir une clause where dans toutes vos requêtes pour accéder à un seul ID client. Ce sera beaucoup plus simple à entretenir et tout aussi facile à développer (car dans les deux cas, vous devez permettre l'identification du client)

adam f
la source
1
C'est un très bon point et valable. Peut-être que l'OP devrait penser à utiliser des schémas et n'avoir que quelques tables dans le schéma public, disponibles pour se joindre à des tables dans le schéma du client privé.
François Beausoleil
Merci, mais cette option a été rejetée dès le début. Il s'agit d'un portage d'une application déjà développée, et changer TOUT le code n'est pas si trivial à ce stade. Mais oui, la gestion quotidienne de plus de 100 bases de données sera ... intéressante ... n'est-ce pas?
Juanin
1
Passer de bases de données distinctes à des schémas distincts ne devrait pas impliquer de changement significatif dans le code. En particulier, vous n'avez pas besoin de préfixer les objets avec leurs schémas car search_pathcela le fait pour vous.
Daniel Vérité
L'archivage Wal pour une sauvegarde aurait du sens ici.
Jharwood
0

Il y a des gens qui font cela, en particulier pour l'hébergement de serveurs partagés.

En réfléchissant aux problèmes ici, il n'y a pas de déjeuner gratuit. Vous pourriez probablement le faire avec des schémas d'une manière transparente pour l'application. Cependant, vous obtenez alors des milliers de schémas et des dizaines de milliers de tables, ce qui posera des problèmes supplémentaires.

Je pense que dans l'ensemble, l'approche à plusieurs bases de données est la plus saine compte tenu de vos commentaires.

La gestion (comme les sauvegardes) deviendra intéressante. Je pense également qu'à un moment donné, les connexions à la base de données commenceront à prendre plus de temps. Si vous utilisez pg_hba.conf pour restreindre l'accès (ce que vous devez faire), cela deviendra également un casse-tête et vous voudrez probablement créer une solution pour générer ce fichier pour vous .....

Chris Travers
la source
Je ne vois pas le problème avec pg_hba.conf. Notre application utilise Ruby on Rails et bascule les connexions pour différentes bases de données, mais dans la même boîte Linux tout le temps. parle de problèmes d'accès simultané au fichier?
Juanin
1
Non, juste si vous voulez gérer quels dbs sont accessibles par quels hôtes, cela deviendra un long fichier et la gestion peut devenir un peu ennuyeuse.
Chris Travers
0

J'espère que ce lien est mieux à lire: 10 000 bases de données sur un cluster PostgreSQL par Jon Jensen, 2008.

Un extrait:

La réponse courte: Postgres 8.1 gère très bien 10 000 bases de données. \l dans psql génère une longue liste de bases de données, bien sûr, mais revient assez rapidement. Les tests de simultanéité ad hoc étaient corrects. L'exécution de requêtes, d'insertions, etc. sur un groupe trié sur le volet des diverses bases de données de jeu a bien fonctionné, y compris pendant la création de nouvelles bases de données.

[...]

La limite réelle sur cette plate-forme [ Linux ext3 ] est probablement 31995 bases de données, car chaque base de données occupe un sous-répertoire dans data / base / et le système de fichiers ext3 a une limite de 31998 sous-répertoires par répertoire, provenant de sa limite de 32000 liens par inode.

user117336
la source
1
Les réponses qui ne contiennent que des liens ne sont pas très utiles, car les liens ont tendance à devenir périmés au fil du temps. Veuillez envisager d'ajouter le résumé de tout ce à quoi vous créez un lien dans votre réponse.
mustaccio