Cas pratiques MongoDB

Contexte : Une nouvelle fonctionnalité nécessite l’ajout d’un champ status avec valeur "active" par défaut. Le Problème : Les documents existants ne contiennent pas ce champ. Contraintes : Mettre à jour tous les documents sans supprimer les données existantes. Livrable attendu : Fournir la commande updateMany permettant d’ajouter le champ status à tous les documents.

Contexte : L’équipe souhaite connaître le nombre total de commandes enregistrées. Le Problème : Aucun indicateur simple n’est disponible. Contraintes : Utiliser une commande MongoDB adaptée sans modifier les données. Livrable attendu : Fournir la commande permettant de compter tous les documents de la collection orders.

Contexte : Une requête doit retourner uniquement les champs name et email des utilisateurs. Le Problème : La requête actuelle retourne tous les champs. Requête actuelle : db.users.find({}, { name: 1, email: 1, active: 0 }) Contraintes : Corriger la projection en respectant les règles MongoDB. Livrable attendu : Fournir la requête correcte retournant uniquement name et email.

Contexte : Une application Node.js utilise MongoDB pour stocker les profils utilisateurs. Le Problème : Une requête censée retourner uniquement les utilisateurs actifs échoue ou retourne tous les documents. Contraintes : Corriger uniquement la requête MongoDB sans modifier les documents existants. Requête actuelle : db.users.find({ active: "true" }) Livrable attendu : Fournir la requête correcte en supposant que le champ active est de type booléen.

Contexte : Une collection orders contient plusieurs milliers de documents. Le Problème : Les recherches par customerId sont lentes. Contraintes : Ajouter un index sur le champ customerId sans modifier les documents existants. Livrable attendu : Fournir la commande MongoDB permettant de créer un index simple sur ce champ.

Contexte : Un nouveau projet nécessite une base MongoDB spécifique. Le Problème : Aucune base ni collection n’ont encore été créées. Contraintes : Créer une base nommée project_db et une collection nommée tasks. Livrable attendu : Fournir les commandes nécessaires pour créer la base et la collection.

Contexte : Une collection products contient un champ price. Le Problème : L’équipe souhaite récupérer uniquement les produits dont le prix est supérieur à 100. Contraintes : Utiliser un opérateur de comparaison MongoDB. Livrable attendu : Fournir la requête find permettant de retourner les produits dont price est strictement supérieur à 100.

Contexte : Une collection products contient des documents avec les champs name, price et createdAt. Le Problème : Une insertion échoue car un champ requis est manquant. Contraintes : Corriger uniquement la commande d’insertion sans modifier la structure de validation. Commande actuelle : db.products.insertOne({ name: "Laptop" }) Livrable attendu : Fournir une commande insertOne valide incluant les champs nécessaires.

Contexte : Un utilisateur a changé son adresse email dans l’application. Le Problème : L’ancienne valeur doit être mise à jour dans la collection users. Contraintes : Mettre à jour uniquement le document dont _id vaut 10. Livrable attendu : Fournir la commande updateOne permettant de modifier le champ email du document concerné.

Contexte : Une collection logs contient des documents anciens qui doivent être supprimés. Le Problème : Les documents plus anciens que 2 ans occupent inutilement de l’espace. Contraintes : Supprimer uniquement les documents dont le champ createdAt est antérieur à une date donnée. Livrable attendu : Fournir la commande deleteMany adaptée avec une condition sur la date.

Contexte : Une collection employees contient des informations sur les employés et un champ bonus doit être ajouté pour les employés ayant plus de 5 ans d’ancienneté. Le Problème : Le champ bonus doit être conditionnel selon l’ancienneté des employés. Contraintes : Utiliser l’opérateur $set pour ajouter le champ bonus aux employés ayant plus de 5 ans d’ancienneté. Livrable attendu : Fournir la requête update() avec l’opérateur $set et une condition $gte.

