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 : Première Partie, Les Approches NoSQL

NoSQL, Le Cloud Et Java : Première Partie, Les Approches NoSQL

Favoris

Points Clés

  • Comment définir des solutions NoSQL avec Java ?
  • Quel est le compromis des solutions NoSQL avec Java ?
  • Quand et pourquoi devrions-nous utiliser NoSQL ?

Les bases de données non relationnelles ou NoSQL sont de plus en plus présentes dans les solutions dans des domaines plus conservateurs tels que les secteurs financiers et la santé, entre autres. Avec la vulgarisation de cette solution, la question se pose de savoir comment intégrer ces bases avec Java. Cet article vise  à analyser des solutions existantes dans le monde Java et à les classer dans cette intégration avec NoSQL.

Motivation pour NoSQL

Un bon point de départ avant de parler de bases de données non relationnelles est la motivation pour utiliser ce type de base de données. Il est toujours important de souligner que l'objectif des bases de données NoSQL n'est pas de concurrencer les bases de données relationnelles déjà consolidées.

Dans les architectures distribuées, nous devrons toujours faire face au théorème CAP. Dans certains cas, il est plus plausible, par exemple, de renoncer à une plus grande cohérence pour obtenir une disponibilité ou une tolérance aux pannes plus proéminente. Comme il est toujours important de le souligner, selon le livre Fundamentals of Software Architecture: An Engineering Approach, une bonne architecture logicielle est basée sur des compromis. Ainsi, une fois que vous avez opté pour une base de données NoSQL, certaines propriétés déjà intégrées dans la base de données relationnelle sont perdues.

Cet article ne se concentrera pas sur les défis liés à l'utilisation de bases de données distribuées. Cependant, cet excellent livre traite de ce sujet.

La possibilité d'avoir une plus grande flexibilité dans le modèle,comme les stratégies sans schéma ou celles qui adhèrent mieux à  BASE qu’à ACID fait de NoSQL une bonne option. Cependant, être sans schéma ne signifie pas avoir une base de données sans cohérence.

Chaque fournisseur caractérise NoSQL avec des fonctionnalités particulières, ce qui aura beaucoup de sens pour certaines entreprises, comme un moteur de recherche, la cohérence et la disponibilité d'une demande, etc.

Un danger majeur est de relier l'adoption de NoSQL sur la base de termes tels que «évolutivité» et «vitesse». Malheureusement, ce sont des mots qui sont devenus plus un argumentaire de vente qu'une solution technique en soi. Si vous choisissez d'utiliser ce terme, comprenez la raison et les situations dans lesquelles ces groupes fonctionnent mieux que les autres concurrents. Sinon, cela a tendance à être un effet de suivi du troupeau. Le fait est que les bases de données relationnelles sont matures, efficaces et peuvent également gérer des milliards d'enregistrements.

NoSQL n'a pas de normes. Et en général, ils sont regroupés en fonction de la structure dans laquelle il stocke les informations. En termes simples, nous avons les cinq types de bases de données NoSQL les plus populaires.

  • Clés-valeurs : très similaire à une structure de Map
  • Familles en colonnes / colonnes larges : interprétation bidimensionnelle de la base de données en valeurs-clés. A partir d'une clé, il est possible d'avoir un grand nombre de valeurs.
  • Documents : structure très similaire à un fichier JSON ou XML.
  • Graphes : une base qui utilise les structures du graphe de sorte que les requêtes soient basées sur les arêtes, les sommets et les propriétés respectives.
  • Multi-modèle : bien que de nombreux ouvrages ne le considèrent pas comme un type en soi, après tout, il s'agit d'une base de données qui prend en charge plusieurs types présentés ci-dessus.

En plus des types mentionnés ci-dessus, d'autres types émergent, par exemple, les séries chronologiques. La quantité considérable de bases de données et de catégories NoSQL fait d'une solution NoSQL un défi colossal pour le monde Java.

Catégories de solutions

Tout comme les concepts de base de données NoSQL, les solutions du monde Java présentent une diversité transcendante. Les définitions reposent sur deux points:

  • Niveau d'abstraction : en pensant au paradigme de la POO, c'est la capacité de l'API à absorber la complexité de la base de données.
  • Pluralité : il est défini en fonction de l'utilisabilité ou de la fréquence qu'une seule API peut être utile dans plusieurs bases de données.

Niveau d’abstraction de l’API

L'abstraction d'une API permet de savoir dans quelle mesure la solution peut absorber ou masquer le paradigme à l'équipe de développement de la base de données.

