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

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

Architectures techniques NoSQL

Vous êtes en train de lire un aperçu.

Consultez-les par la suite

Architectures techniques NoSQL

Plus De Contenu Connexe

Les utilisateurs ont également aimé (20)

Similaire à Architectures techniques NoSQL (20)

Plus par OCTO Technology (20)

Plus récents (20)