+ Répondre à la discussion Actualité déjà publiée
  1. #1
    Responsable .NET

    Avatar de Hinault Romaric
    Homme Profil pro
    Consultant
    Inscrit en
    janvier 2007
    Messages
    4 489
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Cameroun

    Informations professionnelles :
    Activité : Consultant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : janvier 2007
    Messages : 4 489
    Points : 249 949
    Points
    249 949
    Billets dans le blog
    46

    Par défaut 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 ?

    Que pensez-vous de cette solution ?
    Vous souhaitez participer aux rubriques .NET ? Contactez-moi

    Si déboguer est l’art de corriger les bugs, alors programmer est l’art d’en faire
    Mon blog, Mes articles, Me suivre sur Twitter
    En posant correctement votre problème, on trouve la moitié de la solution

  2. #2
    Membre à l'essai
    Homme Profil pro
    Chercheur en informatique
    Inscrit en
    avril 2010
    Messages
    12
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Chercheur en informatique

    Informations forums :
    Inscription : avril 2010
    Messages : 12
    Points : 13
    Points
    13

    Par défaut

    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…

  3. #3
    Modérateur
    Avatar de Gugelhupf
    Homme Profil pro
    Analyste Programmeur
    Inscrit en
    décembre 2011
    Messages
    1 135
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Analyste Programmeur

    Informations forums :
    Inscription : décembre 2011
    Messages : 1 135
    Points : 2 658
    Points
    2 658
    Billets dans le blog
    12

    Par défaut

    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é...
    N'hésitez pas à consulter la FAQ Java, lire les cours et tutoriels Java, et à poser vos questions sur les forums d'entraide Java

    Mon profil Developpez | Mon profil Linkedin | Mon site : https://gokan-ekinci.appspot.com

  4. #4
    Membre confirmé
    Profil pro
    Inscrit en
    décembre 2006
    Messages
    494
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2006
    Messages : 494
    Points : 484
    Points
    484

    Par défaut

    Citation Envoyé par Gugelhupf Voir le message
    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...

  5. #5
    Modérateur
    Avatar de Gugelhupf
    Homme Profil pro
    Analyste Programmeur
    Inscrit en
    décembre 2011
    Messages
    1 135
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Analyste Programmeur

    Informations forums :
    Inscription : décembre 2011
    Messages : 1 135
    Points : 2 658
    Points
    2 658
    Billets dans le blog
    12

    Par défaut

    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 ?
    N'hésitez pas à consulter la FAQ Java, lire les cours et tutoriels Java, et à poser vos questions sur les forums d'entraide Java

    Mon profil Developpez | Mon profil Linkedin | Mon site : https://gokan-ekinci.appspot.com

  6. #6
    Membre confirmé

    Profil pro
    Inscrit en
    octobre 2003
    Messages
    288
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : octobre 2003
    Messages : 288
    Points : 451
    Points
    451

    Par défaut

    @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

  7. #7
    Membre averti

    Homme Profil pro
    Développeur Web
    Inscrit en
    février 2013
    Messages
    86
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : février 2013
    Messages : 86
    Points : 420
    Points
    420
    Billets dans le blog
    1

    Par défaut

    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.

  8. #8
    Membre éprouvé
    Homme Profil pro
    Inscrit en
    mai 2011
    Messages
    319
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : mai 2011
    Messages : 319
    Points : 1 199
    Points
    1 199

    Par défaut

    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.

  9. #9
    Membre à l'essai
    Homme Profil pro
    Inscrit en
    février 2013
    Messages
    6
    Détails du profil
    Informations personnelles :
    Sexe : Homme

    Informations forums :
    Inscription : février 2013
    Messages : 6
    Points : 22
    Points
    22

    Par défaut

    Citation Envoyé par Gugelhupf Voir le message
    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.

  10. #10
    Membre régulier
    Profil pro
    Inscrit en
    avril 2004
    Messages
    71
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : avril 2004
    Messages : 71
    Points : 110
    Points
    110

    Par défaut

    Citation Envoyé par Gugelhupf Voir le message
    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...

  11. #11
    Rédacteur/Modérateur
    Avatar de Logan Mauzaize
    Homme Profil pro
    Architecte technique
    Inscrit en
    août 2005
    Messages
    2 858
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : Transports

    Informations forums :
    Inscription : août 2005
    Messages : 2 858
    Points : 6 894
    Points
    6 894

    Par défaut

    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.
    Java : Cours et tutoriels - FAQ - Java SE 8 API - Programmation concurrente
    Ceylon : Installation - Concepts de base - Typage - Appels et arguments

    ECM = Exemple(reproduit le problème) Complet (code compilable) Minimal (ne postez pas votre application !)
    Une solution vous convient ? N'oubliez pas le tag
    Signature par pitipoisson

Discussions similaires

  1. transformer requête sql sous langage delphi
    Par wiski08000 dans le forum Bases de données
    Réponses: 6
    Dernier message: 20/11/2014, 14h28
  2. Ql.io le nouveau langage de requêtes Web d’eBay associe SQL, JSON
    Par Hinault Romaric dans le forum Général Conception Web
    Réponses: 0
    Dernier message: 05/12/2011, 16h38
  3. SQL Server : problème de requête sur server lié oracle
    Par stever50 dans le forum Langage SQL
    Réponses: 4
    Dernier message: 26/03/2008, 12h06
  4. interface PL/SQL et langage C sous ORACLE
    Par steff2040 dans le forum PL/SQL
    Réponses: 1
    Dernier message: 03/11/2006, 18h12
  5. [Oracle 9.1] Plantage SQL+ à cause d'une requête
    Par ftrifiro dans le forum Oracle
    Réponses: 8
    Dernier message: 04/10/2005, 15h08

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo