MongoDB mars 2012 AGENDA NoSQL vs. SQL MongoDB : architecture et modèle de données Démo 2 SQL : pourquoi ? Une réaction contre les rigidités des précédents systèmes (hiérarchiques ou navigationnels) Une tentative pour « donner la main » à l'utilisateur Un effort de rapprochement entre modèle logique et modèle physique L'idée d'un modèle unique d'accès aux données pour toutes les applications Une normalisation technique des interfaces (ex: DBI/DBD) 3 SQL : limites ? Abandon du mythe de maîtrise directe des données par l'utilisateur Maintien de la contrainte classique de pré-modélisation des données Mise en œuvre défaillante des méthodes de modélisation de données et multiplication des usages inefficaces du SQL Écart sémantique entre le modèle « table-clé-jointure » et la perception de l'information par l'utilisateur Écart entre format tabulaire normalisé et diversité structurelle des gisements de données La table n'est ni la seule structure de données ni la plus « naturelle » 4 NoSQL Sens actuel apparu en 2009 (première utilisation du mot dans un projet de 1998) Origine : communautés du LL + grands opérateurs de services en ligne Besoin : accumuler en continu d'énormes quantités d'informations Succès lié aux applications en ligne (e-commerce, réseaux sociaux, ...) Abandon du modèle « table-clé-jointure » et des « formes normales » classiques Abandon des schémas pré-définis; préséance de l'information telle qu'elle est sur la donnée normalisée 5 NoSQL : quelques références BigTable (propriétaire) → Google SimpleDB (propriétaire) → Amazon Cassandra (Apache) → Facebook, WebEx Voldemort → LinkedIn MongoDB (10gen) → Intuit, LexisNexis ... 6 NoSQL : généralités tables et jointures inconnues absence de schéma prédéfini structure indépendante pour chaque objet la paire clé-valeur est l'unité d'information élémentaire le document est la structure de données principale; les documents se regroupent en domaines ou collections la distinction (artificielle) entre « données structurées » et « données non structurées » disparaît Modèle d'accès « optimiste », allègement des charges d'administration et d'optimisation Architecture technique focalisée sur la montée en charge par parallélisation de serveurs 7 MongoDB : le projet Lancé par 10gen en 2009 Licence GNU-AGPL v3 (free/copyleft); modèle économique basé sur les services Opérationnel en environnements POSIX (Unix/Linux/Mac) et Microsoft Paquets d'installation pré-conditionnés pour certaines platesformes (ex: Debian) Installation et configuration très faciles pour une exploitation mono-instance Matériel/système 64 bits requis (environnement 32 bits tolérable pour découverte et maquettage) 8 MongoDB : les API C/C++ C# Java Interfaces de programmation PHP directement supportées par l'éditeur Python Ruby Haskell Erlang et bien sûr Perl 9 Document Représentation externe en notation JSON Identifiant (ObjectId) obligatoire, généré si non fourni par l'application Dans une paire clé-valeur, la valeur peut être un sousdocument (nombre de niveaux illimité) 10 Document (exemple) Paires clé/valeur et hiérarchie { "Prénom": "John", "Nom": "Smith", "Age": 25, "Adresse": { "Voie": "Commune": "CodePostal": } } "21 2nd Street", "New York", "75017" 11 MongoDB : modèle de données Chaque « document » est une séquence ordonnée de paires clé-valeur (correspondance partielle avec le hash en Perl ou le dico en Python) Tout « document » appartient à une « collection » La « collection » n'a pas forcément une structure fixe (i.e. des documents de structures différentes peuvent appartenir à la même collection) Toute « collection » appartient à une « database »; la « database » est un espace de « connexion » 12 MongoDB : bibliographie MongoDB, the definitive guide – K. Chodorow M. Dirolf, O'Reilly MongoDB in action – Kyle Banker, Manning The Definitive Guide to MongoDB: The NoSQL Database for Cloud and Desktop Computing – E. Plugge T. Hawkins P. Membrey, APRESS The little MongoDB Book – Karl Seguin (http://openmymind.net/2011/3/28/The-Little-MongoDB-Book) 13