Oracle fait de SQL un langage de requêtes pour Hadoop et NoSQL

Oracle fait de SQL un langage de requêtes pour Hadoop et NoSQL
Oracle Big Data SQL unifie et simplifie l’accès aux données structurées et non structurées

Avec l’augmentation du volume de données à gérer, les entreprises se sont tournées vers des solutions bien adaptées à la gestion des Big Data comme Hadoop et NoSQL. Cependant, chaque outil peut entrainer un cloisonnement des données qui va en compliquer l'accès ainsi que l'analyse, et pénaliser ainsi l'extraction d'informations à forte valeur ajoutée. Pourtant, en entreprise, ces outils se partagent couramment la scène avec d’autres systèmes de gestion de données.

De plus, pour analyser les données, les entreprises sont obligées d’avoir recours à plusieurs compétences et outils, pour par exemple bâtir des requêtes distinctes (relationnelles et non relationnelles) pour chaque plateforme pour ensuite tenter de relier les résultats, ou encore transférer les données et les analyser avec un langage basé sur MapReduce.

Pour pallier à cela, Oracle propose Oracle Big Data SQL pour permettre aux entreprises de transformer leur architecture de gestion des données en un véritable système de gestion Big Data, capable d'intégrer de façon transparente tous les types de données issues des sources les plus diverses, y compris Hadoop, NoSQL et les données relationnelles. La solution s'exécute sur Oracle Big Data Appliance et peut fonctionner avec Oracle Exadata Database Machine.

Doté d'une technologie de Smart Scan issue d'Oracle Exadata, Oracle Big Data SQL promet d’offrir aux utilisateurs la possibilité d’interroger toutes les formes de données structurées et non structurées, tout en garantissant la sécurité et les performances.

« Au-delà des bases de données relationnelles, les entreprises utilisent des sources de données toujours plus diversifiées telles que Hadoop et NoSQL. Mais cette évolution entraîne un cloisonnement accru des données, qui pénalise leur analyse et restreint le potentiel Big Data », déclare Andrew Mendelsohn, Executive Vice President, Database Server Technologies chez Oracle. « Oracle Big Data SQL s'appuie sur le langage de requête extrêmement populaire que représente aujourd'hui SQL pour décloisonner les données et intégrer les Big Data avec les outils classiques de l'entreprise ».

Oracle Big Data SQL permettra donc d’exécuter des requêtes SQL sur Hadoop, NoSQL et Oracle Database, en minimisant les déplacements de données tout en augmentant la performance. Selon Oracle, sa solution permet de faciliter et accélérer la découverte d'informations à forte valeur ajoutée, tout en protégeant la sécurité des données et en assurant leur gouvernance.

Avec Oracle Big Data SQL, les mécanismes de sécurité d'Oracle Database et les politiques de sécurité déjà en place au sein de l'entreprise pourront désormais être étendus aux données Hadoop et NoSQL. Les outils et les applications de business intelligence les plus courants, basés sur SQL, pourront également, grâce à la solution, accéder plus facilement aux sources de données Hadoop et NoSQL en complément du datawarehouse traditionnel, pour accélérer la découverte et l'exploitation opérationnelle des analyses Big Data sans avoir à modifier les applications et les outils existants.

Oracle Big Data SQL est annoncé pour le troisième trimestre de cette année.


Source : Oracle


Et vous ?

:fleche: Que pensez-vous de cette solution ?

Un version parmi tant d'autres de "SQL on Hadoop/NoSQL" : http://blog.matthewrathbone.com/2014...or-hadoop.html

Finalement amusant de voir que l’un des domaines les plus actifs de la mouvance NoSQL est la création d’un engin d’execution SQL pour faciliter les requêtes…

Franchement je n'en suis pas étonné, parce que quand je vois le JS utilisé dans MongoDB par rapport à une requête SQL équivalente, y a pas photo : il n'y a pas plus clair et concis que le SQL.

http://bicortex.com/bicortex/wp-cont...DB-mapping.jpg

