DEVOXXFR 2014 : NOSQL, les lignes de force se dessinent

MongoDB la valeur sûre

Lors de la dernière conférence DEVOXXFR, un hand-on et un quickie étaient dédiés à la base MongoDB. Le Data Model orienté document, les nombreuses features de requêtage, la richesse et la diversité des drivers ont depuis quelques années séduits la communauté des développeurs…

La version 2.6, sortie récemment, a ajouté de nouvelles fonctionnalités de requêtage (full-text, geospatial) et amélioré le framework d’agrégation.

MongoDB c’est la valeur sûre des bases NoSQL :

  • le DataModel est très abordable,
  • les fonctionnalités de requêtage et d’indexation sont très riches.

En un mot MongoDB c’est un choix non risqué pour un projet sur lequel l’on sait que l’on va stocker de gros volumes de données hétérogènes (schema-less), peu interconnectées, sans contrainte transactionnelle, et que l’on va probablement interroger et requêter de diverses manières.

Cassandra, rien ne change mais on change tout

En caricaturant un peu (beaucoup), Cassandra c’est le premier de la classe. Celui que l’on respecte parce que tout ce qu’il dit et fait semble très pensé et réfléchi, mais qu’en réalité on ne comprend pas très bien… Celui qui ne veut pas jouer à nos jeux (ou alors qui nous impose ses règles), et que l’on n’invite pas aux anniversaires…

En un mot, dans Cassandra tout est pensé et « engineered » depuis la toute première version :

  • le data model classique orienté « clé de partition – liste de colonnes (éventuellement composites)»,
  • l’API de requêtage (slice de colonnes pour une partition ou en multi-get),
  • les index secondaires,
  • les différentes stratégies pour booster les performances et garantir la haute-disponibilité.

Mais en dehors des stockages massifs de time series, on avait toujours du mal à distinguer pour quels cas d’usages Cassandra est adapté. Conscient des points négatifs, Datastax (le Groupe derrière le produit) a doté Cassandra de CQL, un langage de définition et de manipulation des données (en somme, le SQL de Cassandra).

Exit les column families et les super column families ! Désormais il est possible de créer des tables, avec des clés de partition, des clés d’agrégation (la réunion des deux constituent la clé primaire, et est requêtable hiérarchiquement), et des colonnes de stockage de valeur (sur lesquelles l’on pose les index pour requêter par valeur).

Cela reste complexe, mais devient plus abordable (mais pas encore simple). Cassandra est adapté pour ce qui fait sa force (le stockage des time series), mais peut sans doute plus facilement être sélectionné dans des cas plus standards.

Quand le Data Model est adapté, Cassandra est très probablement un bon choix, en termes de performance et de scalabilité. Par contre cela semble un choix très structurant, beaucoup plus que MongoDB par exemple, où l’on sent davantage de souplesse (mais une scalabilité bien moins native).

Redis, un cache, mais pas que ?

Chez Pivotal (la société derrière Spring), la base Redis fait un peu figure d’OVNI :

  • il obéit au modèle clé – valeurs,
  • 5 data types sont supportés pour les valeurs,
  • la documentation se résume à un ensemble de commandes destinées au requêtage et à la mise à jour de chaque data type et doit tenir sur une page A3 (en écrivant un peu petit),
  • tout est stocké en mémoire (avec des stratégies de sauvegarde persistantes quand même).

Du coup on distingue très bien :

  • les excellentes performances en lecture du produit,
  • l’usage comme Cache ou comme Session Manager du produit.

Nous avons appris toutefois qu’elle pouvait être utilisée comme Base principale (notamment pour le site de Devoxx). Au vu des fonctionnalités de requêtage volontairement restreintes, nous avons quand même du mal à réaliser comment il pourrait en être ainsi sur une appli de gestion « traditionnelle ».

Là encore, sur des données adaptées à son Data Model, Redis est très probablement un bon choix.

Conclusion

Toute la difficulté sur un projet NoSQL réside dans le fait de faire le bon choix de produit en fonction des données du projet

MongoDB offre une certaine souplesse qui va recueillir beaucoup de suffrages. On se dit que l’on pourra toujours s’adapter en cas de changement.

Cassandra semble plus pointue, mais moins « passe-partout ».

Redis a plus un côté boîte-à-outils, hyper adapté à certaines situations.

Dans tous les cas on se trouve sur du non transactionnel, donc l’avenir est non pas au No SQL, mais au Not-Only SQL…

Inscription newsletter

Ne manquez plus nos derniers articles !