Changeset 766
- Timestamp:
- 10/23/07 17:48:38 (1 year ago)
- Files:
Legend:
- Unmodified
- Added
- Removed
- Modified
- Copied
- Moved
materials/advocacy/trunk/Why_PostgreSQL_Instead_of_MySQL.txt
r765 r766 354 354 // transaction, but perhaps hundreds of thousands, to the cost of doing updates. 355 355 * groupement de transactions : relatif au point précédent, PostgreSQL serait parfois affecté par des tests simplets 356 qui ne groupent pas correctement les transactions comme les applications le feraient. Cela n'ajoutera pas seulement le 357 coût d'une transaction, mais peut-être de centaines de milliers, au coût total de la réalisation des modifications. 356 qui ne groupent pas correctement les transactions comme les applications le feraient. Cela n'ajoute pas seulement 357 le coût d'une transaction, mais peut-être celui de centaines de milliers, au coût total de la réalisation des 358 modifications. 358 359 359 360 // * Serial versus concurrent behaviour: A number of the behaviors of MyISAM are tuned for having a single user … … 381 382 Le peu de différences matériels entre les deux systèmes suffit pour ne pas comparer les deux résultats directement. 382 383 Mais le fait que les deux résultats soient assé proches avec une configuration similaire suggère que malgrès que les 383 performances puissent être différentes entre les deux bases, l'importance de cette différence n'est pas particulièrement384 grande avec ce type d'application.384 performances puissent être différentes entre les deux bases, l'importance de cette différence n'est pas 385 particulièrement grande avec ce type d'application. 385 386 386 387 // For comparison sake, an Oracle on HP result offers a similar magnitude of performance on less impressive hardware, … … 463 464 // summarize data across the whole table; PostgreSQL must walk through all rows, in some sense. This normally results 464 465 // in a sequential scan reading information about every row in the table. 466 La raison de cette lenteur vient de l'implémentation MVCC de PostgreSQL. Le fait que plusieurs transactions puissent 467 voir différents états de données implique qu'il ne peut y avoir de méthode simple pour "COUNT(*)" pour résumer les 468 données sur l'ensemble de la table ; dans un sens, PostgreSQL doit parcourir toutes les lignes. Cela abouti 469 normalement sur un scan sequentiel lisant les informations de chaque ligne de la table. 465 470 466 471 // Some DBMSes provide the ability for "COUNT(*)" queries to work via consulting an index. Unfortunately, in 467 472 // PostgreSQL, this strategy does not work, as MVCC visibility information is not stored at the index level. It is 468 473 // necessary to actually examine the rows themselves to determine if they are visible to the transaction or not. 474 Certains SGBD fournissent aux requêtes "COUNT(*)" la capacité de fonctionner en consultant un index. Malheureusement, 475 dans PostgreSQL, cette strategie ne fonctionne pas, car l'information de visibilité MVCC n'est pas présent au niveau 476 de l'index. Il est nécessaire d'examiner les lignes elles-même pour déterminer si elles sont visible pour la 477 transaction ou pas. 469 478 470 479 // In MySQL, MyISAM tables cache the row count information, making this type of count operation almost instant. That … … 474 483 // on InnoDB can't assume that a full row count will be fast, and therefore are hampered by similar limitations to 475 484 // those present in PostgreSQL. 485 Dans MySQL, les tables MyISAM concervent en cache l'information sur le nombre de ligne, faisant de ce type de 486 dénombrement des opérations presque instantannées. C'est la raison pour laquelle tant de codes MySQL utilisent cette 487 construction présumant que c'est une opération triviale. Mais si vous utilisez InnoDB, ce ne sera plus le cas. Voir 488 "COUNT(*) for Innodb Tables" et "COUNT(*) vs COUNT(col)" pour les notes sur les limitations de MySQL dans ce domaine. 489 MySQL conçoit que déployé sur InnoDB, il ne peut assurer qu'un dénombrement de toutes les lignes soit rapide, et qu'ils 490 sont donc prisonnier des mêmes limitations que celles présentes dans PostgreSQL. 476 491 477 492 // It is worth observing that it is only this precise form of aggregate that must be so pessimistic; if augmented with 478 493 // a "WHERE" clause like 494 Il est utile de préciser que seule cette forme précise d'aggrégat doit être si pessimiste ; si elle est complétée avec 495 une clause "WHERE" comme : 479 496 480 497 // SELECT COUNT(*) FROM table WHERE status = 'something' … … 485 502 //PostgreSQL will still need to read the resulting rows to verify that they exist; other database systems 486 503 //many only need to reference the index in this situation. 487 PostgreSQL, MySQL, et beaucoup d'autres implémentations de base de données tireront profi lde la disponibilités des488 index pour le champs restreint afin de limiter le nombre d'enregistrement qdevant être comptés, ce qui accelère504 PostgreSQL, MySQL, et beaucoup d'autres implémentations de base de données tireront profit de la disponibilités des 505 index pour le champs restreint afin de limiter le nombre d'enregistrements devant être comptés, ce qui accelère 489 506 grandement de telles requêtes. 490 507 491 508 //One popular approach for applications that need a row count but can tolerate it not including transactions that are 492 509 //in the middle of being committed is to use a trigger-based mechanism to count the rows in the table. In PostgreSQL, 493 //another alternative when only an approximate count is needed is to use the reltuples field from the pg_class catalog table. 494 Une approche apprécié pour les applications qui ont besoin de compter les lignes mais ... 510 //another alternative when only an approximate count is needed is to use the reltuples field from the pg_class catalog 511 //table. 512 Une approche appréciée pour les applications qui ont besoin de compter les lignes et qui peuvent tolérer de ne pas 513 inclure les transactions en cours de réalisation, est d'utiliser un mécanisme à base de trigger pour compter les lignes 514 de la table. Dans PostgreSQL, une autre alternative est d'utiliser le champs reltuples de la table pg_class du 515 catalogue lorsque seul une valeur approximative est nécessaire. 495 516 496 517 //Join Complexity
