Usi 2013 - NoSql les defis à relever

989 visualizações

Publicada em

Publicada em: Tecnologia
0 comentários
3 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
989
No SlideShare
0
A partir de incorporações
0
Número de incorporações
59
Ações
Compartilhamentos
0
Downloads
0
Comentários
0
Gostaram
3
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Usi 2013 - NoSql les defis à relever

  1. 1. Les défis du NoSql Djamel Zouaoui @DjamelOnLine 1
  2. 2. NoSql est une évolution « Lorsqu'une chose évolue, tout ce qui est autour évolue de même. » 2 Source : Gabs - Changement, je me marre !!!
  3. 3. Rappel : NoSql c’est… Une alternative aux bases de données relationnelles en relâchant certaines contraintes Des avantages et des opportunités pour répondre Aux enjeux contemporains Aux limites technologiques des SGBDR 3 Volumétrie Disponibilité Multi-site Performance Coût Elasticité Débit Latence
  4. 4. Les gènes NoSql Architecture Distribuée Commodity hardware Simplicité d’administration Schemaless 4
  5. 5. 1 - Choisir sa base 5 1
  6. 6. 6 1
  7. 7. Dominante TP ou Analy cs Analyse à faire par pa ern d’accès. Plusieurs technologies peuvent (doivent ?) souvent coexister pour répondre à un scope fonc onnel complet Est-ce que mon besoin peut être résolu avec un SGBDR Juste fais-le. C’est sec, tu peux trouver des compétences facilement Personne ne te virera pourra avoir choisi un SGBDR OUI NON, car un SGBDR est -Top lent -Trop gros -Trop cher Besoin temps réel fort ? Dominante Read ou Write Analy cs TP Read Write Terradata -Requêtes prédéfinies -Résultats rapides -Solu on sèche -Intégra on avec l’existant -Requêtable en SQL Hadoop -Rapport volume/prix -Peu de limite de volume -Faiblement structuré -Requêtage à façon -exploratoire Solu ons de type Quartet FS ou CEP pour des historiques faibles Fort besoin de schémas faiblement structurés ? Solu ons de type MongoDB -Schemaless -Fonc ons de search U liser un SBDR avec •Caching •Réplica on •Sharding Mon enjeu est plutôt le par onnement et la disponibilité Solu ons de type Cassandra et Hypertable Solu ons de type Gemfir e Gigaspace Use case typique : le web -Stockage sur disque car pas de perte de données -Mul site -Haut débit -Schémas de données évolu fs à chaud Use case typique : grilles de calculs bancaires -Stockage en mémoire pour la performance des calculs -Consistance -Richesse des fonc onnalité : SQL, no f, caches locaux Les 2 familles sont élas ques – ajout dynamique de nœuds possibles Elles tendent à évoluer pour avoir le meilleur des 2 mondes C A P C A P OUI NON Mon enjeu est plutôt la consistance et le par onnement OUI NON La latence est l’enjeu clé NON OUI Solu ons de type Memcached / Reddis Use cases typiques : -Ges on de sessions -Main ent de contextes hautement accessibles -Dédoublonnage de transac ons mé er 7 Chez OCTO 1
  8. 8. Et chez les développeurs 8 1
  9. 9. Que faire ? Connaître vos besoins Connaître les technologies Comprendre les paradigmes et choix d’architecture structurants Avoir une vision 360 des produits (dev, ops et archi) S’appuyer sur des retours d’expériences Pourquoi ne parier que sur un seul datastore? 9 1
  10. 10. 2 – La modélisation 10 2
  11. 11. Les méthodes 11 2
  12. 12. La fin du cadre fournie par la base de donnée Atomicité Cohérence Relation Unicité … 12 2
  13. 13. Que faire ? Ce n’est pas qu’une histoire de technique : Modélisation émergente et orientée usage Réfléchir aux use cases en amont Adaptation et évolution du modèle Plus de la rigueur via les pratiques Tests unitaires et fonctionnels automatisés Industrialisation du développement Agilité dans la gestion du cycle de vie 13 2
  14. 14. 3 – La recherche 14 SEARCH 3
  15. 15. 15 3
  16. 16. Que faire niveau 1 16 Index secondaires & index manuels 3
  17. 17. Que faire niveau 2 17 Index secondaires & index manuels Moteur Map/Reduce intégré 3
  18. 18. Que faire niveau 3 18 Index secondaires & index manuels Moteur Map/Reduce intégré Moteur de recherche intégré 3
  19. 19. Les autres défis La production Le DBA L’organisation de la DSI La sécurité L’impact sur les architectures et le SI L’impact sur le code Les backups … Parlons-en (mais dehors vu l’heure) ! 19
  20. 20. Pour résumé Ce n’est pas magique, cela nécessite une excellente maîtrise technologique du sujet Mais ce n’est pas seulement un chantier technique, il faut repenser aussi la façon de travailler et de collaborer au sein des DSI Mais ça en vaut la peine (ok, nous n’avons pas vu cette partie ) 20
  21. 21. Des questions ? 21

×