jeudi 29 décembre 2011

Informix et Perl: un vieux couple plein de ressources

Le shell unix c’est bien, mais il y a beaucoup mieux et  vous l'avez déjà

En tant que DBA émérite, vous avez développé à coup sûr un certain nombre de scripts en command shell. Ce langage est  très pratique et versatile pour assurer vos tâches d’administration IBM Informix Dynamic Server. En le combinant avec les commandes habituelles comme onmode, onstat, oncheck, onparams et autres, vous avez mis en place toute une gamme de scripts qui vous permettent de gérer automatiquement vos sauvegardes, l’exécution des UPDATE STATISTICS, la gestion de certaines alarmes, le démarrage-arrêt de vos instances, ainsi que la connexion auxdites instances. Vous avez probablement ajouté des scripts de monitoring basés sur onstat et oncheck.
Mais soyons sincères, quand nous relisons ces scripts pour les maintenir, ou pire quand nous devons modifier un script écrit par quelqu’un d’autre, le niveau de complexité de l’écriture est très souvent inversement proportionnel  à la facilité de lecture. Il est vrai qu’après le 7ème niveau d’imbrication de « pipe », on ne sait plus trop où l’on est arrivé.
En fait, si le shell unix comprend un très grand nombre de commandes extrêmement utiles et pertinentes, le ciment ( matérialisé généralement le « pipe », assorti de ls, grep, awk, cat, echo et expr ) qui les unit pour en faire de véritables applications est loin d’être simple à comprendre et encore moins simple à débugger. De plus, si vous devez installer ces scripts sur un autre parfum d’Unix, tout se complique car une foule de commandes soit ne réagissent pas de la même manière, soit produisent directement des erreurs de syntaxe.  Je n’évoque même pas le scénario catastrophe du déploiement d’une instance sous Windows ou Mc Intosh, qui font désormais partie des plateformes habituelles de IBM Informix, où vous devrez probablement tout réécrire…

Vous l’avez sous les yeux, et il en fait des choses!

C’est vrai, le shell Unix répond efficacement aux besoins immédiats quand il faut obtenir rapidement un résultat, cependant trop de problèmes de compatibilité, performance et facilité de maintenance viennent impacter négativement l’industrialisation de ces  fonctionnalités d’administration. Je commençais à mesurer la véritable portée de ce problème quand, en 1997, un ami m’a recommandé de regarder de près le langage Perl ( Practical Extraction Report Langage). 

Il a tout d’un grand

Au-delà du rôle originel de Perl qui est le parsing de texte, j’ai très rapidement compris que j’avais entre les mains un véritable langage de développement qui combinait les attributs d’un langage évolué comme C, les utilitaires awk et sed, incluant la majorité des commandes du shell.  Gérant les  variables scalaires, tableaux, hash, visibilité des variables,  opérateurs binaires, unaires, logiques, blocs d’ordres, gestion de fonctions avec passage et réception de paramètres par référence ou non,  un système de gestion d’entrées-sorties très proche du système et enfin les très puissantes expressions régulières, on sent fortement le lien de parenté avec C, mais tout cela reste malgré tout beaucoup plus facile et rapide à coder et à lire ( adieu aussi les core dumped !)

Même pas peur !

Vous disposez également d’un très bon debugger interactif ( adieu les « set –x » oubliés dans le code !). Au sujet performance, Perl n’a pas la rapidité de C puisque les modules ne sont pas compilés, mais reste cependant très honorable ( Ex 2 sec. pour lire entièrement un fichier de 32 Mb/640 000 lignes). 
Mais quel est le véritable intérêt par rapport au shell ?
Perl peut déjà faire tout ce que le shell peut faire, mais de façon beaucoup plus simple. Finies les contorsions et galipettes entre cat, awk, sort ,grep ls, read etc… !  Avec Perl, le code va directement au but recherché.
Par contre, Perl sait faire des choses que le shell ne sait pas faire, notamment dans le domaine de la programmation-système. Par exemple, il est  simple de gérer la communication entre processes via les IPC, gérer des files de messages In/Out et autres friandises du genre.

Il se sent bien partout

Un autre avantage de Perl réside dans sa portabilité. Dans la mesure où vous n’incluez pas dans vos programmes Perl  des commandes shell spécifiques à telle ou telle plateforme, votre programme Perl fonctionnera à l’identique sur des plateformes différentes, que ce soit sur n’importe quel Unix, Windows ou Mac Intosh, pour ce qui nous intéresse.
Mais l’argument de poids est la richesse de la librairie de modules disponible gratuitement pour la communauté.  Ces modules couvrent les fonctionnalités les plus diverses et variées, allant d’extrêmement utiles à plus anecdotiques. Des fonctionnalités indispensables comme une fonction qui traduit n’importe quelle date en format caractère ( ex « lun. Déc 26 17 :45 :14 2011 CET » ) en un nombre entier de type « epoch », permettant en autres de calculer des intervalles entre deux timestamps (Time ::¨ParseDate, utile quand on parse un fichier log par exemple), ou bien obtenir toutes les propriétés d’un fichier  ( stat ), ou bien lire et se déplacer dans un fichier en mode binaire ( IO ::Handle ), mais aussi lire les propriétés d’une image (Image::ExifTool ), et la très puissante Win32::OLE qui permet d’accéder en lecture ou écriture à pratiquement tous les objets Microsoft comme boite email Outlook, documents Word, Excel etc...

Dans cette foule de modules, il en existe un qui nous intéresse particulièrement : DBD::Informix. Vous l’avez compris, ce module est le module de communication avec les bases de données IBM Informix. Développé et maintenu par un Informixien de longue date, et maintenant vénérable IBMer barbu, ce module contient toutes les fonctionnalités nécessaires à pouvoir utiliser le langage SQL pratiquement comme avec Esql/C, Informix 4GL ou dbaccess, dans vos applications Perl.

On essaye ?

