MongoDB Day Paris 2012 – 3 – Hadoop et MongoDB – Pablo Lopez, Xebia

Comment analyser chaque jour des téraoctets de logs générés par plus de 600 JVMs en production, sans impacter leur fonctionnement ?

Cette conférence présentait une solution Big Data 100% Open Source mise en place chez l’un des plus grands sites du web européen avec une architecture basée sur syslog-ng, Flume, Hadoop, MongoDb et Play!

Près de 600 JVM, jusqu’à 13 niveau d’indirection par load balancing, 5 à 10 fichiers de log par jvm et 7go par serveur et par jour de logs générés. Voilà pour l’état des lieux.

Avant de mettre en place la solution présentée ci-dessous la procédure de récupération et analyse de logs était si lente et contraignante que les logs étaient pratiquement inutilisés, grâce à la nouvelle solution le temps a été divisé par 20. Les besoins de cette procédure étaient la centralisation des logs, leur sécurisation puis leur analyse, avec la capacité d’informer et d’archiver, tout cela en temps réel.

Après tâtonnement la solution adoptée utilise pour les logs applicatifs un syslog-ng local sur chaque serveur qui récupère les données de log4j (via udp pour ne pas attendre d’ack) et les transmets à un syslog-ng centralisé (via tcp). Les logs d’Apache sont récupérés par Flume. Tous ces logs sont ensuite stockés sur un hdfs (hadoop distributed file system), voilà pour la procédure de récupération et stockage.

L’analyse se fait ensuite de manière performante grâces aux possibilités de map-reduces offertes par hadoop, les résultats de ces analyses sont stockés dans une base Mongo distribuée sur 5 serveurs, avec réplica et sharding. Enfin Play récupère ces résultats à la demande dans Mongo et les affiche sous forme graphique.

Pourquoi avoir choisi MongoDB plutôt qu’un MySql ?

Avant tout pour la flexibilité dans le design du modèle qui permet de facilement rajouter de nouvelles fonctionnalités, mais aussi pour les possibilités de scalabilité horizontale offertes avec la réplication et le sharding ainsi que sa facilité de déploiement et de configuration. De plus Mongo est plus simple car le résultat au format JSON est renvoyé directement à des Widgets.

Ce billet fait partie de la série sur la journée MongoDB Day Paris 2012:

MongoDB Day Paris 2012 – 2 – Deployment Preparedness – Dan Pasette, 10gen

Quels sont les éléments d’un déploiement de mongoDB réussi ? Voila l’objet de cette conférence.
Beaucoup des conseils et recommandations cités lors de cette conférence sont valables pour bon nombre de projets, qu’ils utilisent Mongo ou non. Ils ont aussi été entendus un bon nombre de fois par l’ensemble d’entre nous, une piqûre de rappel est cependant toujours utile.

Tout le monde est d’accord sur l’importance de chacune de ces étapes mais dans la réalité très souvent une partie de ces phases sont négligées dans le développement des projets.

Prototype

Comme cela a été abordé donc la conférence précédente il faut faire bien attention au design du modèle, schéma libre ne signifie pas « liberté totale ».
De même il faut attacher une grande importance à la création des bons index et garder en tête qu’un seul index peut être utilisé pour une requête donnée. L’outil « explain » est très utile dans ce but, appelé après une requête db.<collection>.find(<query>).explain() il donne des statistiques sur cette requête comme le temps total, le nombre d’objets scannés et l’index utilisé…
Si l’on pense que l’on va utiliser le sharding dans le futur, designer ses schémas en conséquence.

Test

Plutôt que de passer beaucoup de temps en phase de prototypage à développer plein de fonctionnalités il vaut souvent mieux investir du temps dans tests car le temps opérationnel d’une application est la meilleure des fonctionnalités.

Il faut faire des tests de montée en charge mais aussi penser à faire des stress tests. Les tests permettent de réduire l’éventail des inconnus.

Monitoring