Contexte : Une collection orders contient des commandes de différents utilisateurs et l’équipe veut filtrer les commandes par user_id et order_date. Le Problème : Les requêtes sur ces deux champs sont lentes. Contraintes : Ajouter un index composé sur les champs user_id et order_date. Livrable attendu : Fournir la commande d’index composé et expliquer pourquoi cet index améliore la performance des requêtes.

Contexte : Une table des logs contient plusieurs millions d’enregistrements. Le Problème : Il est nécessaire de paginer les résultats pour récupérer les logs par page de 100. Contraintes : Utiliser les opérateurs $skip et $limit pour implémenter une pagination efficace. Livrable attendu : Fournir la requête utilisant skip et limit pour paginer les résultats de la collection logs.

Contexte : Une application doit afficher les ventes totales par mois. Le Problème : La table des ventes contient de nombreuses informations, mais seule la somme des ventes par mois est requise. Contraintes : Utiliser l’aggregation framework pour créer une vue avec des agrégations sur les mois. Livrable attendu : Fournir la requête d’agrégation complète permettant de créer une vue de ventes par mois.

Contexte : Une collection inventory contient des articles et l’équipe souhaite récupérer les articles dont le stock est supérieur à un certain seuil et qui ont été ajoutés avant une date spécifique. Le Problème : La requête doit combiner plusieurs conditions de filtre complexes. Contraintes : Utiliser les opérateurs $gt, $lt et $and dans une seule requête. Livrable attendu : Fournir la requête complète avec les opérateurs nécessaires pour filtrer les articles.

Contexte : Une collection orders référence des produits par product_id depuis la collection products. Le Problème : Il est nécessaire d’afficher des informations complètes sur les produits dans les résultats de commandes. Contraintes : Utiliser la méthode populate pour joindre les informations produit dans la collection orders. Livrable attendu : Fournir la requête populate() pour inclure les informations produits dans les résultats de commandes.

Contexte : Une collection users contient des informations utilisateurs et l’équipe souhaite modifier l’état d’un utilisateur basé sur l’âge et la localisation. Le Problème : Une mise à jour doit être effectuée uniquement pour les utilisateurs âgés de plus de 30 ans et situés à Paris. Contraintes : Utiliser des opérateurs conditionnels dans la requête update. Livrable attendu : Fournir la requête update() permettant de modifier l’état de ces utilisateurs en utilisant les opérateurs $and et $gt.

Contexte : Une collection products contient des articles dont le stock doit être mis à jour selon les ventes. Le Problème : Il faut réduire le stock de plusieurs articles en une seule opération. Contraintes : Utiliser la méthode updateMany pour effectuer cette mise à jour en masse. Livrable attendu : Fournir la requête updateMany() permettant de diminuer le stock de plusieurs produits en fonction de leur product_id.

Contexte : Une collection sales contient des transactions et l’équipe souhaite analyser les ventes par produit. Le Problème : La requête utilisant find() est lente et les résultats sont peu flexibles. Contraintes : Utiliser aggregation pipeline pour regrouper les ventes par produit et calculer le total des ventes. Livrable attendu : Fournir la requête d’aggregation pipeline permettant d’obtenir le total des ventes par produit.

Contexte : Une collection employees contient plusieurs informations sur les employés, et les requêtes filtrent souvent par department_id et join_date. Le Problème : Les requêtes avec ces filtres sont lentes. Contraintes : Ajouter un index composite sur department_id et join_date. Livrable attendu : Fournir la commande d’index composite et expliquer en quoi il améliore les performances des requêtes filtrées.

Contexte : Une entreprise déploie MongoDB en production pour une application à haute disponibilité. Le Problème : Le serveur primaire unique constitue un point de défaillance unique, rendant l’application vulnérable en cas de panne. Contraintes : Mettre en place une réplication avec un ensemble de répliques et configurer une bascule automatique (failover) sans interruption de service. Livrable attendu : Proposer une architecture de réplication avec plusieurs répliques et failover automatique via un replica set, avec la configuration nécessaire.

