Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Chroniqueur Actualités

    Homme Profil pro
    Rédacteur technique
    Inscrit en
    mars 2017
    Messages
    968
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Madagascar

    Informations professionnelles :
    Activité : Rédacteur technique
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : mars 2017
    Messages : 968
    Points : 26 955
    Points
    26 955

    Par défaut PartiQL d’Amazon : un seul langage de requête pour toutes vos données

    PartiQL d’Amazon : un seul langage de requête pour toutes vos données
    Quel que soit le lieu ou le format dans lequel elles sont stockées

    Amazon vient d’annoncer PartiQL, un nouveau langage de requête compatible avec SQL (Structured Query Language). Ce nouveau langage d’interrogation présenté comme « hautement flexible » est censé faciliter la recherche et l’extraction efficace de grandes quantités et variétés de données, quel que soit le lieu ou le format dans lequel elles sont stockées.

    Nom : partiQL-1024x723.png
Affichages : 5320
Taille : 178,8 Ko

    Amazon promet que tant que le moteur de requête utilisé prend en charge PartiQL, vous serez en mesure de traiter (filtrer, assembler, agréger…) de manière intuitive des données structurées à partir de bases de données relationnelles (transactionnelles et analytiques), des données avec ou sans schéma logique défini a priori dans NoSQL et même dans des bases de documents qui autorisent différents attributs pour différentes lignes. Grâce à PartiQL, il serait donc plus facile de fournir un accès cohérent à plusieurs magasins, malgré les différentes hypothèses de schéma des moteurs participants.

    PartiQL fournirait une syntaxe et une sémantique qui permettent l’accès et le traitement complet et précis des données semi-structurées et imbriquées avec un minimum d’extensions dans des formats de données ouverts (tels qu’un lac de données Amazon S3), tout en composant naturellement avec les fonctionnalités standard du SQL. La syntaxe et la sémantique de PartiQL ne sont liées à aucun format de données particulier. Une requête est écrite de manière identique sur les données sous-jacentes dans les formats JSON, Parquet, ORC, CSV, Ion, ou autres. Les requêtes fonctionnent sur un système de type logique complet qui correspond à divers formats sous-jacents. De plus, même si PartiQL dispose d’un nombre d’extensions réduit comparé à SQL, celles-ci sont faciles à comprendre, se prêtent à une implémentation efficace et peuvent être associées aisément.

    Nom : PartiQL-reference-implementation-architecture-1024x706.png