Ou comment « étudier le passé pour mieux prédire le futur ».
Il faut à la fois monitorer à un niveau microscopique et macroscopique.
Des outils Mongo sont nativement disponibles pour le monitoring, comme mongostats, iostats, mongoTop, currentOp, explain… 10gen a aussi développé un outil gratuit et opensource : MMS (Mongo Monitoring Service). C’est un SaaS qui permet de monitorer Mongo et aussi de générer des alertes.

Capacité de montée en charge

Identifier s’il faut scaler verticalement (ram, ssd, …) ou horizontalement (sharding, replica).
Avant même de scaler, refaire un tour sur le design du modèle et vérifier qu’il peut pas être optimisé, c’est peut-être ça qui est vraiment nécessaire plutôt que de rajouter du matériel.

Procédures de reprise sur panne

Utiliser les procédures de backup, restore et upgrade offertes par Mongo. Comprendre les « oplogs » de Mongo. Tester les différentes procédures de reprise sur panne avant qu’un problème arrive afin de bien maîtriser et valider ces procédures.

Ce billet fait partie de la série sur la journée MongoDB Day Paris 2012:

MongoDB Day Paris 2012 – 1 – Schema design principle and practices – Chris Harris, 10gen

MongoDB et son système de schéma libre apporte une grande liberté dans la modélisation des données.
Il reste que certains designs sont plus adaptés que d’autres selon les données et les contraintes que l’on a.
Il faut aussi garder en tête que les règles qui s’appliquent à la conception de schémas pour les bases de données relationnelles ne sont plus toujours vrai pour MongoDB, d’autant plus que celui-ci possèdes des caractéristiques uniques comme les mises à jour atomiques et les index sur tableaux qui changent les règles du jeu.
Le but de la conférence était donc d’identifier les bonnes pratiques pour modéliser les données dans MongoDB.
Il en ressort que la modélisation est tout d’abord contrainte par les relations existantes entre les données du modèle.

Si la relation entre les données est de l’ordre du OneToMany, un blog et des postes par exemple, alors on peut les découper en deux documents, en mettant une référence vers le blog dans les postes. Cette référence est l’id de l’objet à référencer et est l’équivalent d’une clé étrangère dans le monde relationnel à l’exception qu’ici le savoir est au niveau applicatif et que pour mongo c’est un champ comme un autre (il n’y a pas de contrôle d’intégrité).

Si la relation est ManyToMany, des produits et des catégories de produit par exemple, alors si l’on veut découper les données en deux documents on peut au choix avoir dans chacun des documents un tableau de référence vers l’autre collection (les produits aurait un tableau de catégories et les catégories auraient le tableau de produits).
L’autre solution est qu’une seule collection possède des références vers la seconde, par exemple les produits possèdent un tableau de catégories : les insertions sont alors plus rapides et la base est moins lourde. Par contre certaines requêtes en lecture sont beaucoup plus lentes : ainsi si l’on veut récupérer tous les produits d’une catégorie, il faudra alors parcourir tous les produits et regarder pour chacun s’ils appartiennent à cette catégorie…

Si la relation est de type arbre, par exemple un poste de blog et ses commentaires avec la possibilité de commenter les commentaires, alors les choses se compliquent un peu. Il est possible de faire un document unique mais il risque alors d’avoir une taille conséquente. L’autre problème est qu’il va être difficile à requêter, étant impossible de savoir à l’avance sa profondeur.
La meilleure solution est souvent de dé-normaliser en deux documents (poste et commentaire) et d’ajouter à chaque commentaire un tableau d’ancêtres, une autre possibilité est d’avoir un champ  sous la forme d’un chemin à la xpath, par exemple « com1/com3/com5″ puis de faire des requêtes par expression régulière.

Une solution toujours présente quelque soit le type de relation est de tout mettre dans le même document. Une question récurrente lors de la modélisation des données dans mongo est alors la normalisation ou non des données, c’est à dire leur agrégation ou non au sein d’un même document.

