Spring et le NoSQL

Introduction

Historiquement, les grandes entreprises du Web, à cause d’un très grand nombre d’utilisateurs ou de très gros volumes de données, ont eu besoin, à un moment donné, de bases de données de plus en plus vastes. À cette époque, la mise à l’échelle se faisait généralement par l’augmentation de la capacité de la machine hébergeant la base. En effet, dans une base de données relationnelle SQL, les relations sont portées par des clés primaires qui sont référencées par des clés secondaires avec l’aide d’index. Les requêtes sur les données se font par jointures et au bout d’un moment s’il y a trop de jointures, cela devient très vite complexe.

Les modèles de données

Il existe quatre modèles principaux :

Principes des bases de données

Consistance des données

La consistance vise à gérer les modifications concurrentes. Dans une base de données, la consistance est souvent assurée par la notion de transaction. Si on découpe un ensemble d’informations en plusieurs pseudo-tables ou documents, on veut que, si une des modifications échoue, toutes les modifications soient annulées. On veut une mise à jour atomique. La transaction « unitaire » est devenue, après de longues années, acceptable et acceptée.

Pour les bases orientées documents, il faut garder la transaction au niveau de l’agrégat. La mise à jour d’un agrégat peut être atomique, mais...

Pourquoi et quand utiliser une base NoSQL

La base NoSQL trouve sa place là où il y a naturellement des agrégats et là où il y a de grands volumes de données. Pour les grandes bases de données très volumineuses, on a recours au NoSQL, car il n’y a pas de base SQL suffisamment grande.

On peut se baser sur les tableaux suivants pour se faire une idée des bases de données et de leurs usages :

Requêtes simples et rapides :

Requêtes complexes :

Nous savons que le succès des bases SQL vient aussi de leur aspect intégrateur. Une base de données SQL est idéale quand il faut partager des données qui sont accédées par plusieurs applications ou par plusieurs nœuds d’une application clusterisée. La base SQL est très bien pour partager des états entre applications monolithiques. À...

Problèmes liés à l’utilisation des bases NoSQL

L’utilisation des bases de données NoSQL induit de nouvelles décisions, des changements d’organisation. Les DBA traditionnels pour les grandes bases de données SQL comme Oracle, Sybase ou autres se retrouvent face à la relative immaturité des solutions NoSQL. Le manque d’outils, d’expérience, et de savoir dans les équipes ne rassure pas.

Les décisions sont prises dans les équipes de développement qui doivent alors gérer elles-mêmes le suivi et les inconsistances en production. Dans les projets stratégiques, on a souvent recours au NoSQL pour avoir des TTM (Time To Market ou temps de mise à disposition sur le marché) très courts. Nous pouvons profiter de la facilité de développement et gérer beaucoup de données. La tendance actuelle pour les nouveaux projets est de n’utiliser les bases SQL que sur les projets non vitaux et non stratégiques à rythme de releasing lent.

Ces bases de données NoSQL peuvent être persistées sur disques ou être juste en mémoire dans...

Spring et le NoSQL

Comme pour les autres bases SQL, Spring rend plus simple l’utilisation des bases NoSQL à travers la mise à disposition d’API.

Il existe une multitude de bases NoSQL. Voici les plus populaires :

Cache de données

Les caches répondent à la problématique de garder des données en mémoire pour les rendre disponibles sans rechargement. Les caches de données sont proches des bases NoSQL clé/valeur. Spring permet assez simplement d’avoir un cache simple et un cache plus élaboré basé sur GenFire.

Cacher des données avec GemFire

GemFire est la data grid (grille de données) en mémoire basée sur Apache Geode. Elle permet de stabiliser nos services de données à la demande pour répondre aux exigences de performance des applications temps réel. Elle accompagne la montée en charge cohérente et homogène sur plusieurs data centers, offre des données temps réel à des millions d’utilisateurs, a une architecture orientée événements, et elle est idéale pour les microservices. Ses caractéristiques principales sont sa latence faible et prévisible, sa scalabilité et son élasticité, la notification d’événements en temps réel, la haute disponibilité et la continuité de l’activité. Elle est durable et fonctionne sur le cloud.

