English version available

Un petit mémo (très technique) utile si vous avez Spring sur votre projet.

C’est dans le cas assez spécifique où l’on souhaite récupérer / incrémenter la valeur d’une séquence et que le Sequence Generator d’Hibernate ne répond pas à vos besoins (voir la remarque).

Plutôt que de passer par une DAO avec du code Hibernate (ou pire JDBC), Spring peut le faire pour vous en 2 minutes…

• Pour cela, il suffit de déclarer un nouveau bean dans la configuration Spring de votre projet:

         <bean id='mySequenceIncrementer' class='org.springframework.jdbc.support.incrementer.H2SequenceMaxValueIncrementer'>
  	       <property name='dataSource' ref='<Nom de votre datasource>' />
  	       <property name='incrementerName' value='<Nom de votre sequence>' />
         </bean>
  

  A noter: il existe plusieurs implémentations d’incrémenteur pour différentes bases de données (j’utilise H2DB, mais MySQL, PostgreSQL, Oracle, etc. sont également disponibles)

• Injecter ce bean dans la classe de votre choix.
• Et désormais, vous pouvez faire:

  final Long newIdSequence = mySequenceIncrementer.nextLongValue();
  

Testé et approuvé!

 English version available

Le monde NoSQL est vaste: Cassandra, MongoDB, CouchDB, Redis, HBase, Couchbase, Neo4j, BigTable et j’en passe. Sans parler de Map-reduce, Hadoop, Hive qui se rapprochent des concepts NoSQL… Tous ces outils ont vu récemment le jour pour traiter un volume de données toujours plus grand, on parle de « Big data ». Prenez l’exemple de Facebook, LinkedIn ou Instagram avec leurs millions d’utilisateurs et vous comprendrez pourquoi les bases de données relationnelles atteignent leurs limites.

Les premières bases de données relationnelles remontent à 1979 avec Oracle, cela fait plus de 30 ans qu’elles sont utilisées et elles vont sûrement l’être pour encore très longtemps. Alors que les premières bases NoSQL ont vu le jour il y a à peine 7 ans, si l’on prend en compte l’avant-gardisme de Google et sa technologie BigTable en 2006.

Pour nous, développeurs, il est devenu difficile de s’y retrouver dans cette jungle technologique. Il faudrait beaucoup de temps libre et d’énergie pour tester tout cela. Bien souvent, les projets sur lesquels nous travaillons sont loin d’avoir les mêmes problématiques (quelques centaines d’utilisateurs tout au plus). Dans ce cas, une base de données relationnelle classique telle que MySQL fait très bien le job!

Cet article n’est pas une introduction à NoSQL, je vous conseille de lire cet article ou ce document très complet. Ils ont été écrits entre 2010 et 2011. Ils commencent à dater, mais ils restent valides pour comprendre les principes.

Je vais me focaliser sur ces deux bases de données NoSQL orientées documents. « document-oriented » ou « document store » signifie qu’une clé (l’identifiant) correspond à un « document ». Ne songez pas un document complexe, mais un simple texte au format JSON.

Voici un exemple de document:

{
  '_id' : '5897g42s0245afo4o473ai1e7',
  'firstname': 'John',
  'lastname': 'Doe',
  'age': 26,
  'sex': 'M',
  'interests': [ 'Reading', 'Running', 'Hacking' ]
}

Couchbase et MongoDB sont des bases de données très utilisées aujourd’hui. Elles sont en compétition sur un marché, vous l’aurez compris, déjà bien saturé. Ayant utilisé MongoDB (grâce à la formation 10gen) et étant sensibilisé à Couchbase (session au BruJUG), je vais faire une comparaison (sûrement pas très objective) des deux systèmes. Les choses évoluent tellement vite que cet article sera peut-être obsolète dans quelques mois…

Un peu d’historique pour commencer. MongoDB a été créée en 2009 par la société 10Gen, Couchbase a été créée un peu plus tard en 2011 par l’entreprise du même nom.

A l’heure d’aujourd’hui, les deux systèmes partagent de nombreuses caractéristiques (open source, gratuit, compatible avec la majorité des plateformes, documentation bien fournie…). Ils se différentient tout de même sur certains points.

Scalabilité

Dans Couchbase, on peut facilement ajouter des serveurs pour faire du clustering et obtenir un système distribué, Couchbase est suffisamment flexible pour qu’il n’y ait pas de downtime. En effet, elle s’appuie sur la puissance du langage Erlang, un langage fonctionnel qui gère les tolérances aux pannes et les changements à chaud.
Pour MongoDB, la configuration se complique. Par exemple, une fois la shard key définie (la clé de distribution des documents au sein des clusters), il devient difficile de la changer par la suite. Le système n’est pas aussi souple, il faut donc bien réfléchir à votre modélisation des données avant de mettre votre application en production.
La scalabilité est la raison pour laquelle Couchbase est beaucoup utilisée dans tout ce qui est social gaming, où plusieurs millions de joueurs peuvent s’affronter et où leur nombre peut augmenter exponentiellement du jour au lendemain.

Outil de monitoring

Couchbase arrive avec un package clé en main alors que MongoDB demande l’inscription à un service supplémentaire pour monitorer le serveur. Vous pouvez monitorer MongoDB en utilisant la ligne de commande, mais un monitoring sans interface graphique reste relativement contraignant.

Monitoring de MongoDB

Monitoring de Couchbase

Finalement, les produits graphiques semblent assez similaires, mais le fait de devoir s’inscrire pour MongoDB (même si c’est gratuit) et que le service ne soit pas hébergé chez vous… Bof!

Requêtage des données

MongoDB inclut une panoplie d’outils pour faire des requêtes. Ainsi, on trouve un équivalent pour la plupart des opérateurs du langage SQL, bien sûr les jointures sont inexistantes. Quelqu’un qui viendra du monde SQL ne sera donc pas trop dépaysé en retrouvant certains concepts tels que les index et sous-index. Vous trouverez l’ensemble des opérateurs disponibles sur cette page.
Avec Couchbase, on trouve les vues comme en SQL relationnel. C’est une sorte de requête pré-écrite en JavaScript qui se base sur le concept Map-reduce. Et c’est à peu près tout! Si vous voulez faire des opérations plus complexes comme filtrer ou agréger vos données, il faudra utiliser Elastic Search (sous forme de plugin pour Couchbase). Couchbase a fait le choix de se focaliser sur le moteur NoSQL en lui-même, et de laisser faire les outils de recherche spécialisés.

Conclusion

Ces deux bases de données sont très répandues et il existe une large communauté pour chacune. Vous l’aurez compris, il n’y ni gagnant, ni perdant. Comme toujours, l’adoption d’une technologie plutôt qu’une autre dépendra de vos besoins.

Autres ressources

• Documentation de Couchbase
• Documentation de MongoDB
• Couchbase vs MongoDB (DB-engines)