Le document présente les bases de données NoSQL, leur évolution depuis leur apparition en 1998, et les concepts clés comme ACID et CAP qui sous-tendent leur fonctionnement. Il décrit également les différents types de bases de données NoSQL, notamment clé-valeur, orientées colonnes, orientées graphe, et orientées document, ainsi que des exemples d'applications pratiques dans des domaines comme l'énergie et les réseaux sociaux. Les systèmes comme HBase et Cassandra sont cités comme des solutions prisées pour le traitement de grandes quantités de données.

1. LES BASES DE DONNÉES NOSQL

2. NOSQL : DÉFINITION
 1998, le terme NoSQL apparaître pour la première
fois.
 En 2009, Eric EVANS reparle du NoSQL.
 NoSQL = Not Only SQL (pas seulement SQL)
 Les bases de données NoSQL crake les conceptes
fondamentale des SGBDR comme :
 La denormalization
 La sécurisation du données
Afin de :
 Augmenter le scaling (rapidité).
 Augmenter les capacités de stockage

3. NOSQL : CONCEPT – ACID
 Atomicité : les requêtes reçues par la base doivent
être complètes sous peine d'être non traitées
 Cohérence : les requêtes doivent respecter l'état
de validité de la base (respect des contraintes, des
mises à jour...)
 Isolation : les requêtes sont indépendantes les
unes des autres lors d'un envoi simultané
 Durabilité : les modifications de la base doivent
être effectuées en priorité avant toute autre action
pour permettre la sauvegarde de ces changements

4. NOSQL : CONCEPT – CAP
 CAP «Consistency, Availability, Partition tolerance », en
français « Cohérence, Disponibilité, Résistance au morcellement ».
 Consistency / Cohérence : La totalité des nœuds
du système voient au même moment exactement
les même données.
 Availability / Disponibilité : les données doivent être
toujours disponibles pour satisfaire les requêtes.
 Partition tolerance / Résistance au morcellement :
le système doit répondre d’une manière correcte
même si une partie du réseau tombe en panne,
sauf en cas de coupure totale du réseau.

5. NOSQL : CONCEPT – CAP
 CP : « Les données sont consistantes entre tous les
nodes et le système possède une tolérance aux pannes,
mais il peut aussi subir des problèmes de latence ou
plus généralement, de disponibilité ».
 AP : « Le système répond de façon performante en plus
d’être tolérant aux pannes. Cependant rien ne garantit la
consistance des données entre les nodes ».
 CA : « Les données sont consistantes entre tous les
nodes (tant que les nodes sont online). Toutes les
lectures/écritures des nodes concernent les mêmes
données. Mais si un problème de réseau apparait,
certains nodes seront désynchronisés au niveau des
données (et perdront donc la consistance) ».

6. NOSQL : CONCEPT – CAP

7. NOSQL : LES DIFFÉRENTS TYPES
 Clé – Valeur
 Orientées Colonnes
 Orientées Graphe
 Orientées Document

8. CLÉ – VALEUR
 Les bases de données clé-valeur nommée les
bases associatives
 Les données sont représentées par un couple
clé/valeur.
 Impossible de faire des requetés avec des filtres
(une requête de sélection avec une clause WHERE
en SQL).
 Exemple :
 Dynamo
 Riak
 Voldemort.

9. ORIENTÉES COLONNES
 Le type orientées colonnes sont le résultat de
l’évolution des bases de données de type
associative.
 Le modèle le plus proche d’une BD relationnelle
 Dans une BD NoSQL le nombre de colonnes est
dynamique, contrairement aux bases de données
relationnelles les données sont enregistrées en
colonnes et non en lignes.
 Exemple :
 Cassandra
 HBase

10. ORIENTÉES GRAPHE
 Ce modèle représente les données en utilisant la
théorie de graphe.
 Il s’appuie sur la notion de nœuds, de relations et
de propriétés.
 principalement utilisé au traitement des données
des réseaux sociaux.
 Exemple :
 Neo4J
 Titan

11. ORIENTÉES DOCUMENT
 Ce modèle est une évolution du modèle orienté
colonne.
 Le modèle orienté document est plus flexible au
niveau de l’accès aux données que le modèle
orienté colonne.
 Le modèle orienté document est plus flexible au
niveau de l’accès aux données que le modèle
orienté colonne
 Exemple :
 MangoDB
 CouchDB
 RavenDB

12. APPLICATION
 EDF :
 SEI « systèmes électriques intelligents : c’est un système électrique
capable d’intégrer de manière intelligente les actions des différents
utilisateurs, consommateurs et/ou producteurs afin de maintenir une
fourniture d’électricité efficace, durable, économique et sécurisée»:
 Installation des compteurs communicants (35 millions en France) avec un relevé
tous les 10 minutes (1 relevé pas 10 mn / 35 millions de clients / an).
 Volumes de données annuels.
 1800 milliards de relevés ; 600 To de données non compressées.
 Volumes de données journalier.
 5 milliards de relevés ; ~2 To.
 Néanmoins EDF entrevoit la mise en place de traitements complexes
:
 De par la nature des données : des séries temporelles
 De par leur caractère distribué et de la nécessité de traitements à différentes
échelles
 De par les contraintes temps réel pour certains besoins
=> EDF utilise la base de données HBase (Base de données NoSQL de
type orientée colonne), pour le stockage et la manipulation de ces
données.

13. APPLICATION
Réseaux sociaux :
Enregistrent des données massives :
 Historique de conversations,
 Historique d’actions (partage, j’aime, commentaire, Message,…)
 Stockage des vidéos
 …..
 Twitter utilise la base de données Apache Cassandra (il à été remplacer
par une base crée en interne similaire à Apache Cassandra) ainsi que
plusieurs autres outils pour l’enregistrement et la manipulation de ces
données.
Les Moteurs de recherche :
 Pour pouvoir regrouper les informations de différent service (Google
Earth, Google Maps et Blogger), Google à développer l’SGBD BigTable.
 BigTable enregistre les données sous forme de tableau d’octets indexés
par colonne et ligne.