Pour des raisons que vous imaginez sans doute, le module DBD:Informix ne fait pas partie des packages de base généralement livrés avec Perl ( pas plus que le module du « Evil Empire kind of database »  d'ailleurs ). Il faudra aller le chercher sur CPAN, l'immense répositoire de packages Perl. Après avoir « éprouvé quelque difficulté » avec la version précédente de l'installation, il suffit de savoir comment faire et l'installation se fait sans sueur ni larmes.
Les prérequis obligatoires:
-    avoir Perl version supérieure ou égale à 5.14 pour être en totale conformité,
-    avoir esql/C > 7.31 ou mieux Informix CSDK 3,X ( généralement inclus dans IDS à partir de la version 10.00 )
-    avoir un moteur Informix ou IBM Informix ( SE ou IDS ) « on-line »
-    avoir créé la base de démonstration stores
-    avoir créé l'utilisateur informix
-    une connexion internet en état de marche,
-    Sans problème sous Linux, et à ma connaissance sous les autres plateformes Unix, plus délicat pour l'instant sur plateforme Windows, mais affaire à suivre...

Avant de lancer l’installation, vous devez, sous l’utilisateur root, pouvoir vous connecter à la base stores avec dbaccess, donc avoir les variables d’environnement $INFORMIXDIR, $INFORMIXSERVER et $PATH correctement valorisées. Vous devez également pouvoir exécuter un binaire esql/c, donc avoir la variable $LD_LIBRARY_PATH ( linux , AIX) ou $LIBPATH ( solaris etc ) valorisée à « $INFORMIXDIR/lib :$INFORMIXDIR/lib/esql :$INFORMIXDIR/lib/tools »

Une fois ces test préliminaires accomplis,  vous pouvez taper :
perl -MCPAN -e 'install Bundle::DBD::Informix'

Laissez ensuite le système ( l’outil CPAN ) gérer l'affaire. Dans la mesure où les prérequis sont respectés, l'installation se fait sans aucune anicroche. Par contre, en cas d'oubli, les messages d'erreur sont quelque peu démotivants. Il suffit alors de remédier aux prérequis manquants et relancer la commande citée plus haut. Perl CPAN reprendra l'installation là où il s'était arrêté.

Quelques messages d'erreur peuvent apparaître en cours de route. Tant que l'installation ne s'arrête pas, tout va bien. L'installation se termine par « /usr/bin/make install -- OK ».

A la vue de ce message, vous êtes prêt à utiliser le module DBD::Informix. Une petite vérification par un find /usr –name Informix.pm, pour vous assurer que vous avez bien Informix.pm quelque part dans /usr…lib64 … /DBD/Informix.pm.
Vous pourrez aussi  le trouver dans ~root/.cpan/build/DBD-Informix-2011.0612-*, qui est la directory d’installation, mais il doit être absolument dans /usr/…libXX.

Installation OK! voyons les rudiments.
Pour pouvoir utiliser DBD::Informix, il faut l’inclure dans le programme Perl, en notant en tête du module :
use DBD::Informix qw(:ix_types) ;

Pour se connecter à une base :
$dbh=DBI-connect(« dbi:Informix:$databasename »,$username,$password) ;

Pour préparer un SELECT :
$stmt=sprintf «SELECT col1,col2,col3,col4 FROM mytable ORDER BY col2» ;
$sth = $dbh->prepare($stmt);
$sth->execute() ;

Pour lire le curseur, et afficher le contenu :
$sqlcode=0;
while ( $sqlcode != 100 ) {
   ($var1,$var2,$var3,$var4) = $sth->fetchrow_array() ;
   printf “%s %s %s %d\n”,$var1,$var2,$var3,$var4 ;
   $sqlcode=$sth->{ix_sqlcode};
}

Mais vous pouvez également remplir un array contenant le résultat complet du curseur, pour le traiter ensuite en mémoire comme une structure organisée à l’image de la table, à l’image du RECORD LIKE d’Informix 4GL :
$array_ref = $sth->fetchall_arrayref ( {col1=>1,col2=>1,col3=>1,col4=>1}) ;
foreach $row ( @$array_ref ) {
   printf “%s %s %s %d\n”,$row->{col1},$row->{col2},$row->{col3},
 $row->{col4} ;
}

Pour ce qui est du SQL habituel , INSERT, UPDATE, DELETE, vous alliez le trouver tout seul :
$stmt=sprintf «INSERT INTO mytable ( col1,col2,col3) VALUES (?,?,? )» ;
$sth = $dbh->prepare($stmt);
$sth->execute($val1,$val2,$val3) ;
Vous verrez au passage que l’utilisation des placeholders est extrêmement simple, puisqu’il suffit d’en mettre les valeurs entre parenthèses lors de l’execute.

Pour consolider l’utilisation des placeholders, voici un exemple avec UPDATE
$stmt=sprintf «UPDATE mytable SET (col2,col3) = (?,?) WHERE col1=?» ;
$sth = $dbh->prepare($stmt);
$sth->execute($val2,$val3,$val1) ;

Les transactions? Très simple:
$dbh->commit;
$dbh->rollback;
A moins que vous ne désiriez simuler le mode ANSI, en ouvrant la connexion de cette manière, le comportement de vos transaction est identique à celui dont vous avez l’habitude.
$dbh = DBI->connect("dbi:Informix:$databasename",$username,$password,
                        { AutoCommit => 1});

Et mon CURSOR WITH HOLD ?
Trivial, il suffit de le passer comme argument lors du PREPARE, comme ceci :
$sth = $dbh->prepare("SELECT col1,col2 FROM mytable",{'ix_CursorWithHold' => 1});

Et les BLOBS ?
Soyons francs : l’implémentation des BLOBS n’est pour l’instant pas aussi riche qu’avec ESQL/C, mais on s’en approche.
Pour le type TEXT, ou tout autre BLOBS dont le contenu peut être mis dans une variable Perl, on utilisera le bind de paramètres, comme ce qui suit :

$textlocation = sprint “/home/informix/textfiles/file1.txt” ;
fopen TEXT,$textlocation or die “Cannot open file “ . $texlocation ;
@FileContents=<TEXT>;
$text_val = join ( @FileContents ) ;
$pkey = 13452 ;
$timestamp = «2011-12-28 15:00:00» ;
$stmt = sprint “INSERT mytable VALUES (?,?,?)” ;   
$sth = $dbh->prepare($stmt);
$sth->bind_param(1, $pkey);
$sth->bind_param(2, $timestamp ) ;
$sth->bind_param(3, $text_val, { ix_type => IX_TEXT });
$sth->execute;

Pour la lecture des blobs, ceux-ci sont mappés dans une variable Perl de type string. On peut toutefois procéder à un LOCATE, de la façon suivante :
$sth->{ix_BlobLocation} = 'InMemory';   # Comportement par défaut
$sth->{ix_BlobLocation} = 'InFile';     # dans un fichier dont le nom est rendu
$sth->{ix_BlobLocation} = 'DummyValue'; # retourne <text> ou <byte>
$sth->{ix_BlobLocation} = 'NullValue';  # retourne valeur indéfinie

Les SMARTBLOBS ne sont pas (encore ?) supportés directement, MAIS on peut les manipuler avec les fonctions LOTFILE pour lire, FILETOBLB ou FILETOCLOB pour écrire.

Pour insérer:
$stmt = qq!INSERT INTO item2 VALUES (1234,'Desk', FILETOBLOB('image.bmp','client'))!;
$sth = $dbh->prepare($stmt);
$sth->execute();

Pour lire:
$stmt = qq!SELECT LOTOFILE(myimage, ?,'client') FROM mytable!;
$sth = $dbh->prepare($stmt);
$sth->execute($imagefilename) ;
$sth->bind_columns($Image));
while($sth->fetch) {
   print $Image;
…..
}

Alors finalement, quel est l’intérêt d’utiliser Perl avec DBD::Informix ?
En conclusion, nous pourrions continuer longtemps comme cela, mais le réveillon approche et la concentration commence à s’évaporer.
Pour un DBA Informix, cette combinaison permet de développer des scripts beaucoup plus puissants en terme de fonctionnalités, notamment pour les facilités de programmation système « abordables » qu’il offre. Les objets comme les tableaux, les tableaux de hachage, les expressions régulières et surtout l’immense bibliothèque de modules traitant de pratiquement tout ce qui peut se faire, confèrent au développeur une puissance que le shell n’atteindra jamais.
Il permet également de rationaliser les scripts d’administration, de les rendre beaucoup plus lisibles et simples à maintenir. Enfin, argument non négligeable, Perl offre une grande portabilité de vos développements approchant des 100%, pour autant que l’on n’utilise pas de syntaxe spécifique à chaque OS. Un script fonctionnant sur Linux fonctionnera sans mauvaises surprises sur AIX, hp-ux, Solaris, Mac OS X et même Windows !

La cerise sur le gâteau est la possibilité d’accéder en mode natif à vos bases de données Informix comme le fait Informix 4GL, ESQL/C ou java. A partir de ce point s’ouvrent des perspectives de développements encore plus vastes, comme parser et intégrer des documents Microsoft Office dans une base de données Informix, typifier et classer des images dans une base Informix, mais aussi aller fouiller dans vos favoris et historique de Mozilla Firefox, en les intégrant dans une base de données Informix. De façon plus générale vous pouvez envisager de développer très rapidement et à coût très réduit un gateway entre d’autres bases de données et votre base de données préférée, par exemple !

Des exemples concrets sont disponibles sur mon autre blog www.vercelletto.com , ainsi que sur le site de l'UGIF www.informix.fr .
N'hésitez pas à les télécharger et à les utiliser.


En attendant, et pendant que vous réflechissez à tout cela, je vous souhaite plein de bonnes choses pour l’année 2012 !

A lire :
le document de référence de Jonathan Leffler:
http://search.cpan.org/~johnl/DBD-Informix-2011.0612/Informix.pm
sa présentation à la conférence IIUG 2001:
http://www.ibdk.dk/seminar/DBD-Informix-20010508.ppt

