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
