Bases de données Open Source

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. Généralités sur les bases de données relationnelles

4. Généralités • Base de données • Une base de données est un ensemble structuré d'informations. • Système de Gestion de Base de Données • Un système de gestion de base de données est un ensemble d'outils • permettant : • La mise a jour des données (ajout, suppression, modification), • La consultation des données, • La maintenance des données, • dans un environnement généralement "Multi-Utilisateurs"

5. Généralités • Les bases de données font l'objet d'un grand intérêt depuis les années 60. • Le premier système de BD a été conçu pour la gestion des données du projet Apollo de la NASA (1961) • Il se basait sur unmodèle hiérarchique. • Le modèle hiérarchique n'étant pas exempt de limitations, d'autres travaux ont mené à définir unmodèle en réseau[Codasyl71]. • En 1970, un article de E. F. Codd pose les bases du modèle relationnel[Codd70]

6. Généralités • Juin 1970, « A Relational Model of Data for Large Shared Data Banks" : L'article de E. F. Codd pose les fondements du modèle relationnel. Edgar Franck • Utiliser la théorie ensembliste ainsi que la logique du premier ordre pour mettre au point un système de gestion de base de données. • 2 principaux objectifs • maximiser l'indépendance vis-à-vis de la représentation interne des données (même la définition de la base de données est conservée par le biais de relations) • adresser la cohérence des données

7. Généralités • Le premier système relationnel a été développé dans les années 70 (System/R). • Afin de manipuler les données qui y étaient stockées le language SEQUEL a été mis au point. • SEQUEL=Structured English Query Language • Ce langage est ensuite devenu le Structured Query Language: SQL • SQL a été adopté comme recommandation par l'institut de normalisation américaine (ANSI) en 1986, puis comme norme internationale par l'ISO en 1987 sous le nom de ISO/CEI 9075 - Technologies de l'information - Langages de base de données - SQL.

8. Généralités • Les propriétés ACID sont quatre propriétés essentielles d'un sous-système de traitement de transactions d'un système de gestion de base de données. Le mot ACID est un acronyme référant aux propriétés suivantes : • Atomicité : une transaction doit soit être complètement validée ou complètement annulée. • Cohérence : aucune transaction ne peut sortir de la base de données dans un état incohérent. • Isolation : une transaction ne peut voir aucune autre transaction en cours d'exécution. • Durabilité : une probabilité suffisante que la base de données ne perdra aucune transaction validée. • Elle sont décrites dans la norme ISO/IEC 10026-1

9. Théorie • Table = Relation • Contrairement à ce que l'on peut parfois imaginer, le terme relationnel ne vient pas du fait que l'on peut mettre en relation plusieurs tables. • ex : select * from personnes, immatriculations where personnes.id = immatriculations.personne_id • Soit les ensembles E1, E2 et E3, la relation R est un sous ensemble du produit cartésien E1 XE2 X E3. Dans ce cas R est une relation ternaire constituée de triplets. (e1,e2,e3 ) є R

10. Théorie • L'algèbre relationnel est aux relations ce que l'arithmétique est aux entiers. • Cas des immatriculations: • Plaque | Marque | Propriétaire • ------------------------------------------------------------------------------------ • XTC-157 | Opel Vectra | Paul Lenoir • WTD-324 | Citroen | Paul Lenoir • CRT-143 | Mitsubishi | Elodie Detor • RTE-666 | Mercedes | RobVilain • L'ensemble des véhicule que possède Paul Lenoir est donné par: • { (v1,v2):(v1,v2,Pol Lenoir) є R}

11. Open Source

12. Open source • 10 critères: • Libre redistribution, • Disponibilité du code source, • Autorisation de faire des modifications et travaux dérivés, • Intégrité du code source de l'auteur, • Pas de discrimination envers des personnes, • Pas de discrimination sur l'usage, • Distribution de la licence, • Licence non spécifique à un produit, • Licence non restrictive vis-à-vis d'autres logiciels, • Licence technologiquement neutre.

13. Free Software • 4 libertés: • Liberté d'utiliser un programme quelque soit l'usage (freedom 0). • Liberté d'étudier le fonctionnement d'un programme et de l'adapter à ses besoins. (freedom 1). L'accès au code source est une précondition. • Liberté de redistribuer le logiciel pour aider son prochain (freedom 2). • Liberté d'améliorer le programme, et de distribuer ses améliorations pour en faire bénéficier l'ensemble de la communauté. (freedom 3). L'accès au code source est une précondition.

14. Open Source / Free Software • Open Source • Open Source Initiative (OSI) a été fondée en 1998. • Définition établie à l'origine par Bruce Perens • Conduit une politique plus adaptée aux réalités économiques et techniques • ≠ • Free Software • La Free Software Foundation est apparue en 1985 • Sous l'impulsion de Richard Stallman • “Open source is a development methodology; free software is a social movement.”

