Comparaison MySQL, SQLite3 et Postgres - Insert

Répondre


Cette question est un moyen d’empêcher des soumissions automatisées de formulaires par des robots.
Smileys
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :!: :?: :idea: :arrow: :| :mrgreen: =D> #-o =P~ :^o :non: :priere: 8-|
Voir plus de smileys
  Revue du sujet
 

  Étendre la vue Revue du sujet : Comparaison MySQL, SQLite3 et Postgres - Insert

par Berzemus » 22 janv. 2009, 14:17

J'avais une application sur lequel je voulais utiliser sqlite. Mais j'ai du revenir sur MySql puisque les performances de recherche full-texte et les différentes options relatives à la recherche n'étaient pas encore à niveau. Largement assez pour un site, mais pas pour une application qui doit intégrer un moteur de recherche performant.
C'est une bonne raison. Mais, un peu de patience PHP 5.3 arrive: http://phpadvent.org/2008/full-text-sea ... t-macvicar

Ou bien utiliser le module SQLite3 PECL.
j'avais justement utilisé le fts3 (sans nécessairement passer par pdo, en utilisant le module php_pdo_sqlite_external.dll ).

C'est plutôt l'absence de recherche booléenne, floue qui m'ont fait passer à Mysql. De plus, avec le natural search et le query expansion, j'en suis pas mécontent...

par Ripat » 22 janv. 2009, 13:29

J'avais une application sur lequel je voulais utiliser sqlite. Mais j'ai du revenir sur MySql puisque les performances de recherche full-texte et les différentes options relatives à la recherche n'étaient pas encore à niveau. Largement assez pour un site, mais pas pour une application qui doit intégrer un moteur de recherche performant.
C'est une bonne raison. Mais, un peu de patience PHP 5.3 arrive: http://phpadvent.org/2008/full-text-sea ... t-macvicar

Ou bien utiliser le module SQLite3 PECL.

par Berzemus » 22 janv. 2009, 11:00

J'avais une application sur lequel je voulais utiliser sqlite. Mais j'ai du revenir sur MySql puisque les performances de recherche full-texte et les différentes options relatives à la recherche n'étaient pas encore à niveau. Largement assez pour un site, mais pas pour une application qui doit intégrer un moteur de recherche performant.

SELECT concurrents

par Ripat » 21 janv. 2009, 23:32

Pour tester les SELECT concurrents, j'ai utilisé l'utilitaire apache ab qui appelle 400 fois une page PHP qui fait le SELECT plus haut avec une concurrence de 200 requêtes simultanées. Le tout renouvellé 4 fois pour lisser les anomalies. Le tableau de résulats reprend la moyenne des 4 essais par type de SGBD.

Code : Tout sélectionner

$ ab -n 400 -c 200 debian/test/sqlite/pdo_select.php
Résultats:

Code : Tout sélectionner

Time Failed MySQL 7.76 39.50 SQlite 7.00 39.25 Postgres 32.36 40.00
Les failed représentent les failed request.

Ici encore SQLite tient la charge. Etonnant non? Bon, 400 requêtes SELECT dont 200 simultanées ce n'est pas ebay mais certainement beaucoup plus que 95% des sites.

A ce stade, je suis assez séduit par SQlite par sa facilité de mise en oeuvre et son indépendance à un serveur SGBD conventionnel. Qui n'a pas eu un jour un site down en raison d'un problème ou d'une surcharge d'un serveur MySQL en mutualisé? On a pas ce problème avec SQLite. Les reproches maintenant, pas de gestion d'utilisateur (1) et SQL92 standard assez pauvre en fonctions (2). Si on veut un traitement spécifique, de format par exemple, ou de calcul, il faut recourir au traitement PHP des résultats ou construire des fonctions utilisateurs en SQLite. Pour les sociétés qui ont des BDD déportées quelque part sur leur réseau, SQLite n'est pas recommandé non plus en raison de l'instabilité de la gestion des verrous fichiers au travers d'un réseau selon l'OS et le type de système de fichiers. Pour la plupart des sites internet, ce n'est pas un problème, tout est en local.

En tout cas, malgré mes efforts, je n'ai pas réussi à améliorer les résultats de PostgreSQL. C'est certainement un excellent SGBD, comparable à Oracle à bien des égards, mais il semble en avoir la lourdeur aussi. Un bon point cependant: documentation remarquable.
__________________________________________________
(1) pas vraiment dissuasif dans la toute grosse majorité des applications web.
(2) Différences par rapport au SQL92: http://www.sqlite.org/omitted.html
En ce qui me concerne, le seul truc qui me manque est l'impossibilité de simplement renommer une colonne. Il faut recourir à une gymnastique d'export/import assez lourde. Gênant, du moins dans la phase de prototypage d'une bdd. D'autres reprochent à SQLite l'absence de support des Foreign Keys mais 'intégrité référentielle d'une bdd SQlite peut facilement être réalisée avec les triggers comme le montre cette disussion. Autre lecture intéressante sur les FK's: Are Foreign Keys really necessary?

Test de SELECT

par Ripat » 21 janv. 2009, 16:54

SQLite il faudrait tester avec des tables importantes…
Là dessus je n'ai aucun doute. Il n'y a pas de limite documentée pour SQLite, ni en nombre de lignes ni en taille du fichier. Les seules limites publiées se trouvent ici:
http://www.sqlite.org/limits.html

Je viens de teminer un test de SELECT avec un double JOIN sur les tables test suivantes:
ventes (1.066.206 lignes, 8 colonnes)
clients (29.086 lignes, 10 colonnes)
articles (7.193 lignes, 10 colonnes)

Avec, bien sûr, les index qui vont bien.

SQL:

Code : Tout sélectionner

SELECT * FROM clients c JOIN ventes v ON c.codcli=v.codcli JOIN articles a ON a.codart=v.codart WHERE c.codcli='012701';
Résultats:

Code : Tout sélectionner

MySQL: 0.028 SQlite: 0.022 Postgres: 0.097
Ici, j'ai directement travaillé avec les clients respectifs en ligne de commande.

Ne pas oublier que SQlite travaille sur des "fichiers plats". Son auteur le défini comme un fopen() amélioré. Pas mal tout de même!
Another way to look at SQLite is this: SQLite is not designed to replace Oracle. It is designed to replace fopen().
http://www.sqlite.org/whentouse.html
Reste à tester les SELECT concurrents et les UPDATE.

par Sékiltoyai » 21 janv. 2009, 14:01

SQLite il faudrait tester avec des tables importantes…

par @rthur » 21 janv. 2009, 12:06

Bonjour Ripat,

Très intéressant ce benchmark.
Merci pour partager les résultats avec nous. :)

De mon côté, les performance de SQLite me semble normal et confirme ce que j'avais déjà pu observer dans le cadre de quelques projets, en revanche je suis très surpris des résultats plutôt médiocres de PostGre. :shock:
Mais comme je n'ai jamais travaillé avec PostGre je ne saurai pas dire si ces résultats sont conformes à la réalité ou si il y a un problème d'optimisation avec PDO...

Comparaison MySQL, SQLite3 et Postgres - Insert

par Ripat » 21 janv. 2009, 11:35

Bonjour,

Je suis en cours de test comparatif pour les trois SGBD en sujet. Ce test n'a absolument pas de valeur scientifique. Juste un petit test empirique pour démystifier les lieux communs. Vous pouvez vous même faire ce test avec le code donné plus bas.

Je viens de terminer la première phase: insertion de données. Le reste suivra au fur et à mesure.

Méthodologie:
  • Utilisation de la classe d'abstraction PDO (encore heureux qu'elle existe!)
  • Utilisation des "prepared statement" c'est à dire la compilation côté serveur d'une requête répétitive
  • Utilisation des transactions si elles sont supportées (BEGIN ... COMMIT)
  • Insertion de 10.000 chaînes aléatoires sur 4 colonnes.
  • Test d'insertions concurrentes en lançant des processus d'insertion concurrents
  • Serveur de test: hors charge, Pentium 4 2.4 Ghz - 768 MB ram - Linux Debian.
  • PHP 5.2 (avec extension PDO), Mysql 5.0, SQLite 3.3, Postgres 8.2
Code du test:
/*	production des chaînes aléatoires à insérer */
for ($i = 0; $i < 10000; $i++){
	$aCol1[$i] = md5(mt_rand(1, 5000));
	$aCol2[$i] = md5(mt_rand(1, 5000));
	$aCol3[$i] = md5(mt_rand(1, 5000));
	$aCol4[$i] = md5(mt_rand(1, 5000));
}

/* Paramètres des bdd et types de tables*/
$aDbs = array(
	'SQLite' => '',
	'Postgr' => '',
	'MyISAM' => 'ENGINE=MyISAM',
	'InnoDB' => 'ENGINE=InnoDB',
);


foreach ($aDbs as $dbType => $engine){
	
	/*	Connexion PDO aux bdd */
	if ($dbType == 'SQLite'){
		$pdo = new PDO('sqlite:/var/lib/sqlite/test.sqlite3');
	} elseif ($dbType == 'Postgr'){
		$pdo = new PDO('pgsql:host=localhost dbname=test user=****** password=********');		
	} else {
		$pdo = new PDO('mysql:dbname=test;host=localhost', '****', '*******');
	}

	$pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_WARNING);

	/*	RAZ et création d'une table */
	$qry = 'DROP TABLE IF EXISTS table1';
	$pdo->exec($qry);
	$qry = 'CREATE TABLE table1 ( col1 VARCHAR(50), col2 VARCHAR(50), col3 VARCHAR(50), col4 VARCHAR(50)) '.$engine;
	$pdo->exec($qry);

	/*	Insertion: préparation et exécution */
	$time_start = microtime(true);
	$insert = "INSERT INTO table1 (col1, col2, col3, col4) VALUES (:val1, :val2, :val3, :val4)";
	$result = $pdo->prepare($insert);

	$pdo->beginTransaction();
	foreach ($aCol1 as $k => $v){
		$result->execute(array(':val1' => $aCol1[$k], ':val2' => $aCol2[$k], ':val3' => $aCol3[$k], ':val4' => $aCol2[$k]));
	}
	$pdo->commit();

	$time_end = microtime(true);
	echo $dbType.': '.round(($time_end - $time_start), 3)."\n";
}
Résultats:

Code : Tout sélectionner

SQLite: 0.385 Postgr: 4.369 MyISAM: 1.128 InnoDB: 1.171
Commentaires:
Du côté de MySQL, pas trop de différences entre les tables MyISAM et InnoDB. Je sais que MyISAM ne supporte pas les transactions mais j'ai fait le test sans BEGIN ... COMMIT et ça ne change rien au résultat. Sans doute que le pilote PDO_MYSQL se charge lui même de désactiver les transactions pour les tables MyISAM (merci PDO!).

En première analyse SQLite s'en sort mieux que les autres. Reste à voir comment elle se comporte en INSERT concurrents. La gestion d'accès concurrents de SQLite ne semble pas être son point fort. Mon test d'accès concurrents consiste à lancer trois processus concurrents en console (avec l'utisisation de &). Chaque processus fait 10.000 INSERT, et puis là, surprise, SQLite3 semble tenir mieux la charge que les autres:

Code : Tout sélectionner

SQLite: 1.984 Postgr: 29.205 MyISAM: 8.312 InnoDB: 9.176
Pas mal pour SQLite que je voyais jusqu'ici comme une solution pour des sites à faible fréquentation mais je vais peut-être changer d'avis sur la question. Je lui vois bien des avantages: totalement libre (domaine public) ,très léger, pas de serveur (fichier "plat"), portable etc... En tout cas, toutes mes nouvelles appli sont en PDO, on ne sait jamais que l'envie me prenne de changer de SGBD. Toutes mes requêtes SQL sont testées sous MySQL et SQLite3 au cas ou...

Par contre, Postgres se traîne dans ce test. Je ne connais pas bien ce SGBD et ai fait confiance au pilote PDO pour optimiser les INSERTs.

Si vous avez d'autres idées de test.... Je reviens bientôt avec les résultats de test de SELECT sur une grosse table (plus d'un million de lignes).