Chez O’reilly: 
- Programming perl DBI by Alligator Descartes and Time Bunce,
Learning Perl,  by Tom Phoenix, Randal L. Schwartz
- Programming Perl, by  Larry Wall ( l'inventeur de Perl), Tom Christiansen, Jon  Orwant
- Perl advanced Programming, By Simon Cozens
- Perl for System Administration by David Blank-Edelman 
- La doc Perl en français: http://perl.enstimac.fr/DocFr.html
- Rechercher dans la bibliothèque CPAN : http://search.cpan.org/
- Et toute une foule de turoriels perl sur le net

vendredi 9 décembre 2011

Bon anniversaire le village Informix

Bonjour à tous,

eh oui, 1 an déjà! c'est avec émotion que le premier anniversaire du Village Informix a vu le même jour son compteur d'accès passer les 5000 visites! Une goutte d'eau face à d'autres sites consacrés à l'Empire du Mal ( dont le nom se compose de O....e ), ou à d'autres rouleaux compresseurs, mais cela prouve aussi un regain d'intérêt pour cette technologie qui nous tient tous à coeur, dans nos terres francophones et gaulophones.

Nous en profitons pour saluer nos cousins Helvètes, Belges, Africains et Canadiens qui n'hésitent pas à braver montagnes, océans ou péages de voies romaines pour venir nous visiter.

En tous cas merci à tous de vous arrêter chez nous, en espérant que vous y trouvez votre compte.

N'oubliez pas dans vos tablettes Mercredi 14 et Jeudi 15, la réunion de l'UGIF chez IBM à Bois Colombes.

Et si nous ne nous croisons pas d'ici là, nous vous souhaitons de belles fêtes de fin d'année.



A bientôt,
E.


mardi 29 novembre 2011

réunion de l'UGIF le 14 et 15 décembre

Bonjour à tous,



Le User Group Informix France (UGIF) se réunira le 14 décembre  prochain au Forum IBM de Bois Colombes*.  
Après la sortie de Informix Warehouse Accelerator et de GENERO au mois d’avril dernier, Informix  avec son module Time Series est  devenu la solution unique et incontournable du marché dans le domaine de la gestion des compteurs intelligents dans le domaine des donnés temporelles comme  les compteurs électriques, l’eau, le gaz, les marchés financiers, la médecine, etc.
 Venez découvrir une démonstration temps réel du Data Warehouse par le patron R&D du produit en personne.


L'agenda de la journée est le suivant :  
9h00 - 9h15
Accueil


9h30 - 9h40
Introduction
Khaled Bentebal
Président UGIF
9h40 - 9h55
Information management et importance d'Informix dans l’offre IBM
Matthieu Maurice
Directeur Information Management - IBM
9h55-10h30
Informix et la stratégie au sein de l’offre IBM
Jerry Keesee
WW Director Informix Software - IBM
10h30 – 11H15
Nouvelles directions stratégiques: Time Series...
Jacques Roy
Manager et Architecte IDS Application Development Services - IBM
11H15 – 11h45
Pause café
11h45 – 12h30
Informix Warehouse
Sandor Szabo
Manager IBM Informix Database Development - IBM
12h30 - 13h00
Genero : Stratégie et Roadmap
Bryn Jenkins
COO – Four Js Developement
13h00 - 14h30
Déjeuner
14h00 - 14h45
Session technique : Timeseries
Jacques Roy
Manager et Architecte IDS Application Development Services - IBM
14h00 - 14h45
GENERO
Christian Geyer
Senior System Engineer chez Four J's Development Tools
14H45 – 15h15
Pause
15h15 - 16h00
Informix Warehouse Accelerator
Sandor Szabo
Manager IBM Informix Database Development - IBM
15h15 - 16h00
Session technique : Informix V11.70
Olivier Bourdin
EMEA Informix L3 Advanced Support - IBM
16h15 - 16h45
Conclusion
Khaled Bentebal



Nous conclurons l'après-midi entre 16 heures 15 et 16 heures 45 par un dernier tour de table, animé par Khaled Bentebal.  Ceci vous permettra de dialoguer directement avec les intervenants de la journée.
 Toutes les sessions techniques de l'après-midi de l'événement de l'UGIF le 14 décembre seront totalement gratuites.
 Inscrivez vous vite en envoyant un simple mail de confirmation à notre correspondant technique IBM :
 Fabrizio Danusso : fabrizio.danusso@fr.ibm.com
 ou
 Khaled BENTEBAL : khaled.bentebal@consult-ix.fr

* Plan d'accès : http://www-05.ibm.com/fr/ibmforum/Plan_acces_IBM_Forum_BC.pdf


A noter le Proof of Technology le 15 décembre sur Informix Warehouse Accelerator, que je reconseille vivement!

A bientôt

mardi 15 novembre 2011

La version 11.70 xC4 est sortie et disponible

Bonjour à tous,

IBM annonce la sortie de Informix Dynamic Server version 11.70 xC4. Elle est disponible depuis le 25 octobre 2011 sur les canaux habituels.
Que faut-il retenir principalement de cette release?
  • l'emphase sur TimeSeries continue, des nombreuses améliorations et nouveautés sont apportés sur le datablade, qui rappelons-le est sorti en 1998...
  • apparition du "Open Admin Tools Health Advisorplugin": une nouvelle fonctionnalité de OAT dont le but est d'observer les métriques de santé de l'instance et de vous prévenir en cas de non-conformité/problème. Ces vérifications sont planifiables dans le temps, et rangées par catégories.
  • OAT est maintenant inclus dans la distribution du Client Software Development Kit ( CSDK), ce qui facilite énormément son installation.
  • un nouvel ensemble de paramètres ONCONFIG peut désormais être modifié "on the fly", c'est-à-dire sans devoir arrêter et démarrer l'instance. La liste s'allonge avec les paramètres suivants: WSTATS, AUTO_REPREPARE, CKPTINTVL, DIRECTIVES, OPTCOMPIND, SHMADD, qui peuvent désormais être modifiés avec la commande onmode -wm. L'objectif final étant le "zero downtime", cette liste devrait encore s'allonger dans la prochaine release
  • améliorations dans les algorithmes de creation des statistiques, spécialement dans la technique d'échantillonnage pour les très grosses tables/index.
  • rajout de colonnes indiquant la progression d'une opération de compression de table, ainsi que la date/heure estimé de fin d'opération
  • améliorations sur la réplication: rapidité de démarrage du Connection Manager, rapidité de la vérification de consistance, facilité d'exploitation des alarmes du Connection Manager, détection de fausses situations de failover vers le Primary empêchant un basculement inopportun, amélioration de la gestion de la sécurité avec la réplication.
  • améliorations dans la gestion du Global Security Kit: plus de souplesse dans le paramètrage
La release embarque plein d'autres améliorations, ainsi que des bug fixes ( eh: oui ça existe aussi!). Je vous invite donc à aller voir la release note sur le site IBM

Pour un SGBD dont les mauvaises langues ( jaloux!) disent qu'il fait partie du passé et qu'il n'est même plus maintenu, je trouve quand-même que ça fait beaucoup d'améliorations depuis la sortie de la 11.70 il y a un an:
  • Nov 2010: sortie de 11.70 xC1
  • mars 2011: sortie de 11.70 xC2
  • juin 2011: sortie de 11.70 xC3
  • octobre 2011: sortie de 11.70 xC4
Enfin! ceci est une autre histoire :-)

A bientôt




vendredi 11 novembre 2011

La technologie IBM Informix reconnue par le géant Cisco

Bonjour à tous,

nous venons d'apprendre qu'IBM Informix s'est vu décerner un "Software Excellence Recognition" par la compagnie Cisco Inc., le géant de l'industrie du réseau et de la téléphonie.

Pourquoi? Parce que Cisco travaille depuis de nombreuses années, dans la branche téléphonie, avec IBM Informix Dynamic Server embarqué dans ses téléphones, et que ça marche.

