NoSQL & BigData
Qui? Quand? Et Pour qui?

28/01/2014
Cassano Orlando
Quelques mots sur le CETIC
Centre R&D en ICT au Service des
entreprises

Académies

Industries
Génèse du mouvement NoSQL
•  Première	
  appari*on	
  du	
  terme	
  en	
  2009...	
  
...	
  même	
  si	
  certaines	
  t...
Mais pourquoi ?
•  Traitement	
  sur	
  les	
  données	
  de	
  plus	
  en	
  plus	
  
efficace	
  
•  Temps	
  d’exécu*on	
...
Mais pourquoi ?
•  Ensemble	
  des	
  modèles	
  non	
  rela*onnels	
  convenant	
  
aux	
  environnements	
  distribués	
...
Stockage scalable
•  Scalabilité	
  ver*cale	
  	
  
Scaling	
  up	
  
–  Augmenta*on	
  de	
  la	
  capacité	
  matériell...
Théorème CAP
•  Nouvelles	
  contraintes	
  liées	
  aux	
  environnements	
  
distribués	
  
–  Respecte	
  au	
  plus	
 ...
La solution NoSQL
•  Objec*fs	
  sont	
  différentsàRelaxa*on	
  de	
  certaines	
  
contraintes	
  

–  DBMS:	
  Atomicit...
BASE Vs. ACID
•  Ges*on	
  de	
  la	
  cohérence	
  selon	
  3	
  paramètres	
  
–  N: Le nombre de copies d’une donnée qu...
Qui ?
•  U*lisé	
  par	
  «	
  les	
  géants	
  du	
  Web	
  »	
  pour	
  gérer	
  les	
  
grands	
  ensembles	
  de	
  do...
Quoi?
•  Différents	
  modèles	
  de	
  données	
  en	
  fonc*on	
  de	
  
l’applica*on	
  
•  DB	
  catégorisées	
  en	
  ...
Clé
	
  

Valeur
	
  

Stockage Clé-Valeur

•  Une	
  clé	
  unique	
  dans	
  la	
  base	
  est	
  associée	
  à	
  une	
...
Champ1:	
  Valeur
	
  

Clé
	
  

Champ2:	
  Valeur
	
  
Champ3:	
  Valeur
	
  

Orientée documents

Champ4:	
  Valeur
	
 ...
Colonne1	
  :	
  Valeur
	
  

Clé
	
  

Colonne	
  2:	
  Valeur
	
  

Orientée colonnes

Colonne	
  3	
  :	
  Valeur
	
  
...
Column	
  1	
  :	
  Value
	
  

Key
	
  

Column	
  2:	
  Value
	
  

Column	
  3	
  :	
  Value
	
  

3




Orientée colon...
, A
•  Vue	
  conceptuelle	
  de	
  la	
  table	
  

,
#
•  Vue	
  physique	
  de	
  la	
  table	
  
Nœud	
  2
	
  
Nœud	
  1
	
  

Nœud	
  3
	
  

Graph oriented

Nœud	
  4
	
  

• 
• 
• 
• 
• 

Représenta*on	
  des	
  don...
Les modèles NoSQL : résumé
Et le BigData?
•  Scalabilité	
  au	
  niveau	
  

–  du	
  stockage	
  
–  de	
  la	
  capacité	
  de	
  traitement	
  

...
La pile BigData
BI	
  	
  
VISUALISATION
	
  

DATA	
  ANALYSIS
	
  

SCALABILITY	
  

STORAGE
	
  

DATA	
  ACQUISITION	
...
Upcoming SlideShare
Loading in...5
×

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

446

Published on

Présentation de NoSQL par Orlando Cassano, Senior Engineer R&D au Cetic. http://www.cetic.be
Présenté le 28 janvier 2014 à Louvain-la-Neuve

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
446
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
27
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

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

  1. 1. NoSQL & BigData Qui? Quand? Et Pour qui? 28/01/2014 Cassano Orlando
  2. 2. Quelques mots sur le CETIC Centre R&D en ICT au Service des entreprises Académies Industries
  3. 3. 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  
  4. 4. 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  
  5. 5. 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  
  6. 6. Stockage scalable •  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   A-­‐Z   –  Augmenta*on  du  nombre  de  machines   –  Nécessite  une  distribu*on  des  données   sur  différentes  machines  (Sharding)   A-­‐I   J-­‐P   Q-­‐Z  
  7. 7. 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   Par66on   tolerance:   Scaleout   infini   NO   GO   NoSQL   DB   Oracle   RAC   Availability   (Redondance   des   données)  
  8. 8. 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  
  9. 9. BASE Vs. ACID •  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 9
  10. 10. 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   –  ...  
  11. 11. 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   Colonne1  :  Valeur   Clé   Valeur   Clé   Colonne  2:  Valeur   Colonne  3  :  Valeur   BDD  Clé/Valeur   BDD  orientée  colonnes   Nœud  2   Champ1:  Valeur   Clé   Champ2:  Valeur   Champ3:  Valeur   Nœud  1   Nœud  3   Champ4:  Valeur   Nœud  4   BDD  orientée  document   BDD  orientée  graphe  
  12. 12. Clé   Valeur   Stockage Clé-Valeur •  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   12
  13. 13. Champ1:  Valeur   Clé   Champ2:  Valeur   Champ3:  Valeur   Orientée documents Champ4:  Valeur   •  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)   13
  14. 14. Colonne1  :  Valeur   Clé   Colonne  2:  Valeur   Orientée colonnes Colonne  3  :  Valeur   •  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  »  
  15. 15. Column  1  :  Value   Key   Column  2:  Value   Column  3  :  Value   3 Orientée colonnes
  16. 16. , A
  17. 17. •  Vue  conceptuelle  de  la  table   ,
  18. 18. #
  19. 19. •  Vue  physique  de  la  table  
  20. 20. Nœud  2   Nœud  1   Nœud  3   Graph oriented Nœud  4   •  •  •  •  •  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)   16
  21. 21. Les modèles NoSQL : résumé
  22. 22. 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  
  23. 23. La pile BigData BI     VISUALISATION   DATA  ANALYSIS   SCALABILITY   STORAGE   DATA  ACQUISITION    DATA  EXTRACTION   STRUCTURED     DATA   UNSTRUCTURED  DATA   WORKFLOW   PRE-­‐PROCESSING  AND  REQUEST  
  24. 24. 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  
  25. 25. 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  
  26. 26. Pour moi ? •  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   22
  27. 27. Merci Aéropôle de Charleroi-Gosselies Rue des Frères Wright, 29/3 B-6041 Gosselies info@cetic.be orlando.cassano@cetic.be www.cetic.be
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×