1 / 16

Bases de données Open Source

Bases de données Open Source. Pierre Cr é pieux 13/03/2008. Plan. Généralités sur les bases de données relationnelles A quoi serrent elles ? Pourquoi un modèle relationnel ? L'Open Source Qu'est ce que c'est ? Pourquoi utiliser une base de données Open Source

naida-giles
Download Presentation

Bases de données Open Source

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Bases de donnéesOpen Source Pierre Crépieux 13/03/2008

  2. Plan • Généralités sur les bases de données relationnelles • A quoi serrent elles ? • Pourquoi un modèle relationnel ? • L'Open Source • Qu'est ce que c'est ? • Pourquoi utiliser une base de données Open Source • Les bases de données Open source • PostgreSQL • MySQL • … • Conclusion

  3. MySQL

  4. MySQL • Il est intéressant de voir comment les histoires de PostgreSQL et MySQL se croisent • Celle de MySQL commence a Helsinki en 1979! • Michael Widenius (société TcX) développe une base de données "maison" appelée UNIREG • En 1983, Michael fait la connaissance de David Axmark avec qui il créera MySQL AB. • En 1994, TcX décide d'utiliser SQL (devenu un standard) pour ces appli web. • C'est à ce moment que Michael s'intéresse à mSQL. • mSQL a été développé par David Hughes qui travaille alors sur le projet Minerva. • Au tout début, mSQL est juste un traducteur SQL vers POSTQUEL. • Postgres s'est avéré par la suite trop lourd et complexe pour les besoins de Minerva, David décide alors d'écrire son propre moteur de stockage. • Michael contact David pour lui proposer d'intégré des fonctionnalités d'UNIREG (B+ ISAM handler) a mSQL. • En 1995, MySQL AB est fondée. • 2005, Oracle rachète Innobase • 2008, SUN rachète MySQL. • Licence GPL, et commerciale

  5. Fonctionnalités • Base de données relationnelle. • Base de données garantissant les propriétés ACID (en fonction du moteur de stockage) • Permet de définir des procédures stockées ainsi que des triggers. • Tablespaces • Replication, Cluster • Nombreuses API • Possibilité de définir ces propres fonction (UDF) • Multi-plateformes

  6. Terminologie (Ronald Bradford, MySQL conf 2007) • Database (files) --> Database Server Instance • Database Instance (memory) --> Database Server Instance • Schema User --> Database • User --> User • Table Space --> Table Space • --> Storage Engine

  7. Processus • Le serveur consiste principalement en 1 unique processus: • mysqld • Il s'agit du serveur "multi-utilisateur". • Toute application cliente doit se connecter au mysqld qui va créer un nouveau thread pour gérer cette connexion. • Il gère également d'autres thread comme la réplication par exemple. • accompagné de script de démarrage: • mysqld_safe (peut être remplacé par mysqlmanager), • mysql.server et • mysqld_multi (peut être remplacé par mysqlmanager). • Il est en charge de l'accès aux données hébergées sur le serveur • Plusieurs processus mysqld peuvent fonctionner simultanément sur une même machine (il suffit qu'il ait des zone de stockage et des ports de communication différents).

  8. Outils • mysqladmin • client d'administration • mysql • client en ligne de commande • mysqldump • sauvegarde de bases • mysqlimport • importe des fichiers de données

  9. Mise en oeuvre • /etc/init.d/mysqld start • $ mysqladmin -u root password NEWPASSWORD • $ mysqladmin create NEWDBNAME • $ mysql --user=myuser tp • mysql> create table test(… • … • ) ENGINE=INNODB • $ mysqldump –user=myuser tp

  10. Architecture

  11. Architecture cluster

  12. Storage engine

  13. Expériences

  14. Backup

  15. Isolation • Le standard SQL définit 4 niveaux d'isolation dépendant de 3 phénomènes à éviter entre transactions concurrentes: • dirty read: • Une transaction peut lire des données écrites par une transaction concurrente "non commitée". • nonrepeatable read • Une transaction relit une donnée qu'elle a lu et constate que cette dernière a été modifiée par une autre transaction qui a "commité" entretemps. • phantom read • Une transaction ré-execute une requête renvoyant un ensemble de tuples et constate que l'ensemble est différent du précédent. • Il diffère du précédent car les données qui avaient déjà été lu n'ont pas changée, par contre il y en a plus (ou moins)

More Related