Au niveau d'abstraction le plus bas, nous avons le pilote : le pilote a une relation très étroite avec JDBC, cependant il en est de même pour les bases de données NoSQL. Avec ce type d'API, il sera possible de travailler avec la structure de la base de données de manière très proche malgré la variété au sein de la base de données. Il est possible de garantir une plus grande flexibilité en plus d'être une solution plus légère par rapport à Mapper. Sans oublier qu'il devient naturel de travailler avec la programmation orientée données.

Le plus gros problème avec cette solution est que vous devez travailler avec la POO. Dans ce cas, il y a beaucoup de conversions entre la structure de la base de données et l'entité. Ce code boilerplate, en plus de nécessiter plus de temps et plus de code, peut entraîner des bogues.

Quelques exemples de pilotes sont:

D'un autre côté, nous avons une API qui fait une gigantesque abstraction pour les solutions NoSQL : les Mappers. Dans le monde NoSQL, ils ont aussi leurs dérivations similaires à ORM, comme OxM, OGM, et ainsi de suite.

Les mappers facilitent beaucoup le travail et la communication car ils sont responsables de la conversion de la base de données en entité. La réduction standard est une autre caractéristique centrale de cette API car, en plus de réduire le risque de création de bogues, elle augmente la productivité au sein de l'équipe de développeurs. Selon le degré d'abstraction de ce type d'API, il est possible d'oublier qu'il y a une base de données en dessous.

Le mapper a deux stratégies de conversion, soit comme ActiveRecord qui manipule la base de données et assure la responsabilité des opérations sur la base de données dans l'API, gagnant plus de facilité et centralisant les fonctions dans l'API elle-même. Ou les classes Templates qui sont responsables de l'exécution de ce type d'opération.

Cependant, cette abstraction a un prix. Par exemple, l'impédance entre les paradigmes qui se produit également dans le relationnel se produit également dans NoSQL. L'autre point est lié à la génération de métadonnées. Les annotations utilisées dans les entités génèrent des informations pour effectuer la conversion, qui peuvent être exploitées au moment de la construction comme le processeur d'annotation Java ou au moment de l'exécution via Reflection.

Quelques exemples de Mappers dans les solutions NoSQL :

Pluralité

Elle est définie en fonction de l'utilisabilité ou de la fréquence qu'une seule API peut être utile dans les bases de données. Comme les pilotes de communication ont tendance à être spécifiques, cette définition est plus valable pour la couche de mappage.

Par exemple, une API prenant en charge plus de cinq bases de données en aura une plus grande pluralité qu'une seule prenant en charge une seule base de données.

Au niveau le plus bas de la pluralité, il existe des API spécifiques, c'est-à-dire une API pour une base de données unique. Les API spécifiques ont l'avantage le plus significatif de la tendance à disposer de toutes les ressources de la base de données et à toujours se tenir à jour en fonction de la version de la base de données. Cependant, pour chaque nouvelle base de données, il est nécessaire d'avoir une API, ce qui entraîne une courbe d'apprentissage.

Quelques exemples:

D'autre part, les API agnostiques permettent d'utiliser une seule API pour prendre en charge différents types de bases de données. Son avantage est la possibilité de réutiliser l'API dans plusieurs bases de données, ce qui facilite à la fois une courbe d'apprentissage plus petite et un grand pas vers la persistance polyglotte. Cependant, il y a des problèmes avec la synchronisation des mises à jour de la base de données et l'utilisation d'une seule API pour manipuler les ressources particulières de chaque base de données.

JPA a sans aucun doute eu un impact sur les API de persistance du monde Java avec des millions de documentation, de livres, de publications et de conférences. En général, le développeur le connaît déjà. L'utilisation de cette API pour prendre en charge les bases de données NoSQL est une bonne stratégie car elle réduit la courbe d'apprentissage de la part de l'équipe de développement. Cependant, une API axée sur les bases de données relationnelles n'est pas prise en charge et flexible pour les bases de données NoSQL. Ce serait la stratégie classique d'utiliser un couteau dans l'espoir de se comporter comme une fourchette.

Des exemples d'API agnostiques incluent:

Pour conclure, nous avons fait une introduction sur les solutions NoSQL dans le monde Java. Cet article commence par expliquer la raison et la raison de son utilisation ou, surtout, quand ne pas l'utiliser au-delà des classifications de ces cadres. Les solutions pour ce type de base de données se développent de plus en plus au point que certaines plateformes de solutions se concentreront sur le prochain article.

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

Bonjour étranger!

Vous devez créer un compte InfoQ ou cliquez sur pour déposer des commentaires. Mais il y a bien d'autres avantages à s'enregistrer.

Tirez le meilleur d'InfoQ

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

Commentaires de la Communauté

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

BT