Tout d’abord il faut bien avoir en tête les caractéristiques spécifiques à MongoDB.
Il n’y a pas de transaction dans mongo, cependant les mises à jours d’un document se font de manière atomique. Ainsi le seul moyen d’avoir un équivalent des transactions dans mongo est de mettre toutes les données sous transaction dans un même document.
L’inconvénient de ce système de mise à jour atomique est que si trop de données sont dans le même document alors on risque d’avoir des problèmes liés à la concurrence des accès et au déplacement du document sur le disque (padding).

Il faut aussi savoir que la taille limite d’un document est de 16mo, ce qui peut être un frein à la dénormalisation.
Du côté des performances quand les données sont découpées en deux documents il faudra deux requêtes pour faire une requêtes équivalente à une jointure alors qu’une seule requête suffit lorsque les données sont agrégées.

Voilà quelques considérations qu’il faut avoir en tête quand on modélise les données.
Il n’existe pas de solution unique, la bonne solution dépends des requêtes que l’on effectuera et de leurs contraintes.

Ce billet fait partie de la série sur la journée MongoDB Day Paris 2012:

MongoDB Day Paris 2012 – Introduction

Jeudi 14 Juin s’est déroulé à Paris le MongoDB Day.

La journée était dédiée à MongoDB et composée de pas moins de 17 conférences de 45 min.
Une moitié tenue par des membres de 10gen, la société qui développe Mongo, et l’autre moitié par des partenaires et clients français, dont une présentation réalisée par Mathias Kluba de FastConnect dans le cadre de notre partenariat.

Deux conférences étaient constamment tenues en parallèle il m’a donc été impossible de toutes les suivre, voilà cependant un petit résumé de celles que j’ai pu voir, avec les informations qui m’ont marqués.

Ce billet fait partie de la série sur la journée MongoDB Day Paris 2012:

Fastconnect @ MongoDB Day Paris 2012

Nous avons le plaisir de vous annoncer que Fastconnect sera présent à la journée dédiée à MongoDB le 14 Juin à Paris !

  • Votre boss vous parle de NoSQL (car c’est à la mode) mais vous ne savez pas par quel bout prendre la chose ?
  • Vous entendez vos collègues parler de MongoDB à la pause café, mais vous ne voyez pas encore les avantages d’un « base orientée Document »  ?
  • Vous voulez vous rassurer avec des retours d’expériences concrets avant de vous lancer ?
  • Ou vous voulez vous perfectionner et découvrir les experts de 10Gen qui se cachent derrière MongoDB ?

Ce sont toutes de bonnes raisons de vite vous inscrire !

Pour ce faire, et pour plus d’information sur le planning de la journée : http://www.10gen.com/events/mongodb-paris

Vous pouvez nous y retrouver à 13h15:
Nous allons vous parler des outils de déploiement et monitoring autour de MongoDB.

Speaker : Mathias Kluba

Description :

Vous avez opté pour MongoDB, pour sa souplesse du « schemaless design », pour sa scalabilité horizontale, et pour sa simplicité.
C’est un pur bonheur pour le développement, mais qu’en est-il en production?

  • comment facilement et rapidement déployer 10 ou 100 nœuds?
  • comment s’abstraire de l’infrastructure existante pour le déploiement sur des machines physiques, virtuelles, ou du Cloud public/privé?
  • comment monitorer tout le cluster, et effectuer des opérations de maintenance (backups, etc..)?

Nous allons vous présentez lors de cette session quelques outils permettant de déployer une architecture MongoDB solide et fiable, que ce soit en sharding ou replicatSet, tout en monitorant l’ensemble pour garantir une haute disponibilité.

Choisir les bons outils va vous permettre de réduire le temps et le coût lors du passage de la phase de développement à une production solide avec une forte SLA.

Cette présentation sera en Français.
Alors, inscrivez-vous vite, et bénéficiez de 20% de réduction avec le code promo: FastConnect20

Nous espérons vous y voir nombreux !