Le document décrit l'expérience d'un consultant utilisant MongoDB pour traiter des données volumineuses dans le contexte d'un site de presse en ligne souhaitant construire un paywall. Il détaille les défis rencontrés lors de l'agrégation de 67 millions de lignes de données, ainsi que les améliorations apportées pour optimiser le temps de traitement. Les recommandations incluent des adaptations d'indexation et de stockage pour mieux gérer les besoins en performance.

1. A Morning with MongoDB
MongoDB et « l’analytics »
1
© OCTO 2012

2. Arnaud Huon
Consultant Senior
Média & Internet
ahuon@octo.com
MongoDB Addict depuis 2010
2
© OCTO 2012

3. 3
© OCTO 2012

4. MongoDB & Moi
Mes rendez-vous
8 mois d’Urbandive
500 000 entités géographiques sur du replica set
1 mois de Groupe Moniteur
Traces fonctionnelles indexées et requêtables
3 jours d’Analytics
Réconciliation et Agrégation de traces de visites
Mes sentiments
Versatile
Facile d’accès
Facile à mettre en place
Robuste
Developer Friendly
4
© OCTO 2012

5. Application orientée
Au-delà de 10 To en ligne, les Stockage Au-delà de 1 000
architectures « classiques » transactions/seconde les
nécessitent des adaptations architectures « classiques »
logiques et matérielles très Stockage nécessitent des adaptations
importantes. distribué logiques et matérielles très
Share importantes.
nothing
Univers
FaireFlux
orientée
glisserProcessing vers l'espace réservé ou
Application
l'image
Event Stream « standard »
XTP
Application orientée
SGBDR, Transaction
cliquer sur l'icône pour l'ajouter
évènementiel Serveur d’application,
ETL, ESB
Au-delà de 1 000 Au-delà de 10 threads/Core
évènements/seconde, les CPU, la programmation
Programmation
architectures « classiques » séquentielle classique atteint
parallèle
nécessitent des adaptations ses limites (IO).
logiques et matérielles très
importantes.
Application orientée
Calculs
5
© OCTO 2012

6. Application orientée
Stockage
MongoDB
Faire glisser l'image vers l'espace réservé ou orientée
Application
orientée Flux
Univers Application
Transaction
« standard »
cliquer sur l'icône pour l'ajouter
évènementiel
Application orientée
Calculs
6
© OCTO 2012

7. Cas d’usage « Analytics »
Contexte : un site de presse en ligne veut construire un paywall
Enjeu : Etre capable d’agréger 67 M de lignes de CSV (soit 10
Go), avec un temps de développement minimum
5 épreuves imposées : insertion – modification – réconciliation –
double agrégation – export
Ma contrainte : je ne suis pas DBA !
7
© OCTO 2012

8. Amélioration en 3 phases
Développement initial en ½ journée
Amélioration 1 : faire l’indexation après l’insertion
Réduction de 30% du temps de traitement
Amélioration 2 : Modifier les données directement à la source
Réduction de 50% du temps de traitement
Amélioration 3 : Changement d’infrastructure
8
© OCTO 2012

9. Notre benchmark
Configuration serveur RHEL5 Debian instance "m2.2xlarge" sous
16Go de RAM (8 dispo) 24Go de RAM RHEL6
8 CPU 8 CPU 32Go (35 visible dans le
Disque Dur 100Go SSD 70Go top)
4 CPU
stockage EBS 300Go
Etapes du traitement
import des 67 000 000
lignes 1h15 30 mn 55 mn
Indexation 1h05 20 mn 40 mn
Réconciliation des données
10h 3h30 8h30
Agrégations de préparation
Agrégations interrompu au bout de 26h, pas fait,
loin d'avoir fini... manque d'espace disque 14h00
9
© OCTO 2012

10. Doggy Bag
Insérer puis indexer
Modifier plutôt les fichiers sources plutôt que les données
insérées
Avoir un disque dur volumineux et rapide
Avoir le plus de RAM possible
10
© OCTO 2012

11. Des questions ?
ahuon@octo.com
11
© OCTO 2012