On se place dans le cas de processus ou de thread ?
L'un ou l'autre suivant le MPM Apache utilisé (prefork ou worker).
Au démarrage de apache toutes les connexions se font d'un coup puis sont partagées entre les sessions php ?
Non. Quand tu crées ta connexion avec un *_pconnect (donc la première fois que le fils va exécuter une page PHP qui fait un appel à une fonction *_pconnect), le fils Apache conserve la connexion pour toute sa durée de vie.
Et lorsque ce fils la meurt, que deviennent les connexions ?
La connexion est fermée. C'est l'un des moyens de garantir que tes connexions vont se fermer une fois de temps en temps. Ca fait du ménage.
Je n'arrive pas a comprendre comment les connexions sont ensuite partagées ?
Elles ne sont pas partagées.
Pour chaque fils Apache et pour un DSN donné, tu as une et une seule connexion.
Toutes les requêtes qui sont traitées par ce fils utilisent la même connexion.
Les autres fils ont leur connexion propre.
Donc 30 fils Apache qui ont au moins fait un _pconnect durant leur vie = 30 connexions persistentes à la base de données. S'ils se sont connectées à 3 bases de données différentes (plusieurs applications avec des bases différentes), ça te fait 3 connexions par fils donc 90 connexions établies.
On en arrive vite à utiliser un pool de connexions entre les serveurs web et la base, du coup (en tout cas pour du PostgreSQL).
Je ne comprends plus rien à PHP ou alors il a grandement évolué dans sa version 5...
Euh, ça fonctionne comme ça depuis au moins les versions 4.0.x (je n'ai pas touché à PHP avant).
Non, tu as du confondre avec une utilisation en mode CGI.
En utilisant PHP en mode module sous Apache, PHP s'arrête entre chaque page, pas le fils Apache et c'est le fils Apache qui maintient la connexion que tu récupères à l'exécution de chaque fils PHP.
Voir http://fr2.php.net/manual/en/features.persistent-connections(...) (il y a une section qui concerne le module Apache) et c'est très facile de vérifier en le testant (la majorité de nos applications PHP/PostgreSQL sont en connexions persistentes et cela fonctionne effectivement comme attendu).
Oui, complètement d'accord. Et même si mes nouveaux écrans sont plutôt bons (ce sont deux Samsung 206BW), c'est bien en dessous de mon Flatron en terme de qualité d'image et de dynamique.
Mais :
- ça prend vraiment trop de place,
- ça fait plusse mal aux yeux,
- mes deux écrans étaient de tailles/résolutions différentes et c'était un peu chiant à la longue.
Bon et puis pour être chiant, Squid c'est plutôt un proxy cache, très complet, très utile et extensible pour authentifier les gens et faire tout sorte de chose en tant que proxy. Il permet de fonctionner en reverse proxy.
Ca a beaucoup changé avec la 2.6 (qui a un âge certain maintenant) qui fait de Squid un vrai reverse-proxy alors qu'avant c'était juste une possibilité un peu rustre. Le fait de pouvoir utiliser toutes les fonctionnalités du proxy est vraiment un gros plus. Je pense particulièrement à l'ICP (pour faire communiquer deux Squids) ou aux delay_pools pour faire des limitations de BP en utilisant les ACL Squid (un delay_pool ne concerne que le trafic transmis aux parents donc permet de régler la BP RP <-> frontaux - on l'utilise pour limiter l'activité des robots d'indexation sur un site très très indexé, ~ 2 millions de pages indexées par Google / jour si on ne limite pas). Les redirectors, les acls externes etc sont aussi des fonctionnalités bien chouettes qui ont des applications très concrètes.
La doc visolve est en plus très chouette et je n'ai pas vraiment trouvé de bonne doc pour varnish qui me permette de valider rapidement que je pourrais trouver/faire avec du VCL tout ce dont j'ai besoin.
Le seul truc ennuyeux est la limite de 2048*2048 quand on utilise compiz mais le chipset du D630 est probablement plus récent et corrige peut-être ce problème.
Merci pour ce lien. Il n'est pas dans le manuel de la 5.0 (la version stable actuelle) ce tableau, par contre, j'ai l'impression. C'est un chouette ajout.
Pas d'accord pour les contraintes d'intégrité. Ca existe en utilisant *certains* moteurs de stockage de MySQL, ça n'existe pas dans MySQL.
C'est très très différent parce que certaines autres fonctionnalités de MySQL excluent le choix de ces moteurs et ne permettent donc pas d'avoir les contraintes d'intégrité.
Dans le cas des contraintes d'intégrité de type foreign keys, ça te restreint à InnoDB et donc :
- tu n'as plus les count(*) instantanés magiques à la MyISAM,
- tu ne peux pas faire de multi-master,
- probablement d'autres trucs.
Bref, tu peux effectivement avoir des contraintes d'intégrité en utilisant certains moteurs mais ça te coupe de fonctionnalités proposées par d'autres. Le jour où cela sera supporté par tous les moteurs et ne sera pas discriminant, ce sera effectivement présent dans MySQL.
Ce serait intéressant d'avoir une matrice des fonctionnalités présentes dans chaque moteur pour bien voir le OU et pas une liste de fonctionnalités globales qui masque la réalité en faisant un ET.
Il y en a plusieurs différents sur des archis différentes (de mémoire, MySQL AB a participé à celui sur la plate-forme Sun d'ailleurs)
Mouais, je ne savais pas que les SGBD avaient à voir avec un quelconque « ordre naturel »
Disons que ça a à voir avec la cohérence.
de même que Postgres (ou un autre SGBD) peut très bien vivre sans laisser le choix de 5 (4 ? 6 ? j'ai arrêté de suivre) moteurs de stockage différents
Mouais. Ca n'a pas grand chose à voir avec ce dont je parlais. PostgreSQL offre une cohérence globale et un ensemble de fonctionnalités qui l'est tout autant (avec comme principe général que si c'est présent, ça marche sans limite). Et je préfère avoir cette cohérence que plein de moteurs différents qui ont tous des limitations bizarroïdes différentes, limitations qui ont des conséquences sur l'intégrité de mes données. Après, chacun ses choix :).
Evidemment, on peut apprendre à faire avec (ou plutôt sans), je me rappelle encore le temps où MySQL AB expliquait comment on pouvait se passer de toutes les fonctionnalités qu'ils intègrent maintenant. Il n'en reste pas moins que c'est tellement plus simple et tellement plus sécurisant avec.
Prendre un exemple pour illustrer mon propos, ce n'est pas de l'optimisation prématurée :). J'aurai pu prendre d'autres exemples mais celui-là a l'avantage de parler à tout le monde.
Le fait que MySQL puisse se limiter à une passe sur l'index en MyISAM est principalement dû au fait que MyISAM n'est pas MVCC (multi-version concurrency control). Donc en l'occurrence, c'est une limite de MyISAM qui permet de contourner le problème. De ce que j'ai lu, la musique est différente avec InnoDB. Et MyISAM a tellement d'autres limitations que je ne suis pas super motivé pour l'utiliser.
PostgreSQL ne stocke pas les infos de visibilité des tuples dans l'index et ne peut donc pas se limiter au parcours d'un index.
Bref, on peut sans doute trouver des contournements avec MySQL et trouver des raisons pour lesquelles c'est inutile (en l'occurrence, c'est assez dangereux de présager que ce sera inutile pour tout le monde...), mais il n'en reste pas moins que c'est une limitation dangereuse et qui peut surprendre parce que ce n'est pas dans l'ordre naturel des choses. A mon sens, il aurait mieux valu attendre d'avoir réglé ce problème avant de mettre à disposition les triggers dans MySQL.
éventuellement, une commande shell à éxecuter automatiquement juste avant la suppression d'un journal
En l'occurrence, cette action est effectuée quand PostgreSQL passe au fichier de journal suivant, pas quand le journal est supprimé ou réutilisé. C'est ce qui est utilisé pour la réplication via log shipping.
Avec PostgreSQL, tu n'as aucun mal à prévoir la taille totale des journaux: taille d'un fichier x nombre de fichiers.
En l'occurrence, ce n'est pas tout à fait vrai. PostgreSQL n'offre aucune garantie à ce niveau. A très très forte charge en écriture, tu peux dépasser les (2 * checkpoint_segments + 1) fichiers habituels. Ce n'est pas un cas qui se produit souvent mais il n'y a pas de garantie.
Ben, pour citer quelqu'un de chez MySQL "InnoDB is not a clustered engine" [http://forums.mysql.com/read.php?25,131517,131704#msg-131704].
Donc, quand on me dit que MySQL gère telle et telle fonctionnalité via InnoDB (les foreign keys par exemple) et qu'il ne faut évidemment pas utiliser MyISAM et qu'on me parle ensuite de MySQL Cluster, je me dis qu'il y a un bug quelque part :).
Sur le principe, l'idée d'avoir plusieurs moteurs est plutôt pas mal. Ce qui me gêne personnellement, c'est qu'ils ne sont vraiment pas homogènes et que certains ont des limitations vraiment tordues.
On retrouve un peu les mêmes limitations bizarres sur pas mal de fonctionnalités ajoutées ces dernières années un peu à la va-vite à mon goût.
Pour prendre un exemple concret sur les triggers : "Triggers currently are not activated by foreign key actions." [http://dev.mysql.com/doc/refman/5.0/en/routine-restrictions.(...)]
Si on imagine un forum avec des topics et des messages. On pose un trigger sur la table messages pour mettre à jour le nombre de messages dans un forum. Si on supprime un topic qui via une foreign key supprime les messages qui en dépendent, cela ne déclenchera pas le trigger de mise à jour du nombre de messages.
Il y a pas mal d'autres exemples dans le manuel (beaucoup de fonctionnalités ont une page avec les limitations).
C'est notamment toutes ces petites limitations bizarres qui me font éviter MySQL au maximum. PostgreSQL est, de manière générale, beaucoup plus cohérente.
Je ne sais pas si la réplication arrivera un jour dans le coeur de PostgreSQL. Il y a des "outils" pour construire des solutions de réplication dans le coeur mais la vision PostgreSQL de la chose est qu'il y a énormément de manières de faire de la réplication et qu'il est peu probable d'arriver à trouver une solution qui satisfasse tout le monde. D'où la mise en place d'outils communs et la construction de solutions différentes par dessus.
A noter que sur les 3 projets cités, seul Slony-I est à mon avis utilisable en production.
Juste quelques remarques générales sur les comparaisons avec MySQL :
* l'un des soucis que j'ai avec les papiers sur MySQL (et tu le soulignes à la fin de ton post), c'est que les gens additionnent l'ensemble des fonctionnalités de tous les moteurs. Pour chaque objet que tu crées, tu as un et un seul moteur donc parler des avantages d'InnoDB quand on utilise du MySQL Cluster et donc le moteur NDB est un non-sens. C'est soit l'un soit l'autre pour chaque objet. Chaque moteur a une page Known limitations assez conséquente en plus de ses spécificités en terme de performances donc ce n'est clairement pas une addition qu'il faut faire.
* je rappelle que la version stable de MySQL est la 5.0, que la 5.1 est encore en pre-release et on parle déjà des fonctionnalités de la 6.0 comme d'un fait et du moteur Falcon comme de quelque chose de stable. La 6.0 est loin d'être sortie (la 5.1 n'est toujours pas considérée stable alors qu'ils en sont à la 5.1.22...) et Falcon, aussi bon qu'il pourra être, sera très très très jeune comparé à tous les autres moteurs actuels. Seul l'avenir nous dira s'il vaut vraiment le coup et s'il est fiable, performant et pérenne dans toutes sortes de situations et de cas réels. Ni les fonctionnalités de la 5.1 ni celles de la 6 ne sont utilisables à l'heure actuelle en production.
Ensuite, juste pour info :
De même MySql permet aussi la sauvegarde par cliché (base gelée en écriture mais pas en lectureà alors que pg est le seul de la liste à ne pas le supporter)
Avec PostgreSQL, tu fais un SELECT pg_start_backup('ton_backup'); et non seulement tu peux faire un cliché mais ta base est toujours accessible en lecture *ET* en écriture. Cette fonctionnalité existe depuis la 8.1 soit depuis novembre 2005 (et je parle d'une vraie 8.1 finale, pas d'une pre-release).
OpenVZ, je n'aime pas le comportement de la société qui met en avant sa solution proprio partout, même sur le wiki "communautaire"
J'ai vraiment l'impression que c'est une fausse idée. J'ai fait pas mal de recherches concrètes sur OpenVZ et beaucoup lu la doc et les forums pour le mettre en place en test et je n'ai vraiment pas eu cette impression.
Un des trucs qui contredit ce que tu penses, c'est qu'ils fournissent des noyaux patchés pour pas mal de distributions et les maintiennent (ils maintiennent encore le noyau de la RHEL4 par exemple). Ca aide quand même pas mal à l'adoption d'OpenVZ alors qu'ils auraient pu fournir un patch et un kernel vanilla.
La virtualisation, je peux la concevoir dès lors qu'une redondance est assurée par une autre machine.
Je dirai la même chose de la non-virtualisation :).
Le fait d'avoir un SPOF n'est pas un problème intrinsèque de la virtualisation, juste que ton SPOF est peut-être plus critique. Ca reste une mauvaise idée d'avoir un SPOF. Et la "virtualisation" (j'inclus les containers) peut te permettre de redonder tes services de manière élégante (ie en évitant d'avoir une machine fourre-tout).
Pour prendre l'exemple d'une plate-forme d'un client qu'on est en train de refaire (l'ancienne a 3 ans et montre ces limites en terme de performances), toute la partie principale (grosso modo l'hébergement des sites soit 7 serveurs) n'est pas virtualisée. On sait qu'on a besoin de beaucoup de ressources et on ne veut pas la déstabiliser avec d'autres services.
Par contre, on a galéré pendant les 3 ans pour gérer des services annexes répartis sur plusieurs autres serveurs. Certains étaient petits au début et ont trop grossi pour qu'on les laisse perturber les autres services d'une machine. Pour d'autres, on avait prévu large et finalement, ça a vivoté. Du coup, on a pas mal galéré à déplacer les services, les réorganiser...
On a maintenant 4 machines banalisées pour ces services. Chaque service est dans un VServer et s'il y a besoin de les balader, ça se fera de manière plutôt transparente.
Le principe du "j'ai un serveur qui tombe, je perds n services" n'est pas forcément pertinent vu qu'on ne peut pas vraiment se permettre de perdre ne serait-ce qu'un service. Donc, les VServers sont doublés sur les 4 machines (ce qui aurait été chiant à faire sinon parce que tous les services auraient été mélangés).
En l'occurrence, on n'a pas moins de serveurs qu'avant sur la plate-forme. On est passé de 17 à 15 mais juste parce qu'on a supprimé une couche intermédiaire. Par contre, c'est plus propre, on peut la faire évoluer plus facilement et on sera serein sur les démarrages de nouvelles fonctionnalités ou pour l'évolution des anciennes. Pas besoin de prévoir 2 serveurs dès le départ, on monte 1 ou 2 VMs pour les différents services et on attend de voir ce que cela donne.
Après pour prendre un autre exemple avec de la vraie virtualisation, c'est aussi très pratique sur des machines d'intégration pour avoir plein d'environnements différents.
Clairement, il y a un gros effet de mode actuellement mais derrière il y a des vrais besoins et cela apporte vraiment quelque chose sur le plan pratique.
En particulier sur OpenVZ. Pour avoir très sérieusement envisagé de l'utiliser, je n'ai jamais eu l'impression que les gens de Virtuozzo poussaient outre mesure les utilisateurs vers la solution propriétaire, que ce soit dans les forums et sur les mailing-lists où j'ai toujours vu une attitude très constructive pour aider les utilisateurs. Ils maintiennent vraiment OpenVZ comme une solution technique viable et fiable, pas comme une version de développement mal finie de Virtuozzo.
De plus, ils ont une vraie volonté d'intégrer leurs technos dans le noyau Linux pour que Linux propose enfin en standard une vraie solution de container.
Le seul truc qui m'a un peu rebuté dans OpenVZ, c'est la gestion des ressources puissantes mais pas spécialement facile à prendre en main. Il est difficile de trouver de la documentation concrète sur le sujet.
Je n'aurai pas comparé les solutions de containers type VServer et OpenVZ avec les solutions de virtualisation que peuvent être Xen ou KVM. Les usages et les contraintes ne sont pas du tout les mêmes et il faut, AMHA, au moins une solution de chaque.
Typiquement, quand il s'agit juste d'obtenir un gain de facilité d'administration en compartimentant des services (avec pour objectif d'avoir des services bien identifiés, de pouvoir les rerépartir sur des machines en fonction de leur évolution...), les solutions de container sont clairement devant. Elles sont beaucoup plus souples et offrent en général de meilleures performances.
Je suis par ailleurs un peu surpris par le fait que VServer soit considéré comme complexe - il est à mon sens plutôt simple à utiliser et les outils sont assez rodés. Je suis par contre on ne peut plus d'accord sur le fait que maintenir des patches sur des trucs aussi complexes peut poser des soucis de maintenabilité à long terme.
OpenVZ a l'avantage de proposer des patches sur les kernels des distributions (notamment ceux des RHEL), ce qui est plutôt bien pour des serveurs de production. Il me semble qu'il y a des kernels debian aussi mais je n'y mettrai pas ma main au feu.
Bon, après, c'est probablement un peu facile de critiquer mais je pense qu'il est important d'insister sur le fait que containers ET virtualisation ne répondent pas aux mêmes besoins et qu'il est important d'avoir les deux. Et j'attends avec impatience le jour où il y aura enfin une solution de containers dans les kernels standards.
Oulah, pas du tout. Open Wide est une société indépendante. Il y a bien quelques investisseurs institutionnels dans notre capital (Thales et Schneider Electric notamment) mais c'est tout.
Nous n'avons aucun lien avec Bull.
Il me semble aussi qu'il existe une extension pour postgresql qui permet de gérer des arborescences.
Oui, il s'agit de ltree ( http://www.sai.msu.su/~megera/postgres/gist/ltree/ ). Comme beaucoup d'extensions PostgreSQL, il s'agit d'un type particulier et d'un ensemble d'opérateurs/fonctions pour ce type (et ça utilise le framework GiST pour les index).
Le principe est simplissime. L'arbre est créée sous la forme Racine, Racine.Noeud1, Racine.Noeud1.Noeud2. Chaque noeud a donc un libellé propre et un chemin depuis la racine. Ensuite des opérateurs permettent d'obtenir les fils, les parents...
Pour l'utiliser dans un projet, ça marche très très bien. La seule contrainte est qu'il faut mettre à jour tous les fils quand on déplace un noeud car chaque noeud a le chemin complet de l'arborescence (cette manipulation est triviale mais peut causer la mise à jour d'un grand nombre de noeuds).
Les opérateurs fournis permettent de manipuler l'arbre de manière triviale et très rapide (en posant les index qui vont mieux).
Et pour finir, il est très facile de se rendre compte de la tête de l'arbre et de détecter un problème en regardant les lignes de la table, ce qui est loin d'être toujours le cas avec les autres méthodes.
Le problème, c'est que ce n'est pas portable du tout donc à réserver à des projets pour lesquels la portabilité des requêtes n'est pas une contrainte.
Et a aussi des inconvénients :). Le but n'était pas de troller sur qui était preum's, juste de répondre à la question par rapport à PostgreSQL. Le lien de wikipedia reprend toute la liste des bases supportant MVCC et Interbase était effectivement une des premières à l'implémenter.
ce n'est pas un fork, c'est un nouveau type de gestion de données pour Mysql qui s'ajoute à la longue liste en plus de MyIsam, InnoDB, ...
Oui, oui, je connais le fonctionnement du moteur MySQL. Ce que je voulais signaler, c'est le fait que c'est à conjuguer au futur. Il _va_ s'ajouter à la liste quand il sera stable. MySQL AB a un peu tendance à faire du marketing bien avant qu'une fonctionnalité soit dans une version stable.
Même après l'intégration dans une version stable, il se passera un petit moment avant que ce backend soit vraiment considéré comme production ready (résistance aux pannes, scalabilité, traitement de requêtes complexes...).
Je suis curieux de voir ce que cela va donner en terme de scalabilité, de performances et de sécurité des données. Je n'aime pas MySQL pour plein d'autres raisons que les problèmes avec les moteurs actuels donc ça ne me fera pas abandonner ma préférence pour PostgreSQL mais c'est toujours intéressant de jeter un oeil sur un petit nouveau.
PostgreSQL implémente également un modèle MVCC, depuis très longtemps. Voir mon commentaire plus complet plus bas : http://linuxfr.org/comments/790027.html#790027 avec notamment la liste des SGBD(R) qui l'implémentent.
> les tables MyIsam ne sont là que pour les applications légères qui n'ont pas besoin des avantages/inconvénients/fonctionnalités des transactions
Sans oublier les "avantages/inconvénients/fonctionnalités" du moteur InnoDB car le moteur InnoDB a des inconvénients qui ne sont pas forcément dans les autres bases transactionnelles (et peut-être vice versa d'ailleurs).
Le mot magique n'est pas transaction. Le mot magique est versioning des lignes : c'est la grosse nouveauté apporté par ce moteur. PostgreSQL implémente un modèle MVCC (multi version concurrency control) depuis très longtemps (ca a été ajouté entre la 6 et la 7, ca a toujours été le cas dans la branche 7 en tout cas donc déjà en 2000).
Le principe est d'avoir plusieurs versions de la même ligne afin de permettre à des transactions différentes d'avoir une vue différente de la base.
Les implémentations peuvent être assez différentes suivant les bases : Oracle utilise un undo log pour gérer cela (d'après mes lectures, jamais utilisé Oracle), PostgreSQL conserve toutes les versions jusqu'à un VACUUM qui supprime les versions plus vieilles que la plus ancienne des transactions.
[^] # Re: Durée de vie des objets et connexions permanentes...
Posté par Guillaume Smet (site web personnel) . En réponse à la dépêche Zend Framework 1.5 : consolidation et disponibilité. Évalué à 3.
L'un ou l'autre suivant le MPM Apache utilisé (prefork ou worker).
Au démarrage de apache toutes les connexions se font d'un coup puis sont partagées entre les sessions php ?
Non. Quand tu crées ta connexion avec un *_pconnect (donc la première fois que le fils va exécuter une page PHP qui fait un appel à une fonction *_pconnect), le fils Apache conserve la connexion pour toute sa durée de vie.
Et lorsque ce fils la meurt, que deviennent les connexions ?
La connexion est fermée. C'est l'un des moyens de garantir que tes connexions vont se fermer une fois de temps en temps. Ca fait du ménage.
Je n'arrive pas a comprendre comment les connexions sont ensuite partagées ?
Elles ne sont pas partagées.
Pour chaque fils Apache et pour un DSN donné, tu as une et une seule connexion.
Toutes les requêtes qui sont traitées par ce fils utilisent la même connexion.
Les autres fils ont leur connexion propre.
Donc 30 fils Apache qui ont au moins fait un _pconnect durant leur vie = 30 connexions persistentes à la base de données. S'ils se sont connectées à 3 bases de données différentes (plusieurs applications avec des bases différentes), ça te fait 3 connexions par fils donc 90 connexions établies.
On en arrive vite à utiliser un pool de connexions entre les serveurs web et la base, du coup (en tout cas pour du PostgreSQL).
Je ne comprends plus rien à PHP ou alors il a grandement évolué dans sa version 5...
Euh, ça fonctionne comme ça depuis au moins les versions 4.0.x (je n'ai pas touché à PHP avant).
[^] # Re: Durée de vie des objets et connexions permanentes...
Posté par Guillaume Smet (site web personnel) . En réponse à la dépêche Zend Framework 1.5 : consolidation et disponibilité. Évalué à 4.
En utilisant PHP en mode module sous Apache, PHP s'arrête entre chaque page, pas le fils Apache et c'est le fils Apache qui maintient la connexion que tu récupères à l'exécution de chaque fils PHP.
Voir http://fr2.php.net/manual/en/features.persistent-connections(...) (il y a une section qui concerne le module Apache) et c'est très facile de vérifier en le testant (la majorité de nos applications PHP/PostgreSQL sont en connexions persistentes et cela fonctionne effectivement comme attendu).
--
Guillaume
# Pour info
Posté par Guillaume Smet (site web personnel) . En réponse au journal Donne écrans cathodiques sur Lyon. Évalué à 3.
[^] # Re: ma vie
Posté par Guillaume Smet (site web personnel) . En réponse au journal Donne écrans cathodiques sur Lyon. Évalué à 2.
Mais :
- ça prend vraiment trop de place,
- ça fait plusse mal aux yeux,
- mes deux écrans étaient de tailles/résolutions différentes et c'était un peu chiant à la longue.
Donc, je suis plutôt content du changement.
[^] # Re: Récup
Posté par Guillaume Smet (site web personnel) . En réponse au journal Donne écrans cathodiques sur Lyon. Évalué à 2.
[^] # Re: montée en charge
Posté par Guillaume Smet (site web personnel) . En réponse à la dépêche Drupal 6 est sorti. Évalué à 3.
Ca a beaucoup changé avec la 2.6 (qui a un âge certain maintenant) qui fait de Squid un vrai reverse-proxy alors qu'avant c'était juste une possibilité un peu rustre. Le fait de pouvoir utiliser toutes les fonctionnalités du proxy est vraiment un gros plus. Je pense particulièrement à l'ICP (pour faire communiquer deux Squids) ou aux delay_pools pour faire des limitations de BP en utilisant les ACL Squid (un delay_pool ne concerne que le trafic transmis aux parents donc permet de régler la BP RP <-> frontaux - on l'utilise pour limiter l'activité des robots d'indexation sur un site très très indexé, ~ 2 millions de pages indexées par Google / jour si on ne limite pas). Les redirectors, les acls externes etc sont aussi des fonctionnalités bien chouettes qui ont des applications très concrètes.
La doc visolve est en plus très chouette et je n'ai pas vraiment trouvé de bonne doc pour varnish qui me permette de valider rapidement que je pourrais trouver/faire avec du VCL tout ce dont j'ai besoin.
# Intellinuxgraphics
Posté par Guillaume Smet (site web personnel) . En réponse au message Carte Intel GM965/GL960 et dual screen ? (portable DELL D630). Évalué à 1.
Le seul truc ennuyeux est la limite de 2048*2048 quand on utilise compiz mais le chipset du D630 est probablement plus récent et corrige peut-être ce problème.
[^] # Re: postgresql c'est mieux
Posté par Guillaume Smet (site web personnel) . En réponse à la dépêche Sortie de PostgreSQL 8.3. Évalué à 3.
[^] # Re: postgresql c'est mieux
Posté par Guillaume Smet (site web personnel) . En réponse à la dépêche Sortie de PostgreSQL 8.3. Évalué à 10.
C'est très très différent parce que certaines autres fonctionnalités de MySQL excluent le choix de ces moteurs et ne permettent donc pas d'avoir les contraintes d'intégrité.
Dans le cas des contraintes d'intégrité de type foreign keys, ça te restreint à InnoDB et donc :
- tu n'as plus les count(*) instantanés magiques à la MyISAM,
- tu ne peux pas faire de multi-master,
- probablement d'autres trucs.
Bref, tu peux effectivement avoir des contraintes d'intégrité en utilisant certains moteurs mais ça te coupe de fonctionnalités proposées par d'autres. Le jour où cela sera supporté par tous les moteurs et ne sera pas discriminant, ce sera effectivement présent dans MySQL.
Ce serait intéressant d'avoir une matrice des fonctionnalités présentes dans chaque moteur pour bien voir le OU et pas une liste de fonctionnalités globales qui masque la réalité en faisant un ET.
[^] # Re: Et Derby alors ?
Posté par Guillaume Smet (site web personnel) . En réponse à la dépêche Sun Microsystems fait l'acquisition de MySQL. Évalué à 3.
http://tweakers.net/reviews/657/2/database-test-dual-intel-x(...)
Il y en a plusieurs différents sur des archis différentes (de mémoire, MySQL AB a participé à celui sur la plate-forme Sun d'ailleurs)
Disons que ça a à voir avec la cohérence.
Mouais. Ca n'a pas grand chose à voir avec ce dont je parlais. PostgreSQL offre une cohérence globale et un ensemble de fonctionnalités qui l'est tout autant (avec comme principe général que si c'est présent, ça marche sans limite). Et je préfère avoir cette cohérence que plein de moteurs différents qui ont tous des limitations bizarroïdes différentes, limitations qui ont des conséquences sur l'intégrité de mes données. Après, chacun ses choix :).
Evidemment, on peut apprendre à faire avec (ou plutôt sans), je me rappelle encore le temps où MySQL AB expliquait comment on pouvait se passer de toutes les fonctionnalités qu'ils intègrent maintenant. Il n'en reste pas moins que c'est tellement plus simple et tellement plus sécurisant avec.
[^] # Re: Et Derby alors ?
Posté par Guillaume Smet (site web personnel) . En réponse à la dépêche Sun Microsystems fait l'acquisition de MySQL. Évalué à 2.
Le fait que MySQL puisse se limiter à une passe sur l'index en MyISAM est principalement dû au fait que MyISAM n'est pas MVCC (multi-version concurrency control). Donc en l'occurrence, c'est une limite de MyISAM qui permet de contourner le problème. De ce que j'ai lu, la musique est différente avec InnoDB. Et MyISAM a tellement d'autres limitations que je ne suis pas super motivé pour l'utiliser.
PostgreSQL ne stocke pas les infos de visibilité des tuples dans l'index et ne peut donc pas se limiter au parcours d'un index.
Bref, on peut sans doute trouver des contournements avec MySQL et trouver des raisons pour lesquelles c'est inutile (en l'occurrence, c'est assez dangereux de présager que ce sera inutile pour tout le monde...), mais il n'en reste pas moins que c'est une limitation dangereuse et qui peut surprendre parce que ce n'est pas dans l'ordre naturel des choses. A mon sens, il aurait mieux valu attendre d'avoir réglé ce problème avant de mettre à disposition les triggers dans MySQL.
[^] # Re: Et Derby alors ?
Posté par Guillaume Smet (site web personnel) . En réponse à la dépêche Sun Microsystems fait l'acquisition de MySQL. Évalué à 2.
En l'occurrence, cette action est effectuée quand PostgreSQL passe au fichier de journal suivant, pas quand le journal est supprimé ou réutilisé. C'est ce qui est utilisé pour la réplication via log shipping.
En l'occurrence, ce n'est pas tout à fait vrai. PostgreSQL n'offre aucune garantie à ce niveau. A très très forte charge en écriture, tu peux dépasser les (2 * checkpoint_segments + 1) fichiers habituels. Ce n'est pas un cas qui se produit souvent mais il n'y a pas de garantie.
[^] # Re: Et Derby alors ?
Posté par Guillaume Smet (site web personnel) . En réponse à la dépêche Sun Microsystems fait l'acquisition de MySQL. Évalué à 3.
Donc, quand on me dit que MySQL gère telle et telle fonctionnalité via InnoDB (les foreign keys par exemple) et qu'il ne faut évidemment pas utiliser MyISAM et qu'on me parle ensuite de MySQL Cluster, je me dis qu'il y a un bug quelque part :).
Sur le principe, l'idée d'avoir plusieurs moteurs est plutôt pas mal. Ce qui me gêne personnellement, c'est qu'ils ne sont vraiment pas homogènes et que certains ont des limitations vraiment tordues.
On retrouve un peu les mêmes limitations bizarres sur pas mal de fonctionnalités ajoutées ces dernières années un peu à la va-vite à mon goût.
Pour prendre un exemple concret sur les triggers : "Triggers currently are not activated by foreign key actions." [http://dev.mysql.com/doc/refman/5.0/en/routine-restrictions.(...)]
Si on imagine un forum avec des topics et des messages. On pose un trigger sur la table messages pour mettre à jour le nombre de messages dans un forum. Si on supprime un topic qui via une foreign key supprime les messages qui en dépendent, cela ne déclenchera pas le trigger de mise à jour du nombre de messages.
Il y a pas mal d'autres exemples dans le manuel (beaucoup de fonctionnalités ont une page avec les limitations).
C'est notamment toutes ces petites limitations bizarres qui me font éviter MySQL au maximum. PostgreSQL est, de manière générale, beaucoup plus cohérente.
[^] # Re: Et Derby alors ?
Posté par Guillaume Smet (site web personnel) . En réponse à la dépêche Sun Microsystems fait l'acquisition de MySQL. Évalué à 2.
Je ne sais pas si la réplication arrivera un jour dans le coeur de PostgreSQL. Il y a des "outils" pour construire des solutions de réplication dans le coeur mais la vision PostgreSQL de la chose est qu'il y a énormément de manières de faire de la réplication et qu'il est peu probable d'arriver à trouver une solution qui satisfasse tout le monde. D'où la mise en place d'outils communs et la construction de solutions différentes par dessus.
A noter que sur les 3 projets cités, seul Slony-I est à mon avis utilisable en production.
[^] # Re: Et Derby alors ?
Posté par Guillaume Smet (site web personnel) . En réponse à la dépêche Sun Microsystems fait l'acquisition de MySQL. Évalué à 9.
* l'un des soucis que j'ai avec les papiers sur MySQL (et tu le soulignes à la fin de ton post), c'est que les gens additionnent l'ensemble des fonctionnalités de tous les moteurs. Pour chaque objet que tu crées, tu as un et un seul moteur donc parler des avantages d'InnoDB quand on utilise du MySQL Cluster et donc le moteur NDB est un non-sens. C'est soit l'un soit l'autre pour chaque objet. Chaque moteur a une page Known limitations assez conséquente en plus de ses spécificités en terme de performances donc ce n'est clairement pas une addition qu'il faut faire.
* je rappelle que la version stable de MySQL est la 5.0, que la 5.1 est encore en pre-release et on parle déjà des fonctionnalités de la 6.0 comme d'un fait et du moteur Falcon comme de quelque chose de stable. La 6.0 est loin d'être sortie (la 5.1 n'est toujours pas considérée stable alors qu'ils en sont à la 5.1.22...) et Falcon, aussi bon qu'il pourra être, sera très très très jeune comparé à tous les autres moteurs actuels. Seul l'avenir nous dira s'il vaut vraiment le coup et s'il est fiable, performant et pérenne dans toutes sortes de situations et de cas réels. Ni les fonctionnalités de la 5.1 ni celles de la 6 ne sont utilisables à l'heure actuelle en production.
Ensuite, juste pour info :
Avec PostgreSQL, tu fais un SELECT pg_start_backup('ton_backup'); et non seulement tu peux faire un cliché mais ta base est toujours accessible en lecture *ET* en écriture. Cette fonctionnalité existe depuis la 8.1 soit depuis novembre 2005 (et je parle d'une vraie 8.1 finale, pas d'une pre-release).
[^] # Re: Bof
Posté par Guillaume Smet (site web personnel) . En réponse à la dépêche Livre blanc Bearstech sur la virtualisation en logiciel libre. Évalué à 2.
J'ai vraiment l'impression que c'est une fausse idée. J'ai fait pas mal de recherches concrètes sur OpenVZ et beaucoup lu la doc et les forums pour le mettre en place en test et je n'ai vraiment pas eu cette impression.
Un des trucs qui contredit ce que tu penses, c'est qu'ils fournissent des noyaux patchés pour pas mal de distributions et les maintiennent (ils maintiennent encore le noyau de la RHEL4 par exemple). Ca aide quand même pas mal à l'adoption d'OpenVZ alors qu'ils auraient pu fournir un patch et un kernel vanilla.
[^] # Re: Bof
Posté par Guillaume Smet (site web personnel) . En réponse à la dépêche Livre blanc Bearstech sur la virtualisation en logiciel libre. Évalué à 3.
Je dirai la même chose de la non-virtualisation :).
Le fait d'avoir un SPOF n'est pas un problème intrinsèque de la virtualisation, juste que ton SPOF est peut-être plus critique. Ca reste une mauvaise idée d'avoir un SPOF. Et la "virtualisation" (j'inclus les containers) peut te permettre de redonder tes services de manière élégante (ie en évitant d'avoir une machine fourre-tout).
[^] # Re: Bof
Posté par Guillaume Smet (site web personnel) . En réponse à la dépêche Livre blanc Bearstech sur la virtualisation en logiciel libre. Évalué à 5.
Pour prendre l'exemple d'une plate-forme d'un client qu'on est en train de refaire (l'ancienne a 3 ans et montre ces limites en terme de performances), toute la partie principale (grosso modo l'hébergement des sites soit 7 serveurs) n'est pas virtualisée. On sait qu'on a besoin de beaucoup de ressources et on ne veut pas la déstabiliser avec d'autres services.
Par contre, on a galéré pendant les 3 ans pour gérer des services annexes répartis sur plusieurs autres serveurs. Certains étaient petits au début et ont trop grossi pour qu'on les laisse perturber les autres services d'une machine. Pour d'autres, on avait prévu large et finalement, ça a vivoté. Du coup, on a pas mal galéré à déplacer les services, les réorganiser...
On a maintenant 4 machines banalisées pour ces services. Chaque service est dans un VServer et s'il y a besoin de les balader, ça se fera de manière plutôt transparente.
Le principe du "j'ai un serveur qui tombe, je perds n services" n'est pas forcément pertinent vu qu'on ne peut pas vraiment se permettre de perdre ne serait-ce qu'un service. Donc, les VServers sont doublés sur les 4 machines (ce qui aurait été chiant à faire sinon parce que tous les services auraient été mélangés).
En l'occurrence, on n'a pas moins de serveurs qu'avant sur la plate-forme. On est passé de 17 à 15 mais juste parce qu'on a supprimé une couche intermédiaire. Par contre, c'est plus propre, on peut la faire évoluer plus facilement et on sera serein sur les démarrages de nouvelles fonctionnalités ou pour l'évolution des anciennes. Pas besoin de prévoir 2 serveurs dès le départ, on monte 1 ou 2 VMs pour les différents services et on attend de voir ce que cela donne.
Après pour prendre un autre exemple avec de la vraie virtualisation, c'est aussi très pratique sur des machines d'intégration pour avoir plein d'environnements différents.
Clairement, il y a un gros effet de mode actuellement mais derrière il y a des vrais besoins et cela apporte vraiment quelque chose sur le plan pratique.
[^] # Re: Bof
Posté par Guillaume Smet (site web personnel) . En réponse à la dépêche Livre blanc Bearstech sur la virtualisation en logiciel libre. Évalué à 4.
En particulier sur OpenVZ. Pour avoir très sérieusement envisagé de l'utiliser, je n'ai jamais eu l'impression que les gens de Virtuozzo poussaient outre mesure les utilisateurs vers la solution propriétaire, que ce soit dans les forums et sur les mailing-lists où j'ai toujours vu une attitude très constructive pour aider les utilisateurs. Ils maintiennent vraiment OpenVZ comme une solution technique viable et fiable, pas comme une version de développement mal finie de Virtuozzo.
De plus, ils ont une vraie volonté d'intégrer leurs technos dans le noyau Linux pour que Linux propose enfin en standard une vraie solution de container.
Le seul truc qui m'a un peu rebuté dans OpenVZ, c'est la gestion des ressources puissantes mais pas spécialement facile à prendre en main. Il est difficile de trouver de la documentation concrète sur le sujet.
Je n'aurai pas comparé les solutions de containers type VServer et OpenVZ avec les solutions de virtualisation que peuvent être Xen ou KVM. Les usages et les contraintes ne sont pas du tout les mêmes et il faut, AMHA, au moins une solution de chaque.
Typiquement, quand il s'agit juste d'obtenir un gain de facilité d'administration en compartimentant des services (avec pour objectif d'avoir des services bien identifiés, de pouvoir les rerépartir sur des machines en fonction de leur évolution...), les solutions de container sont clairement devant. Elles sont beaucoup plus souples et offrent en général de meilleures performances.
Je suis par ailleurs un peu surpris par le fait que VServer soit considéré comme complexe - il est à mon sens plutôt simple à utiliser et les outils sont assez rodés. Je suis par contre on ne peut plus d'accord sur le fait que maintenir des patches sur des trucs aussi complexes peut poser des soucis de maintenabilité à long terme.
OpenVZ a l'avantage de proposer des patches sur les kernels des distributions (notamment ceux des RHEL), ce qui est plutôt bien pour des serveurs de production. Il me semble qu'il y a des kernels debian aussi mais je n'y mettrai pas ma main au feu.
Bon, après, c'est probablement un peu facile de critiquer mais je pense qu'il est important d'insister sur le fait que containers ET virtualisation ne répondent pas aux mêmes besoins et qu'il est important d'avoir les deux. Et j'attends avec impatience le jour où il y aura enfin une solution de containers dans les kernels standards.
[^] # Re: Linagora et autres SSLL
Posté par Guillaume Smet (site web personnel) . En réponse au journal Les SSLL en France. Évalué à 1.
Oulah, pas du tout. Open Wide est une société indépendante. Il y a bien quelques investisseurs institutionnels dans notre capital (Thales et Schneider Electric notamment) mais c'est tout.
Nous n'avons aucun lien avec Bull.
--
Guillaume
[^] # Re: Gestion d'arbres par représentation intervallaire
Posté par Guillaume Smet (site web personnel) . En réponse au journal Création du projet "OQLToLang". Évalué à 2.
Oui, il s'agit de ltree ( http://www.sai.msu.su/~megera/postgres/gist/ltree/ ). Comme beaucoup d'extensions PostgreSQL, il s'agit d'un type particulier et d'un ensemble d'opérateurs/fonctions pour ce type (et ça utilise le framework GiST pour les index).
Le principe est simplissime. L'arbre est créée sous la forme Racine, Racine.Noeud1, Racine.Noeud1.Noeud2. Chaque noeud a donc un libellé propre et un chemin depuis la racine. Ensuite des opérateurs permettent d'obtenir les fils, les parents...
Pour l'utiliser dans un projet, ça marche très très bien. La seule contrainte est qu'il faut mettre à jour tous les fils quand on déplace un noeud car chaque noeud a le chemin complet de l'arborescence (cette manipulation est triviale mais peut causer la mise à jour d'un grand nombre de noeuds).
Les opérateurs fournis permettent de manipuler l'arbre de manière triviale et très rapide (en posant les index qui vont mieux).
Et pour finir, il est très facile de se rendre compte de la tête de l'arbre et de détecter un problème en regardant les lignes de la table, ce qui est loin d'être toujours le cas avec les autres méthodes.
Le problème, c'est que ce n'est pas portable du tout donc à réserver à des projets pour lesquels la portabilité des requêtes n'est pas une contrainte.
[^] # Re: les transactions ...
Posté par Guillaume Smet (site web personnel) . En réponse au journal Arrivée de Falcon dans MySQL. Évalué à 2.
Et a aussi des inconvénients :). Le but n'était pas de troller sur qui était preum's, juste de répondre à la question par rapport à PostgreSQL. Le lien de wikipedia reprend toute la liste des bases supportant MVCC et Interbase était effectivement une des premières à l'implémenter.
Oui, oui, je connais le fonctionnement du moteur MySQL. Ce que je voulais signaler, c'est le fait que c'est à conjuguer au futur. Il _va_ s'ajouter à la liste quand il sera stable. MySQL AB a un peu tendance à faire du marketing bien avant qu'une fonctionnalité soit dans une version stable.
Même après l'intégration dans une version stable, il se passera un petit moment avant que ce backend soit vraiment considéré comme production ready (résistance aux pannes, scalabilité, traitement de requêtes complexes...).
Je suis curieux de voir ce que cela va donner en terme de scalabilité, de performances et de sécurité des données. Je n'aime pas MySQL pour plein d'autres raisons que les problèmes avec les moteurs actuels donc ça ne me fera pas abandonner ma préférence pour PostgreSQL mais c'est toujours intéressant de jeter un oeil sur un petit nouveau.
[^] # Re: questions
Posté par Guillaume Smet (site web personnel) . En réponse au journal Arrivée de Falcon dans MySQL. Évalué à 5.
PostgreSQL implémente également un modèle MVCC, depuis très longtemps. Voir mon commentaire plus complet plus bas : http://linuxfr.org/comments/790027.html#790027 avec notamment la liste des SGBD(R) qui l'implémentent.
[^] # Re: les transactions ...
Posté par Guillaume Smet (site web personnel) . En réponse au journal Arrivée de Falcon dans MySQL. Évalué à 3.
Sans oublier les "avantages/inconvénients/fonctionnalités" du moteur InnoDB car le moteur InnoDB a des inconvénients qui ne sont pas forcément dans les autres bases transactionnelles (et peut-être vice versa d'ailleurs).
[^] # Re: les transactions ...
Posté par Guillaume Smet (site web personnel) . En réponse au journal Arrivée de Falcon dans MySQL. Évalué à 4.
Le principe est d'avoir plusieurs versions de la même ligne afin de permettre à des transactions différentes d'avoir une vue différente de la base.
Les implémentations peuvent être assez différentes suivant les bases : Oracle utilise un undo log pour gérer cela (d'après mes lectures, jamais utilisé Oracle), PostgreSQL conserve toutes les versions jusqu'à un VACUUM qui supprime les versions plus vieilles que la plus ancienne des transactions.
Pour information :
http://www.pervasive-postgres.com/instantkb13/article.aspx?i(...)
http://en.wikipedia.org/wiki/Multiversion_concurrency_contro(...)
C'était un _gros_ manque de MySQL et ça l'est toujours en attendant d'avoir une version stable l'implémentant.