Après plus d’un an et demi de pause forcée, j’ai pu enfin retourner au NormandyJUG !

Cette soirée était consacrée à un seul et unique thème :  l’accès aux données face à la montée en charge. La session était animée par Julien Dubois qui est entre autre l’auteur de Spring par la pratique. Le sujet ou l’intervenant devaient intéresser puisque nous étions une 50aine.

En partant du principe que la scalabilité d’une application Java est limitée par la base de données, la présentation consistait à évaluer les solutions disponibles. En effet, avec le Cloud Computing, il est “facile” d’ajouter des machines pour assurer la montée en charge d’une application mais le point de contention reste le serveur de base de données. Avant d’aller plus loin, il faut rappeler le théorème de CAP qui indique qu’il est impossible de répondre à ces trois contraintes en même temps :

  • Cohérent (Consistent)
  • Disponible (Available)
  • Tolérant aux pannes réseaux (Partition tolerant)
Quelles sont donc les solutions pour la base de données ne soit plus un point de contention ?

Le serveur de base de données

Les éditeurs de base de données proposent par exemple du partitionning de table sur différents disques. Les lectures seront optimisées mais ça ne résout pas réellement le problème d’écriture dans les faits.
Il est également possible de mettre en place des clusters d’applications pour le serveur de base de données. A priori, la montée en charge est possible. Cependant, le cluster doit positionner les locks réseaux qui malheureusement plombent les performances.

Hibernate et le cache

S’il n’est pas possible d’améliorer à volonté la performance de la base de données, nous pourrions être tenté de ne plus systématiquement faire appel à cette dernière. C’est là qu’en en scène le cache de niveau 2 d’Hibernate.
Il faut connaitre le fonctionnement d’Hibernate pour bien utiliser le cache. Il est également possible de mettre en pratique la loi de Zipf pour une utilisation avancée du cache. Néanmoins, très rapidement, vous allez être confronté à des problèmes de désynchronisation de cache. Il faut alors mettre en place une solution de cache distribué. Les solutions commerciales actuelles fonctionnent plutôt bien. En revanche, il faut en même temps investir dans des outils de monitoring afin de prévenir tout phénomène de split brain. Il faut savoir que ces outils peuvent proposer des systèmes de write-behind afin de lancer des batchs asynchrones d’insertion.

NoSQL

Si malgré tous ces efforts, votre application ne tient toujours pas la charge à cause de l’accès au données, il vous reste encore une solution : NoSQL (pour Not only SQL).
Vous vous rappelez du théorème de CAP ? En général, on veut un système cohérent (contrôle d’intégrité, transaction, etc…). Et c’est ce que fait la plupart des serveurs de base de données. NoSQL se concentre sur les deux autres contraintes au détriment de la cohérence. Enfin, pour être plus précis, NoSQL indique qu’il sera cohérent à un moment donné (mais pas forcément tout le temps).
Il existe de nombreuses solutions NoSQL mais ici nous avons vu Cassandra qui serait le plus performant en écriture. En gros, c’est un cluster de données sans maître où chaque données est répliquée sur au moins 3 noeuds. Lorsque l’on interroge un noeud, il répond tout de suite avec les informations dont il dispose. Puis va chercher à se mettre à jour (d’où le à terme sera cohérent). En écriture, la gestion des conflits se fait via une date cliente. C’est donc le dernier arrivé qui l’emporte ! 😉
Par contre, oubliez schemas, tables, colonnes, SQL et autres ! Vous manipulez un identifiant et des listes de couples clé/valeur. Celà permet de faire des choses assez sympa comme le wide-row. Mais les contre-parties sont :
  • Pas de JPA ni JDBC, il faut tout faire à la main
  • Le modèle est défini dans le métier
Pour information, il existe des drivers pour différents langages. De plus, des projets sont en cours pour faciliter le développement avec par exemple Hibernate OGM (Hibernate) ou Kundera (JPA).
Mais alors quelle solution choisir ?
  • Vous avez besoin de transaction, d’intégrité ? La base de données relationnelle est votre meilleure amie !
  • Les solutions de cache sont vraiment des pistes intéressantes.
  • Vous avez un cloud ? Aujourd’hui, aucune base de données n’est scalable via le cloud. NoSQL pourrait être salvateur.
  • Et si on mixait SGBDR et NoSQL ? :-p