Installation et configuration

Transcription

1 Installation et configuration Olivier Perrin IUT Nancy-Charlemagne Département Informatique Université Nancy 2 Olivier.Perrin@loria.fr

2 Quel SGBD? Open source MySQL 5.x PostgreSQL 8.x Firebird 1.5.x MaxDB 7.5 Ingres R3 Open source gratuit: bien analyser les licences Bien analyser les besoins et les fonctionnalités 2

3 Analyse Quelques critères licence plates-formes compatibilité SQL standard vitesse stabilité compatibilité ACID intégrité sécurité authentification vues 3

4 Analyse (2) Licence MySQL GPL Commerciale PostgreSQL BSD licence (pas besoin d inclure le source) Firebird IDPL & IPL (Interbase Public Licence) Commentaire attention à la licence! 4

5 Analyse (3) Plateformes MySQL Linux, MacOS, Windows, FreeBSD, OpenBSD, PostgreSQL Linux, MacOS, Windows, FreeBSD, OpenBSD, Firebird Linux, FreeBSD, MacOs, Windows Commentaires toutes les plateformes les plus courantes sont supportées 5

6 Analyse (4) Conformité SQL MySQL moyenne PostgreSQL très bonne Firebird bonne Commentaires MySQL: sous-ensembles de SQL 92 et SQL 99 PostgreSQL: sous-ensemble de SQL

7 Analyse (5) Vitesse MySQL moyenne/bonne PostgreSQL moyenne Firebird moyenne/bonne Commentaires MySQL utilise un serveur avec des threads, PostgreSQL utilise les processus MySQL supérieur pour SELECT simple, moins pour UPDATE PostgreSQL largement optimisable (cf. optimisation) 7

8 Analyse (6) Stabilité MySQL bonne PostgreSQL bonne Firebird bonne Commentaire toujours prendre une version stable! 8

9 Analyse (7) Sécurité MySQL bonne PostgreSQL bonne Firebird? 9

10 Analyse (8) Stockage MySQL plusieurs possibilités: MyISAM, BerkeleyBD, MERGE, InnoDB PostgreSQL une seule possibilité Firebird EVT Commentaire MySQL: seul InnoDB est transaction-safe PostgreSQL: un seul modèle, plus cohérent 10

11 Analyse (9) Intégrité des données MySQL ACID classique PostgreSQL MVCC: Multi Version Concurrency Control Firebird ACID Commentaire MySQL: row-level PostgreSQL: row-level, MVCC 11

12 Analyse (10) Procédures stockées MySQL oui, supérieure à 5.0 PostgreSQL oui Firebird oui Commentaire PostgreSQL: langage pl/pgsql, plus pl/perl, pl/tcl, pl/python 12

13 Analyse (11) Langage MySQL non PostgreSQL oui Firebird non Commentaire PostgreSQL pgsql est équivalent à PL/SQL (Oracle) 13

14 Analyse (12) Triggers MySQL oui, rudimentaire, version supérieure à 5.0 PostgreSQL oui Firebird oui Commentaire pas de contraintes pour MySQL 14

15 Analyse (13) Index MySQL oui, full-text par tierce partie PostgreSQL oui, full-text en modifiant le source Firebird oui 15

16 Analyse (14) Backups MySQL InnoDB seulement pour la cohérence réplication PostgreSQL Write Ahead Logging Recovery après un problème disque (Point-in-Time Recovery) Firebird oui, backup incrémental Commentaire réplication single-master ou multi-slave pour MySQL et PostgreSQL 16

17 Analyse (15) Interface MySQL JDBC, ODBC, C++, Python, Perl, PHP, ADO.Net PostgreSQL ODBC, JDBC, C++, Python, Perl, PHP, Tcl/Tk Firebird ODBC, JDBC, PHP, Perl, Python, ADO.Net Commentaire PostgreSQL possède en plus son propre langage 17

18 Choix de PostgreSQL version 8 18

19 Mise en œuvre Télécharger Compiler outils gmake, gcc, gzip, tar packages GNU Readline library, OpenSSL, Tcl/Tk, JDK (JDBC) espace disque 200 Mo nécessaires pour installation l espace évolue en fonction des données 19

20 Mise en œuvre (2) Construire l application 20

