Vous n'êtes pas identifié(e).
Pages : 1
Salut à tous,
Je bosse sur un moteur 9.2 sous Cent-OS.
J'ai une BD dans laquelle une table est fortement sollicitée.
Un enregistrement de cette table fait environ 700 octets.
Un enregistrement contient un champ JOUR de type DATE.
15 à 20000 INSERT/JOUR.
18 mois sont gardés "en ligne".
Environ 1000 utilisateurs peuvent faire du SELECT, au travers d'une application WEB, à différents moments de la journée, pour voir le boulot qu'ils ont fait sur J, J-1 et jusqu'à J-8.
Une application Java fait les insertions la nuit, à partir d'infos d'autres tables.
Environ 50 P.C font des ajout/modification/suppression chaque jour, généralement sur J-1 mais aussi jusqu'à J-15 (peu de volume mais reste connectés).
A peu près autant de P.C peuvent faire des extractions de données, à n'importe quel moment de la journée, sur des périodes divers (à la semaine, au mois, ...).
Ce système fonctionne sur 10 Sites et il doit être prochainement centralisé sur un seul serveur.
Je cherche des pistes pour absorber la charge et garder des temps de réponse performants ?
J'ai déjà quelques idées :
- Créer la table dans un schéma par Site,
- Faire du partitionnement sur le JOUR,
- Peut être utiliser une table intermédiaire pour séparer l'utilisation "journalière" des extractions (peut être avec aggrégation de données).
J'espère avoir fourni suffisamment d'infos.
Que pensez-vous de ces idées ?
Avez-vous d'autres pistes à me proposer ?
D'avance merci pour votre aide.
Hors ligne
Avez-vous déjà implémenté quelque chose ? et dans ce cas, quels en sont les performances ?
Parce que cette marée de chiffres ne veut pas dire grand-chose en soi. PostgreSQL peut très bien le supporter comme ne pas le supporter. C'est impossible de le dire à partir de votre texte.
La seule chose que je peux dire, c'est que vous ne pourrez pas avoir 1000 utilisateurs connectés directement à PostgreSQL et exécutant une requête en même temps. Par contre, via un pooler comme pgBouncer, vous devriez y arriver.
Guillaume.
Hors ligne
Pages : 1