Pour l’exemple qui suit, nous utilisons la configuration embarquée (Embedded) qui est la plus simple pour faire un cache distribué haute disponibilité.

Exemple d’utilisation

Classe Application :

@ClientCacheApplication(name = "CachingGemFireApplication", 
logLevel = "error")  
@EnableGemfireCaching  
@SuppressWarnings("unused")  
public class Application {  
  private static final Logger logger= LoggerFactory.getLogger 
(Application.class);...

GemFire en tant que base de données NoSQL

La classe ApplicationEnableGemfireRepositories :

@ClientCacheApplication(name = "DataGemFireApplication", logLevel = 
"error") 
@EnableGemfireRepositories  
public class ApplicationEnableGemfireRepositories {  
  public static void main(String[] args) throws IOException {  
    SpringApplication.run(ApplicationEnableGemfireRepositories.class, 
args); 
  }  
 
  @Bean("Department")  
  public ClientRegionFactoryBean<String, Department>  
      departmentRegion(GemFireCache gemfireCache) {  
    ClientRegionFactoryBean<String, Department> departmentRegion =  
      new ClientRegionFactoryBean<>();  
    departmentRegion.setCache(gemfireCache);  
    departmentRegion.setClose(false);  
    departmentRegion.setShortcut(ClientRegionShortcut.LOCAL);  
    return departmentRegion;  
  }  
 
  @Bean  
  ApplicationRunner run(DepartmentRepository departmentRepository) { 
    return args -> {  
      Department ain = new Department("01","AIN");...

Redis en autonome

@SpringBootApplication  
@EnableCaching  
public class Ex3CacheRedis implements CommandLineRunner {  
 
  private static final Logger LOGGER = 
LoggerFactory.getLogger(Ex3CacheRedis.class);  
 
  public static void main(String[] args) {  
    SpringApplication.run(Ex3CacheRedis.class, args);  
  }  
 
  @Autowired  
  private DepartementRepository departementRepository;  
 
  @Override  
  public void run(String... args) throws Exception {  
    departementRepository.cacheEvict();  
 
    LOGGER.info("27->{}", departementRepository.getByCode("27")); 
    LOGGER.info("44->{}", departementRepository.getByCode("44")); 
    LOGGER.info("51->{}", departementRepository.getByCode("51")); 
 
    LOGGER.info("27->{}", departementRepository.getByCode("27")); 
    LOGGER.info("44->{}", departementRepository.getByCode("44")); 
    LOGGER.info("51->{}", departementRepository.getByCode("51")); 
 
    departementRepository.patch("27","__EURE__");  
    LOGGER.info("27->{}", departementRepository.getByCode("27"));  
 
  }  
} 

MongoDB

MongoDB est un système de base de données orienté documents, sous licence AGPL, avec les données réparties sur plusieurs serveurs. Il n’y a pas de schéma de données. Les pilotes sont sous Apache et la documentation sous licence Creative Common.

Créée en 2007, il a fallu attendre la version 1.4 de 2010 pour pouvoir l’utiliser en production. Les données sont au format BSON (JSON binaire), enregistrées sous forme de collections d’objets JSON à niveaux multiples. Ces enregistrements dans la base peuvent être polymorphiques avec comme contrainte de partager un champ-clé principal nommé "id". Cet index unique permet d’identifier un document (enregistrement dans la base). Les requêtes se font en JavaScript. 

La base de données dispose d’un interpréteur de commande en mode texte directement accessible via le binaire Mongo. Des outils graphiques libres existent, comme par exemple nosqlbooster4mongo.

 
@SpringBootApplication  
public class Ex1MongoDB implements CommandLineRunner {  
 
  private static final Logger LOGGER = LoggerFactory.getLogger(Ex1MongoDB.class);  
 
  @Autowired  
  private CapitaleRepository repository;  
 
  public static void main(String[] args) {  
    SpringApplication.run(Ex1MongoDB.class, args);  
  }  
 
  @Override  
  public void run(String... args) throws Exception {  
    repository.deleteAll();  
    repository.save(new Capitale("Afghanistan", "Kaboul", "Asie"));  
    repository.save(new Capitale("Afrique du Sud"...