2. Agenda
Un petit historique
Les acteurs et les cas d'utilisations
Les principes et les familles
Les probématiques
Le futur
Présentation So@t 2
License Creative Commons 2.0 – Share Alike
3. Un peu d'histoire...
1998 : naissance du terme
Professional NoSQL par Shashank Tiwari
2009 : meetup de San Francisco
100 participants des principaux acteurs
1970 : premières bases NoSQL
Présentation So@t 3
License Creative Commons 2.0 – Share Alike
4. Un nom étrange
Première signification : Pas de SQL
Puis : Not Only SQL
Autres noms :
BigData
NotRelational
En opposition à SGBDR
Présentation So@t 4
License Creative Commons 2.0 – Share Alike
5. Qui les utilisent ?
Présentation So@t 5
License Creative Commons 2.0 – Share Alike
6. Pourquoi faire ?
Gérer des volumes de données énormes
Plusieurs téra octets
Des performances en lectures/écritures
Centaines de milliers de lectures/secondes
Centaines de milliers d'écritures/secondes
Distribuer ses données
Répartition multisites
Éviter les Single Point Of Failure
Load balancing
S'affranchir des schémas rigides
Présentation So@t 6
License Creative Commons 2.0 – Share Alike
7. Des cas pratiques...
Gérer des logs
Stocker des messages utilisateurs
Stocker des données de crawling
Remplacer les DataWarehouses
Stocker des données hétérogènes
Présentation So@t 7
License Creative Commons 2.0 – Share Alike
8. Un contre exemple
Présentation So@t 8
License Creative Commons 2.0 – Share Alike
9. Des grands principes...
Pas de jointures
Des moteurs simples
Des Apis propres à chaque moteur
Des données distribuées
Structures flexibles
Duplication des données
Présentation So@t 9
License Creative Commons 2.0 – Share Alike
10. Les types de bases NoSQL
Clefs/Valeurs
Documents
Colonnes
Graphes
Présentation So@t 10
License Creative Commons 2.0 – Share Alike
13. Colonnes
Chaque ligne possède des colonnes différentes
Très flexible
Présentation So@t 13
License Creative Commons 2.0 – Share Alike
14. Graphes
Liens complexes et flexibles entre les données
Modélisation proche de la réalité
Présentation So@t 14
License Creative Commons 2.0 – Share Alike
15. Nouvelles problématiques
Changements des paradigmes de modélisation
Plus proche de la réalité
Plus proche du code
Problématiques de distribution
Intégration dans le Cloud
Théorème de CAP
Algorithmes distribués
Report de fonctionnalité sur l'application
Pas de jointures
Tri difficiles
Bien choisir ses clefs
Manque d'outils
Présentation So@t 15
License Creative Commons 2.0 – Share Alike
16. Théorème de CAP ou CDP
SGBDR
Disponibilit
é
(Availability)
Cohérence
(Consistenc NoSQL
Résistance
y)
au
morcellem
ent
(partition
Impossible tolerence)
Présentation So@t 16
License Creative Commons 2.0 – Share Alike
17. Un exemple !
Présentation So@t 17
License Creative Commons 2.0 – Share Alike
18. Map/Reduce en théorie
Calcul distribué sur des données énormes (>1Tb)
Découpage du problème en sous problèmes (map)
Agrégation des résultats (reduce)
Présentation So@t 18
License Creative Commons 2.0 – Share Alike
20. Standardisation
Chaque moteur possède son langage de requêtes
Certains réintègrent un SQL allégé
Frameworks de standardisations :
En Java : Spring Data, Hibernate OGM
En DotNet : LINQ
Encore beaucoup de chemin à parcourir
Présentation So@t 20
License Creative Commons 2.0 – Share Alike
21. L'avenir : la guerre
Des technologies jeunes portées par des Startup
Beaucoup de solutions
Les gros du secteurs commencent à s'y intéresser
Dans 10 ans combien auront survécu ?
Présentation So@t 21
License Creative Commons 2.0 – Share Alike
22. L'avenir : multi-BDD
Chaque solution possède ses avantages et inconvénients
Utiliser le bon outil pour le bon problème
Pas de remplacement des SGBDR mais un complément
Au final nos applications auront plusieurs bases
Présentation So@t 22
License Creative Commons 2.0 – Share Alike
23. Les systèmes de caches
Cache = clefs/valeurs distribuées
Stockage en mémoire et sur le disque
Convergence des deux mondes
Présentation So@t 23
License Creative Commons 2.0 – Share Alike
Quels sont les ingrédients techniques pour la réussite d’un projet? L’effet tunnel Traçabilité de la vie du projet => Livraison régulière, … Et qd il y a bcp de développeurs, qu’est ce qui consomme du tps? L’intégration => qui doit être indépendante de l’env Reproductivité de l’environnement de compilation Reproductivité de l’environnement technique
Quels sont les ingrédients techniques pour la réussite d’un projet? L’effet tunnel Traçabilité de la vie du projet => Livraison régulière, … Et qd il y a bcp de développeurs, qu’est ce qui consomme du tps? L’intégration => qui doit être indépendante de l’env Reproductivité de l’environnement de compilation Reproductivité de l’environnement technique
l’intégration est une activité complexe… l’effort augmente significativement avec : le nombre d’artéfacts, les tests d’intégration…et leurs définitions, le nombre d’erreurs, la qualité du code, … le temps écoulé depuis la dernière intégration. l’intégration continue est apparue avec les pratiques XP avec comme motivation de remplacer les grosses et longues phases d’intégration en fin de projet par des phases plus petites et plus fréquentes l’idée principale : réduire au minimum l’effort d’intégration de l’application sans altérer le processus de développement logiciel
trois composants : Un outil de construction automatisée Tel qu'Ant ou Maven2, permettant aussi bien au développeur qu'à l'outil d'intégration continue de construire tout ou partie du système. Un unique système de gestion de sources, Tel que CVS ou Subversion, contenant les sources et l'historique des modifications apportées par les développeurs sur le système. A chaque mise à jour, le serveur d'intégration continue charge les modifications et exécute la construction complète du système. Un serveur d'intégration continue, Tels que Hudson, Bamboo, Continuum ou Cruise Control. Son rôle est de détecter les mises à jour sur le système de gestion de sources, d'exécuter le cas échéant la construction du système et de notifier l'équipe de développement du résultat