ParisJUG : soirée NoSQL

Ce compte-rendu ne contient que  la première partie. Je n’ai malheureusement pu assister qu’à celle-ci.

Présentée par Olivier Mallassi et Michael Figuière, elle nous a offerte une vision globale du mouvement N(ot)O(nly)SQL.

Ils ont commencé par répondre aux grandes questions :

  • La fin du langage SQL ? non
  • La fin des transactions (ACID) ? Oui et non on parle plus d’un relâchement
  • La fin des SGBDR ? Non, ce n’est pas un remplacement

NoSQL est un domaine d’innovation, un écosystème riche et complexe.

L’idée est de répondre à des besoins émergents notamment chez les gros acteurs du web :

  • plus de disponibilité (notamment au niveau de l’écriture)
  • plus de souplesse des schémas/structures
  • plus d’élasticité de l’infrastructure
  • un volume de données croissant

Le cloud démocratise des solutions spécifiques de stockages capable de monter en puissance sans explosion des coûts.

Deux grands exemples :

  • Google : big table et algorithme map/reduce : besoin massif en lecture, permet l’aggrégation de gros volumes de données
  • Amazon : Dynamo : besoin de débits et d’une disponibilité important en écriture. Problématique différente en fonction des phases d’achat : (fill cart – checkout – payment) disponibilité en écriture, clé/valeur suffisant puis (process order – prepare – send) reporting, asynchrone

NoSQL est principalement un marché OpenSource : Cassandre, MongoDB, Riak, Neo4J …

On y retrouve plusieurs catégories :

  • Clé/valeur – Voldemort, Riak
  • Document – fichier XML avec id – MongoDB, CouchDB
  • Orienté colonne – Cassandra
  • Graphe – Neo4J (limite de la modélisation relationnelle)

NoSQL est surtout un changement de paradigme par rapport à SQL :

  1. table de hachage distribuée afin d’assurer une répartition uniforme des objets dans les clusters
  2. Relâchement d’ACID

Les technologies « NoSQL »  base leur consistance ou leur « consistance éventuelle » sur la formule :

Le nombre de réponses de lecture à attendre (R) ajouté au nombre de confirmation d’écriture à attendre (W) doit être supérieur au nombre de réplicas (ou serveur) (N).
En faisant varier R et W, on peut alors paramétrer si on cherche à optimiser la lecture ou l’écriture.

En ce qui concerne les propriétés ACID, les données ne sont plus co-localisées et globalement on perd l’atomicité.

Par contre les avantages sont bien présents !

  • Performance, débit en écriture
  • Stocker et manipuler de plus gros volumes de données
  • Disponibilité
  • Élasticité des infrastructure de stockage
  • Souplesse de modélisation

Mais les problèmes aussi :

  • faible modélisation et requetage de la donnée.
  • Des problématiques qui remontent au niveau Applicatif (gestion des transaction par exemple)
  • Changement au niveau de l’exploitation
  • La sécurité pratiquement inexistante

Il faut aussi rappeler que toute la problématique NoSQL vs Base de données standards relationnelles tourne autour du théorème de CAP dont les propriétés sont :

  • Cohérence forte: tous les clients voient le même point de vue, même en présence de mises à jour
  • Haute disponibilité: tous les clients peuvent trouver une réplique des données, même en présence d’échecs
  • Partage de tolérance: les propriétés du système tiennent même lorsque le système est partitionné

Il est uniquement possible d’avoir 2 de ces propriétés sur une même technologie.

L’avenir de NoSQL est bien sur incertain, aucun des présentateurs ne s’aventure à faire des pronostics pour dans 5 ans et insistent que ce sont des solutions très spécifiques adaptées à un besoin bien particulier.
De plus il existe aussi des solutions d’architecture type Event Sourcing ou CQRS qui permettent à une solution SQL standard de répondre mieux aux besoins en performance.

Pour rappel, Objet Direct avait déjà fait une petite introduction sur NoSQL.

Une réflexion au sujet de « ParisJUG : soirée NoSQL »

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *