(Courriels de diversion: <termineront@bougonne-incongru.com> <paniquons@assoupissais-glorifier.com> <discordantes@atrophierions-corroborerions.com> <tressailliraient@desintoxiquerent-raisonnant.com> <agresses@sous-expositions-condensations.com> <rationnant@revenaient-detectes.com> <subjuguons@engloutirait-quête.com> <presbyte@attribuaient-orthographierais.com> <parodies@oripeaux-detaxent.com> <gendarmees@espacement-retirait.com> )
Bonjour, Tonton Th a écrit : | "En effet, les recherches d'itinéraires ne nous apportant pas de | revenus directs," | | Eh, trouduc, si tu ne sais pas où vont tes avions, | explique-moi comment tu vends tes billets... Il n'a pas tort : il ne vend pas le calcul d'itinéraire et ce dernier ne lui octroie donc aucun revenu _direct_. | "45 serveurs quadriprocesseurs 64 bits Itanium 2, équipés de 32 Go | de mémoire vive." & "dans 267 tables transactionnelles InnoDB, | autorisant un verrouillage fin sur chaque enregistrement" | | Donc, InnoDB, ça rame. Il faudrait voir les traitements effecutés, notamment au niveau des jointures, avant de conclure... | "Le support des transactions est indispensable, car les données | issues des serveurs frontaux HP Non-Stop Server sont synchronisées | en permanence avec le cluster." | | Euh, ça rame tellement qu'on est obligé de mettre un frontal ? Répartir les serveurs applicatifs et SGBD sur des machines différentes est chose courante. Dès lors que ce type d'architecture est mis en oeuvre, seul l'accès aux serveurs applicatifs est nécessaire. Il est même fortement recommandé dans ce cas de figure d'interdire l'accès direct aux SGBD aux utilisateurs et autres applications. | "Nos tests ont montré que les performances de MySQL étaient aussi | bonnes - voire parfois meilleures - que celles des produits | propriétaires." | | Et PostgreSQL, il pue le mazout ? Personnellement, je suis un inconditionnel de PostgreSQL car il me séduit par sa richesse fonctionnelle et sa capacité à prendre en charge des bases de données très volumineuses et complexes (sans compter moult détails tel que la richesse et l'efficacité de la console psql). Ceci étant, j'ai effectué quelques tests de performance sur des bases un peu volumineuses mais très simples et il n'y a pas photo : MySQL est plus rapide que PostgreSQL et qu'Oracle (forcément, comme il y a plein de choses que MySQL ne gère pas, le code a moins de contrôles à effectuer et moins d'étapes à franchir, il ne peut donc être que plus rapide). Par contre, quand les choses se compliquent, que les besoins se font plus pointus ou qu'on atteint des volumes très importants, PostgreSQL me semble incontournable (ceci étant, à titre personnel, j'utilise PostgreSQL en toute circonstance). | "La licence commerciale. Nous ne voulions pas reverser notre code | à la communauté open source, car il expose des éléments stratégiques | de notre activité. Cette licence nous protège de l'effet viral de | la licence GPL" | | Ah oui, vu comme ça, PostgreSQL pue le paté moisi, pour eux. Et | MySQL, c'est tellement bien, qu'on est obligé de le patcher pour | que ça marche. Sur ce point, la réflexion de Michael Benzinger m'amuse car elle montre une mauvaise compréhension de la GNU GPL. ATSE est visiblement une application interne, exclusivement utilisée par Sabre Holdings. Or, la GNU GPL n'impose la diffusion du code source que lorsque le produit est fourni à des tiers. On peut donc développer autant de produits internes qu'on le souhaite sans la moindre contrainte. | "Et MySQL 5.0 introduira les procédures stockées et les triggers." | | Depuis combien de temps MySQL vaporwariZe ? On peut dire ce que l'on veut mais MySQL AG est une boîte sérieuse qui tient ses promesses. Si de telles fonctionnalités sont programmées dans la version 5.0, on peut les attendre avec une relative confiance. | "D'autant que ses fonctions sont parfaitement standards." | | Bel aphorisme pour décideur pressé, ça :) En plus, cette information est fausse (ce qui n'est pas forcément un mal puisqu'il est heureux que certains SGBD aillent plus loin que la stricte norme et fournissent des fonctionnalités avancées) : http://dev.mysql.com/doc/mysql/fr/Compatibility.html | "Elle y supporte des transactions Acid sur de gros volumes : | 300 000 requêtes par heure. " | | 300,000 / 3600 = 83.333 requ/seconde. | 83.333 / (45*4) = 0.463 requ/sec/cpu. | | Mon 486dx2 en fait autant, donc. J'ai la plus grosse aussi. Là encore, il faut prendre ces chiffres avec des pincettes. Je pense que Michael Benzinger parle de requête au sens applicatif et non au sens SQL strict : le calcul d'un itinéraire peut nécessité plusieurs dizaines de requêtes SQL plus ou moins complexes. | Fin analyse publi-reportage Soyons positifs et réjouissons-nous : le type explique qu'il utilise des logiciels libres sous forte contrainte et qu'il est pleinement satisfait. C'est de la bonne pub pour le libre ! Sébastien -- Sébastien Dinot, sdinot@april.orgSecrétaire de l'APRIL (http://www.april.org) Association pour la Promotion et la Recherche en Informatique Libre -------------------------------------------------------------------- Les listes de diffusion occultes: <URL:http://www.CULTe.org/listes/>