Architectures techniques NoSQL
- 1. Architectures Techniques « noSQL » © OCTO 2011
- 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. La fin des bases de données relationnelles? NON… © OCTO 2011 3
- 4. 40 années d’expérience. Compatible avec l’écosystème du SI. Viable dans la majorité des cas. © OCTO 2011 4
- 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. POURTANT © OCTO 2011 6
- 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 $/GB POURTANT 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. 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.00 POURTANT 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. 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. 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. « Capacity Planning » & administration simplifiée. Elasticité et prédictibilité pour absorber les saisonnalités. POURTANT © OCTO 2011 11
- 12. L’approche « plateforme ». et les enjeux de mutualisation sous jacent. POURTANT © OCTO 2011 12
- 13. Un constat : « scaler » un RDBMS, « ça peut être complexe ». Trafic en lecture. W W R R R W/R POURTANT - 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. Un constat : « scaler » un RDBMS, « ça peut être complexe ». Trafic en lecture. W W R R R W/R POURTANT - 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. Un constat : « scaler » un RDBMS, « ça peut être complexe ». Trafic en écriture. W/R W/R W/R W/R POURTANT - 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. 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. …construites sur un ADN différent © OCTO 2011 17
- 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 « consistent un ADN différent hashing ». Client md5(key) = GUS JOE #2 JOE BOB GUS «3» BOB GUS © OCTO 2011 18
- 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. …construites sur Elasticité de l’infrastructure. Administration « simplifiée ». Impact la modélisation un ADN différent $ bin/nodetool decommision –h 10.0.0.2 JOE GUS BOB GUS BOB JOE © OCTO 2011 20
- 21. Challenge… Durabilité Atomicité Cohérence © OCTO 2011 21
- 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. 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. 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. 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. 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. « 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. 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. Un nouvel univers extrêmement riche. Challenge… « Partition Tolerant » « Data Grid » noSQL Amazon Dynamo clones « Availability » « Consistency » RDBMS © OCTO 2011 29
- 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. ET (APRÈS) DEMAIN? © OCTO 2011 31
- 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. « Auto-scaling ». ET (APRÈS) Architectures élastiques (gérées au niveau applicatif). DEMAIN? © OCTO 2011 33