Architectures Techniques                             « noSQL »© OCTO 2011
noSQL, c’est quoi? Ensemble de technologies alternatives aux RDBMS Un écosystème riche qui adresse des problématiques di...
La fin des bases de données relationnelles?      NON…© OCTO 2011                                                 3
40 années d’expérience.              Compatible avec              l’écosystème du SI.              Viable dans la majorité...
1970, premières bases de données relationnelles                              Système                             Centralis...
POURTANT© OCTO 2011   6
Des évolutions « hardware ».                                      Optimiser l’organisation de la donnée pour optimiser le ...
Des évolutions « hardware ».                                                 Utiliser le disque pour contourner la limite ...
Vers du « commodities »...              Des besoins qui dépassent la capacité d’une unique machine.              Optimisat...
Vers plus de disponibilité des              systèmes.                Disponibilité (en écriture).                Tolérance...
« Capacity Planning » &     administration simplifiée.              Elasticité et prédictibilité pour absorber les saisonn...
L’approche « plateforme ».              et les enjeux de mutualisation sous jacent.POURTANT© OCTO 2011                    ...
Un constat : « scaler » un RDBMS, « ça peut être complexe ».       Trafic en lecture.                                     ...
Un constat : « scaler » un RDBMS, « ça peut être complexe ».       Trafic en lecture.                                     ...
Un constat : « scaler » un RDBMS, « ça peut être complexe ».       Trafic en écriture.                                    ...
Evolution du hardware Vers du « commodities »                              Un foisonnement « Capacity planning » et     de...
…construites surun ADN différent© OCTO 2011        17
Distribution des données, de la…construites sur      charge.          Mécanisme de partitionnement.          Routage clien...
…construites sur  Tolérance à la panne.         Réplication synchrone / asynchrone.         « Fail-over » automatique.    ...
…construites sur              Elasticité de l’infrastructure.                Administration « simplifiée ».               ...
Challenge…              Durabilité              Atomicité              Cohérence© OCTO 2011                21
Durabilité.      Stockage sur disques standards voire en mémoire.  Challenge…                      Réplication applicative...
Relâchement de                        ACID.              Modélisation de la donnée en fonction des patterns d’accès.      ...
MapReduce ou l’art de distribuer le   traitement.         Traiter (plus rapidement) des volumes de données plus faibles.  ...
A    CID comme variable d’ajustement.  Challenge…                                    « Partition                          ...
A   CID vu du client.              Compromis entre cohérence, temps de réponse, tolérance à la panne en              fonct...
« Read your write » cohérence.              Modèle Master/Slave (pour une partition donnée).              Réplication sync...
Cohérence à terme & « Quorum based      protocol »              Approche Master / Master (sur une partition donnée).  Chal...
Un nouvel univers    extrêmement riche.  Challenge…                                      « Partition                      ...
« Data Grid : bridging the gap »    Un modèle moins en rupture, des solutions configurables.    Permet le stockage en mémo...
ET (APRÈS) DEMAIN?© OCTO 2011   31
« Big Memory » pour trouver l’équilibre    entre scalabilité horizontale et opérabilitéET (APRÈS)        Modélisation indé...
« Auto-scaling ».ET (APRÈS)     Architectures élastiques (gérées au niveau     applicatif). DEMAIN?© OCTO 2011            ...
Upcoming SlideShare
Loading in...5
×

Architectures techniques NoSQL

981

