NoSQL: Quoi, quand et pour qui par Orlando Cassano du CETIC

NoSQL & BigData

Qui? Quand? Et Pour qui?

28/01/2014 Cassano Orlando

Quelques mots sur le CETIC

Académies Industries

Centre R&D en ICT au Service des entreprises

Génèse du mouvement NoSQL

•  Première appari*on du terme en 2009... ... même si certaines technologies sont plus anciennes

•  Mouvement lancé par les entreprises

•  Nouveaux besoins provenant de l’explosion des données

•  Les RDBMS classiques ont aGeint leurs limites

•  Le NoSQL propose des alterna*ves au modèle rela*onnel

è NoSQL = Not Only SQL

Mais pourquoi ?

•  Traitement sur les données de plus en plus efficace

•  Temps d’exécu*on souvent passé en accès disque – Les disques durs sont lents – Les alterna*ves (SSD) restent onéreuses

•  1 disque dur = 75MB/sec 1000 disques durs = 75GB/sec

•  àBesoin de paralléliser l’accès aux données structurées

Mais pourquoi ?

•  Ensemble des modèles non rela*onnels convenant aux environnements distribués

•  Solu*on aux limites du modèle rela*onnel – Des structures rigide de données – Le temps d'inser(on/de lecture augmente grandement avec le nombre d'enregistrements

– Par**onnement difficile à meGre en œuvre – Gain non linéaire en fonc*on du nombre de serveurs

•  Scalabilité ver*cale Scaling up –  Augmenta*on de la capacité matérielle de la machine (fréquence du processeur, mémoire, taille/vitesse du disque)

–  Solu*on limitée et à coût croissant en fonc*on de la scalabilité

•  Scalabilité horizontale Scaling out –  Augmenta*on du nombre de machines –  Nécessite une distribu*on des données sur différentes machines (Sharding)

Stockage scalable

A-‐Z

Q-‐Z J-‐P A-‐I

Théorème CAP

•  Nouvelles contraintes liées aux environnements distribués –  Respecte au plus 2 des 3 contraintes du théorème CAP –  Les objec*fs des systèmes NoSQL sont différents

Consistency : les données sont vues de la même manière au même instant par tous les nœuds du réseau ;

Availability : garan*e d’obtenir une réponse, même en cas de panne ;

Par11on tolerance : le système doit con*nuer à répondre correctement même si une par*e de l’infrastructure est inaccessible.

Consistency: Transac*ons

ACID

Availability (Redondance

des données)

Par66on tolerance: Scaleout infini

Oracle RAC

NoSQL DB

NO GO

La solution NoSQL

•  Objec*fs sont différentsàRelaxa*on de certaines contraintes –  DBMS: Atomicity, Consistency, Isola*on, Durability (ACID) –  NoSQL : BASE

Basically Available : le système semble fonc*onner à tout moment ;

So9 state : le système n’a pas à être cohérent à tout instant ;

Eventually consistent : la cohérence sera assurée ultérieurement . Source: Eric Brewer

BASE Vs. ACID

9

•  Ges*on de la cohérence selon 3 paramètres –  N: Le nombre de copies d’une donnée qui seront maintenues (nombre

de réplications) –  R: Le nombre de copies qui seront interrogées lors d’une lecture –  W: Le nombre d’écritures à effectuer avant marquer l’insertion

comme complétée

Configuration NRW Résultat

W=N R=1 Optimisé pour la lecture – cohérence forte

W=1 R=N Optimisé pour l’écriture – cohérence forte

W+R<=N Une lecture peut ne pas voir le dernier état de la donnée – Eventually consistent – disponibilité forte

W+R>N Une lecture recevra au moins une fois le dernier état de la donnée – consistance forte

Qui ?

•  U*lisé par « les géants du Web » pour gérer les grands ensembles de données – Google : BigTable – Amazon : Dynamo –  Yahoo! : HBase – Microsoq : Azure Storage – Facebook : Cassandra -‐ HBase – LinkedIn : Voldemort –  ...

Quoi?

•  Différents modèles de données en fonc*on de l’applica*on

•  DB catégorisées en 4 modèles – Clé/Valeur – Orienté document – Orienté colonnes – Orienté graphe

•  Extensions du modèle clé/valeur

Clé Valeur

BDD Clé/Valeur

Clé

Colonne1 : Valeur

Colonne 2: Valeur

Colonne 3 : Valeur

BDD orientée colonnes

BDD orientée graphe

Nœud 1