21 Mise en œuvre (3) Options dans configure --enable-multibyte: pour les caractères --enable-odbc: support de ODBC --with-openssl=directory: connexions SSL --with-java: support de JDBC --enable-syslog: démon syslog --enable-debug: symboles de debug --enable-cassert: assertions (dégrade les performances) 21

22 ./configure --bindir=/usr/local/bin -- mandir=/usr/local/share/man/ --enable-recode --with-cxx - -enable-odbc --with-java --enable-syslog --enable- unicode-conversion --enable-multibyte 22

23 Environnement L utilisateur PostgreSQL le serveur est démarré à partir d un compte utilisateur spécial généralement, postgres ajouté grâce à adduser Ne pas utiliser le compte ROOT! 23

24 Espace disque Créer un cluster première chose, initialisation d un espace sur le disque notion de cluster collection de bases de données gérées par une seule instance du serveur après initialisation, le cluster contient une base template le cluster est créé sous /usr/local/pgsql/data grâce à initdb initdb -D /usr/local/pgsql/data à partir du compte postgres 24

25 Espace disque (2) Créer un cluster (suite) options -W: nécessite un mot de passe administrateur pour créer le cluster -A md5, -A password: le mode d authentification trust n est pas utilisé -D directory: répertoire des données -E encoding: caractères -U username: nom de l administrateur -d: debug 25

26 Démarrer Démarrer le serveur: utilisation de pg_ctl pg_ctl start, pg_ctl stop pg_ctl restart, pg_ctl reload pg_ctl status pg_ctl kill options -D directory: répertoire des données -l logfile: fichier de log -m mode: mode de l arrêt: smart, fast, immediate (smart est conseillé!) -w/-w: attend ou pas que le lancement soit fini pour redonner la main -o options: options de postmaster 26

27 Démarrer (2) Démarrage (suite) le serveur doit savoir où trouver les données pg_ctl -D /usr/local/pgsql/data -l logfile start 27

28 Arrêter Ne jamais faire de kill -KILL (ou kill -9) perte de données ou données corrompues Arrêter avec pg_ctl smart: attend que tous les clients aient fermé leur connexions fast: le serveur s arrête, sans vérifier les clients immediate: contourne la procédure d arrêt, recovery au redémarrage 28

29 Redémarrage & statut Option restart de pg_ctl équivalent à stop et start Option status pas d impact sur les données nécessite -D chemin Option reload relit les fichiers de configuration: pg_hba.conf, postgresql.conf, envoi d un signal SIGHUP (relecture) Option kill pour Windows 29

30 Administration phppgadmin 30

31 Optimisation des performances Deux critères importants pour l optimisation de performances décider du niveau de performance souhaité il faut connaître et fixer à l avance le niveau voulu, sinon, on optimise souvent à la marge décider de la partie que l on veut optimiser la charge d un SGBD dépend du SGBD, du matériel et de l application on peut optimiser PostgreSQL: postgresql.conf on peut optimiser le serveur, le système d exploitation, le réseau, on peut optimiser l application: requêtes, triggers, procédures, Pour tester l efficacité d une configuration, il faut tester sur une grande variété de requêtes, pas juste sur une seule requête! 31

32 Configuration Les bases pour optimiser PostgreSQL à partir de postgresql.conf la mémoire partagée par les différentes bases la mémoire dédiée aux tris le cache les fichiers pour les transactions Des paramètres plus fins random_page_cost maintenance_work_mem max_fsm_pages max_fsm_relations wal_buffers Les dernières optimisations 32

33 shared_buffers Objectif indique le nombre de blocs mémoire que le serveur utilise pour exécuter les requêtes (exécution et stockage du résultat) quand cet espace est plein, utilisation du disque, d où ralentissement la valeur par défaut est petite, 1000 blocs de 8192 octets (8MB), pour une base en production Utilisation doit au moins être le double de la variable max_connections attention à ne pas sur-dimensioner, impact sur les performances également (pas plus de 1/3 de la RAM disponible) la valeur doit être comprise entre 1000 et (8MB et 400MB) en fonction de la mémoire disponible, de la taille des relations, des requêtes 33

34 work_mem Objectif spécifie la mémoire disponible pour les tris et fonctions de hashage (order by et group by) la valeur par défaut est 1024 Utilisation valeur plus élevée si base importante, les requêtes complexes, ou beaucoup de RAM valeur moins élevée si peu de RAM, ou beaucoup d utilisateurs simultanément surveillance des fichiers temporaires (PGDATA/base/DB_OID/pgsql_tmp) mettre une valeur plus élevée si beaucoup de swap peut être ajusté par connection: on augmente work_mem avant d exécuter les requêtes complexes, puis on le laisse à la valeur par défaut pour les autres requêtes 34

