Cependant, il faudra aussi aller piocher un grand nombre d'éléments dans la pile technologique d'Oracle. En effet, pour profiter au mieux de Big Data SQL, il faut que l'utilisateur installe et fasse tourner une base de données Oracle sur une machine Exadata de l'éditeur. « Dans ce cas, la machine Exadata et Big Data Appliance peuvent partager une interconnexion pour l'échange de données », a expliqué Neil Mendelson. En outre, Big Data SQL est uniquement compatible avec la version 12c de la base de données d'Oracle, disponible depuis l'année dernière. Or, la plupart des clients actuels de la base de données d'Oracle utilisent toujours les versions 11g et antérieures. Cet investissement dans Big Data SQL présente néanmoins certains avantages. « Les clients pourront notamment utiliser les fonctions de sécurité avancées de la base de données Oracle dans les magasins Hadoop et NoSQL », a expliqué le VP d'Oracle. « Les règles de sécurité définies pour les données dans la version 12c sont simplement « poussées » dans ces autres environnements », a-t-il ajouté.
Limiter le déplacement des données
Toujours selon Neil Mendelson, Oracle a prévu de rendre son outil Big Data SQL compatible avec d'autres systèmes maison. Le logiciel sera disponible partout dans les prochains mois. Son prix sera annoncé au moment de la sortie. « Big Data SQL n'a pas pour ambition de remplacer les moteurs SQL déjà existants pour Hadoop, comme Hive et Impala, lesquels seront toujours livrés avec la Big Data Appliance d'Oracle », a précisé le VP d'Oracle. « Nous voulons vraiment résoudre un problème plus large. L'un des grands défis auxquels sont confrontés les scientifiques dans le domaine des données se situe essentiellement au niveau du déplacement des données entre les systèmes », a-t-il dit. Selon lui, Big Data SQL permet d'envoyer des requêtes vers différents types de magasins en limitant au minimum le déplacement des données et en utilisant des requêtes plus efficaces grâce à la technologie Smart Scan de la pile logicielle Exadata.
Au premier abord, Big Data SQL pourrait apparaître comme un autre moyen de faire de la mutualisation de requêtes, une solution connue et utilisée ici et là depuis un certain temps. Selon Curt Monash, analyste de Monash Research, « l'outil a aussi ses inconvénients ». En particulier, « fédérer une requête à travers différents systèmes a toujours un coût réseau », a-t-il ainsi déclaré. « Souvent, il faut aussi que la requête soit planifiée par un optimiseur qui ne pondère pas forcément de façon optimale toutes les parties de la requête », a ajouté l'analyste. « Si le gain en performance pour le déplacement des données est assez important pour compenser ces inconvénients, il serait encore mieux de déplacer les données avant de lancer la requête, comme c'est le cas habituellement », préconise-t-il encore.
Un filtrage local
Mais Big Data SQL « utilise la consolidation des données en donnant la priorité à une pile principale », a déclaré Curt Monash. « Un prédicat fait, dans ce cas-là , partie de l'instruction SQL. Au lieu de tout faire dans le lieu de traitement principal - en l'occurrence, un cluster pourrait le faire lui-même - vous faites descendre certains prédicats au niveau où sont stockées les données. C'est tout l'intérêt d'Exadata », a ajouté l'analyste. « Une grande partie du filtrage est effectué localement, de sorte que l'impact sur le réseau n'est pas aussi négligeable qu'il pourrait être autrement. Ce facteur atténue les objections sur la fédération de données. C'est une bonne idée, tout comme Exadata est une bonne idée. Mais il serait exagéré de dire que Big Data SQL apporte quelque chose de nouveau », a tempéré l'analyste. « Toutes ces solutions sont déjà connues, mais Oracle les met en oeuvre dans son environnement fermé particulier ».