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