Contexte : L’équipe d’exploitation rencontre des problèmes de performances non identifiés sur MongoDB. Le Problème : Les outils intégrés de MongoDB ne fournissent pas assez d’informations sur les goulets d’étranglement. Contraintes : Utiliser des outils externes comme mongotop, mongostat ou des solutions tierces pour surveiller les performances et identifier les problèmes sous-jacents. Livrable attendu : Proposer un plan de diagnostic complet avec les outils et techniques permettant d’auditer les performances de MongoDB et identifier les problèmes.

Contexte : Une application utilise des sessions utilisateurs stockées dans MongoDB. Le Problème : Les sessions ne sont pas automatiquement supprimées après expiration, ce qui entraîne un gaspillage d’espace disque. Contraintes : Utiliser un index TTL (Time To Live) pour supprimer automatiquement les documents de la collection session après un certain temps. Livrable attendu : Fournir la requête pour configurer un index TTL et expliquer son fonctionnement pour gérer la suppression automatique des sessions expirées.

Contexte : Une application critique utilise MongoDB et des sauvegardes régulières sont nécessaires. Le Problème : Les sauvegardes complètes sont trop lentes et prennent trop de place. Contraintes : Configurer des sauvegardes incrémentielles et permettre une récupération granulaire des documents, en utilisant les mécanismes de MongoDB pour la sauvegarde et la restauration. Livrable attendu : Décrire la stratégie de sauvegarde incrémentielle, y compris l’utilisation des oplogs et la procédure de récupération granulaire des données.

Contexte : Une application doit générer des rapports complexes sur les ventes, incluant des agrégations multi-niveaux. Le Problème : Les requêtes actuelles sont lentes et la logique de regroupement est trop complexe. Contraintes : Utiliser l’aggregation framework de MongoDB pour effectuer des jointures entre collections et des regroupements multi-niveaux avec des conditions avancées. Livrable attendu : Proposer une solution d’agrégation complète avec des opérations comme $lookup, $group, $sort, et $match pour simplifier et accélérer les requêtes.

Contexte : Une application transactionnelle nécessite de garantir la cohérence des données lors de la mise à jour de plusieurs documents dans différentes collections. Le Problème : Les transactions ne sont pas utilisées et l’application risque d’introduire des incohérences. Contraintes : Implémenter des transactions distribuées pour assurer l’atomicité des opérations dans différentes collections. Livrable attendu : Fournir la stratégie de gestion des transactions avec l’utilisation des sessions et la syntaxe des transactions dans MongoDB.

Contexte : Une collection stores contient des données de localisation et l’application doit fournir des résultats rapides pour les requêtes géospatiales. Le Problème : Les requêtes géospatiales sont lentes, ce qui nuit à l’expérience utilisateur. Contraintes : Créer un index géospatial efficace pour accélérer les recherches basées sur la distance. Livrable attendu : Proposer un index géospatial adapté et expliquer pourquoi il améliore les performances des requêtes géospatiales sur la collection.

Contexte : Une collection logs contient des milliards d’enregistrements et les performances sont affectées par la croissance des données. Le Problème : Les requêtes sur les anciennes données sont extrêmement lentes. Contraintes : Implémenter un sharding pour partitionner la collection en fonction d’un critère, tel que la date ou le type de log, et maintenir l’accès aux données anciennes rapide. Livrable attendu : Décrire une stratégie de partitionnement des données via sharding, en incluant la configuration des clés de sharding et la gestion des partitions.

Contexte : Une entreprise souhaite renforcer la sécurité de ses instances MongoDB en gérant précisément les accès utilisateur. Le Problème : Actuellement, tous les utilisateurs ont un accès trop large à la base de données. Contraintes : Créer des rôles personnalisés avec des privilèges d’accès très fins sur les collections et les opérations. Livrable attendu : Fournir les commandes pour définir des rôles avec des permissions granulaires et sécuriser les accès utilisateurs en fonction des besoins spécifiques de l’entreprise.