Bien que Cisco ait, il y a quelque temps, effectué une réévaluation de toutes les autres plateformes SGBD, ( il est toujours bon de se poser les bonnes questions ) ils ont confirmé le choix de IDS 11.70 comme SGBD pour leurs systèmes téléphoniques. Leurs critères étaient simples: simplicité d'administration, fiabilité, performance et facilité de déploiement.

Donc ils sont contents, et ils le disent et ils n'en ont pas peur!

Allez voir la page IBM Informix sur Facebook

A propos de téléphones, saviez-vous que le système téléphonique de l'avion présidentiel américain 'Air Force One', se repose sur Informix Dynamic Server ?
Il en est de même pour le système téléphonique de la Maison Blanche à Washington, ainsi que le fameux '911' américain, qui est le système national des appels d'urgence.
Des systèmes qui ne peuvent pas se permettre une quelconque panne sous peine de conséquences catastrophiques...

A bientôt!

mercredi 9 novembre 2011

Informix Warehouse Accelerator désormais disponible avec la Growth Edition

Bonjour à tous,

Vous avez vraisemblablement entendu parler de IBM Informix Ultimate Warehouse Edition,  cet "add-on" révolutionnaire basé sur la combinaison des technologies de base de données colonnaire, de compression de données et de "tout en mémoire", dont la fonction est de réduire plus que drastiquement les temps de réponse dans un contexte décisionnel, infocentre ou data warehouse, suivant le terme qui vous convient le mieux.

Nous avions décrit les grandes lignes de IWA ( Informix Warehouse Accelerator) dans cet article il y a quelques mois. Il est vrai que les résultats obtenus font rêver. Cependant, le problème majeur était plus d'ordre budgétaire, dans la mesure où l'on était obligé de l'installer sur une Ultimate Edition. 
Répondant aux architectures de haut de gamme, le pricing de l'édition Ultimate n'est pas adapté aux environnements de moindre taille, privant par là-même ces environnements d'utiliser Informix Warehouse Accelerator.

IBM a décidé de combler ce vide en créant désormais une nouvelle édition: Informix Growth Warehouse Edition. Avec un pricing beaucoup plus accessible et surtout adapté à une grande partie de la base installée IBM Informix Dynamic Server, cette édition permet donc, comme le fait sa grande soeur Ultimate Warehouse Edition, d'intégrer les données d'infocentre dans un serveur Linux 64Bits et traiter les requêtes avec des temps de réponses qui ressemblent plus à un mensonge qu'à la vérité.

Et pourtant! les résultats sont bien là: une campagne de benchmarks chez des clients existants montre des résultats fulgurants, comme par exemple:

  • temps sur IDS : 20 minutes, temps avec l'Accelerator: 4 secondes
  • temps sur IDS: 105 minutes, avec Accelerator: 9 minutes 48sec.
  • temps sur IDS: 106 minutes, avec Accelerator : 20 secondes