PS: C'est bien beau tout ça mais Oracle affiche déjà les meilleures performances du marché avec son SGBDR, j'aimerais bien voir une comparaison avec son NoSQL (des courbes qui se croisent et qui indiquent à quel moment il devient plus intéressant d'utiliser le NoSQL). Il n'y a pas que des avantages à utiliser le NoSQL : pas de transactions (sauf dans le cas où le traitement se fait sur la table en cours...), pas de jointures (bonjour la conception), pas de contrainte d'intégrité...

Citation:

---

Envoyé par Gugelhupf

Franchement je n'en suis pas étonné, parce que quand je vois le JS utilisé dans MongoDB par rapport à une requête SQL équivalente, y a pas photo : il n'y a pas plus clair et concis que le SQL.

[...]

PS: C'est bien beau tout ça mais Oracle affiche déjà les meilleures performances du marché avec son SGBDR, j'aimerais bien voir une comparaison avec son NoSQL (des courbes qui se croisent et qui indiquent à quel moment il devient plus intéressant d'utiliser le NoSQL). Il n'y a pas que des avantages à utiliser le NoSQL : pas de transactions (sauf dans le cas où le traitement se fait sur la table en cours...), pas de jointures (bonjour la conception), pas de contrainte d'intégrité...

---

Hem.. Le problème dans l'infographie, c'est que ce ne sont pas les même choses qui sont comparées... Comparer du SQL et du NoSQL de cette manière est à mon sens une mauvaise approche. Si on est sur la simple sémantique, une requête SQL peut être "simple", le code générant la requête de manière dynamique, beaucoup moins...

Non, il n'y a pas que des avantages à utiliser du NoSQL, c'est bien pour ça que le No de NoSQL signifie "Not Only". L'idéal voudrait qu'un SI combine les deux approches en fonction du besoin...

Je ne dis pas que le NoSQL est inutile parce qu'on a déjà les SGBDR, le souci c'est que je vois beaucoup de gens autour de moi qui prennent l'exemple ce que fait Google ou Facebook, et pensent facilement reproduire le modèle pour leurs applications...
Je suis sur que le NoSQL est très une bonne solution pour l'infographie ou la traçabilité d'une usine de production industrielle (données en masse), par contre pour les applications de tous les jours je suis mitigé.
D'où la question que je me pose, à quel moment devient-t-il plus intéressant d'utiliser le NoSQL par rapport aux SGBDR traditionnels ? 1 milliard de tuples avec 50 colonnes de type chaine ?

@Gugelhupf: Ton infographie est terrible, car elle commence à dater (3 ou 4 ans) et depuis MongoDb et les autres, ont quand même bc évoluer.
On peut faire bc de chose en MongoDb sans utiliser Map/Reduce et avec une écriture assez simple.
L'écriture d'une requête en MongoDB ressemble, dans la forme, à l'utilisation des Steams en Java 8.
SQL Comparaison
Aggregation Framework

La question du SGBDR vs NoSQL est la même que CPU vs GPU. Il faut juste un peu de temps pour que ça rentre dans les esprits, vous n'allez pas utiliser un GPU pour les calculs itératifs sur de simples variables, le CPU sais faire en mieux.

Sans l'utilisation du map/reduce (ou du moins une technique approchante), l'utilisation de NoSQL reviens à revenir en arrière pour les SGBDR.
Un SGBDR en instances multiples sera monté avec des relations maître-esclave où le maître est seul agrégateur (c'est ce qui permet les jointures compliquées et de respecter les propriétés ACID).
Sur du NoSQL, on abandonne les propriétés ACID et on ne prends pas les données comme répondant à un modèle relationnel mais un ensemble de documents. Attention on viens d'abandonner BEAUCOUP de choses! En contrepartie, une bonne architecture vas chercher, avec aussi une relation maître-esclave, de laisser le maître orchestrer au maximum (dans le cas idéal c'est son seul rôle, il ne gère aucune donnée) et les esclaves doivent lire les données et agréger ces mêmes données. L'agrégation des données se fait réellement à deux niveaux, en interne au sein de chaque esclave et entre les esclaves avec l'aide de l'orchestrateur.

Si on prends un exemple simple d'utilisation de NoSQL : Compter dans tous les ouvrages français le nombre d'occurrence de chaque mot.

On assume que les "optimisations" n'existent pas sur nos SGBDR, on en trouvera nécessairement pour ce cas basique mais sur des problèmes plus complexes (ce n'est pas de ressort d'un programmeur de le trouver mais plus d'un statisticien), les "optimisations" n'existeront pas.

Le SGBDR aura partagé toutes ses données entre ses esclaves, on peux donc facilement stocker une quantité hallucinante d'ouvrages. Mais le problème n'est pas ici. Le serveur maître doit lire chaque ouvrage pour pouvoir compter tous les mots de chaque ouvrage. On a donc une limitation sur la vitesse de lecture du serveur maître. A supposer qu'on peux connecter autant de cartes réseau que l'on veux, le critère limitant serait alors le processeur, la mémoire vive et la carte mère. Nous sommes alors limités au mieux par la qualité du serveur maître. Sur une base de données de 100To avec (je dis surement des bêtises mais l'ordre de grandeur reste là) une lecture de 10Go/s, on doit attendre plusieurs heures que le serveur maître (qu'on a pourtant optimisé au mieux d'un point de vue technique) fasse le compte.

Maintenant avec NoSQL, c'est un peu différent. Chaque esclave va de son côté compter le nombre occurrence de chaque mot qu'il trouve dans son propre entrepôt. Chaque serveur se retrouve avec une liste d'entrées clé-valeur où la clé est le mot et la valeur est le nombre d'occurrences trouvé.
Ensuite, avec l'aide du serveur maître qui orchestre l'opération, les serveurs esclaves envoient leurs résultats intermédiaires aux autres serveurs esclaves pour avoir un résultat final. Dans notre exemple, chaque esclave vas demander au maître qui traite le regroupement de chaque mot pour en regrouper les résultats. Le serveur maître est certes bombardé de requêtes, mais elles sont bien moindres en nombre car la quantité de mots différents est de beaucoup moindre à la quantité de mots dans toutes nos données.
Au même moment que les esclaves reçoivent les résultats intermédiaires de leurs homologues, ils agrègent ces résultats intermédiaires.
Dans ce système, si on suppose une grappe de serveurs même médiocres mais en quantité suffisante, on peux atteindre de "relativement" bonnes performances (plus on a de serveurs, plus vite on arrive au résultat). Je ne parle pas de quantité de données à traiter car la vitesse de traitement est [presque] proportionnelle au ratio quantité de données / nombre de serveurs. C'est quand la quantité de données explose que le SGBDR perds la course.

Il faut nuancer ces performances car il y a ÉNORMÉMENT d'axes d'améliorations pour chaque requête créée et les propriétés ACID perdues ne sont pas une mince affaire. Le système parfait n'existe malheureusement pas, c'est pour cela que j'invite à former des équipes à métiers multiples pour résoudre ces problématiques. Des programmeurs doivent travailler de paire avec des statisticiens pour obtenir de bonnes performances. A une véritable échelle industrielle (coucou Google, Facebook, Twitter), même une amélioration mineure peux faire gagner des jours de traitement.

Maintenant, pour stocker des objets avec du relationnel, ne cherchez pas à utiliser NoSQL s'il vous plait, sinon on va vous faire coder en assembleur sur des GPU où les seules opérations autorisées sont l'addition, la soustraction et le shift. De même, du NoSQL sur un seul serveur c'est une table à une seule colonne dans un SGBDR. Oubliez cette idée.

Salut,

ne croyez-vous pas que l'on va reproduire la même chose avec les SGBD NoSQL que ce qui s'est déjà passé il y a un petit moment avec les SGBD XML ? A l'époque, les SGBD purement XML ont été fagocités par des solutions hybrides "SGBDR XML" telles qu'Oracle8i.

Citation:

---

Envoyé par Gugelhupf

Je ne dis pas que le NoSQL est inutile parce qu'on a déjà les SGBDR, le souci c'est que je vois beaucoup de gens autour de moi qui prennent l'exemple ce que fait Google ou Facebook, et pensent facilement reproduire le modèle pour leurs applications...
Je suis sur que le NoSQL est très une bonne solution pour l'infographie ou la traçabilité d'une usine de production industrielle (données en masse), par contre pour les applications de tous les jours je suis mitigé.
D'où la question que je me pose, à quel moment devient-t-il plus intéressant d'utiliser le NoSQL par rapport aux SGBDR traditionnels ? 1 milliard de tuples avec 50 colonnes de type chaine ?

---

Fqcebook et Google utilisent massivement SQL. Il n'y qu'à voir leur pqrticipqtion à WebScaleSQL.

Citation:

---

Envoyé par Gugelhupf

PS: C'est bien beau tout ça mais Oracle affiche déjà les meilleures performances du marché avec son SGBDR, j'aimerais bien voir une comparaison avec son NoSQL (des courbes qui se croisent et qui indiquent à quel moment il devient plus intéressant d'utiliser le NoSQL). Il n'y a pas que des avantages à utiliser le NoSQL : pas de transactions (sauf dans le cas où le traitement se fait sur la table en cours...), pas de jointures (bonjour la conception), pas de contrainte d'intégrité...

---

Je ne suis pas sûr que le SGBDR de Oracle soit le plus performant du marché actuellement... L'un des plus chers, sans doute. Le plus présent historiquement, OK. Sur des usages purement analytiques (data warehouse...), il est très loin du top...

L'annonce de Oracle sur son offre SQL on Hadoop arrive tard par rapport aux concurrents. Cela reste de plus un message purement marketing car il n'y a aucun détail sur le fonctionnement et la solution n'est pas encore sortie.
La seule chose que l'on sait c'est qu'il faut une appliance spécifique qui va à l'encontre de ce que l'on imaginerait mettre en place dans un projet Big Data. Deux raison à ça, on peut supposer que les coûts sont prohibitifs d'une part, et que les gains sont limités d'autre part.

Si je prends la promesse de pouvoir requêter des données non-structurées en SQL, c'est du vent. Personne sur le marché ne propose de telle solution...

Il n'y a pas que les bases orientées Document et BigTable/Column-oriented dans NoSQL ... Il y a aussi les bases orientées graphes et d'autres. Pour ce qui concerne le stockage/requêtage.

La préservation des propriétés ACID est une autre caractéristique d'un système de gestion de données. D'ailleurs il faut détailler chaque lettre, car chaque système conserve au moins l'une des propriétés : Atomicité, Cohérence, Isolation et Durabilité. Certaines solutions NoSQL conserve les propriétés ACID.

Néanmoins la caractéristique la plus souvent recherché dans NoSQL c'est la mise à l'échelle (scalability) et c'est là qu'il est nécessaire de sacrifier la cohérence (on attend pas que tout le système soit synchronisé) et l'isolation (on ne créé pas de fantômes des données lorsqu'il existe une autre transaction active).


En ce qui concerne les solutions de stockage XML, elles ressemblent beaucoup aux bases orientées document. On stocke le document as-is dans une sorte de blob et on stock/index quelques informations extraites pour faciliter le requêtage. Pour avoir travaillé sur des projets de stockage/indexation de gros documents SGML/XML, c'est une très bonne façon de faire.


Pour les performances d'Oracle, c'est comme tout. Ca dépend de ce qu'on en fait. Dans certains cas il sera performant, dans d'autres lents à souhait. Le tout étant de trouver un compromis entre les différents cas d'utilisation, les fonctionnalités recherchées et les bugs. Et sur ce dernier point Oracle en tient une couche.