Nœud 2

Nœud 3

Nœud 4

Clé

Champ1: Valeur

Champ2: Valeur

Champ3: Valeur

Champ4: Valeur

BDD orientée document

Stockage Clé-Valeur

12

•  Une clé unique dans la base est associée à une valeur arbitraire (en bits) –  Similaire à une Hashtable distribuée

•  Accès aux données très efficaces –  Pour des mul*ples accès aléatoires –  A une donnée spécifiée... Si on en connait la clé

•  Idéalement parallélisable (+ réplica*on possible) •  Cohérance forte en jouant sur les paramètres NRW •  Scalabilité linéaire

Clé Valeur

Orientée documents

13

•  Chaque champ au sein d’un document est accessible •  Grande flexibilité dans la structure des documents

–  Un schéma pour chaque document –  Généralement des documents XML/JSON

•  Modèle le plus proche du modèle rela*onnel •  Ajout, modifica*on, lecture ou suppression de seulement certains champs dans un document (pas pour toutes les solu*ons)

Clé

Champ1: Valeur

Champ2: Valeur

Champ3: Valeur

Champ4: Valeur

Orientée colonnes

•  Le modèle de données –  Ensemble de tables contenant une liste de clés –  A chaque clé est associée un ensemble fixe de familles de colonnes –  Chaque famille de colonnes peut contenir une nombre indéterminé de

colonnes

•  Structure flexible pour les tables •  Bien adapté aux rela*ons one-‐to-‐many •  Stockage des données de façon ver*cale •  Pas de coût de stockage pour les valeurs vide / « null »

Clé

Colonne1 : Valeur

Colonne 2: Valeur

Colonne 3 : Valeur

Orientée colonnes

•  Vue conceptuelle de la table

•  Vue physique de la table

3� ��

, A� ��

, �� #��"� ��

3� ��

, A� ��

, �� #��"� ��

Key

Column 1 : Value

Column 2: Value

Column 3 : Value

Graph oriented

16

•  Représenta*on des données sous forme d'un graphe •  Modèle le plus “Human-‐friendly” •  U*les quand on doit faire face à des JOIN en chaîne •  Idéales pour les rela*ons many-‐to-‐many •  Algorithms de parcours de graphe pour explorer la BDD (conduit à des requêtes complexes)

Nœud 1

Nœud 2

Nœud 3

Nœud 4

Les modèles NoSQL : résumé

Et le BigData?

•  Scalabilité au niveau –  du stockage –  de la capacité de traitement

•  Volume •  Velocity, vitesse d’arrivée, durée de traitement •  Variety, hétérogénéité

•  Et encore d’autres... Variability, validity, veracity, value , etc.

•  Le NoSQL aide à tous les niveaux de la pile BigData

La pile BigData

SCALABILITY

DATA ACQUISITION & DATA EXTRACTION

STORAGE

PRE-‐PROCESSING AND REQUEST

DATA ANALYSIS BI & VISUALISATION

WORK

FLOW

STRUCTURED DATA

UNSTRUCTURED DATA

Traitement distribués

•  Algorithme Mapreduce majoritairement u*lisé •  Convient parfaitement aux infrastructures de Cloud Compu*ng

•  Réduc*on du transfert de données (share nothing architecture)

èLes données sont traitées là où elles se situent

Stockage scalable

•  Systèmes de fichiers distribués – Pas de modèle pré-‐défini – Agit comme un système de fichier classique – Réplica*on des données – Prêt pour du traitement en parallèle des données – Solu*ons pour ajouter un modèle sur les données

•  Hive = Requêtes SQL sur les fichiers plats distribués

•  Bases de données •  RDBMS distribués •  NoSQL

Pour moi ?

22

•  Pas de conversion directe entre un système rela*onnel et le NoSQL

•  Une bonne connaissance de l’applica*on et des accès aux données est nécessaire

•  Emploi de NoSQL lié au besoin … … pas uniquement aux performances •  Pourquoi pas plusieurs modèles de données à différents niveaux de l’applica*on? (solu*on mixte)

•  Les bases de données rela*onnelles restent de bons candidats

Aéropôle de Charleroi-Gosselies Rue des Frères Wright, 29/3 B-6041 Gosselies [email protected] [email protected] www.cetic.be

Merci

NoSQL: Quoi, quand et pour qui par Orlando Cassano du CETIC

Technology

Transcript of NoSQL: Quoi, quand et pour qui par Orlando Cassano du CETIC