Mongo db : Introduction.

Notes de l'éditeur

1. Donc on va faire une comparaison entre BDR et NOSQL afin de savoir les points forts de chaque un d’eux et pour quoi il est recommandé d’utiliser un SGBD nosql dans les grands projets aussi que vos petits projets
2. par exemple, l’utilisateur n°20 a ses informations enregistrées sur la table « users » et s’il achète quelque chose, son identifiant sera consigné dans la table « commands » pour savoir que c’est bien lui qui a commandé tel produit dans la table « products »
3. Pourtant, MySQL pose un problème dans le domaine du web : s’il est extrêmement pratique de manière générale dans tout environnement informatique, les contraintes inhérente à l’outil font qu’il est parfois ardu (pour le serveur) de trouver l’information dont on a besoin, surtout quand des dizaines de milliers de personnes cherchent à accéder à une information
4. Une information à chercher en base peut être coûteuse en termes de ressources. C’est dans cette optique qu’a été pensé le NoSQL
5. 1 - en mongoDB les données sont stockées sous format BSON - binaryjson " - "qui a était conçu pour avoir ces trois caractéristiques : - léger - traversable – efficace (encodage vers bson) .2- nous facilite la vie (pas de schéma, on peut extraire la date à partir de l’id …).3- il y’en a 2 type de scalabilité, scalabilité verticale pour les les BDR classic (mysql) et scalabilité Horizontal (shardin en anglais), le problém qu’on a sur mysql par exemple c’est un jours votre application a connus le succès, donc vous êtes besoin d’ajouter d’autre processeurs et d’autre segments de stockage et ca demande un configuration avancé et meme ca on va tomber sur le problème de la fiabilité (on a toujours un limite) un system d’éxploitation ne peut pas gérer 20 processeurs et 120 disque dur par exemple d’une manière fiable.
6.  les propriétés ACID (atomicité, cohérence, isolation et durabilité) sont un ensemble de propriétés qui garantissent qu'une transaction informatique est exécutée de façon fiable.- Cloud.
7. en démormalisant nos tables on va gagner plus de rapidité au niveau des requêtes, parce que au moement qu'on exécute une requête, un lock est définit sur la table tout au cours de l'exécution du requête (verouillage).
8. imaginant si on a des dizaines d'utilisateurs qui veulent une information de la table (blog_post) par exemple, et elle est relié avec une autre table (author) alors on aura une durée de latence très grande
9. en mongodb, "techniquement" il est recommandé de dénormaliser vos collection, et utiliser les options d'organisations de données que mongodb vous offres (le sauvgarde des données ous format tableau, objet), parce que quand un lock est définit, il va être définit sur la table en cours d'utilisation et non pas plusieurs. (mongodb est une base de données non relationnelle)