dire oui au NoSQL ? (2/2)

La première partie de cet article s’est attachée à présenter le contexte du mouvement NoSQL : un monde de systèmes gestionnaires de bases de données (SBGD) dominé pendant des années par les bases de données dites « relationnelles ». De nouveaux besoins liés au web (ou encore au M2M) ont émergé progressivement et pour lesquels des approches alternatives peuvent apporter un gain conséquent.

Si les acteurs du mouvement NoSQL se sont accordés pour repenser la gestion de données en sortant des sentiers battus par le SQL, chacun des nouveaux produits proposés emprunte une piste propre. La tendance des SGBD NoSQL est à la spécialisation, dans l’optique de proposer une solution optimisée pour un sous-ensemble particulier d’attentes potentielles des utilisateurs, face à leurs données.

la grande famille du NoSQL

Quand on se penche un peu sur l’ensemble des solutions labélisées « NoSQL », certaines tendances émergent. En voici une liste non exhaustive, une base NoSQL donnée pouvant entrer dans zéro, une ou plusieurs de ces catégories :

• un fonctionnement « en mémoire » (ex: Redis) : ce type de SGBD est conçu pour fonctionner avec l’ensemble des données chargées en RAM, ce qui assure des performances énormes, en dépit de la durabilité des données (pertes possibles en cas de crash)

• une structuration des données « orienté document » / « sans schéma » (ex: MongoDB) :
  les données sont ici stockées sous la forme de propriétés de documents, eux-mêmes regroupés en collections. Aucune structure n’est imposée sur les documents d’une même collection, ce qui permet de stocker ensemble des classes hétérogènes d’entités. Cette approche offre une grande souplesse dans la gestion du schéma, et accélère le test et la réalisation de maquettes. Néanmoins, « sans schéma » ne veut pas dire « sans réflexion », et le travail de « dénormalisation » des données doit être mené avec attention pour optimiser les performances de la base

• une structuration de type « big table » / « orientées colonnes » (ex : Cassandra) : les données sont ici stockées au sein de tables multidimensionnelles où le nombre de colonnes utilisées peut varier d’un enregistrement à l’autre et évoluer au cours du temps. Ce type d’approche permet de bénéficier d’architectures distribuées très performantes

• une approche « orientées graphes » (ex : Neo4j) : spécialisés dans la gestion de données représentant des entités fortement liées les unes aux autres, ces SGBD sont par exemple particulièrement adaptés à la représentation des liens entre comptes utilisateurs au sein d’un réseau social

• support de mécanismes de sharding et/ou de réplication : le SGBD facilite un déploiement distribué sur de nombreuses machines (« nœuds »), de manière à augmenter ses performances et/ou sa disponibilité. Cette distribution peut être administrée ou automatisée de manière plus ou moins fine et peut proposer différents degrés de résilience suivant les méthodes de distribution des données et de synchronisation entre nœuds (degré de réplication des données, réplication synchrone ou asynchrone, fonctionnement multi-maîtres, gestion des conflits entre versions concurrentes des données, etc.)

• support de MapReduce (ou assimilé) : le SGBD sait réaliser une exécution en parallèle d’un même calcul sur les différents nœuds sur lesquels les données sont distribuées, permettant une analyse statistique poussée de volumes potentiellement énormes de données. Ce type de solution se révèle ainsi un outil précieux pour l’entrée dans le monde de la Big Data.

conclusions

On le voit, les bases NoSQL ont apporté une vraie richesse d’approches possibles pour la gestion de nos données, offrant dans certains cas des gains conséquents en performances ou en temps de développement.

Pourtant, envisager l’utilisation de bases NoSQL a aussi un prix :

• la formation, chaque outil présentant des principes, une terminologie, des interfaces de programmation, une administration et maintenance chaque fois différents. Votre équipe dispose-t-elle du temps nécessaire à l’exploration de ces nouvelles pistes pour trouver chaussure à son pied ? Ou bien saurez-vous trouver des ressources dûment formées à ces technologies pour les mettre en place et les faire vivre ?
• la sécurité, qui est un aspect abordé encore superficiellement par une majorité de ces technologies (préférant reléguer cette question côté front-end). Pourtant les solutions relationelles, même si réputées plus matures, peuvent parfois offrir de mauvaises surprises
• la (ré)introduction de couplage fort entre le choix du SGBD et la conception des applications clientes (une fois le SGBD NoSQL choisi, difficile d’en changer)

Le choix d’un SGBD NoSQL n’est donc pas à prendre à la légère et doit être le fruit d’une réflexion poussée sur la structure et l’utilisation de vos données.

Et c’est là en somme la grande réussite de ce mouvement, précurseur des réflexions sur la « Big Data » : replacer les données au cœur de notre attention.

Cette approche trouve aussi tout son sens sur des domaines tels que le M2M où la capacité à stocker et traiter des volumes important de données brutes et hétérogènes et à les corréler est le principal levier de création de valeur ajoutée.

Charly

crédit photo : © JohnKwan - Fotolia.com