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

C'est une vraie révolution de voir une solution qui fera cohabiter le shared-nothing avec le shared-all...ainsi complementer l'utilisation de RAC pour manager des gros DWs. Les spécialistes qui ont utilisés les 2 technologies sont ravis de voir cette évolution pértinante qui reglera des problèmes de jointures, locking dans le shared nothing et transfert de données dans shared all etc...
le monsieur de netezza qui n'a pas évouler dans son point de vue, reste sur des message des années 2000! comparer les fonctionalités de netezza avec celles d'oracle : c'est de la rigolade, les puristes comprendront! monsieur Adrien lui mélange tous...donc pas de commentaire car il doit relire l'annonce d'oracle ou voir le blog de kevin closson pour mieux comprendre.

Bah voyons, calmons nous.

Mon opinion ( ceci n'engage que moi et mon expérience ) :

-Oracle a une belle part de marché dans les DW. Mais leur domaine fétiche reste l'OLTP.
-Lancer une appliance est une chose intéressante. C'est à la mode et il y a un avenir pour ce type de solution.
-Dire qu'Oracle sait tout faire avec des performances foudroyantes revient à dire que Blanche Neige existe ou que les clients d'autres solutions ont fait un mauvais choix ou sont incompetents.
Attention aux grandes "phrases" saupoudrées de démagogie, messieurs d'Oracle, les clients attendront tout et ...ils le l'auront pas :-)
-Oracle a bien plus de moyens commerciaux/marketing.
-Oracle a des années devant pour intégrer et améliorer tous les produits achetés même à ce niveau de R&D et ne pourra pas tout couvrir, à moins que le CEO d'Oracle décide que la BI prend tout le budget R&D, ce qui va faire des mécontents ailleurs ( ERP, etc. ). :aie:


-Teradata et Netezza sont des acteurs de niche. Mais s'ils ont des clients c'est qu'ils ont leur avantages.
- Etre spécialisé sur une niche c'est investir plus de R&D dans ce petit domaine spécifique et être susceptible d'être mieux sur un certain nombre de sujets restreints rendant heureux un certain nombre de clients ayant ces besoins spécifiques.

Et pour la bonne bouche, j'ai vu pléthore des projets BI où Oracle et Teradata par exemple cohéxistaient en paix.

La BI est un sujet vaste à ce jour et il y a la place pour tout le monde, petits et grands, chacun son petit/grand avantage qui correspond parfaitement au besoin X ou Y et à l'architecture de la boîte Z.

Enfin jusqu'à ce que la vague de rachats recommence :-)

Philippe Nieuwbourg a écrit : "Basé sur une architecture massivement parallèle...". Peut-il définir "architecture massivement parallèle" ?

Car si dans cette annonce, Oracle proposait une véritable achitecture MPP, ce ne serait plus une évolution mais une vraie révolution ! Or ne s'agit-il pas plutôt d'une configuration (super-)RAC pour laquelle la liaison serveur-système de stockage a (enfin) été considérée comme un élément critique en matière de montée en charge ?

Quant à tous ces commentaires partisans vantant les performances ou les fonctions "bien plus mieux" que celles des autres, je crois que ça fait longtemps que je n'ai plus lu autant de contre-vérités (toutes faites) sur decideo. C'est soirée catch ou soirée poker (menteur) ?

Oracle est une excellente base de données. Teradata aussi. DB2 aussi. Et Netezza a vraiment inventé quelque chose avec son architecture de cartes combinant CPU et disque. La critique est aisée mais l'art difficile. Et la question est toujours la même : compte-tenu des caractéristiques de MON data warehouse, quelle est la technologie/architecture la plus pertinente ?

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.