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

Version imprimable

02/08/2019, 13h29
Christian Olivier

2 pièce(s) jointe(s)

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.

Pièce jointe 495130

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.

Pièce jointe 495129

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 ?

:fleche: Que pensez-vous de cette initiative ?

Voir aussi

:fleche: Nous pouvons faire mieux que SQL qui présente quelques lacunes, selon Elvis Pranskevichus
:fleche: Faut-il utiliser les ORM ou continuer d'écrire simplement des requêtes SQL ? Eli Bendersky donne son avis
:fleche: Cours complet pour apprendre les différents types de bases de données et le langage SQL
02/08/2019, 14h16
yahiko

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.
02/08/2019, 14h43
III Jonathan III

Citation:

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 :D
02/08/2019, 15h49
abriotde

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".
02/08/2019, 20h17
yahiko

Citation:

Envoyé par III Jonathan III

Actuellement, si je veux faire une telle chose, je fais une CTE, c'est hyper pratique c'est vrai :D

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
08/08/2019, 22h22
louxorman

Citation:

Envoyé par III Jonathan III

Actuellement, si je veux faire une telle chose, je fais une CTE, c'est hyper pratique c'est vrai :D

Hello, je ne vois pas trop la nouveauté ni la différence avec une vue ?

Citation:

Envoyé par loutox

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

Mon propos était surtout sur cet aspect. Pas le relationnel classique.
https://partiql.org/tutorial.html#querying-nested-data

Ça me semble possible :

Code:

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>

Citation:
Envoyé par skuatamad
Ça me semble possible :
Code:

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:

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.

19/08/2019, 12h48
Waldar

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.