En lançant sa 'Machine', Oracle attaque Teradata, Netezza et tout le marché des 'appliances'

Nous constatons aussi chez IBM une demande croissante de nos clients pour des solutions décisionnelles performantes, simples et économiques. C’est pour cette raison que nous avons lancé la nouvelle Appliance « InfoSphere Balanced Warehouse » intégrant la base de donnée DB2 DWE V9.5, version parallélisée, sur un cluster MPP xSeries ou pSeries sous Linux, Windows ou Unix.

L’originalité de notre offre, contrairement à cette d’Oracle est de proposer plusieurs version de cette Appliance, avec un point d’entrée très bas (inférieur à 50K€) !
- C-Class de 50 GB à 700G B, sous Linux ou Windows, destinée principalement au PME,
- D-Class de 1 à 3 TB sous Linux, destiné au grandes entreprises,
- E-Class sous AIX pour les DWH haute performance de plus de 3 TB.

InfoSphere embarque aussi, en option, l’ETL Datastage PX (parallélisé) et la suite Cognos BI V8.

Point important, afin se faciliter la maintenance HW et SW IBM fournit un point de support unique pour l’ensemble de la solution. On peut d’ailleurs se demander qui, d’Oracle ou de HP, assurera le support efficace de l’offre Oracle ?

Nous sommes aussi dubitatif sur le coût total de la solution Oracle, car si l’on fait le calcul du coût des licences Oracle pour la configuration proposée et du HW, il y a de quoi se faire peur (environ 5 millions d’euro) ! La complexité bien connue d’administration de RAC restera aussi l’écueil majeur à la généralisation de l’offre d’Oracle.

Eric Sallou
IBM InfoSphere Balanced Warehouse Specialist
eric.sallou@fr.ibm.com

Oracle démocratique? D'après leur discours récents ils ressemblent de plus en plus à Microsoft. ( on sait tout faire, avec les meilleurs perfs du monde et au meilleur prix pour tous les domaines fonctionnels ). Ils ont certains des produits qui tiennent la route soit, mais j'aime pas ce genre de "propagande" alors que leurs solutions sont loin d'être si parfaites sur nombre de domaines.

Je vais rajouter une "anecdote" bien réelle sur le choix d'une solution BI.

Le responsable X de la société Y du CAC40 s'en va après Z années de loyaux services. Le nouveau responsable T souhaite à tout prix se remarquer et décide de tout changer. Il s'heurte de la politique de Y qui a des standards. Mais arrive néanmoins à changer la base et l'ETL.

Les travaux démarrent en vitesse afin de mettre en place cette merveilleuse solution. Tout se passe bien, le nouveau DW se met en place, mais l'imprévu arrive quand le standard impose la solution de reporting. Projet titanesque de migration de ce projet vers le nouveau DW, abandonné en cours de route pour tout refaire ( plus simple et moins long avec cette solution de reporting ).

Un jour, un responsable financier jette un oeil curieux sur la facture. Alors, faisons le compte...abadon de la base 1 : xxx euro , achat de la base 2 : xxx euro , abandon de l'ETL , travaux d'adaptation etc. Grand total W millions d'euros. Avec en prime des utilisateurs mécontents car données pas à jour et revenus tranquillement à leur Excel favori sur toute la ligne.

Conclusion? Une solution BI peut reposer sur les meilleurs outils du marché, ça risuqe de ne pas fonctionner pas quand même. C'est valable pour nombre de domaines dans l'informatique, mais la BI a cette particularité de dépendre des hommes qui la conçoivent et implémentent plus que d'autres.

