Discussion :

[mic79]

Bonjour,

actuellement je dispose d'un serveur avec un sql serveur d'installer dessus. ce dernier comprend une base de données d'environ de 15go (et oui) Je ne chiffre plus les données en milliers mais plutot en million.

pour des choix purement financier, je souhaite passer cette base sous un postgres (sous linux bien sur) et je souhaiterais savoir s'il tiendrais le coup.

Avez vous des liens ou des infos à me fournir concernant la solidité du postgres ?

par avance merci

Mic

[Spoutnik]

Salut,

15Go, c'est presque de la petite base.

Perso, pour un ancien projet, j'ai utilisé une base de 170Go environ en tables de 90 millions de lignes (15Go/tables).
Avec qq optimisations (quasiment pas de jointures et procédures stockées) j'avais un temps d'accès inférieur à 10ms sur un P4 2.6 et 1Go de ram sous RH9.
à terme, ca fera 300Go (voire plus?)
En charge, ce qui est net, c'est que mon disque dur n arrivait pas à suivre, du coup, je ne dépassais pas les 2000 lectures/ecritures par sec, mais bon, je suis parti avant la mise en place du RAID et c'est déjà pas trop mal

Donc, pas de problème, tu peux y aller les yeux fermés (à mon humble avis ).

[hpalpha]

Je pense aussi que tu peux y aller les yeux fermés.
Il faudra faire attention a bien reecrire tres vues et tes procedures stockées s'il y en a.

[mic79]

ok merci,

je c ce qu'il me reste à faire maintenant ;-), et moi qui penser etre tranquille la semaine prochaine... :-)

encore merci pour vos commentaires

Mic

[Celestos]

Bonjour à tous,

je relance le débat car je suis plutôt habitué à Oracle. Mais, je dois étudier le cas d'une base PostGreSQL 8.1 dont certaines tables auront plusieurs centaines de millions d'enrtegistrements (le maxi identifié étant de 1 500 000 000 lignes dans une table ce qui correspond à 10 ans de stockage).

La question que je me pose n'est pas d'ordre hardware (serveur octo pro, 16 Go Ram, baie de stockage dédiée), mais bel et bien si PostgreSQL ets capable de tenir une telle charge.

Merci d'avance de votre expertise.