Voilà des petites notes concernant ma petite sessions de mains dans le cambouis actuelle:
Installer et jouer avec MongoDB, une base de données "NoSQL" dans la tendance actuelle.
Qu'est ce qu'une base de données NoSQL:
--> une base de donnée non "structurée", basée principalement sur un système de "clé - valeur", et donc qui ne nécéssite pas de structurer fortement l'information en tables avec des relations complexes entres-elles. (comme les traditionnelles bases de données)
Ici MongoDB, stocke les données sous formes de documents JSON (C'est un objet Javascript, mais plus silplement, c'est un peu comme un tableau de données textuelle moins "verbeux" que du XML)
Les avantages principaux sont principalement dans les domaines suivants:
-> grande capacité de stockage: il est beaucoup plus facile de gérer de très grandes quantités de données en ajoutant des nouveaux serveurs physiques, celà se fait beaucoup plus simplement qu'avec Mysql par exemple, où il faut bien vérifier la synchronisation des données entres serveurs.
http://fv.cruxaustralis.net/languages/php/installing-mongodb-and-the-php-driver-in-ubuntu-10-10/
Ce document présente une discussion intérressante sur le choix des solutions:
http://stackoverflow.com/questions/1476295/when-to-use-mongodb-or-other-document-oriented-database-systems
Le résumé étant que les bases de données SQL se sont développées à un point tel que leur objectif primaire: stocker et retrouver rapidement de la donnée de manière ACID, s'est transformer en un système complexe intégrant de plus en plus de logique métier au sein même du système de données.
L'objectif principal des premiers systèmes de gestion de données était de stocker le maximum de données en utilisant le minimum de place avec un accent sur la persistance des données ainsi que
de s'assurer que les opérations sur les bases de données se faisaient avec une fiabilité et une consistance sur les données (systèmes bancaires et de systèmes de gestion).
Ces contraintes de transaction sont de moins en moins importantes ( principalement sur des données non structurées telles que les conversations et les likes de facebook, avec la permanence de l'internet il y a de plus en plus de données à collecter (logs d'accès aux sites, liste des pages visitées par les internautes, ..... l'importance d'une extrême fiabilité sur ces données est bien moins grande que celle de pouvoir facilement augmenter la capacité à ajouter et lire en même temps un grand nombre de données, l'importance de la fiabilité des données est moins importante que celle de la "scalabilité", permettre de gérer l'augmentation du nombre de serveurs facilement, sans avoir a gérer la réplication complète.
Si je résume:
SQL (tradi) :
NoSQL
Installer et jouer avec MongoDB, une base de données "NoSQL" dans la tendance actuelle.
Qu'est ce qu'une base de données NoSQL:
--> une base de donnée non "structurée", basée principalement sur un système de "clé - valeur", et donc qui ne nécéssite pas de structurer fortement l'information en tables avec des relations complexes entres-elles. (comme les traditionnelles bases de données)
Ici MongoDB, stocke les données sous formes de documents JSON (C'est un objet Javascript, mais plus silplement, c'est un peu comme un tableau de données textuelle moins "verbeux" que du XML)
Les avantages principaux sont principalement dans les domaines suivants:
-> grande capacité de stockage: il est beaucoup plus facile de gérer de très grandes quantités de données en ajoutant des nouveaux serveurs physiques, celà se fait beaucoup plus simplement qu'avec Mysql par exemple, où il faut bien vérifier la synchronisation des données entres serveurs.
http://fv.cruxaustralis.net/languages/php/installing-mongodb-and-the-php-driver-in-ubuntu-10-10/
Ce document présente une discussion intérressante sur le choix des solutions:
http://stackoverflow.com/questions/1476295/when-to-use-mongodb-or-other-document-oriented-database-systems
Le résumé étant que les bases de données SQL se sont développées à un point tel que leur objectif primaire: stocker et retrouver rapidement de la donnée de manière ACID, s'est transformer en un système complexe intégrant de plus en plus de logique métier au sein même du système de données.
L'objectif principal des premiers systèmes de gestion de données était de stocker le maximum de données en utilisant le minimum de place avec un accent sur la persistance des données ainsi que
de s'assurer que les opérations sur les bases de données se faisaient avec une fiabilité et une consistance sur les données (systèmes bancaires et de systèmes de gestion).
Ces contraintes de transaction sont de moins en moins importantes ( principalement sur des données non structurées telles que les conversations et les likes de facebook, avec la permanence de l'internet il y a de plus en plus de données à collecter (logs d'accès aux sites, liste des pages visitées par les internautes, ..... l'importance d'une extrême fiabilité sur ces données est bien moins grande que celle de pouvoir facilement augmenter la capacité à ajouter et lire en même temps un grand nombre de données, l'importance de la fiabilité des données est moins importante que celle de la "scalabilité", permettre de gérer l'augmentation du nombre de serveurs facilement, sans avoir a gérer la réplication complète.
Si je résume:
SQL (tradi) :
- vient du monde bancaire
- vient d'un monde ou on optimisait le contenu au "bit près" (quant on optimise une BDD on essaye de ne jamais répéter deux fois la même info)
- vient d'un monde en "noir et blanc" ou les premiers utilisateurs requêtaient directement en SQL. La logique métier devait être vérifiée strictement au niveau base de données pour leur éviter les bêtises.
NoSQL
- vient d'un monde ou les donnnées sont souvent moins importantes en elles même
- "le nombre de like d'un utilisateur FB vs le solde bancaire après une transaction"
- "la place sur les disques s'est développée plus vite que la largeur de bande passante, si le nombre d'internautes à accéder en même temps aux données des applications a été multiplié par 1000 alors que la bande passante / performance des serveurs n'a été multipliée que par 10, il vaut mieux limiter les contrôles stricts réalisés par une BDD relationnelle pour ainsi accélérer les réponses aux requêtes quitte à ce qu'elles soient un peu "fausse" en tant réel.
- vient d'un monde où tout est graphique et où l'utilisateur ne va jamais requêter directement la base. (clic, touch, voire même pour les développeurs: ORM ...). On peut donc écrire la logique dans le code de l'application elle même pour éviter les incohérences de données sans nécessairement rajouter de couche inutile.
Commentaires
Enregistrer un commentaire
Tell me what you think