NoSQL: Quoi, quand et pour qui par Orlando Cassano du CETIC
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

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

  • 431 views
Uploaded on

Présentation de NoSQL par Orlando Cassano, Senior Engineer R&D au Cetic. http://www.cetic.be ...

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

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
431
On Slideshare
431
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
14
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. NoSQL & BigData Qui? Quand? Et Pour qui? 28/01/2014 Cassano Orlando
  • 2. Quelques mots sur le CETIC Centre R&D en ICT au Service des entreprises Académies Industries
  • 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Column  1  :  Value   Key   Column  2:  Value   Column  3  :  Value   3   Orientée colonnes  
  • 16.   , A  
  • 17.    
  • 18.   •  Vue  conceptuelle  de  la  table   , 
  • 19.  # " 
  • 20. 
  • 21.   •  Vue  physique  de  la  table  
  • 22. 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
  • 23. Les modèles NoSQL : résumé
  • 24. 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  
  • 25. La pile BigData BI  &   VISUALISATION   DATA  ANALYSIS   SCALABILITY   STORAGE   DATA  ACQUISITION  &  DATA  EXTRACTION   STRUCTURED     DATA   UNSTRUCTURED  DATA   WORKFLOW   PRE-­‐PROCESSING  AND  REQUEST  
  • 26. 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  
  • 27. 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  
  • 28. 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
  • 29. 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