Discussion :

[souf_87]

Bonjour,
Je travaille sous Postgres, j'ai une base de données de 100 tables et j'ai des tables avec des millions d'enregistrements, ce qui bouffe énormement la mémoire dans les applications.
Ça rame beaucoup, ça prend beaucoup de temps pour générer une page.
Je voulais savoir s'il y a une solution pour diminuer les enregistrements de la table, c'est-à-dire par exemple créer une autre base avec les mêmes tables qui possèdent le plus d'enregistrement. Et dans cette base ne faire migrer que les enregistrements qu'on utilise plus, et garder les enregistrements qui datent de 3 ans et tout le reste, le migrer vers l'autre base.

[CinePhil]

j'ai une base de données de 100 tables

Ça fait beaucoup !
Le modèle de données est-il optimisé ?

et j'ai des tables avec des millions d'enregistrements

Ça commence à faire beaucoup en effet ! Mais ce n'est pas encore énorme pour une BDD optimisée.

je voulais savoir est ce qu'il a une solution pour diminuer les enregistrements de la table,c'est à dire par exemple creer une autre base avec les meme tables qui possèdent le plus d'enregistrement. et dans cette base ne faire migré que les enregistrement qu on utilise plus, et garder les enregistrement qui date depuis 3ans et tout le reste le migré vers l'autre base

Oui bien sûr !
Plutôt qu'une autre BDD, si ça doit être sur le même serveur, il vaut peut-être mieux utiliser un autre schéma dans la même BDD. Ainsi tu pourras requêter sur les deux schémas si tu as besoin d'analyser des données anciennes avec les récentes.

À toi de déterminer quelles sont les lignes (et pas enregistrements ! ) des tables à migrer et de faire attention aux clés étrangères.

[SQLpro]

100 tables, c'est franchement pas énorme. En règle générale mes bases ont ua minimum cela, voire beaucoup plus (uqleques centaines).
Quelques millions de lignes ce n'est pas gênant, quelques une des bases sur lesquelles je travaille ont plusieurs centaines de millions et jusqu'à un milliard.

Le secret pour que cela fonctionne bien est, dans l'ordre :
1) le respect du modèle relationnel
2) une RAM adéquat à la taille de la fenêtre de données
3) une bonne indexation

1) le respect du modèle relationnel
Avez vous respecté toutes les formes normales (1, 2, 3, FNBC, 4, 5, FNDC...) ?
Si ce n'est pas le cas, vous avez donc de la redondance et donc un volume de données trop important !
Remodélisez !

2) une RAM en adéquation
Les données de toutes les requêtes manipulées dans le SGBDR doivent être en mémoire pour pouvoir être traité. Il n'est pas possible pour le SGBDR de traiter une requête si elle n'est pas en RAM. Dans le cas ou les données ne sont pas en RAM, le SGBRD commence par les y placer avant de faire la requête. SI votre RAM est trop juste cous consommez du disque. Or la différence de vitesse entre RAM et disque est de l'ordre de 1000 fois minimum (souvent 10000...)

3) une bonne indexation
Un index permet de réduire de manière logarithmique les lectures lors de recherches, des tris, des groupages notamment. En l'absence d'index, le coût et exponentiel !
Lisez l'article que j'ai écrit sur l'indexation : http://sqlpro.developpez.com/cours/quoi-indexer/

A +

[souf_87]

Merci pour votre reponse
Je voulais savoir aussi est ce qu'il a un logiciel a télécharger pour connaitre les requetes qui ramennent bcp de lignes,les requetes qui nécessitent de manipuler bcp de données dans la base de données comme v$sql ou AWR statspack sur oracle meme si je c pas comment il marche.
Pour connaitre les statistiques

[bustaf]

Bonsoir
Lisez la section (EXPLAIN) dans la documentation.
Cordialement

[scheu]

Merci pour votre reponse
Je voulais savoir aussi est ce qu'il a un logiciel a télécharger pour connaitre les requetes qui ramennent bcp de lignes,les requetes qui nécessitent de manipuler bcp de données dans la base de données comme v$sql ou AWR statspack sur oracle meme si je c pas comment il marche.
Pour connaitre les statistiques

Tu seras vite limité, au jour d'aujourd'hui sur Postgresql tu ne trouveras jamais un seul outil aussi performant que le Statpack/AWR d'Oracle.
Il existe néanmoins quelques outils utiles qui peuvent te permettre, dans le meilleur des cas (seulement dans les dernières versions de Postgresql), de:
- tracer les requêtes les plus longues et les sortir sous forme de rapport avec par exemple pgfouine
- avoir les plans d'exécution de ces requêtes avec la contrib autoexplain
- avoir les statistiques d'utilisation des différents objets (nb d'updates dans une table, nb de lignes ramenées au total issu de requêtes "select", nb d'accès I/O sur un index, ...) avec les vues système pg_stat_* et pg_statio_*

Après, il faut coupler les points précédents avec la supervision OS (CPU, mémoire, disques) pour essayer de trouver les pistes d'optimisation possibles (réécriture de requêtes, ajout de RAM, ...)

Bref les problèmes d'optimisation sont rarement simples à investiguer, d'autant plus sur Postgresql (comparé à des SGBDs payants comme Oracle qui disposent d'outils te sortant en quelques clics les requêtes les plus longues et le temps passé en CPU, I/O, ...)