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 :
- table de hachage distribuée afin d’assurer une répartition uniforme des objets dans les clusters
- 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.
Derniers commentaires