Il n'y a pratiquement pas de benchmarks correctement spécifiés qui aient été publiés (autre que les articles trollesques du genre "d'après mes essais, TrucSQL c'est tellement pourri caca que mon serveur s'est mis à fumer").
Une exception intéressante, à prendre avec son lot de pincettes : http://www.sqlite.org/speed.html(...)
Une chose qu'oublient trop souvent ceux qui font ce genre de mesures, c'est que MySQL n'utilise pas les transactions par défaut (il faut paramétrer les tables spécialement). Donc quand tu lances une séquence de requêtes du type BEGIN; 25000 INSERTs; COMMIT, en réalité MySQL va écrire chacune des 25000 insertions séparément, tandis qu'un moteur transactionnel les écrira en une seule fois : pour que la comparaison soit plus juste, il faudrait par exemple enlever le "BEGIN..COMMIT" en réglant le AUTOCOMMIT à 1, de façon à ce que les moteurs transactionnels se comportent de la même façon ; ou alors au contraire fusionner les INSERTs par paquets de 50 ou 100, afin d'aider MySQL.
Sur des écritures bien pensées (INSERTs groupés par exemple), MySQL peut être très très rapide. Son principal handicap en termes de performance (il y a aussi le SQL moins puissant que celui des autres de SGBD) est en cas d'accès concurrents multiples. Avec le type de tables par défaut, une écriture en cours verrouille (i.e. fait attendre) les lectures et vice-versa : si tu as de très longues écritures sur une base qui doit être consultable en permanence, cela peut être rhédibitoire. Il paraît qu'utiliser le type de tables InnoDB résout le problème
Dernière chose : MySQL 4 (utilisable en production) inclut un cache de requêtes SQL, dont l'efficacité peut être redoutable dans certains types de situation : notamment si ta base est consultée très régulièrement mais qu'elle n'est mise à jour que de façon ponctuelle (cas typique d'un site Web "dynamique" n'ayant pas lui-même de système de cache).
[^] # Re: MySQL/Postgree
Posté par Moby-Dik . En réponse au journal MySQL/Postgree. Évalué à 5.
Une exception intéressante, à prendre avec son lot de pincettes : http://www.sqlite.org/speed.html(...)
Une chose qu'oublient trop souvent ceux qui font ce genre de mesures, c'est que MySQL n'utilise pas les transactions par défaut (il faut paramétrer les tables spécialement). Donc quand tu lances une séquence de requêtes du type BEGIN; 25000 INSERTs; COMMIT, en réalité MySQL va écrire chacune des 25000 insertions séparément, tandis qu'un moteur transactionnel les écrira en une seule fois : pour que la comparaison soit plus juste, il faudrait par exemple enlever le "BEGIN..COMMIT" en réglant le AUTOCOMMIT à 1, de façon à ce que les moteurs transactionnels se comportent de la même façon ; ou alors au contraire fusionner les INSERTs par paquets de 50 ou 100, afin d'aider MySQL.
Sur des écritures bien pensées (INSERTs groupés par exemple), MySQL peut être très très rapide. Son principal handicap en termes de performance (il y a aussi le SQL moins puissant que celui des autres de SGBD) est en cas d'accès concurrents multiples. Avec le type de tables par défaut, une écriture en cours verrouille (i.e. fait attendre) les lectures et vice-versa : si tu as de très longues écritures sur une base qui doit être consultable en permanence, cela peut être rhédibitoire. Il paraît qu'utiliser le type de tables InnoDB résout le problème
Dernière chose : MySQL 4 (utilisable en production) inclut un cache de requêtes SQL, dont l'efficacité peut être redoutable dans certains types de situation : notamment si ta base est consultée très régulièrement mais qu'elle n'est mise à jour que de façon ponctuelle (cas typique d'un site Web "dynamique" n'ayant pas lui-même de système de cache).