Il est donc désormais possible de bénéficier de l'Accelerator avec la Growth Edition, suivant le principe des diverses éditions d'IBM Informix, avec les limitations suivantes:
  • Le serveur Linux hébergeant l'Accélérateur est limité à 16 coeurs,
  • l'Accélerator peut être configuré à un maximum de 48 Gb de RAM, ce qui suivant le principe de compression des données, permet de charger jusqu'à 250 Gb de données utiles ( les index sont inutiles pour l'Accelerator, donc ils ne sont pas chargés).
Les blasés diront encore que la concurrence fait évidemment aussi bien, voire mieux, mais regardons de plus près:
L'Accelerator s'installe en général sur un autre serveur physique que l'instance OLTP. C'est un serveur Linux, donc à priori x86, sans gros besoins en disque ( les données proviennent de l'instance OLTP et sont directement chargées en mémoire ), et le poste important du chiffrage est la RAM. En règle générale, un serveur pour Informix Warehouse Accelerator se chiffre nettement en dessous des 10.000 Euros ( pour la Growth Edition  ).

L'Accelerator est une extension logique du moteur Informix,  effectuant le travail de requêtes sur un autre serveur physique faisant partie de la même entité de traitement. l'avantage est donc d'exécuter les requêtes décisionnelles les plus lourdes sans impacter aucunement votre instance OLTP.
C'est l'optimiseur Informix qui décide qui, entre le serveur OLTP ou l'Accelator, exécute la requête. Ceci implique qu'il n'y a aucune modification à apporter à vos applications décisionnelles, donc des économies en termes  de projets.

Il n'ya a pas de duplication de données, ne demandant ni beaucoup d'espace disque supplémentaire, ni d'administration lourde d'un autre système.
Informix Warehouse Accelerator ne se "tune" pratiquement pas. Il ne constitue pas une charge supplémentaire pour les DBA, contrairement à d'autres systèmes à fonctionnalité similaire

Le coût d'administration se limite à la gestion des datamarts ( conception, chargement) avec l'interface graphique très bien conçu IBM Smart Analytics Studio.

En conclusion, Informix Warehouse Accelerator vous permettra de faire  cohabiter votre charge transactionnelle et votre charge décisionnelle sans problèmes de voisinage ni surcoût d'administration, et qui divisera suivant les cas par 10,100 et parfois plus, les temps de réponses sur vos requêtes d'infocentre.

Dans ces conditions, il est parfaitement envisable de considérer une utilisation toute autre de vos requêtes OLAP:
Si une requête répond en 4 secondes au lieu de 20 minutes, vous pouvez utiliser le temps économisé pour lancer d'autres requêtes auxquelles vous n'auriez même pas pensé, faute de temps.

Par ailleurs, une requête qui répond en quatre heures peut être exécutées au maximum 6 fois par jour. Dans les faits, elle ne sera d'ailleurs lancée qu'une fois par jour, au cas où... Par contre si la requête répond en  5 minutes, la donne est radicalement différente: elle peut être planifiée avec une fréquence beaucoup plus élevée dans la journée, et contribuera à l'amélioration drastique de la réactivité de votre infocentre. Réagir vite pour corriger vite.

Bien sûr ces faits valent aussi pour IBM Informix Ultimate Edition que pour la Growth Edition.

Tout ceci pique votre curiosité? Eh bien lancez-vous et venez au PoT Deep Drive on IWA and Informix Data Warehouse dans les locaux de IBM Forum Paris, le 15 décembre prochain.  Ce "Proof of technology" comportera une présentation du produit ainsi que des exercices pratiques qui vous feront voir la technologie de près.
Renseignements et inscriptions ici

A bientôt

vendredi 7 octobre 2011

Load et unload sous Informix-4GL: des talents cachés

Bonjour à tous,

une fois n'est pas coutume, aujourd'hui nous allons faire très court. Vous connaissez tous les commandes SQL load et unload, utilisées pour charger et décharger le contenu de/vers une table à partir de/vers un fichier ascii plat et délimité.

Dans la document Informix 4GL, cette commande est qualifiée comme "non préparable", c'est à dire qu'on ne peut pas écrire de choses du genre:
LET statement = "LOAD FROM /tmp/monfichier.unl INSERT INTO matable"
PREPARE monordre FROM statement
EXECUTE monordre

Oui mais... ce qui n'est pas dit dans la documentation, mais qui est quand même supporté et qui marche très bien, c'est la forme suivante:
LET monfichier="/tmp/monfichier.unl"
LET ins_statement = "INSERT INTO matable"
LOAD FROM monfichier ins_statement

Même principe pour unload:
LET monfichier="/tmp/monfichier.unl"
LET sel_statement = "SELECT * FROM matable"
UNLOAD TO monfichier sel_statement 

Pas de quoi vous changer la vie, j'admets, mais quand même de quoi rendre bien des services, nommément  quand on a besoin d'avoir des load et unload dont la stucture est conditionnée par l'application, ou bien réécrire un simili dbexport en 4GL à partir de la table systables par exemple.

C'est tout :-)
A bientôt
Eric



vendredi 30 septembre 2011

Une alternative sérieuse aux bases de données gratuites

Bonjour à tous,

La rentrée des classes est passée, et malgré le contexte quelque  peu morose, l'activité redémarre,  les budgets IT se  concoctent comme bien souvent à cette période de l'année.

Au vu de la forte tendance à réduire les budgets dans les départements IT, mais à l'encontre de la tendance "fonctionnelle" qui a pour effet de générer de plus en plus de projets IT, se pose souvent la question de la réduction des coûts de licences, notamment en ce qui concerne les serveurs de bases de données.

Naissance des SGBD « GNU Public License » et assimilés.

Apparus il y a quelques années, et majoritairement issus de transfuges des grands éditeurs de SGBD, des produits tels que MySql, PostgreSQL et Sqlite qui évolue dans un autre registre, ont conséquemment grimpé en popularité, parce que ce sont de bons produits et surtout parce qu'ils sont gratuits. Le besoin est réel, principalement axé sur projets de petite à moyenne taille, n'entrant pas dans la catégorie "business critical", et dont la capacité d'investissement reste volontairement limitée.

La raison majeure pour un tel choix est la restriction budgétaire, zéro Euros étant toujours d'une grande aide pour faire des économies substantielles.

Une autre raison souvent invoquée est clairement politique: ne plus être empêtrés dans les griffes  de ces vilains gros éditeurs et pouvoir faire ses choix sans devoir courber l'échine ni se soumettre servilement à leur volonté. Argument fort louable et totalement en phase avec l'air du temps. Mais les faits correspondent-ils vraiment

Ce qui se montre et ce qui se cache derrière la gratuité

A travers notre prisme, PostgreSql joue véritablement le jeu de l'open source, n'étant à ce jour dépendant d'aucun "grand éditeur" qui peut à n'importe quel moment décider soit d'arrêter le produit, soit de le rendre payant. Il faut l'avouer, le produit est sympa, moderne, plein de fonctionnalités intéressantes que ce soit au niveau du moteur comme au niveau de son langage SQL extensible.

Il est par contre un autre SGBD "open source" faisant partie des 2 principaux SGBD open source, donc "l'autre", c-a-d MySql, qui ne peut plus prétendre à une telle indépendance. MySql, autrefois totalement indépendant, a été acquis par Sun Microsystems ( propriétaire à l'époque de Java ), lequel a été à son tour, comme vous le savez, acquis par un éditeur de Software dont il me coûte encore de prononcer le nom ( éducation Informixienne où il était interdit de dire des gros mots, soit en anglais: " the Evil Empire" ).

Peut-on vraiment être rassuré par les intentions de cet éditeur qui n'hésite à arrêter le portage de son SGBD  sur la plateforme HP Itanium, laissant pour compte toute une partie de sa fidèle clientèle, et briser aabruptement une collaboration de plus de 20 ans avec ce constructeur ? Et que se passe-t-il si l'éditeur décide de revenir à ses valeurs fondamentales et de rendre le produit payant ?

Le système croît au-delà des prévisions : on fait quoi ?

Au delà de ces deux arguments reste un gros problème: il est reconnu de tous que ces produits sont des produits d'entrée de gamme, et conçus comme tels. Donc tant que l'on reste "dans les clous", tout le monde est content.

Mais que se passe-t-il si l'on sort des clous, si la volumétrie explose, ou bien si le nombre d'utilisateurs dépasse de façon constante les prévisions initiales ? On se retrouve avec un SGBD qui ne répond plus au besoin et il faut en changer, c'est à dire passer cette fois-ci à un SGBD "éditeur".

Solution sans doute facile pour certains décideurs ( il n'y a qu'à migrer, ce n'est qu'une question de temps et de nombre de consultants qui se feront un plaisir de relever le défi ), mais le risque induit est important, et le temps pour "retomber sur ses pattes" n'est que trop souvent bien supérieur aux estimations initiales, laissant le champ à de probables mauvaises surprises : revoir le(s) schéma(s) de base, traduire les types de données, modifier les procédures stockées, les triggers, les comportements face au niveau d'isolation, au verrouillage, la gestion des erreurs. Sans oublier l'énoncé des requêtes Sql des 40 000 lignes de cette petite application.

Bref, je crois que je me fais comprendre : la date de livraison du projet de migration peut être qualifiée de au mieux de « potentiellement variable », et quelques grincements de dents sont dans ce cas à prévoir.

La surprise générale : IBM publie une version gratuite d'IDS.

C'est à ce stade qu'IBM a joué un coup de maître en Novembre 2010, au moment du lancement de Panther ( la 11.70): contre toute attente, IBM a publié une version gratuite d'Informix Dynamic Server: Innovator-C Edition.  Contrairement à la « Developper Edition » qui imposait des restrictions de volume de données, et surtout une licence destinée exclusivement à l'utilisation dans un environnement de développement,  vous avez entre les mains une licence d'utilisation  en production, sans restriction de volume de données, si ce n'est celles de IBM Informix Dynamic Server.

Un produit gratuit, donc c'est un jouet ?

Situons le terrain de jeu. Il existe effectivement une liste clairement identifiée de fonctionnalités non disponibles, qui peut éventuellement effrayer le décideur. Cependant, après analyse, nous allons comprendre qu'il nous reste un excellent produit entre les mains.

Le postulat de départ est que vous avez entre les mains le même produit que la « Ultimate Edition », mais que certaines fonctionnalités ont été désactivées.

1) Le volume de données est illimité, vous êtes donc tributaire de l'espace disque de votre machine. Un de mes serveurs est monté en 11.70FC3, linux 64, avec 3 dbspaces de 1 chunk : 1 de 60 Gb, 1 de 80 Gb et 1 de 100 Gb. Evidemment créer un dbspace de 100Gb prend un peu de temps, mais ça marche. Je n'ai pas été plus loin faute de place sur la machine.

2) La ressource CPU est limitée à 1 socket avec au maximum 4 cores ( en français 1 processeur physique avec 4 coeurs).  Si l'on parle d'un exemple d'un serveur Intel based Linux dédié, cela représente quand même pas mal de réserve de puissance, d'autant que la vitesse d'horloge n'est pas limitée. Vous pourrez alors affecter sans problème 4 CPU VP's à IDS si le serveur est dédié.

3) La ressource mémoire est effectivement limitée à 2 Gb. Il s'agit là du total de la taille occupée par les BUFFERS de données et de la SHMVIRTSIZE. Sachant que nous ne disposons malheureusement pas des Parallel Data Query, les besoins en extension de cette dernière seront limités aux besoins des opérations de tri, groupe et autres agrégations, qui peuvent être estimés à 25% de ces 2 Gb. Sincèrement, avec 1,5 Gb de BUFFERS, cela fait de la place pour quelques bonnes dizaines d'utilisateurs, voire plus.

4) La fonctionnalité PDQ n'est pas utilisable. Au premier abord, ce manque parait regrettable. Mais si l'on se place dans le contexte d'une application OLTP, on se console rapidement car cette fonctionnalité est surtout utile dans un contexte décisionnel. De toutes façons vu le nombre maximum de cœurs utilisables, il ne serait pas rentable d’en tirer parti.

Comme l'explique un IBM Informix Champion (*), DBA chez un très gros client Informix aux Etats-Unis) , ces limitations lui permettent quand même d'effectuer 4.000.000 de transactions ( commits) par 24heures en 24x24, 7X7, tout en ayant ses CPU à 99% idle la plupart du temps. Je pense qu'à ce stade on reste dans le champ de ce pour quoi Innovator-C est recommandée et aussi de notre sujet : les applications départementales.

Si c'est un jouet, alors c'est vraiment un beau jouet !

