Re: [

> Pour pouvoir utiliser une architecture telle que tu la proposes il faut que
> pg gère le clustering d'instances ( le RAC d'oracle) et à ma connaissance
> ça n'est pas le cas.

Effectivement! Ça n'est pas encore le cas. Pour avoir un cluster de ce type, il
faut que PostgreSQL possède le Two Phase Commit. C'est un élément qui figure
depuis quelques années dans la TODO list. À ma connaissance, certains ont
commencé sur le sujet... Notament, pour sa réplication synchrone (Slony-II), Jan
Wieck devra bien s'y coller :)

> Une autre solution est peut-être de partionner "logiquement" les tables et
> de les mettre dans des bases différentes (et donc si nécessaire dans des
> instances voir des serveurs différents)
>
> Exemple:
> Une table TABLE1 est découpée en TABLE1_JANVIER, TABLE1_FEVRIER,
> TABLE2_FEVRIER...
> Et dans les services métiers implémenter le test sur la date d'insertion
> ...

Oui, diviser pour mieux reigner...

En fait cette approche à palier à des insuffisances d'un Sgbd (ou un autre) avec
des "recettes" basées sur des "logiques métier" (aka fonctionelles ou
applicatives) s'impose souvent dans des systèmes mal réfléchis dès le départ, où
on n'a pas trouvé mieux pour "sauver le SI" sans le détruire... (ce n'est pas
une critique cinglante, c'est juste un constat que j'ai souvent fait sur le
terrain).

Dans le même style, on peut faire des bdd avec seulement des tables en
lecture... Dont la pluspart sont cachées en Ram. Garder les tables où il y a
bcps d'écritures pour le/les système(s) où on a privilégié la rapidité des IO.

Dans des cas critiques, on peut créer une table par jour, en suffixant le nom de
la table par une date iso, par exemple DATA_CAPTEUR => DATA_CAPTEUR_YYYYMMDD
On peut bien sûr réduire encore en créant une table par heure... S'il s'agit de
réduire la volumétrie des tables 'maitresses' de la base..

Il y a plein de "recettes" de ce type là...

La moins pire à mon sens est le principe de la "base archive" ou "base morte"
qui contient les tuples que l'on ne peut pas effacer pour une raison ou une
autre (souvent pour des raisons légales ou liées au métier..): on accepte dans
ces cas là des performances minables sur cette base, en ayant à l'esprit qu'elle
contient 90% des tuples du SI. Par contre, la base "vive" ou "active", soulagée
de tous ces tuples "poids morts", est plus rapide..

Perso, j'approuve pas vraiment toutes ces recettes : il s'agit de
contournements d'impossibilités techniques. On se retrouve souvent à mettre à la
poubelle tous ses développements lorsque *la* fonctionalité qui manquait sort
enfin... c'est domage, non? :) De même, dans bien des cas, on arrive à des
complications qu'on attendait pas...

Alors?

Si ça peut te rassurer, tu ne serais pas le 1er à avoir des bases de données de
plusieurs Térabytes sous PostgreSQL. Par exemple, vas lire ce mail, qui date
d'aout 2002:

http://archives.postgresql.org/pgsql-advocacy/2002-08/msg00005.php

"The American Chemical Society - The largest professional organization of
Chemists in the world, with over 165,000 members, and a website that
receives more than 12 million visits every day. Their Journal Archive
stores 125 years of full publications (2.5 million pages, more than 1
terabyte of data) using PostgreSQL."

En cherchant un peu, on trouve sur Techdocs d'autres témoignages:

http://techdocs.postgresql.org/techdocs/supportcontracts.php

A mon sens, la solution est souvent liée à l'activité de la base. On peut très
souvent s'alléger de quelques millions de tuples avec des règles simples. Par
exemple, dans le cas de SI alimentés par des capteurs (au hasard! ;)...), on
peut réduire de manière dramatique le nombre de tuples en appliquant des modèles
mathématiques aux données. ... Concrêtement, cela revient à de la compression :)
... reste à savoir si on s'autorise à perdre un peu de la précision ou pas
(compression à la huffman ou pas..)..

C'est toujours au cas par cas, il y a toujours de compromis à faire..

Bon courage!

--
Jean-Paul ARGUDO

Site perso : http://www.argudo.org
PostgreSQL : http://www.postgresqlfr.org
l'APRIL : http://www.april.org