L'organisation des fichiers avec mysql est simple :
/var/lib/mysql puis
toto/ : tous les fichiers de la base toto
titi/ : tous les fichiers de la base titi
mysql/ : base pour la conf (compte, etc...).
...
L'implémentation de quota doit être simple pour un hébergeur.
Sous postgres, les choses sont plus compliquer et moins claire au niveau système de fichier. Le support de transaction peu créer une grosse quantité de donnée (hors du répertoire de la base de donnée en cour).
Afin, pour chaque connection sous un compte différent, progresql utilise un "postmaster" différent par process client. Un exemple pour être plus claire (en imaginant l'utilisation de connection persistante de php ; ce n'est pas un problème avec php en cgi ...) :
Apache établie une connection avec mysql sous le compte titi (lancement d'un process si la connection n'existe pas avec le serveur). Puis une connection avec mysql sous le compte toto (utilisation de la connection précedante). Sous mysql il n'y a, au pire,qu'un process mysql par process httpd.
Sous postgres il y a autant de process attachés à httpd qu'il y a de comptes (postgresql) utilisés (constaté avec PostgreSQL V6.2).
Imaginons maintenant 1000 comptes et un serveur apache qui peut monté à 200 process. Dans la pire des situations, on peut monter théoriquement à 200 000 process ... et le nombre de fichier ouvert doit etre considérable... Enfin, il faut reconfigurer les ipc (dont postgresql est un assez gros consommateur).
Bref, PostgreSQL ne semble pas adapté à l'hébergement d'un gros nombre de base de donnée sous différents comptes.
Il y a certainement des conneries dans ce post... mais j'ai déjà configuré un serveur pour ouvrir plus de 32 000 fichier (16000 n'étant même pas suffisant lors des tests de tenu en charge) car il hébergais plusieurs base de donné (via apache/php et connection persistante).
[^] # RE: hebergement de db
Posté par matiasf . En réponse à la dépêche PostgreSQL 7.2 is out. Évalué à 10.
L'organisation des fichiers avec mysql est simple :
/var/lib/mysql puis
toto/ : tous les fichiers de la base toto
titi/ : tous les fichiers de la base titi
mysql/ : base pour la conf (compte, etc...).
...
L'implémentation de quota doit être simple pour un hébergeur.
Sous postgres, les choses sont plus compliquer et moins claire au niveau système de fichier. Le support de transaction peu créer une grosse quantité de donnée (hors du répertoire de la base de donnée en cour).
Afin, pour chaque connection sous un compte différent, progresql utilise un "postmaster" différent par process client. Un exemple pour être plus claire (en imaginant l'utilisation de connection persistante de php ; ce n'est pas un problème avec php en cgi ...) :
Apache établie une connection avec mysql sous le compte titi (lancement d'un process si la connection n'existe pas avec le serveur). Puis une connection avec mysql sous le compte toto (utilisation de la connection précedante). Sous mysql il n'y a, au pire,qu'un process mysql par process httpd.
Sous postgres il y a autant de process attachés à httpd qu'il y a de comptes (postgresql) utilisés (constaté avec PostgreSQL V6.2).
Imaginons maintenant 1000 comptes et un serveur apache qui peut monté à 200 process. Dans la pire des situations, on peut monter théoriquement à 200 000 process ... et le nombre de fichier ouvert doit etre considérable... Enfin, il faut reconfigurer les ipc (dont postgresql est un assez gros consommateur).
Bref, PostgreSQL ne semble pas adapté à l'hébergement d'un gros nombre de base de donnée sous différents comptes.
Il y a certainement des conneries dans ce post... mais j'ai déjà configuré un serveur pour ouvrir plus de 32 000 fichier (16000 n'étant même pas suffisant lors des tests de tenu en charge) car il hébergais plusieurs base de donné (via apache/php et connection persistante).