Je suis d'accord avec vous ICU est une vraie daube, tout comme les données concernant les fuseaux horaires et d'autres trucs absolument inadmissible sous linux.Envoyé par SQLpro
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
Je suis d'accord avec vous ICU est une vraie daube, tout comme les données concernant les fuseaux horaires et d'autres trucs absolument inadmissible sous linux.
Bonjour Frédéric,
Un détail dans ton article : La dernière colonne du tableau de comparaison présente "ratio (MS/PG)" alors que les chiffres donnés sont en fait un "ratio (PG/MS)".
https://www.cybertec-postgresql.com/...in-postgresql/
Transactions
Dans l'article il est bien expliqué que cette méthode est utilisée pour assurer l'isolation des transactions: les transactions ouvertes avant l'update continuent de voir l'ancienne ligne.
Alors puisque vous trouvez cette méthode "naze", auriez-vous un lien vers une "bonne" méthode pour faire des update sans remettre en cause l'isolation des transactions (et une méthode n'obligeant pas à verrouiller la ligne, puisque dans l'article, l'utilisateur de la session 1 n'avait pas posé de verrou)?
Oui, et ça le restera longtemps.... C'est lié à la conception même de PostGreSQL et de son fameux (je devrait dire "fumeux") MVCC....
Le MVCC (Multi Version Concurrency Control) assure le versionnement des lignes rendu nécessaire par le verrouillage optimiste.
Un verrou optimiste est le fait de conserver l'ancienne version de la ligne tout en créant une nouvelle jusqu'au moment ou la nouvelle soit confirmée par un COMMIT, auquel cas on peut se passer de l'ancienne si tous les autres transactions n'y accèdent plus. C'est comme cela que fonctionne aussi Oracle.
Oui, heureusement, tous les SGBDR ne sont pas aussi mal conçus à ce niveau en commençant par Oracle qui est le modèle que tente de copier, hélas très mal, PostGreSQL...
Voici ce que je dit dans le papier n° 3 de cette série :
"
Finally, the technical solution chosen for the MVCC of PostGreSQL (for duplicating rows) is the worst of all the RDBMS...
- in Oracle, the transaction log (undo part exactly) is used to reads the formerly rows. No more data are generated for this feature, but the remaining part of the transaction logs can growth up if a transaction runs a long time;
- In SQL Server the tempdb database is used to keep the row versions. Some more data, out of the production database is generated and quickly collected (garbage's) to liberate space. The tempdb system database has a particular behavior to perform this work. Recently (2019) SQL Server add the ADR/PVS mechanism to accelerate recovery and when this feature is activate, the row versions can be stored in specific storage relative to the database.
- In PostGreSQL, all the different versions of the table rows are kept inside the data pages of the table and reside in memory, when data are caching, then is written on disks, causes table bloats, until a mechanism call VACUUM proceed to sweep of the obsolete rows.
"
Un peu plus loin
"
The PG MVCC solution is the worst way to do it, because it has three major inconvenient:
- First, the table is naturally bloating, and this "bloattage" is increasing severely when the number of concurrent transactional operation is high...
- Second, because that pages are the minimal logical memory storage, the data cache (table and index's pages containing rows are pin in memory to reduce IO disk access) is filled with plenty of obsolete rows, this results in the cache memory being replete with a lot of unnecessary data, pushing out a lot of data actually used.
- Third, you need to use the terrific VACUUM tool, that locks a lot and causes some deadlock crashes to clean up the memory and remove the rows no longer needed.
"
Ce qui revient effectivement à créer de multiples lignes pour les UPDATE, à l'intérieur même des lignes de la table, et non modifier les lignes existante, contrairement à ce que fait Oracle ou SQL Server en la matière !
A +
Ou n'importe quel autre SGBD me semble-t-il, PG est bien le seul à utiliser cette étrange stratégie non ?
Bonjour,
Est-il prévu un comparatif de performances de commandes entre SQL Server Et Oracle ?
Merci
Non...
Ce que nous savons d'après les tests officiels sur le transactionnel est, que, aujourd'hui, Oracle est largué au niveau des performances à tous niveaux (lectures comme écritures). En témoigne les benchmarks officiels du TPC.org.
Le TPC-C qui date de 1992 est relativement obsolète. La requête la plus complexe utilise 3 tables... TPC.org aurait dû fermé ce benchmark, mais sous la pression d'Oracle, cela na pas été le cas, car Oracle continu de battre ses propres records, quasiment tout seul, les autres éditeurs ayant préféré migré leurs tests sur le nouveau benchmark TPC-E datant de 2007, dont la requête la plus complexe comporte 8 tables...
Mais, ce qu'il y a de rigolo, ce que Oracle s'est fait battre à plate coutures pas les chinois avec Alibaba !
http://tpc.org/tpcc/results/tpcc_res...pm&sortby=desc
Microsoft à préféré migré sur le nouveau benchmark (TPC-E) dès sa parution, plus représentatif :
http://tpc.org/tpce/results/tpce_results5.asp
Sur le décisionnel Oracle est aussi à la traine...
- Sur les bases de 1 To il arrive péniblement au niveau de SQL Server
- Sur les bases de 3 To, il est loin de SQL Server : indice de perf 1 244 450 pour SQL Server contre 409 721 pour Oracle, soit donc 3 fois moins performant
- Sur les bases de 10 To, c'est pire encore... : indice de perf 1 651 514 pour SQL Server contre 377 594 pour Oracle, soit donc 4 fois moins performant
http://tpc.org/tpch/results/tpch_results5.asp
Seul EXASOL fait mieux que SQL Server et Oracle sur la BI.
Dans les comparatifs privés que nous avons fait pour des clients, la différence entre SQL Server et Oracle est très importante.... Un seul exemple, Oracle ne supporte toujours pas les index verticaux (columnstore dans SQL Server) pour les bases OLTP... Et ils commencent juste à se rendre compte que les index IOT (équivalent des index cluster de SQL Server) ça peut être bluffant. Et ils n'ont toujours pas la clause INCLUDE que PostGreSQL vient d'ajouter pour ses index et que SQL Server avait depuis la version 2005.
A +
PostGreSQL vs Microsoft SQL Server - Partie 2 : performances des requêtes avec COUNT
Chers membres du club,
J'ai le plaisir de vous présenter la deuxième partie de cet article de SQLpro :
Bonne lectureCe second article compare PostGreSQL à SQL Server et met en avant les différences de performances des requêtes d’agrégation qui utilisent la fonction COUNT.
Notre premier article comparait les temps de réponse entre PostGreSQL et SQL Server des requêtes administratives que les DBA doivent ordinairement exécuter.
Retrouvez les meilleurs cours et tutoriels pour apprendre les SGBD et SQL
.
Bonsoir,
Merci cette doc, je garde sous le coude ! Avoir ce type est toujours utile quand on chercher des "logiques de fabriques" de requêtes.
MVCC crée de multiples versions des mêmes lignes
"MVCC crée de multiples versions des mêmes lignes" cela créé des multiples lignes si il y a des transactions d'écritures simultanées non ?
Vous avez parfaitement raison et je devrais rectifier cela. Plus de détails sur le fonctionnement de MVCC par Bruce Momjian :
https://momjian.us/main/writings/pgsql/mvcc.pdf
Merci
A +
Tester PostgreSQL sous Windows, n'a aucun intérêt
Pourquoi s'entêter à mesurer les performances de PostgreSQL alors que personne n'utilise PostgreSQL sous Windows en production et que PostgreSQL fonctionnera certainement plus vite sous Linux que sous Windows comme l'affirme Magnus Hagander l'une des personnes qui a porté PostgreSQL sous Windows sur Stack Exchange · Server Fault :
J'ai bien peur que ce test n'est que peu d'intérêts. Mais bon L'auteur (un MVP Microsoft) est bien connu pour s'être donné comme mission de faire de la propagande SQL Server au détriment des bases de données open source, et il fait ça depuis très longtemps (voir par exemple son article Découvrez les dangers de MySQL et MariaDB truffés d'erreurs). J'ignore pourquoi l'auteur s'est donnée cette mission, il ne serait pas surprenant qu'il en tire quelques avantages en coulisses.PostgreSQL fonctionnera certainement plus vite sous Linux que sous Windows (et je dis cela en tant que l'un des gars qui a écrit le portage Windows de celui-ci...) Il est conçu pour une architecture de style Unix, et implémente cette même architecture sous Windows, ce qui signifie qu'il fait un certain nombre de choses que Windows n'est pas conçu pour faire correctement. Il fonctionne bien, mais il n'est pas aussi performant.
Bonjour,
En dehors de toute considération pour un parti ou un logiciel. Concernant les perfs SQL, la question de fond avoir est la suivante : "en terme d’exécution qu'elle est le SGBD le plus "rapide" ?".
Sur l'aspect vitesse d’exécution ou vitesse de traitement, bien évidement qu'un Oracle, MS Server, SAS, Access seront plus rapide ... La gratuité se "paye" . Comment ? Un Wamp ou un MySQL est bon a faire une base d'archive ...
J'ai l'impression qu'il manque un bout des résultats ; je n'ai que le chapitre "XII. Performances du COUNT sans aucun index", un tableau de résultat et ensuite des conclusions qui parlent d'index Btree & ColumnStore.
Donc à "la question de fond", tu réponds par un argument sur la forme...
Bonsoir,
Tu casses les pieds a toujours intervenir inutilement.
Quand je dis la "gratuité se paye", sur le fond, c'est qu'un produit gratuit se sera toujours moins aboutit qu'un produit payant ...
Désolé mais j'ai autant le droit que toi de m'exprimer. Je pense que ce que tu racontes est du grand n'importe quoi bien plus inutile. Mais je ne te reproche pas de le dire alors merci d'en faire autant.
Justement comme l'atteste ces nombreux articles ou commentaires l'auteur Frédéric Brouard a un parti pris contre les bases de données open source depuis des années, donc l'impartialité de Frédéric Brouard porte à suspicion. Mesurer les performances de PostGreSQL sur Windows est juste un moyen de baiser les résultats puisque le port Windows de PostgreSQL n'est pas aussi performant que la version Linux. Et surtout personne n'utilise PostGreSQL sous Windows en production, donc l'intérêt de ce test est sans intérêt, sauf si on veut dénigrer PostGreSQL. On peut faire confiance aux compétences reconnues de Frédéric Brouard pour trouver les tests qui désavantageront PostgreSQL, comme exécuter PostgreSQL sur un système d'exploitation où il est moins performant. Mais l'auteur a sûrement d'autres astuces dans son sac.
Votre esprit embrumé, confond deux choses. Votre première confusion est la gratuité et l'open source. Un logiciel gratuit n'est pas forcément open source. Ensuite votre deuxième confusion vient de la licence d'un logiciel et de sa performance. À vous croire le fait de publier un logiciel sous licence open source le rendrait moins rapide ? Je ne sais pas si vous êtes conscient de l'absurdité de votre raisonnement. La performance et la licence d'un logiciel sont deux choses distinctes.
Bonsoir,
Tout le monde a un parti pris ... Enfonçons le clou justement , Access + le VBA ou SAS (avec SQL + les proc) , dans les deux cas on a des logiciels qui bien plus performant que MySQL qui propose du "SQL de base". La raison est simple des "addon" couvert par une licence payante. Donc du SQL pouvant s'utiliser avec un complément sera bien plus performant .
Faite le test sur le min/max d'un nombre pour plusieurs fois la même occurrence, en ne retournant que le min ou le max de cette occurrence. 45 minutes en MySQL , 30 second en SQL SAS avec des proc et une transposée ...
Vous avez une vision un peu trop simpliste mon cher ...
Prenez MySQL, MariaDB, PostGreSQL et Base (de libre office, open office) ... logiciels open source et / ou gratuit ... les perfs , l'ergonomie, la rapidité d’exécution, les langages addons pour faciliter les traitement ...
Dites moi en quoi c'est absurde de dire qu'un SAS avec des proc et plus rapide / performant qu'un MySQL avec du php ?
Donc oui l'open source est la gratuité joue beaucoup ...
Répondre avec citation
Partager