1. Les défis du NoSql
Djamel Zouaoui
@DjamelOnLine
1

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. 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. Les gènes NoSql
Architecture Distribuée
Commodity hardware
Simplicité d’administration
Schemaless
4

5. 1 - Choisir sa base
5
1

6. 6
1

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. Et chez les développeurs
8
1

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. 2 – La modélisation
10
2

11. Les méthodes
11
2

12. La fin du cadre fournie par la base de donnée
Atomicité
Cohérence
Relation
Unicité
…
12
2

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. 3 – La recherche
14
SEARCH
3

15. 15
3

16. Que faire niveau 1
16
Index secondaires
& index manuels
3

17. Que faire niveau 2
17
Index secondaires
& index manuels
Moteur Map/Reduce
intégré
3

18. Que faire niveau 3
18
Index secondaires
& index manuels
Moteur Map/Reduce
intégré
Moteur de
recherche intégré
3

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. 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. Des questions ?
21