1) Vous disposez de la fonctionnalité de Enterprise Replication ( avec un maximum de 2 « root nodes », et pas de limitation pour les « leaf nodes ».  Il en est de même pour la HDR ( high availability data replication ) : vous disposez d'un couple de serveurs en HDR Primary/ Secondary en read/write. De quoi garantir la haute disponibilité de votre serveur départemental. Avoir cette technologie pour ce prix était inespéré.

2) Le produit est livré avec un ensemble confortable de datablades :
* Spatial apporte les types de données et un ensemble très complet de méthodes d'accès aux données de géolocalisation, très en vogue en ce moment
* Basic Text Search : mettez vos données « ASCII imprimables » dans un clob (character large object, taille maxi 2Gb) et effectuez des recherches indexées dessus avec un ensemble de fonctions très utiles et surtout très efficaces.
* Binary : gérez les données opaques binaires
* MQ Series : un ensemble de types de données et fonctions destinés à la communiquer avec MQ series
* TimeSeries : le buzz du moment. Gestion des données basées sur le temps, qui pulvérise tous les records de benchmarks ( exemple : gérer la prise de mesure toutes les 15 mn de 100 millions de compteurs électriques).
* Web Datablade : on ne le présente plus. Permet d'inclure des appels Sql dans html et aussi diverses méthodes d'accès à XML.

3) le Scheduler
Introduit dans la version 11,70, il agit comme un cron, mais il est interne au serveur. Couplé avec l'introduction de  commandes d'administration exécutables à partir de dbaccess, un grand nombre de ces opérations peut désormais être préprogrammées directement dans IDS

4) le Storage Provisionning : gérez de façon proactive l'allocation d'espace disque. A froid, vous préparez un ensemble de chunks dans une réserve d’espace disque, et au moment où IDS en a besoin, il va affecter la ressource au dbspace,blobspace ou sbspace qui est en manque d'espace. Plus de blocage du moteur à 3h00 du matin du à un dbspace plein !

4) Open Admin Tool
Le petit bijou pour le DBA. Parti sur une base de conception « open source », cette application en php est la tour de contrôle de votre architecture Informix Dynamic Server. Tous les points de contrôle importants y sont traités, et ce pour toutes les instances Informix déclarées. Au delà des indicateurs de performances, vous pouvez également gérer votre espace disque, l'allocation de ressources, effectuer une approche top-down de la performance d'une session par exemple.
C'est aussi le point de contrôle et de gestion de votre Cluster ou Flexible Grid.

Je ne nomme pas toutes les fonctionnalités, mais si vous utilisez déjà IDS, vous savez pourquoi vous aimez ce produit. Comment ne pas reconnaître que pour zéro Euros, vous avez déjà un produit qui joue sans ambigüité dans la cour des grands ?

Alors pourquoi choisir Innovator-C Edition dès le début du projet ?

Voici les questions à se poser quand on effectue un choix de SGBD:
1) vous manque-t-il des fonctionnalités dans Innovator-C par rapport aux autres SGBD gratuits ?
2) quel SGBD vous coûtera le moins de temps en administration ?
3) quel SGBD affiche le plus long temps de « uptime » ou temps entre deux interruptions « non volontaires » ( chez IDS, on l'exprime souvent en années ), meilleur indicateur de la stabilité du produit ?
4) Quel est le SGBD dont l'architecture de base est la plus performante ?
5) Comment le SGBD escalade-t-il ? Avec ce bel anglicisme, je parle du comportement du moteur face à l’augmentation de la demande en ressources système? Ce dernier est-il intrinsèquement conçu pour réagir à l'augmentation de charge ? Est-il possible de répondre à cette augmentation, et si oui, quels sont  la difficulté et le risque techniques de la solution à mettre en oeuvre ?   

Vous l'avez compris, IDS arrive probablement en première place aux questions 1 à 4. Mais la question critique est la dernière, nous allons ci-dessous détailler la réponse.

Quand la ressource système est poussée dans ses derniers retranchements, on peut toujours changer pour une machine plus puissante et voir jusqu'à quel point le SGBD tiendra la charge. C'est à ce stade que l'on constate que les maximum affichés ( taille de tables etc...), sont théoriques et jamais atteints ( même pas en rêve).

Donc on change de marque de SGBD, on acquiert un produit de classe « Workgroup » ou « Enterprise » et on refait tout ou presque, comme détaillé dans le début de cet article. Scénario catastrophe, le système ne répond plus ou très mal, les utilisateurs sont mécontents. Le temps de mettre en production une solution stable est inacceptable. Prévoir de lourdes retombées depuis le haut de la pyramide hiérarchique, et dans le meilleur des cas, les nerfs en prennent un bon coup !

Et si j'avais démarré avec Innovator-C ?

Si j'avais démarré avec Innovator-C, je n'aurais pas  dépensé d'argent pour mon SGBD, mais j'aurais eu depuis le départ un produit IBM Informix Dynamic Server, une application et une infrastructure conçus pour ce produit.

La demande en ressources augmente et les limitations sont atteintes ou en passe de l'être ?

Je commande la Growth Edition ou bien la Ultimate Edition, suivant le besoin. J'arrête mon instance IDS, j'installe le nouveau produit et je redémarre mon instance sur la même machine et sur les mêmes disques. Temps de l'opération : aux alentours de 10mn probablement ! Prévoir quand même des tests dans un environnement de staging surtout en cas de changement de version.

J'ai maintenant toute latitude pour rajouter de la puissance CPU nécessaire et surtout je peux l'utiliser efficacement grâce à l'architecture Dynamic Scalable Architecture, universellement reconnue pour  sa capacité à optimiser l'utilisation des ressources disponibles lors de la montée en charge. Je ne touche pas à mon application, mais je peux par contre rajouter des CPU VP, augmenter le BUFFERPOOL par exemple ou bien utiliser le  PDQ, partionner les tables et autres fonctionnalités livrées avec Ultimate Edition.

Dans tous les cas, en démarrant avec Innovator-C je suis préparé à faire face à une très importante montée en charge, basé sur le principe que je ne changerai pas de SGBD. Sans modifier l’application, il suffira de débloquer et paramètrer les nouvelles ressources dont j'ai besoin. Il faut payer les licences, c'est sûr, mais pour tous les autres SGBD, il faut payer les nouvelles licences mais aussi retoucher fortement (refaire ?) l'application et son infrastructure, subir une lourde charge de tests fonctionnels et de performance, et parer aux imprévus.

Alors, on fait quoi ?














(*)Merci à Andrew Ford pour le partage de son expérience

vendredi 26 août 2011

Pocket guide Informix sur Android

Bonjour à tous,


Aujourd'hui je vais aller vite: pour ceux qui n'ont pas la syntaxe complète de onstat, onspaces, onparams, onmode et oncheck en tête,et qui n'ont pas envie de se promener avec la doc, voici un petit outil sympathique qui est téléchargeable sur tout device android:

http://kazer.com/android.html

Edité par un gros partenaire IBM Informix des Etats Unis.


A bientôt

dimanche 7 août 2011

Choix du type de file system sur linux: au cas où vous auriez des doutes...

Bonjour à tous,

c'est sous ce ciel menaçant que je prends ma plume pour me lancer dans un test que je voulais refaire depuis déjà quelque temps: l'incidence du choix de type de file system pour implémenter nos chunks Informix Dynamic Server, dans notre cas sur Linux.

Comme vous le savez sans doute, le raw device est depuis quelque temps une technologie obsolète sur la plupart des distributions Linux. Fait typique du conflit d'intérêts entre les éditeurs de base de données qui préconisent son utilisation,et les éditeurs d'OS et fabricants de hardware qui vont dans le sens contraire.

La manière d'implémenter des chunks sous IDS n'est pas sans effet, dans la mesure où elle impacte directement la performance d'entrées-sorties, donc la performance globale. Pour rappel, il est toujours bon de répartir au maximum les données sur le plus grand nombre possible de disque, et d'en maîtriser la disposition physique.
C'est pour celà qu'il est préférable d'éviter de créer les chunks sur des disque gérés de façon sans doute sécurisée ( RAID 0/1, RAID 5, file system journalisé etc..), mais qui vont coûter cher en termes de performance.

A priori, il est déjà inutile de sécuriser les dbspaces de données, sauf si vos bases de données ne sont pas journalisées ou si vous ne sauvegardez pas vos logical logs. Dans ces deux cas, il est probablement urgent de réviser votre stratégie sauf si la perte d'une journée de travail ou plus ne cause pas de problème.