Affichages : 3653
Taille : 100,9 Ko

    PartiQL est déjà utilisé par Amazon S3 Select, Amazon Glacier Select, Amazon Redshift Spectrum, Amazon Quantum Ledger Database (Amazon QLDB) et les systèmes internes Amazon. En outre, Amazon EMR envoie les requêtes PartiQL vers S3 Select. Les serveurs de Couchbase et davantage de services AWS devraient également prendre en charge PartiQL dans les mois à venir.

    PartiQL est entièrement open source sous licence Apache2.0. Amazon indique que n’importe qui peut voir, utiliser, modifier et distribuer le tutoriel, la spécification et une implémentation de référence de son langage de requête « unificateur ». L’implémentation prend en charge l’analyse des requêtes PartiQL par les utilisateurs dans des arbres syntaxiques abstraits que leurs applications peuvent analyser ou traiter et l’interprétation directe des requêtes PartiQL. La firme de Seattle estime que le fait de rendre PartiQL open source devrait faciliter l’analyse, l’intégration et l’adoption de PartiQL par les développeurs. C’est pourquoi elle invite ces derniers à faire part de leurs contributions à l’élargissement de la spécification, à l’élaboration de la technologie et à l’accroissement de son adoption et de son partage au sein de la communauté des utilisateurs. PartiQL nécessite l’installation de Java Runtime (JVM).

    Source : Amazon

    Et vous ?

    Que pensez-vous de cette initiative ?

    Voir aussi

    Nous pouvons faire mieux que SQL qui présente quelques lacunes, selon Elvis Pranskevichus
    Faut-il utiliser les ORM ou continuer d'écrire simplement des requêtes SQL ? Eli Bendersky donne son avis
    Cours complet pour apprendre les différents types de bases de données et le langage SQL
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Rédacteur/Modérateur

    Avatar de yahiko
    Homme Profil pro
    Développeur
    Inscrit en
    juillet 2013
    Messages
    1 178
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Alpes Maritimes (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : juillet 2013
    Messages : 1 178
    Points : 7 466
    Points
    7 466
    Billets dans le blog
    43

    Par défaut

    Pouvoir définir dans la clause FROM un ensemble de données en référence à un autre ensemble de données déclaré avant, c'est simple, élégant... Fallait juste y penser (et l'implémenter).
    Franchement, ça m'a tout l'air de l'innovation qu'attendait le monde de la data depuis des années car le gros défaut du langage SQL était une prise en charge déficiente des structures de données imbriquées.

    Je crois qu'on va assister à un avant et un après PartiSQL.
    Tutoriels et FAQ TypeScript

  3. #3
    Membre régulier
    Homme Profil pro
    Chef de projet BI
    Inscrit en
    août 2013
    Messages
    40
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val d'Oise (Île de France)

    Informations professionnelles :
    Activité : Chef de projet BI

    Informations forums :
    Inscription : août 2013
    Messages : 40
    Points : 77
    Points
    77

    Par défaut

    Pouvoir définir dans la clause FROM un ensemble de données en référence à un autre ensemble de données déclaré avant, c'est simple, élégant... Fallait juste y penser (et l'implémenter).
    Actuellement, si je veux faire une telle chose, je fais une CTE, c'est hyper pratique c'est vrai

  4. #4
    Membre expérimenté
    Homme Profil pro
    Développeur informatique
    Inscrit en
    juillet 2007
    Messages
    723
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : juillet 2007
    Messages : 723
    Points : 1 363
    Points
    1 363

    Par défaut

    Ca me fait penser à OsQuery de Facebook (https://code.fb.com/security/introducing-osquery/).

    Après c'est l'API unifié qu'il manque, pour pouvoir se connecter à la base ou à l'OS dans le même "schéma".
    Tout ce que j'écris est libre de droits (Licence CC0) et je vous incite à faire de même.

  5. #5
    Rédacteur/Modérateur

    Avatar de yahiko
    Homme Profil pro
    Développeur
    Inscrit en
    juillet 2013
    Messages
    1 178
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Alpes Maritimes (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : juillet 2013
    Messages : 1 178
    Points : 7 466
    Points
    7 466
    Billets dans le blog
    43

    Par défaut

    Citation Envoyé par III Jonathan III Voir le message
    Actuellement, si je veux faire une telle chose, je fais une CTE, c'est hyper pratique c'est vrai
    Les CTE ne fonctionnent pas avec des données au format JSON. Mon propos était surtout sur cet aspect. Pas le relationnel classique.
    https://partiql.org/tutorial.html#querying-nested-data
    Tutoriels et FAQ TypeScript

  6. #6
    Nouveau membre du Club
    Homme Profil pro
    Consultant informatique
    Inscrit en
    septembre 2014
    Messages
    15
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : Tourisme - Loisirs

    Informations forums :
    Inscription : septembre 2014
    Messages : 15
    Points : 27
    Points
    27

    Par défaut

    Citation Envoyé par III Jonathan III Voir le message
    Actuellement, si je veux faire une telle chose, je fais une CTE, c'est hyper pratique c'est vrai
    Hello, je ne vois pas trop la nouveauté ni la différence avec une vue ?

  7. #7
    Expert confirmé
    Profil pro
    Inscrit en
    août 2008
    Messages
    2 807
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : août 2008
    Messages : 2 807
    Points : 5 504
    Points
    5 504

    Par défaut

    Citation Envoyé par loutox Voir le message
    Hello, je ne vois pas trop la nouveauté ni la différence avec une vue ?
    Vu que les CTE existent depuis plus de 15 ans, c'est sûr que ce n'est pas une grande nouveauté.
    Une vue c'est pour stocker du code SQL en base, une vue est donc disponible pour plusieurs requêtes.
    Une CTE c'est plus comme une sous requête (inline view) mais ça permet de mieux structurer le code SQL pour les requêtes complexes et de réutiliser un bout de SQL au sein de la requête contrairement au inline view classique.
    Les CTE peuvent surtout être récursives.

    Citation Envoyé par yahiko Voir le message
    Mon propos était surtout sur cet aspect. Pas le relationnel classique.
    https://partiql.org/tutorial.html#querying-nested-data
    Ça me semble possible :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    68
    69
    70
    71
    SQL> @test_json.sql
    SQL> set linesize 500
    SQL> column EMPLOYEENAME format A20
    SQL> column PROJECTNAME  format A30
    SQL> --
    SQL> drop table employees;
     
    Table dropped.
     
    SQL> --
    SQL> create table employees (employeesNest CLOB
      2  	 CONSTRAINT ensure_json CHECK (employeesNest IS JSON));
     
    Table created.
     
    SQL> --
    SQL> insert into employees (employeesNest)
      2  values ('{
      3  	       "id": 3,
      4  	       "name": "Bob Smith",
      5  	       "title": null,
      6  	       "projects": [ { "name": "AWS Redshift Spectrum querying" },
      7  			     { "name": "AWS Redshift security" },
      8  			     { "name": "AWS Aurora security" }
      9  			   ]
     10  	       }');
     
    1 row created.
     
    SQL> --
    SQL> insert into employees (employeesNest)
      2  values ('{
      3  		   "id": 4,
      4  		   "name": "Susan Smith",
      5  		   "title": "Dev Mgr",
      6  		   "projects": []
      7  	       }');
     
    1 row created.
     
    SQL> --
    SQL> insert into employees (employeesNest)
      2  values ('{
      3  		   "id": 6,
      4  		   "name": "Jane Smith",
      5  		   "title": "Software Eng 2",
      6  		   "projects": [ { "name": "AWS Redshift security" } ]
      7  	       }');
     
    1 row created.
     
    SQL> --
    SQL> commit;
     
    Commit complete.
     
    SQL> --
    SQL> SELECT json_value(e.employeesNest, '$.name') as employeename
      2  	  , p.projectname
      3    FROM employees e
      4  	  , json_table(e.employeesNest, '$.projects[*]'
      5  	      COLUMNS (projectname VARCHAR2(100) PATH '$.name')) AS p
      6   where p.projectname like '%security%';
     
    EMPLOYEENAME	     PROJECTNAME
    -------------------- ------------------------------
    Bob Smith	         AWS Redshift security
    Bob Smith	         AWS Aurora security
    Jane Smith	         AWS Redshift security
     
    SQL>

  8. #8
    Rédacteur/Modérateur

    Avatar de yahiko
    Homme Profil pro
    Développeur
    Inscrit en
    juillet 2013
    Messages
    1 178
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Alpes Maritimes (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : juillet 2013
    Messages : 1 178
    Points : 7 466
    Points
    7 466
    Billets dans le blog
    43

    Par défaut

    Citation Envoyé par skuatamad Voir le message
    Ça me semble possible :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    SQL> @test_json.sql
    SQL> set linesize 500
    SQL> column EMPLOYEENAME format A20
    SQL> column PROJECTNAME  format A30
    SQL> --
    SQL> drop table employees;
     
    Table dropped.
     
    SQL> --
    SQL> create table employees (employeesNest CLOB
      2  	 CONSTRAINT ensure_json CHECK (employeesNest IS JSON));
     
    Table created.
     
    SQL> --
    SQL> insert into employees (employeesNest)
      2  values ('{
      3  	       "id": 3,
      4  	       "name": "Bob Smith",
      5  	       "title": null,
      6  	       "projects": [ { "name": "AWS Redshift Spectrum querying" },
      7  			     { "name": "AWS Redshift security" },
      8  			     { "name": "AWS Aurora security" }
      9  			   ]
     10  	       }');
     
    1 row created.
     
    SQL> --
    SQL> insert into employees (employeesNest)
      2  values ('{
      3  		   "id": 4,
      4  		   "name": "Susan Smith",
      5  		   "title": "Dev Mgr",
      6  		   "projects": []
      7  	       }');
     
    1 row created.
     
    SQL> --
    SQL> insert into employees (employeesNest)
      2  values ('{
      3  		   "id": 6,
      4  		   "name": "Jane Smith",
      5  		   "title": "Software Eng 2",
      6  		   "projects": [ { "name": "AWS Redshift security" } ]
      7  	       }');
     
    1 row created.
     
    SQL> --
    SQL> commit;
     
    Commit complete.
     
    SQL> --
    SQL> SELECT json_value(e.employeesNest, '$.name') as employeename
      2  	  , p.projectname
      3    FROM employees e
      4  	  , json_table(e.employeesNest, '$.projects[*]'
      5  	      COLUMNS (projectname VARCHAR2(100) PATH '$.name')) AS p
      6   where p.projectname like '%security%';
     
    SQL>
    Le SQL est un langage récursif et il est donc potentiellement possible de tout faire. Maintenant, la syntaxe de partiSQL me semble plus homogène et élégante, pas d'appel à json_table et json_value qui ne font pas parti de la syntaxe SQL, ce sont des fonctions additionnelles fournies selon le SGBDR.
    Juste
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    SELECT e.name AS employeeName, 
           p.name AS projectName
    FROM hr.employeesNest AS e, 
         e.projects AS p
    WHERE p.name LIKE '%security%'
    Il y a d'autres aspects intéressants comme la capacité de gérer les "champs" non homogènes du point de vue du typage et d'adresser des jeux de données sans schéma.

    Il faudrait sans doute un article plus étoffé en français pour mieux faire comprendre l'utilité de ce langage par rapport au SQL qui néanmoins, avec quelques contorsions peut effectivement tout réaliser. Là n'est pas le sujet. C'est le plus simplement qui est en jeu ici.
    Tutoriels et FAQ TypeScript

  9. #9
    Modérateur

    Homme Profil pro
    Consultant Teradata
    Inscrit en
    septembre 2008
    Messages
    7 858
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Consultant Teradata

    Informations forums :
    Inscription : septembre 2008
    Messages : 7 858
    Points : 15 625
    Points
    15 625

    Par défaut

    PartiQL ajoute de l'élégance effectivement dans les requêtes sur du JSON, mais de prime abord ça ressemble à un parser JSON inspiré de SQL qui ne traite qu'un document à la fois.

    Ça va fonctionner avec une architecture micro-service où les lignes sont traitées unitairement - ce qui correspond bien à la philosophe de développement sur AWS - mais probablement pas sur quelque chose de plus ensembliste.

    D'ailleurs le support à la norme c'est SQL-92 ce qui n'augure que très peu de fonctionnalités ainsi que quelques sacrifices sur la sémantique, comme ces jointures avec JOIN sans ON.

    Edit : je dis JSON il faut comprendre "semi-structuré". J'ai bien lu dans les spécifications que ça supporte d'autres types de données.

Discussions similaires

  1. Oracle fait de SQL un langage de requêtes pour Hadoop et NoSQL
    Par Hinault Romaric dans le forum Oracle
    Réponses: 10
    Dernier message: 30/07/2014, 14h16
  2. Réponses: 3
    Dernier message: 13/01/2012, 16h38
  3. Requête pour filtrer des données
    Par altecad dans le forum Requêtes
    Réponses: 2
    Dernier message: 03/02/2008, 14h16
  4. rejoindre deux requêtes pour afficher des données
    Par schats dans le forum PHP & MySQL
    Réponses: 8
    Dernier message: 26/12/2007, 14h19
  5. Réponses: 8
    Dernier message: 17/04/2007, 12h13

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