Published on

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
981
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Architectures techniques NoSQL

  1. 1. Architectures Techniques « noSQL »© OCTO 2011
  2. 2. noSQL, c’est quoi? Ensemble de technologies alternatives aux RDBMS Un écosystème riche qui adresse des problématiques différentes  Modélisation de la donnée (graphe…)  « Data Analytics »  « Transaction Processing »© OCTO 2011 2
  3. 3. La fin des bases de données relationnelles? NON…© OCTO 2011 3
  4. 4. 40 années d’expérience. Compatible avec l’écosystème du SI. Viable dans la majorité des cas.© OCTO 2011 4
  5. 5. 1970, premières bases de données relationnelles Système Centralisé Atomicité Optimisation Modélisation du stockage relationnelle Cohérence Isolation Durabilité Moteur & Stockage sur Langage disque SQL© OCTO 2011 5
  6. 6. POURTANT© OCTO 2011 6
  7. 7. Des évolutions « hardware ». Optimiser l’organisation de la donnée pour optimiser le stockage. 1965 1970 1975 1980 1985 1990 1995 2000 2005 2010 2015 1,000,000.00 100k $/GBPOURTANT 100,000.00 10,000.00 1,000.00 HDD 100.00 RAM 10.00 1.00 0,10 $/GB 0.10 0.01 Source :http://www.mkomo.com/cost-per-gigabyte© OCTO 2011 7
  8. 8. Des évolutions « hardware ». Utiliser le disque pour contourner la limite de RAM. 1965 1970 1975 1980 1985 1990 1995 2000 2005 2010 2015 10 GB 1 GB 1,000.00POURTANT 100.00 10.00 1 MB 1.00 RAM 0.10 0.01 0.00 0.00 Source : http://www.jcmit.com/memoryprice.htm© OCTO 2011 8
  9. 9. Vers du « commodities »... Des besoins qui dépassent la capacité d’une unique machine. Optimisation du coût de la transaction. $POURTANT $ Source : « Datacenter As A Computer »© OCTO 2011 9
  10. 10. Vers plus de disponibilité des systèmes. Disponibilité (en écriture). Tolérance à des niveaux de pannes plus importants, à coût contraint.POURTANT© OCTO 2011 10
  11. 11. « Capacity Planning » & administration simplifiée. Elasticité et prédictibilité pour absorber les saisonnalités.POURTANT© OCTO 2011 11
  12. 12. L’approche « plateforme ». et les enjeux de mutualisation sous jacent.POURTANT© OCTO 2011 12
  13. 13. Un constat : « scaler » un RDBMS, « ça peut être complexe ». Trafic en lecture. W W R R R W/RPOURTANT - Modéliser en fonction des « patterns » d’accès. - Dénormalisation - Topologie Master / Slave - Décharge les lectures - (peut) impacter l’OPEX - (potentielle) fenêtre d’incohérence - Stratégie de cache - Améliore les temps de réponse / débits en lecture - Nécessite des stratégies - De « rechargement » - Des tolérances à la perte du cache - (potentielle) fenêtre d’incohérence© OCTO 2011 13
  14. 14. Un constat : « scaler » un RDBMS, « ça peut être complexe ». Trafic en lecture. W W R R R W/RPOURTANT - Modéliser en fonction des « patterns » d’accès. - Dénormalisation - Topologie Master / Slave - Décharge les lectures - (peut) impacter l’OPEX - (potentielle) fenêtre d’incohérence - Partitionnement du cache pour limiter l’impact en cas de perte - Impacts les « operations »© OCTO 2011 14
  15. 15. Un constat : « scaler » un RDBMS, « ça peut être complexe ». Trafic en écriture. W/R W/R W/R W/RPOURTANT - Modéliser en fonction des « patterns » d’accès. - Vers des modèles K/V, modélidation par évènements plutôt que - Stratégie « scale up » - (potentiellement) le coût - - Impact à migrer sur du « distribué » Coût réseau induit par la -Stratégie de partitionnement - Complexité d’administration, d’opérabilité - (potentiellement) le coût - Licence / infrastructure spécifique distribution stock, « append-only »© OCTO 2011 15
  16. 16. Evolution du hardware Vers du « commodities » Un foisonnement « Capacity planning » et de solutions administration simplifiée émergentes… Transactionnel, Décisionnel… Vers plus de disponibilité des systèmes L’approche « plateforme »© OCTO 2011 16
  17. 17. …construites surun ADN différent© OCTO 2011 17
  18. 18. Distribution des données, de la…construites sur charge. Mécanisme de partitionnement. Routage client ou serveur suivant les implémentations. Le partitionnement et l’association clé/serveur sont assurés via « consistentun ADN différent hashing ». Client md5(key) = GUS JOE #2 JOE BOB GUS «3» BOB GUS© OCTO 2011 18
  19. 19. …construites sur Tolérance à la panne. Réplication synchrone / asynchrone. « Fail-over » automatique. Gestion applicative (et non plus « hardware ») de la résilience.un ADN différent JOE BOB GUS GUS BOB JOE© OCTO 2011 19
  20. 20. …construites sur Elasticité de l’infrastructure. Administration « simplifiée ». Impact la modélisationun ADN différent $ bin/nodetool decommision –h 10.0.0.2 JOE GUS BOB GUS BOB JOE© OCTO 2011 20
  21. 21. Challenge… Durabilité Atomicité Cohérence© OCTO 2011 21
  22. 22. Durabilité. Stockage sur disques standards voire en mémoire. Challenge… Réplication applicative des données. Mécanismes de « write-behind », « write-through », « overflow ». ms µs ns 0.000,000,000,000 Disque Cache L2, L1 Mémoire© OCTO 2011 22
  23. 23. Relâchement de ACID. Modélisation de la donnée en fonction des patterns d’accès. Proche de ce qui est fait en relationnel sous contrainte de performance. Possibilité de colocalisation des données. Challenge… INSERT INTO… JOE BOB GUS© OCTO 2011 23
  24. 24. MapReduce ou l’art de distribuer le traitement. Traiter (plus rapidement) des volumes de données plus faibles. Challenge… Paralléliser ces traitements « plus unitaires ». Co-localiser traitements et données. Requête Orchestrateur Tâches Tâches© OCTO 2011 24
  25. 25. A CID comme variable d’ajustement. Challenge… « Partition Tolerant » ~ système distribué « Availability » « Consistency » La donnée est Les nœuds proposent accessible la même donnée au même moment Source : « CAP Theorem » - Eric Brewer© OCTO 2011 25
  26. 26. A CID vu du client. Compromis entre cohérence, temps de réponse, tolérance à la panne en fonction du type de la donnée. Challenge… Cohérence faible « Cohérence à terme » Cohérence Forte Aucune garantie de « Eventual « Read-your-write » cohérence – garantie de récupérer récupérer la dernière Consistency » & la dernière version donnée Quorum-based protocol Source : « Eventually Consistent » - Werner Vogels « Availability » « Consistency »© OCTO 2011 26
  27. 27. « Read your write » cohérence. Modèle Master/Slave (pour une partition donnée). Réplication synchrone ou asynchrone. Challenge… Lecture « round robin » sur les partitions. Client Write Client Write Client Read md5(key) = 3 md5(key) = 3 md5(key) = 3 JOE JOE JOE© OCTO 2011 27
  28. 28. Cohérence à terme & « Quorum based protocol » Approche Master / Master (sur une partition donnée). Challenge… Compromis entre cohérence, temps de réponse, tolérance à la panne en fonction du type de la donnée, du cas d’usage. Résolution des conflits : suivant les implémentations. Client Write Client Write Client Read md5(key) = 3 md5(key) = 3 md5(key) = 3 JOE JOE JOE© OCTO 2011 28
  29. 29. Un nouvel univers extrêmement riche. Challenge… « Partition Tolerant » « Data Grid » noSQL Amazon Dynamo clones « Availability » « Consistency » RDBMS© OCTO 2011 29
  30. 30. « Data Grid : bridging the gap » Un modèle moins en rupture, des solutions configurables. Permet le stockage en mémoire pour privilégier la latence, le « near cache »... Challenge… « Distributed Event Driven Architecture » et mécanisme de notification. RDBMS « Data Grid » noSQL Client App Client App Client App Near Cache - « Disk based » - « throughput/latency oriented - « throughput oriented - Stratégie « scale up » architecture » architecture » - « Master/Slave » sur les - « Master/Master » sur les partitions partitions - Partitionnement / réplication - Partitionnement uniquement - Cohérence configurable - « Eventually consistent » - Cache local - « Disk based » - « Disk / memory based »© OCTO 2011 30
  31. 31. ET (APRÈS) DEMAIN?© OCTO 2011 31
  32. 32. « Big Memory » pour trouver l’équilibre entre scalabilité horizontale et opérabilitéET (APRÈS) Modélisation indépendante du stockage. DEMAIN?© OCTO 2011 32
  33. 33. « Auto-scaling ».ET (APRÈS) Architectures élastiques (gérées au niveau applicatif). DEMAIN?© OCTO 2011 33

×