IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

PostgreSQL Discussion :

Fragmentation et performances


Sujet :

PostgreSQL

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre éclairé Avatar de BakaOnigiri
    Inscrit en
    Avril 2002
    Messages
    366
    Détails du profil
    Informations forums :
    Inscription : Avril 2002
    Messages : 366
    Par défaut Fragmentation et performances
    Bonjour,

    j'ai une question assez simple, imaginons une base de données, contenant une vingtaine de tables.

    Une de ses tables reçoit environ 50 enregistrements / minutes (d'environ 100Ko).
    Une autre table serte à faire des stats sur ces enregistrements, et contient donc 24 enregistrements pour une journée, elle peut contenir 3 jours.

    Passés ses 3 jours, on sauvegarde les données de stats dans une table de sauvegarde, qui pourra recevoir plusieurs mois, avant d'être sauvegardés en fichier et vidée.

    Le découpage en multiple base de donnée pour une histoire de performance est-elle valable ? Cela change-t-il vraiment qqchose de séparer en bdd ou pas ?


    Merci d'avance.

  2. #2
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    22 002
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 22 002
    Billets dans le blog
    6
    Par défaut
    50 lignes minutes cela fait 3000 lignes heure et 72 000 jours, ce qui n'est pas énorme, si les lignes sont petites (normalisation), même pour plusieurs mois de données.

    24 ligne par jour sur 3 jours => 72 lignes c'est ridicule. Aucun intérêt d'archiver ou de purger.

    La seule chose importante est l'indexation si vous voulez des performances.

    Tant que la taille globale de la base (toutes tables confondues) peut tenir en RAM vous n'aurez aucun problème. Dès que le volume de la base dépasse la RAM, alors les index viennent à la rescousse, car il sont plus petit et n'ont pas besoin d'être chargés intégralement en RAM pour pouvoir être exploités.

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

Discussions similaires

  1. [maintenance][performance] Que faire comme maintenance ?
    Par woodwai dans le forum PostgreSQL
    Réponses: 5
    Dernier message: 06/11/2003, 15h39
  2. Fragmentation du DD
    Par guillaume_pfr dans le forum Administration système
    Réponses: 5
    Dernier message: 05/06/2003, 17h19
  3. [ POSTGRESQL ] Problème de performance
    Par Djouls64 dans le forum PostgreSQL
    Réponses: 6
    Dernier message: 26/05/2003, 16h18
  4. [JDBC][connexion persistante] performances avec JDBC
    Par nawac dans le forum Connexion aux bases de données
    Réponses: 6
    Dernier message: 06/05/2003, 10h37
  5. performance entre 3DS, ase, asc ...
    Par amaury pouly dans le forum OpenGL
    Réponses: 3
    Dernier message: 24/03/2003, 11h41

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo