fsmrel

_________________________________________

Je rapporte ici une anecdote concernant un banc d�essai effectu� en 1987 (cela fait maintenant un paquet d�ann�es...) par une soci�t� am�ricaine r�put�e pour son s�rieux.
Un article parut � ce sujet (Le Monde Informatique du 21 septembre 1987) :

DB2 en transactionnel lourd : des probl�mes de performance

Selon cet article, la soci�t� am�ricaine en question avait rendu un verdict tr�s s�v�re concernant le SGBDR DB2 d�IBM (DB2 version 1, release 2), en insistant sur le fait que, � l�occasion du banc d�essai, il s��tait r�v�l� que le mauvais d�bit transactionnel �tait la cons�quence d�un syst�me de verrouillage trop rudimentaire, pas assez fin (verrouillage au niveau de la page, le verrouillage ai niveau de la ligne �tant devenu possible seulement fin 1995, avec la version 4 de DB2).

Il y �tait fait mention qu�IBM citait de son c�t� le cas d�un utilisateur danois parvenant � un d�bit de 62 pages/seconde, alors que selon les propres tests de la soci�t� am�ricaine, ce d�bit ne d�passait 18 pages/seconde.

Comble de la honte pour IBM : soumis au banc d�essai, le SGBD quasi-relationnel (sic !) Datacom/DB d�ADR d�pota pour sa part � 36 pages/secondes, pour une consommation CPU pr�s de 4 fois plus r�duite que celle de DB2.

Conclusion �vidente : IBM racontait n�importe quoi et devait manifestement revoir son syst�me de verrouillage...

Mais... Un mois apr�s la parution de l�article, Ted Codd (p�re du Mod�le Relationnel de Donn�es) et Chris Date (le plus ardent d�fenseur du Mod�le) vinrent � Paris, animer un s�minaire au Palais des Congr�s, du 29 septembre au 2 octobre 1987. L�introduction � ce s�minaire fut faite par Sharon Weinberg (devenue Sharon Codd 3 ans plus tard), qui avait eu chez IBM la responsabilit� technique de la premi�re version de DB2 et nous l�appelions affectueusement Madame DB2. A un moment donn�, Sharon cita les tests effectu�s par l�utilisateur danois sans oublier les 62 pages/seconde et je sursautais, car j�avais en m�moire l�article du Monde Informatique. Lors de la pause, avant que Chris ne pr�t la parole, comme j�avais encore cet article dans ma besace, je me d�p�chai de le mettre sous les yeux de Sharon, qui me promit de tirer tout cela au clair : pensez, son b�b� attaqu� ! La d�sinformation en action ! Elle fit une photocopie du papier litigieux et me fit part en fin de journ�e des r�sultats de l�enqu�te qu�elle s��tait empress�e de faire :

Les informaticiens de la soci�t� auteur du banc d�essai �taient des sp�cialistes de longue date de Datacom/DB, mais totalement novices en DB2, et l�ayant install� trois semaines avant d�entamer le fameux banc d�essai. Fermez le ban !

Quelques commentaires personnels :

Effectuer un benchmark n�cessite une grande comp�tence pour chacun des SGBD concern�s, ce qui en l�occurrence n��tait absolument pas le cas.

Il ne faut pas se laisser impressionner par le s�rieux d�un article et par la carte de visite du testeur pour tenir comme cr�dibles des conclusions pr�tendument imparables, mais r�v�latrices d�une l�g�ret� coupable.

A la lecture de l�article, j�aurais d� avoir la puce � l�oreille, ne serait-ce que par le label de "quasi-relationnel" que son auteur a accord� � Datacom/DB : soumis deux ans plus t�t aux 12 r�gles de Codd, permettant de qualifier les SGBD se pr�tendant relationnels, le candidat Datacom/DB avait obtenu la note peu flatteuse et sans appel de 0 sur 12 (contre 7 pour DB2)...

Concernant la syst�me de verrouillage de DB2, j�eus plus tard la confirmation (et le v�rifiai par moi-m�me chez un de mes clients, chez qui je b�tis un prototype de performances et de concurrence en mise � jour) que ce n��tait pas le m�canisme de verrouillage des pages des tables qui �tait en cause, mais celui des index, ce qui manifestement avait �chapp� aux testeurs � experts � : une fois identifi�e pr�cis�ment la cause, on pouvait d�bloquer la situation, mais encore fallait-il un minimum de bon sens, de m�thodologie et d�absence de pr�jug�s, � d�faut de comp�tence. Par la suite, j�ai toujours utilis� le verrouillage au niveau page pour les tables, sans dommage pour les applications (bien que, comme je l�ai �voqu�, IBM offr�t par la suite le verrouillage par ligne, m�canisme qui du reste n�a pas que des avantages. Et puis, les verrous ont �t� accompagn�s de loquets et autres subtilit�s concourant � lib�rer au mieux les ressources).

Je n�en veux pas trop au Monde Informatique qui n�a fait que rendre compte, quoique sa conclusion fa�on � presse du c�ur � est un rien subjective et d�sinformatrice :

� Il est clair que la difficult� de pr�dire les temps de r�ponse dans des applications �voluant vers un degr� de complexit� croissant a de quoi inqui�ter les utilisateurs de DB2 �

� Il est clair � ? Vraiment ? Plus prudemment, j�aurais �crit :

� La difficult� de pr�dire les temps de r�ponse dans des applications �voluant vers un degr� de complexit� croissant a de quoi inqui�ter, parmi les utilisateurs de DB2, ceux qui sont peu soucieux d�effectuer des travaux s�rieux de prototypage �

Je d�nonce plut�t l�approche de la soci�t� ayant effectu� le banc d�essai : savoir pr�dire les temps de r�ponse, �a s�apprend, surtout avec un SGBDR et une approche (ensembliste) que l�on ne conna�t pas, auquel cas on commence du reste par m�diter la proposition num�ro 7 du Tractatus de Ludwig Wittgenstein :

� Sur ce dont on ne peut parler, il faut garder le silence. � (Wovon man nicht sprechen kann, dar�ber mu� man schweigen.)

Apr�s Datacom/DB, place � IDMS/R...

Peu de temps apr�s, en ayant assez de voir la soci�t� �ditrice du SGBD pr�tendu relationnel IDMS/R passer son temps � vanter les m�rites de son SGBD (ce qui est normal) et tirer � boulets rouges sur ce malheureux DB2 (ce qui m�aga�ait singuli�rement), je proc�dai durant six mois � une �tude comparative tr�s pouss�e, sous le contr�le de cette soci�t�, laquelle fit une dr�le de grimace et dut rendre les armes, au terme du compte-rendu de travaux qui ne laiss�rent gu�re de r�pit � un puissant mainframe que je chauffais � blanc la nuit, durant les heures creuses. Un peu d�objectivit� de temps en temps ne fait pas de mal...

Incidemment, je rappelle que, dans son article An Evaluation Scheme for Database Management Systems that are claimed to be Relational (reprenant ses articles parus dans Computerworld en octobre 1985), Ted Codd avait soumis � l�aune des douze r�gles, 3 SGBD qualifi�s de relationnels selon leurs �diteurs respectifs : DB2, Datacom/DB et IDMS/R : comme je l�ai d�j� mentionn�, 7 sur 12 pour DB2, z�ro point� pour Datacom/DB, m�me punition, m�me motif pour IDMS/R. Depuis, ces deux SGBD pr�-relationnels ont chang� de propri�taire et de nom et sont r�f�renc�s d�sormais comme CA-Datacom/DB et CA-IDMS (CA �tant l�abr�viation de Computer Associates, si vous le voulez, prononcez � Compiouteur � chaussettes �, c�est moins difficile...), ils permettent m�me d�sormais de faire du SQL...