35 effective_cache_size Objectif permet au serveur d utiliser au mieux la RAM disponible c est l optimiseur de requêtes (cf. cours optimisation) qui va analyser si la taille du cache est suffisante pour utiliser les index ou s il faut utiliser une recherche séquentielle la valeur par défaut est (128 MB) Utilisation supposons que vous avez 1.5 GB de RAM, la valeur de shared_buffers est 32MB et la valeur de effective_cache_size est 800MB si une requête a besoin de 700MB, PostgreSQL va se servir des index lors de l optimisation, mais si la valeur de effective_cache_size est 200MB, l optimiseur va choisir un parcours séquentiel une valeur raisonnable est environ 2/3 de la RAM 35

36 fsync Objectif indique au serveur d écrire physiquement les mises à jour sur le disque (true) ou de les remettre à plus tard (false) la valeur par défaut est true Utilisation si vous avez confiance en votre serveur (matériel), votre onduleur, votre mémoire, ou si votre base est en lecture seule, vous pouvez mettre fsync à false accélération des traitements (mises à jour) mais en cas de crash, récupération impossible (sauf dernier backup ou RAID) si vous préférez la sécurité, la valeur par défaut est préférable traitements (mises à jour) un peu plus lents possibilité d accélérer en plaçant les fichiers WAL (Write Ahead Logging) sur un disque dédié 36

37 random_page_cost Objectif spécifie le coût d un accès à un n-uplet dans la base influence l optimiseur sur le choix des index ou non la valeur par défaut est 4.0 (la valeur doit être comprise entre 2.0 et 4.0) Utilisation si vous avez un disque rapide, un CPU rapide, et que la base peut tenir entièrement en mémoire, on peut mettre une valeur basse (2.0) dans le cas contraire, on met une valeur plus élevée (4.0) 37

38 maintenance_work_mem Objectif spécifie la taille mimum de la mémoire utilisée lors des opérations de maintenance telles que VACUUM, CREATE INDEX et ALTER TABLE ADD FOREIGN KEY (fonctions qui utilisent intensivement le disque) la valeur par défaut est (16 MB) Utilisation une valeur élevée permet à PostgreSQL de copier des blocs plus importants en mémoire, et donc d augmenter les performances une valeur entre 16 et 32 MB est optimale 38

39 max_fsm_pages Objectif comme Oracle, PostgreSQL mémorise la place libre dans chaque bloc indique le nombre maximum de blocs à conserver dans la liste des blocs libres 6 octets (dans la mémoire partagée) sont nécessaires pour chaque bloc, la valeur doit être supérieure à 16 * max_fsm_relations (slide suivant) la valeur par défaut est (valeur comprise entre et ) Utilisation une valeur appropriée permet de ne pas recourir à vacuum full (ou reindex) la valeur est associée au cluster (toutes les bases du cluster sont concernées) si la valeur est trop importante par rapport à la RAM disponible, cela peut être pénalisant 39

40 max_fsm_relations Objectif indique le nombre maximum de relations (tables ET index) pour lesquelles l espace libre sera conservé 5 octets (dans la mémoire partagée) pour chaque objet la valeur par défaut est 1000 (valeur optimale!) Utilisation doit être au moins égal au nombre de relations (tables, index, vues, ) 40

41 wal_buffers Objectif spécifie le nombre de blocs alloués aux données WAL (écriture de la transaction) dans l espace mémoire partagé la valeur par défaut est 8 Utilisation les données sont écrites une fois qu une transaction se termine la taille doit donc être supérieure aux données WAL générées pour la transaction qui génère le plus de données 41

42 Quelques optimisations supplémentaires Vérifier le système de fichiers utilisé et la journalisation: Ext3, ReiserFS, XFS, Utilisation de noatime lorsqu un filesystem (Linux par exemple) est monté avec cette option, les accès en lecture ne mettent pas à jour l information atime (access time) qui permet de connaître le dernier accès au fichier Utilisation du démon auto vacuum démon qui compacte la base si besoin (VACUUM après analyse de la base grâce à ANALYZE) s exécute toutes les autovacuum_naptime secondes 42