BT

Diffuser les Connaissances et l'Innovation dans le Développement Logiciel d'Entreprise

Contribuez

Sujets

Sélectionner votre région

Accueil InfoQ Articles NoSQL, Le Cloud Et Java : Troisième Partie, Les Standards

NoSQL, Le Cloud Et Java : Troisième Partie, Les Standards

Favoris

Points Clés

  • Les standards NoSQL

  • Les difficultés pour définir ses standards

  • Pourquoi ne pas utiliser JPA pour les bases de données NoSQL ?

Le nombre de données bases NoSQL augmente. Il existe déjà plus de deux cents solutions réparties en plusieurs catégories, et ce nombre a augmenté au fil du temps au-delà de la popularité. Une solution serait de créer une API standard pour simplifier l'utilisation de ces bases de données. Après tout, les comportements sont des opérations de base, mais quelle est la raison de ne pas mettre en œuvre cette exigence ? Cet article a pour but de discuter et de mettre à jour un point de ces travaux liés aux standards des bases de données NoSQL.

Dans Info World, l'article «L'heure des normes NoSQL est maintenant» mentionne que le point critique pour les base de données associées est que les base de données relationnelles ont des normes. Ce modèle dans les bases de données relationnelles permet, en plus d'éviter le verrouillage du fournisseur, de créer des outils, des API dans les langages de programmation, entre autres dispositifs autour de SQL. S'il existait une norme NoSQL, on s'attendrait à ce que le comportement se produise de la même manière.

«The key advantage of the RDBMS, rather, is standardization. The history of relational databases has proven that even a poor job of standardization can create a market better than none at all. Indeed, standardization is the key obstacle to the takeover by the new breed of databases.»
- Andrew C. Oliver, Info World.

Cependant, cet article date de 2012. Il n'y a pas eu beaucoup de succès - malgré, un grand nombre de tentatives. L'une des raisons, comme déjà évoquée, réside dans la grande diversité des types et le nombre d'éditeurs rendant difficile la synchronisation de la définition des comportements attendus.

Une alternative serait d'apporter cette abstraction à l'API au niveau du logiciel au lieu de la couche de bases de données.

Une solution de niveau API a été essayée dans le monde Java au sein de la plate-forme jusqu'alors appelée Java EE (actuellement connue sous le nom de Jakarta EE). Dans sa stratégie, il se diviserait entre JPA et JDBC, dont il y aurait une API pour chaque API existante en plus des ressources spécifiques pour une base de données particulière.

Dans la philosophie de la division et de la conquête, les meilleures initiatives existantes pour le processus de normalisation sont un seul type d'API. Les meilleurs résultats viennent, en particulier dans l'API graphique. Dans ce travail, deux projets peuvent être cités.

OpenCypher se concentre sur la création d'une API standard pour communiquer avec des bases de données de type graphes avec Graph Query Language, GQL, ISO pour les graphes. Il existe actuellement environ 21 bases de donnes de type graphes prenant en charge GQL. Il est basé sur Neo4J, qui est l'une des bases de données les plus connues. Donc, si le développeur a de l'expérience avec Neo4J, il sera familier avec ce concept.

MATCH
 (p:Product)-[:CATEGORY]->(l:ProductCategory)-[:PARENT*0..]->
 (:ProductCategory {name:"Dairy Products"})
RETURN p.name

Une autre solution est le projet Apache Tinkerpop, tout comme OpenCypher, qui est open source. Ce projet est une API dont l'objectif est d'être un JDBC pour l'API graph. Il propose une API pour plusieurs langages, dont Java, qui possède un langage nommé gremlin via cette API. Actuellement, plus de trente bases de données de type API sont prises en charge.

//What are the name of Gremlin’s friend's friends?
g.().has("name", "gremlin")
    .out("knows").out("knows")
    .values("name")
//management chain going from Gremlin fo the CEO
g.().has("name", "gremlin")
    .repeat(in("manages"))
    .until((has(title","ceo"))
    .path().by("name")

Une autre option pourrait être Eclipse JNoSQL, qui suivrait une ligne similaire au projet qu'Oracle aurait aimé livrer dans Java EE 9. Ainsi, deux couches d'API seraient composées d’une API pour le mapping et d’une API pour la communication avec des extensions pour prendre en charge des comportements de base de données particuliers.

Comme dans la proposition d'Oracle, dans les deux couches, il existe une API pour chaque type. Dans l'API Graph, au lieu de créer une nouvelle API, l'API Apache Tinkerpop est utilisée.

Eclipse JNoSQL est devenu la base de la création de la première spécification pour le monde de Jakarta sous le nom de Jakarta NoSQL.

Pourquoi ne pas utiliser JPA pour les bases de données NoSQL?

Il y a une discussion massive à ce sujet. En résumé, cela n'a pas de sens d'utiliser une API pour le relationnel et de la mettre sur NoSQL.

L'intention est excellente. Une fois que le développeur connaît le JPA, cette personne peut utiliser la même API pour travailler sur NoSQL, ce qui réduit la complexité et la courbe d'apprentissage.

En effet, dans l'histoire de Java, nous avons ce type d'API pour couvrir une variété de bases de données : Java Data Object, JDO.

Malheureusement, ce projet n'est pas devenu populaire.

Dans Jakarta NoSQL, il y a ceci au moins une fois par mois:

En résumé, nous pouvons utiliser les commentaires d'Oliver:

Nous avons également analysé une autre solution à ce sujet, telle que :

Les deux ne sont pas allés plus loin car NoSQL a une différence considérable. En outre, il y a de nombreux détails dans le monde NoSQL, tels que MongoDB ayant des transactions; cependant, nous devons réfléchir à deux fois en raison du problème de performances. De plus, il y a Cassandra, qui ne fournit pas du tout de transactions, et ainsi de suite.

En résumé

Lorsque nous avons une API de type bateau et que nous la déplaçons dans un avion juste parce que les deux sont des moyens de transport cela a tendance à être une mauvaise idée.

Les avantages de créer et d'utiliser des normes dans le monde NoSQL sont innombrables, par exemple, une courbe d'apprentissage plus courte, la facilité de création d'outils tels que des tests unitaires, la facilité d'échange les bases de données, etc. Cependant, il y a plusieurs défis en plus de l'incroyable diversité car les changements sont constants. Avec cela, le travail avec les normes NoSQL s'accroît avec plusieurs projets. Cependant, aucun des projets n’est fini.

 

A propos de l'auteur

Otávio Santana est un ingénieur logiciel avec une vaste expérience dans le développement open source, avec plusieurs contributions à JBoss Weld, Hibernate, Apache Commons et à d'autres projets. Axé sur le développement multilingue et les applications haute performance, Otávio a travaillé sur de grands projets dans les domaines de la finance, du gouvernement, des médias sociaux et du commerce électronique. Membre du comité exécutif du JCP et de plusieurs groupes d'experts JSR, il est également un champion Java et a reçu le JCP Outstanding Award et le Duke's Choice Award.

 

Evaluer cet article

Pertinence
Style

Contenu Éducatif

BT