15. Offres propriétaires, commerciales • Couts des licences • manque de souplesse • Complexité d'administration • … • Force de vente • Base de clients établie • Pérennité • Absence présumée de risques de défaillance • Sécurisant pour le Direction Technique • Support Technique • Fonctionnalités • …

16. Offre Open Source • Manque de visibilité pour les décideurs • Couts cachés • Développement, • Intégration, • Prise en mains. • Support • contractualisation ??? • Absence de licence • Disponibilité du code • Modifications possibles • Réactivité de la communauté • Support • Importante communauté • Sécurité

17. Les bases de données Open source

18. PostgreSQL • PostgreSQL est un moteur de base de données issu de travaux menés à l'université de Berkeley • Le projet initial s'appelait POSTGRES et était dirigé par Michael Stonebraker (1985) • Michael Stonebracker stop le projet en 1993 • Le projet est ensuite repris par 2 étudiants, puis une communauté grandissante. • En 1995, le suppport du language SQL est ajouté, le projet devient Postgres95 • En 1996, il devient PostgreSQL • Licence BSD • Développement 100% communautaire !

19. Fonctionnalités • Base de données relationnelle-objet. • Il est possible de faire hériter une table d'une autre table • Base de données garantissant les propriétés ACID • Très respectueux des normes existantes • Permet de définir des procédures stockées ainsi que des triggers. • PITR (Point In Time Recovery) • Tablespaces • Nombreuses API • Possibilité de définir ces propres types • Multi-plateforme

20. Processus • Le serveur consiste principalement en 2 types de processus: • postmaster • Il s'agit du serveur "multi-utilisateur". • Toute application cliente doit se connecter au postmaster qui va créer un nouveau process (postgres) pour gérer cette connexion. • Il gère également les communications entre les processus qu'il a instancié. • postgres • C'est un processus dédié à une connexion qui va traiter les requêtes du client. • Ils sont en charge de l'accès aux données hébergées sur le serveur • Un processus postmaster gère les données d'un seul cluster de base de données. • Plusieurs processus postmaster 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).

21. Outils • initdb • Créé un cluster de base de données • créé une arborescence sur le système de fichier afin de stocker les données de chaque base de données • createdb (dropdb) • crée une base de donnée • createuser (dropuser) • crée un nouvel utilisateur • pg_dump (pg_dumpall) • sauvegarde une base de données • psql • client en ligne de commande permettant de se connecter un serveur PostgreSQL

22. Architecture de PostgreSQL

23. Mise en oeuvre • /etc/init.d/postgresql start • createuser -U postgres postuser • createdb -U postuser tp • psql -U postuser -l • Name | Owner | Encoding • -------------------------+-------------+--------------- • | tp | postuser | SQL_ASCI • I postgres | postgres | SQL_ASCI • I template0 | postgres | SQL_ASCI • I template1 | postgres | SQL_ASCI • (4 rows)

24. Mise en oeuvre • psql -U postuser tp • > \h CREATE TABLE > CREATE TABLE people ( id SERIAL NOT NULL, first_name TEXT NOT NULL, last_name TEXT NOT NULL, email_address TEXT NOT NULL, PRIMARY KEY(id), UNIQUE(email_address) ); NOTICE: CREATE TABLE will create implicit sequence "people_id_seq" for serial column "people.id" NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "people_pkey" for table "people" NOTICE: CREATE TABLE / UNIQUE will create implicit index "people_email_address_key" for table "people" > Insert into people (first_name, last_name,email_address) values ('pierre', 'crépieux','pierre.crepieux@.... .com'); > select first_name,last_name from people;

25. MVCC • MVCC (Multiversion Concurrency Control ) • Chaque transaction voit un snapshot de la base de données (une version donnée) • permet de garantir l'isolation des transaction • Grâce au MVCC, les "verrous" d'accès en lecture ne bloquent pas les verrous d'accès en écriture sur les données. • permet d'optimiser la concurrence des accès

26. 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)

27. Isolation

28. WAL • WAL (Write Ahead Log) • L'idée est que les modifications des fichiers de données (tables, indexes) doivent être écrites sur disque après avoir été loggées. • un log décrivant ces changements a été flushé sur disque. • Il n'est plus nécessaire d'écrire les pages de données sur le disque à chaque commit de transaction • Il est possible de reconstituer la base de donnée grâce à ce log (REDO log) • le log étant séquentielle, l'activité disque est grandement réduite

29. Architecture logicielle

30. Architecture logicielle

31. Conclusion