Question sécurité de vos données, IDS est très bien fait. En "backupant" les logical logs en continu sur un device externe, et bien sur en faisant régulièrement vos sauvegardes avec ontape ou onbar, vous pouvez affronter un crash total avec un indice de confiance élevé quant à la pérennité de votre emploi.

Le gros intérêt de ce système est que IDS garantit la cohérence des données ( par le biais des transactions), et que la phase de restauration d'une instance se base sur ces mêmes transactions pour restaurer les données. L'intervalle effectif entre chaque backup de logical log sur une device externe est donc important, puisqu'il déterminera combien de temps de travail pour pouvez perdre en cas de crash de tous les disques de l'instance.

Bref, il est inutile de sécuriser vos file system hôtes de vos données, cela ne sert pas à grand chose, sauf éventuellement pour le rootdbs et/ou le dbspace contenant physical et logical logs pour garantir la disponibilité ( RAID 0/1 par exemple ).

Pour les dbspaces de données, je me suis donc livré à un exercice comparatif, qui a consisté à effectuer le dbimport d'une base de données de taille réduite ( 1.7 Gb), mais à indexation très complexe.

Le plan de test était le suivant:
1) création du dbspace sur sur un file system linux ext4 ( journalisé ), avec le paramètre onconfig DIRECT_IO à 0, puis dbimport dans une base non journalisée
2)création du dbspace sur sur un file system linux ext4 ( journalisé ), avec le paramètre onconfig DIRECT_IO à 1, puis dbimport dans une base non journalisée
3)création du dbspace sur sur un file system linux ext2 ( non journalisé ), avec le paramètre onconfig DIRECT_IO à 0, puis dbimport dans une base non journalisée
4)création du dbspace sur sur un file system linux ext2 ( non journalisé ), avec le paramètre onconfig DIRECT_IO à 1, puis dbimport dans une base non journalisée.

Je vois pointer la question: "qu'est-ce que DIRECT_IO ". C'est un paramètre onconfig qui permet de passer outre la couche de gestion des file systems, de telle sorte qu'IDS  écrit et lit en utilisant le Kernel IO, offrant donc pratiquement les mêmes avantages que si l'on utilisait des raw devices, à savoir sécurité d'écriture ( c'est IDS qui écrit dans le cooked file, pas le file system ), et un gain de performance variable en IO. Ce paramètre est disponible à partir de la Growth Edition,et malheureusement pas sur Innovator-C Edition :-(

faisons court:
test 1: durée du traitement =   91m41s
test 2: durée du traitement = 195m57s

test 3: durée du traitement =   54m49s
test 4: durée du traitement =   49m54s

Le vainqueur est donc sans appel le file system en ext2, avec direct_io activé.
La surprise a été le test en ext4 avec direct_io activé: combinaison à éviter absolument.

A noter que chaque test a été répété 2 fois, en prenant soin de redémarrer l'instance entretemps. Les temps obtenus pour chaque test ont été à chaque fois  très cohérents.

Vous avez donc maintenant des éléments de décision pour vos prochaines implémentations.



A bientôt sur notre station pour de nouveaux défis.

vendredi 1 juillet 2011

Objectif Performance

Bonjour à tous,

je me propose aujourd'hui de mettre en ligne un case study que j'ai écrit pour la Newsletter du User Group Informix France ( petit nom UGIF ), auquel je vous recommande de vous abonner car elle contient plein d'infos intéressantes. Pour s'abonner, c'est très simple: envoyez un email à ifmxnewsletter@fr.ibm.com avec "ABONNER" dans le sujet.
Bonne lecture et bons tests.
Eric

Etude de cas : Objectif performance…
"Bonjour, merci de vous être connecté sur notre station. Votre mission est, si vous l'acceptez, d'implémenter une nouvelle table dans la base de données, d'en faire un chargement initial avec un temps d'opération inférieur à 10 minutes, et de fournir à l'équipe de développeurs une manière de gérer au mieux les temps de réponses sur une requête imposée qui, selon le comité des testeurs de l'application reportant au Directeur des Opérations, a un temps de réponse inacceptable. Vous disposez d'IBM Informix Dynamic Server V11.70 FC2 Innovator-C Edition, un serveur Linux avec un processeur 4core, 16 Gb de RAM entièrement à votre disposition. Ah! J’oubliais, la table à charger comporte environ 70 millions de rangées, mais n'est pas très complexe quant à son schéma et son indexation. Il faudra de plus y charger environ 500 000 rangées tous les soirs" 

Ce genre de demande vous rappellera très certainement des situations vécues soit en tant que DBA, soit en tant que développeur. On constate généralement, à ces instants précis, un certain flottement dans le regard du destinataire de cette requête, de même que des symptômes caractéristiques du découragement ou d'une féroce envie de décliner la demande sous le chef de « ça n'est pas réaliste ». Il est vrai que dans les versions antérieures d'IDS cette demande représentait un véritable défi, difficile à relever. 
Mis à part peut-être l'utilisation de High Performance Loader, pas trop simple à mettre en oeuvre dans l'urgence, il faut avouer qu'il y avait au minimum de quoi être troublé par cette demande. Fort heureusement, nous sommes en 2011 et les laboratoires IBM Informix nous ont concocté un certain nombre d'améliorations très utiles, qui vont nous permettre de relever le défi avec IDS 11.70. 

Analysons tout d'abord la demande: 1) La nouvelle table contient tous les billets d’avion sur les liaisons entre la France, l’Allemagne, l’Angleterre, l’Italie, l’Espagne et les Etats-Unis depuis le 1er janvier 2005. en voici le schéma : create table tickets ( 
ticketno bigint, # N° unique de ticket 
lastname varchar(60), # Nom voyageur 
firstname varchar(30), # Prénom voyageur 
gender char(3), # MR/MRS/INF 
flightdate date, # Date du vol 
flightno char(6), # N° du vol 
fileno char(8), # N° de dossier 
price money(8,2), # Prix du vol 
carrier char(2), # Compagnie aérienne 
departfrom char(3), # aéroport de départ 
destination char(3) # aéroport de destination ); 
create index tickets3 on tickets (flightdate); 
create index tickets7 on tickets (destination);

Et enfin la requête qui pose des problèmes à nos amis développeurs: 
select destination , count(*) 
from tickets,airports 
where tickets.destination = airports.code 
and tickets.destination between "AAA" and "ZZZ" 
and airports.country = 'France' 
and flightdate between "21/03/2006" and "31/07/2010" 
group by 1 

J’avais au préalable réussi à convaincre les développeurs de fournir des indexes mono-colonne, de façon à éviter l’obtention de trop nombreux niveaux de B-Tree affaiblissant la performance. L'évocation du chiffre de 70 millions de rangées initiales, grossissant environ d'un million tous les 2 jours, est par contre de nature à susciter au minimum de l'intérêt, au maximum de l'inquiétude quant à l'atteinte des objectifs définis. 

Nous ne parlerons pas aujourd’hui de fragmentation de cette table qui pourrait nous apporter une solution ultérieurement en cas de détection de problèmes d'IO sur celle-ci. Nous ne parlerons pas non plus de la compression des tables, technique provenant de XPS et implémentée à partir de la version 11.50.xC6 qui, tout en réduisant environ de moitié (ou plus) l'espace disque, permet d'augmenter de façon significative les performances sur les "grosses" tables. Cette fonctionnalité est pour l'instant « optionnelle » (lire payante), et ne fait donc pas partie des options à envisager dans notre cas. 

Concentrons-nous donc sur la première partie du défi : le chargement de 70 millions de rangées en moins de 10 minutes. Nous avons pensé à High Performance Loader, qui est un outil très efficace, mais un peu complexe à mettre en oeuvre pour une première fois et dans le temps imparti. 

Je voulais donc évoquer ici l'utilisation des tables externes, provenant également de XPS et implémentées depuis la version 10.50. Le principe est très simple, vous créez votre table, sauf qu'au lieu de résider dans l'instance IDS, celle-ci est constituée par un fichier sur file system, structuré soit par l'existence de délimiteurs de champs, soit par une structure fixe. Vous créez la table externe qui pointe sur ce(s) fichier(s) et qui en décrit la structure comme une table « normale ». Nous avons donc appliqué ceci pour le cas d'aujourd'hui : 
CREATE EXTERNAL TABLE ext_tickets 
SAMEAS tickets 
USING (DATAFILES ("DISK:/home/eric/StagingArea/ObjectifPerf/tickets.unl"), DELIMITER "|",EXPRESS,MAXERRORS 10,REJECTFILE "/tmp/x_tickets.out")

Expliquons : 
« SAMEAS tickets » veut dire créer la table à l'image du schéma de la table déjà existante tickets. 
« DATAFILES DISK » : notre fichier est sur disque et se nomme... 
« DELIMITER » : c'est une structure avec délimiteurs de champs, ici le « pipe » 
« EXPRESS » : le mode de chargement. Il s'oppose au mode DELUXE. Ce mode évite l'utilisation des pages de buffers lors de la lecture dans cette table, ce qui va muscler fortement la performance de notre chargement. 
« MAXERRORS » : au-delà de ce nombre d'erreurs, la création de la table s'arrête. 
« REJECTFILE » : le fichier où sont consignées les erreurs de chargement.

Une table externe peut donc être manipulée par des tous types de requêtes SELECT ( order by, group by, prédicats) , mais ne peut pas être UPDATED,DELETED ni INSERTED. Résultat , avec table raw la commande de chargement est : 
INSERT INTO tickets SELECT * FROM ext_tickets 
70000000 row(s) inserted. 
real 6m20.937s user 0m0.005s sys 0m0.005s

Nous avons comparé avec la méthode insert into table load from file, et le résultat est sans appel : nous avons arrêté le chargement au bout de 24 minutes : seulement 24 Millions de rangées étaient chargées. 

Autre point important à relever : nous avons crée une table de type « RAW ». Ce type de table a la particularité de désactiver la journalisation de la table incriminée. En conséquence, la performance de chargement est drastiquement améliorée du fait de l'absence d'IO à cause de la journalisation (logical logs). La différence est plus que notoire. Le gros intérêt est qu'il est possible de changer en type STANDARD (journalisation) après le chargement par un simple ALTER TABLE, puis repasser en RAW pour les chargements consécutifs. 
Nous évitons également l’écueil de la ‘long transaction’

Nous avons donc atteint le premier objectif de passer sous les 10mn de temps de chargement, et restons sereins pour les chargements journaliers. 

Passons maintenant au deuxième défi : la requête La table tickets a un nombre de rangées respectable ( 70 millions de rangées ), et à cette échelle il convient de veiller à optimiser les ressources ainsi que les accès. 
Nous partirons de la baseline proposée par l'équipe des développeurs et prendre une mesure de performance. 
Nous avons de fait renoncé à la baseline, comprenant les plaintes des développeurs : la requête a été abortée au bout de 60 mn sans qu’elle soit terminée, voici son plan de requête : 
Estimated Cost: 3126460 
Estimated # of Rows Returned: 775663 
Temporary Files Required For: Group By 
1) eric.airports: INDEX PATH 
Filters: (eric.airports.code >= 'AAA' AND eric.airports.code <= 'ZZZ' ) 
(1) Index Name: eric.i_airp3 
Index Keys: country (Serial, fragments: ALL) 
Lower Index Filter: eric.airports.country = 'France' 2) eric.tickets: 
INDEX PATH Filters: (eric.tickets.flightdate >= 21/03/2006 AND eric.tickets.flightdate <= 31/07/2010 ) 
(1) Index Name: eric.tickets7 
Index Keys: destination (Serial, fragments: ALL) 
Lower Index Filter: eric.tickets.destination = eric.airports.code
NESTED LOOP JOIN 

Nous obtenons donc une nested loop (boucle imbriquée pour la jointure ), avec utilisation de l’index sur les pays pour la table airports ( 10000 rangées ), et l’index date du vol pour la table des tickets. Onstat - p nous donne 7509528 rangées lues (read). 

C’est à ce moment que nous introduisons la nouvelle directive d’optimiseur MULTI_INDEX, qui va nous permettre d’utiliser plusieurs indexes sur une même table, contrairement à ce qui se faisait auparavant. La syntaxe : 
SELECT --+multi_index(tickets tickets3 tickets7) 
distinct(destination) , count(*) .... 
from tickets,airports etc.... 

Nous allons dire à l’optimiseur d’utiliser les index tickets3 ET tickets7 pour la table tickets afin de lire un minimum de pages de données, et par conséquence réduire les IO sur cette requête. Voici le résultat du set explain : 
DIRECTIVES FOLLOWED: MULTI_INDEX ( tickets tickets3 tickets7 ) 
DIRECTIVES NOT FOLLOWED: 
Estimated Cost: 113176408 
Estimated # of Rows Returned: 775663 
Temporary Files Required For: Group By 
1) eric.tickets: MULTI INDEX PATH (SKIP SCAN) 
(1) Index Name: eric.tickets7 
Index Keys: destination (Serial, fragments: ALL) 
Lower Index Filter: eric.tickets.destination >= 'AAA' 
Upper Index Filter: eric.tickets.destination <= 'ZZZ' AND 
(2) Index Name: eric.tickets3 Index Keys: flightdate (Serial, fragments: ALL)
Lower Index Filter: eric.tickets.flightdate >= 21/03/2006 
Upper Index Filter: eric.tickets.flightdate <= 31/07/2010 
2) eric.airports: INDEX PATH 
Filters: Table Scan Filters: (eric.airports.code >= 'AAA' AND eric.airports.code <= 'ZZZ' ) 
(1) Index Name: eric.i_airp3 
Index Keys: country (Serial, fragments: ALL) 
Lower Index Filter: eric.airports.country = 'France' 
DYNAMIC HASH JOIN
Dynamic Hash Filters: eric.tickets.destination = eric.airports.code

La physionomie du plan de requête a totalement changé : nous voyons l’activation de la directive multi-index sur la table tickets, qui a pour effet l’utilisation de l’index tickets7 + l’index tickets3 et finalisant le plan par un HASH JOIN pour la jointure.

Onstat -p nous indique que seulement 2.294.947 de rangées ont été lues, ce qui devrait signifier un progrès sensible. Et le temps de réponse ???? 
Le voici : 
155 row(s) unloaded 
real 5m22.672s user 0m0.005s sys 0m0.008s 

Oui ! c’est bien 5 mn 22s. L’objectif d’amélioration du temps de réponse est atteint. N’ayant pas de données implémentées sur plusieurs disques, nous ne pourrons pas profiter du multiplexage des scan threads qui auraient pu améliorer encore notre performance. N’ayant pas lancé ce test sur la Ultimate Edition, nous ne pouvons pas bénéficier du PDQPRIORITY qui aurait sans doute amélioré légèrement les résultats. 
Nous avons clairement profité de la directive MULTI INDEX, qui a diminué le temps d’attente de plus d’une heure (peut-être beaucoup plus ) à 5 mn 22s.

Il faut savoir également que cette technique est extrêmement efficace dans des requêtes avec prédicat « OR » portant sur des indexes différents d’une même table. Combien de fois nous a-t-il fallu réécrire une requête de ce type en incluant une UNION ? Avec cette technique, plus la peine de tout réécrire, il suffit d’ajouter la directive d’optimiseur qu’il faut, et le tour est joué ! 

Nous vous encourageons également à utiliser l’option de onmode ‘-Y sessionid 1 output file’, qui produira le fichier d’explain de la session ‘sessionid’ sans avoir à rajouter le ‘SET EXPLAIN ON’ dans le code de l’application. A utiliser toutefois avec modération en environnement production, car ce mode est très volubile et peut générer une charge d’IO qui pourra parasiter la performance. 

Voilà, mission accomplie ! Merci aux techniques de tables externes en mode EXPRESS, de table de type RAW qui suppriment temporairement la journalisation, et la nouvelle directive d’optimiseur MULTI_INDEX. A bientôt sur notre station pour de nouveaux défis.