Un seul débat technique ne suffit pas, pour ma part j'ai par exemple même vu des outils ad-hoc tordus pour faire du reporting de masse et information delivery. Le comble c'est que ça marchait. ( après nombre d'efforts tout de même ). Je me tais sur la maintenabilité de la solution...

Chaque outil a ses points forts et ses applications, ses clients etc. Il y aura révolution quand on passera à un autre type de BI. Mon avis ce qu'il faut regarder ailleurs que seule la technique, l'infrastructure se copie vite et se fabrique en Chine.

A vos plumes.

Choisir son DW est moins dangereux que de faire du parapente! le risque serait une mort prefessionnelle de courte durée à la limite ;-)
Bien entendu le DW actif ne peut être reconnu comme tel que si on tiens compte du chargement au fil de l'eau avec des opérations d'insert/update/upsert/delete et select en même temps et sur les mêmes tables pour des applications sensibles comme la fraude, gestion de risques, revenue assurance, cotations etc etc ou on a besoin d'une donnée fraiche et up-to-date...je suis désolé mais les appliances ne savent pas allier le temps réel et le DSS et le mixed workload.. j'ai eu mainte fois l'occasion de le vérifier....c'est justement pour cela que je defend oracle qui permet de faire le "tout terrain" aussi bien pour les petits budgets que pour les gros..et la démocratisation des architectures massivement // a vu le jour avec Exadata.

Philippe, sachez tout d'abord que j'admire votre travail depuis de nombreuses années et surtout, votre probité jamais mise en défaut et votre art consommé de la communication. Je ne voulais donc surtout pas laisser à penser que ma remarque avait quelque objectif prétentieux de vous mettre en porte-à-faux. Si un doute a plané à se sujet, je vous présente moi aussi toutes mes excuses.

Une architecture MPP peut être définie, selon moi, par l'organisation des données du SGBR. Dans une architecture cluster comme RAC, toutes les données de la base sont partagées par toutes les CPU de l'architecture ou autrement dit, chaque CPU (et donc l'applicatif qui l'utilise) peut accéder à toutes les données de la base. Dans une architecture MPP, les données de chaque table de la base sont réparties sur les CPU qui ne voient et ne gèrent que ce sous-ensemble de données. Cette répartition est prise en charge par le SGBDR (ex. via algorithme de hashing). Voilà ce que je souhaitais préciser par ma modeste remarque, sans aucune prétention naturellement. Naturellement, une architecture MPP ne peut pas se limiter à cette définition, mais disons qu'elle peut être vue comme un postulat fondamental.

J'en profite également pour apporter une autre précision. Le dernier message de Mario indiquait que le data warehouse actif induisait des problèmes de locking en écriture concurrente sur le data warehouse. Je suis au regret de vous dire que c'est totalement faux. Que ce soit avec Oracle, DB2, Teradata ou SQL Server. Non pas d'ailleurs pour des raisons techniques comme l'entendait Mario, mais pour des raisons fonctionnelles. En effet, le data warehouse actif se définit par la proposition de services SOA utilisant les données du data warehouse dans les environnements opérationnels, mais ces services sont en mode LECTURE (SQL SELECT et non INSERT/UPDATE/DELETE). La contention en matière de locking peut éventuellement se poser au niveau de l'alimentation du dw actif, qui se fait en temps réel ou quasi réel, mais ce risque est réduit car porte sur un sous-ensemble très réduit de données. J'ai personnellement quelque expérience en matière d'implémentaition et peut témoigner que toutes les bases du marché sont parfaitement équipées techniquement pour faire du dw actif. Tout dépend encore une fois du périmètre du projet car en revanche, toutes ne monteront pas en charge de la même manière inconditionnelle, surtout lorsqu'il faudra s'engager sur la qualité de service des transactions SOA actives. Un exemple ? Garantir un temps de traitement de 100 msec pour les 200 transactions simultanées "actives SELECT" avec en même temps un utilisateur SAS qui lance LA requête de scoring des 4 millions de clients ou un utilisateur BO qui vient de lancer (dans le vide) une requête "oooups" faisant un superbe "full table scan" de la table de faits de 3 milliards de lignes.

Je fais du parapente depuis 20 ans. Je peux aujourd'hui entrer dans une boutique et acheter une voile de compétition. J'ai toutes les chances de me tuer dans les 20 premiers vols. Et pourtant, c'était la voile avec les meilleures performances du moment.