Au cours des trois dernières décennies, les bases de données et le langage de requête structuré (SQL) étaient presque synonymes. Quiconque souhaitait récupérer des informations dans une base de données devait apprendre SQL. Quiconque souhaitait s’occuper d’une base de données ou occuper un poste d’administrateur de base de données devait maîtriser ses nuances.
Le langage lui-même est un retour en arrière, une opportunité de penser et de coder comme le faisaient les utilisateurs du mainframe. Alors que le reste du monde a adopté les lettres minuscules, les utilisateurs de SQL ont continué à taper des mots comme SELECT ou WHERE. Même aujourd’hui, peu semblent se soucier du fait que certains utilisateurs de Tik Tok se moquent d’eux ou demandent pourquoi ils crient. Si ALL CAPS était assez bon pour les jockeys de cartes perforées portant des cravates et des chemises à manches courtes, eh bien, c’est toujours assez bon pour le télétravailleur d’aujourd’hui portant des pyjamas en peluche.
Mais l’emprise de SQL sur la récupération des données est en train de glisser. De nouvelles bases de données voient le jour, et certaines parlent des langages entièrement nouveaux. Ce n’est pas que SQL devient moins populaire. Au contraire, plus de SQL est écrit que jamais. C’est juste que le monde du stockage de données explose encore plus vite, et une partie de cette croissance stimule une envie d’expérimenter et de se diversifier.
Cet article présente huit nouvelles approches de récupération de données. Dans certains cas, les innovations sont simplement cosmétiques. Les développeurs ont mis à jour la syntaxe de SQL pour la rendre un peu plus claire et plus facile à lire, il est donc moins difficile de changer de vitesse entre l’écriture de code pour le navigateur et la récupération de données. Les créateurs de ces outils soulignent que la structure sous-jacente est essentiellement la même que SQL. Il sera toujours facile à apprendre. Ne vous inquiétez pas.
D’autres outils nous invitent à penser d’une manière complètement différente. Les bases de données qui stockent leurs bits dans des graphiques ou dans une série chronologique offrent de nouveaux paradigmes sur la façon dont les programmeurs spécifient ce qu’ils veulent trouver.
Toutes ces options ne seront pas meilleures que SQL pour ce que vous devez faire. Tous ne saisiront pas les possibilités que vous recherchez. Mais tous offrent une chance de penser différemment à cette mer d’octets sur un serveur, attendant juste que vous trouviez un moyen d’épeler ce dont vous avez besoin.
GraphQL
Le nom de GraphQL est un peu déroutant car ce n’est pas vraiment un langage conçu pour exploiter toutes les possibilités des bases de données de graphes. Cela ressemble plus à un raccourci élégant pour interroger des données stockées dans un format imbriqué similaire à JSON. La requête est juste une description rapide de ce à quoi les résultats devraient ressembler. Le back-end examine cette liste de champs, qui peut comporter des restrictions sur les valeurs, et essaie de trouver les résultats qui correspondent. Où SQL spécifie comment la base de données doit remplir une requête, les utilisateurs de GraphQL fournissent simplement une liste de champs. Certains l’appellent “requête par exemple”.
Le langage est une correspondance naturelle pour certaines bases de données JSON, mais GraphQL devient également de plus en plus populaire pour la recherche de bases de données relationnelles avec un schéma tabulaire. Les back-ends intelligents peuvent traduire les requêtes imbriquées en un modèle de JOIN qui correspond au schéma.
Le langage d’origine a commencé comme un projet interne chez Facebook, mais après sa sortie en tant que projet open source indépendant, d’autres ont commencé à développer des back-ends GraphQL. Il existe maintenant des versions écrites dans toutes les langues principales et de nombreuses langues expérimentales modernes également.
PRQL
Si vous considérez naturellement le logiciel comme un pipeline ou un langage d’assemblage, alors vous aimerez peut-être PRQL, qui signifie Pipelined Relational Query Language (prononcé “Prequel”). Les requêtes dans ce langage sont structurées comme une chaîne de petites commandes. Ensemble, les commandes produisent un résultat avec uniquement les données souhaitées.
Semblable à de nombreux langages de programmation modernes, le modèle mental d’une requête adopte une approche fonctionnelle. Des fonctionnalités simples comme les variables réduisent les répétitions et simplifient le flux. Les résultats d’une ligne sont introduits dans la ligne suivante dans une longue chaîne. Si vous souhaitez supprimer une étape, vous pouvez souvent simplement commenter cette ligne et le reste du pipeline fonctionnera toujours.
Le code de PRQL est écrit en Rust en tant que transpileur pour convertir PRQL en SQL. La structure de base est censée être extensible, vous pouvez donc ajouter plus d’abstractions en fonction de votre cas d’utilisation. Cette facilité d’expérimentation assure une évolution rapide du langage.
WebAssembly
De nombreux développeurs considèrent WebAssembly (en abrégé Wasm) comme un outil permettant de créer des applications rapides qui s’exécutent dans des navigateurs Web. Lorsque Redpanda a commencé à créer un outil de streaming de données pour remplacer Kafka, ils voulaient ajouter un mécanisme non seulement pour fournir les données, mais aussi pour les transformer occasionnellement en cours de route. WebAssembly était leur choix.
Redpanda agit comme un grand livre en créant un flux de données immuable et ordonné. Les événements sont ajoutés et les programmeurs peuvent puiser dans le flux à tout moment dans le passé. La plupart commenceront avec des événements nouvellement créés, mais certains peuvent commencer dans le passé pour créer des agrégations historiques.
WebAssembly, bien sûr, est beaucoup plus performant et de bas niveau que même les procédures stockées qui font partie de certaines bases de données. Tous les développeurs ne veulent pas écrire du code au niveau de l’octet. Mais l’option ouvre le flux de données pour élaborer des transformations qui vont bien au-delà de ce qui est possible avec SQL.
GQL
Graph Query Language, ou GQL, est une norme proposée qui fusionne des langages déclaratifs similaires comme Cypher, PGQL et GSQL. Les développeurs créent des requêtes en spécifiant un modèle particulier pour un ensemble de nœuds, puis la base de données est chargée de trouver des correspondances. GQL fonctionne avec des graphes de propriétés plus complexes qui permettent à des paires de nœuds de partager plusieurs connexions différentes.
La norme est en cours de développement actif. Actuellement, les meilleures implémentations sont des outils de recherche qui ne sont pas destinés à un déploiement à long terme.
Diablotin
L’un des langages d’origine pour rechercher un graphe, Gremlin demande un ensemble d’étapes pour rechercher à travers les connexions entre les nœuds. Certains l’appellent un langage “basé sur les chemins” ou “parcours de graphes”. Chaque requête est construite sur des étapes, et chaque étape peut impliquer soit le mappage du nœud actuel, le filtrage d’une liste ou la tabulation du résultat d’une manière ou d’une autre.
La langue n’est souvent qu’un point de départ. Certains, par exemple, étendent Gremlin en y incorporant un interpréteur Python afin que les requêtes puissent inclure du code Python. D’autres intègrent Gremlin dans un langage de programmation standard comme Java afin que les programmeurs puissent exploiter la puissance de Gremlin à l’intérieur de ce langage.
Gremlin a d’abord été conçu pour le projet TinkerPop d’Apache et a été adopté par les principales bases de données de graphes transactionnels comme Neptune d’Amazon et les frameworks de traitement de graphes utilisant Apache Spark ou Hadoop.
N1QL
Au fil des ans, Couchbase a recherché la meilleure façon d’interroger des documents généraux. Au début, la requête était écrite comme une fonction JavaScript qui était transmise à la base de données pour exécution. C’était une belle solution générale qui prenait parfois une éternité à générer un résultat, mais elle obligeait les programmeurs à penser un peu différemment.
N1QL (prononcé « nickel ») est conçu pour faciliter le travail des natifs SQL avec les objets JSON qui pourraient être stockés dans Couchbase. Une requête de base comporte plusieurs sections spécifiées par les mots clés SELECT, FROM et WHERE, tout comme SQL. Les détails de la spécification du chemin dans la structure de données d’où proviendront les données sont ajustés et adaptés au monde imbriqué des objets JSON.
Pour encourager l’expérimentation, N1QL propose un atelier de requêtes avec une interface visuelle pour tester et affiner les requêtes. Couchbase propose également une option de recherche générique en texte intégral qui s’exécute indépendamment pour les requêtes recherchant des mots de texte au lieu de données structurées.
Malloy
Le problème avec SQL, selon les créateurs de Malloy, réside dans les détails syntaxiques. Exprimer même la requête la plus simple prend du temps car le langage est verbeux et plein de pièges de performance cachés. Ainsi, ils ont créé un langage de programmation moderne avec des valeurs par défaut naturelles et une syntaxe plus simple qui peut être compilée en SQL, de sorte que personne n’ait besoin de moderniser une base de données de stock.
Le résultat est une syntaxe qui ressemble à un GraphQL plus puissant. Une requête ressemble plus à un modèle ou à une vision du résultat, y compris les restrictions, les correspondances ou les valeurs par défaut. Malloy gère certaines optimisations en arrière-plan. Des JOIN plus intelligents, par exemple, peuvent être générés automatiquement pour éviter les pièges de performance des gouffres et des ventilateurs. Les sous-requêtes peuvent être agrégées pour gagner du temps. Des indices sont également ajoutés au besoin. En conséquence, écrire des requêtes ressemble plus à écrire du code moderne, la ponctuation servant à garder la structure succincte.
Le noyau open source de Malloy est construit en TypeScript pour être inclus dans le code Node.js. Un plugin VS Code simplifie le développement.
Base
La plupart des langages de requête sont directement liés à une base de données particulière. Basis construit davantage un pipeline qui peut puiser dans une variété de sources avant de les filtrer avec un mélange de SQL et de Python. À la fin du pipeline se trouvent des exportateurs qui fournissent les données à une variété d’options standard, qui vont du code d’exécution aux algorithmes d’IA en passant par les graphiques et les tableaux de bord.
Les développeurs construisent déjà des pipelines comme celui-ci dans leur propre code, et de nombreux projets dépendent de structures similaires. Basis offre une option prédéfinie qui peut être personnalisée de manière plus élaborée. Les entrées vont des requêtes de base de données standard aux robinets d’API en passant par le code Python personnalisé. Les transformateurs ne sont pas limités aux clauses WHERE de base de SQL, car vous pouvez écrire du code Python qui fait plus que filtrer lorsque les données circulent dans le pipeline.
Basis n’est qu’un exemple des nouveaux outils de pipeline de données qui ouvrent le processus d’interrogation pour puiser dans plusieurs sources, filtrer avec plusieurs langues et fournir les données sous plusieurs formes. C’est une vision de pouvoir prendre des données de presque n’importe quelle source et de les fournir à presque n’importe quel consommateur.
Copyright © 2022 IDG Communications, Inc.