Re: Utilisation du SSD

Le mardi 4 décembre 2012 09:11:03, Guillaume Lelarge a écrit :
> On Mon, 2012-12-03 at 15:59 -0800, Samuel ROZE wrote:
> > Le lundi 3 décembre 2012, Guillaume Lelarge a écrit :
> > "PostgreSQL, quand ce n'est pas votre métier", donné à l'AFUP
> > de Lyon.
> > Pour les slides, c'est sur
> > http://www.dalibo.org/postgresql_quand_ce_n_est_pas_votre_metier.
> >
> > Salut Guillaume,
> >
> >
> > Dans ce cas là, pourquoi déconseilles-tu l'utilisation du SSD?
> > Un tablespace dans lequel les données les plus lues sont présentes sur
> > ce type de disque peut pourtant améliorer très significativement les
> > performances!
>
> Un SSD améliore fortement les performances, il n'y a aucune doute
> là-dessus. Le problème est toujours la fiabilité de ce type de disque.
> Même si certains ont fait de gros progrès là-dessus, j'ai
> personnellement toujours un doute. De plus, vu le prix à la volumétrie,
> le choix se ne se porte pratiquement jamais sur les plus coûteux qui
> offrent généralement la meilleure qualité.
>
> Évidemment, tout ceci n'est pas très précis ("pratiquement",
> "généralement"). C'est ce qui m'a été donné de voir ou de lire. Vous
> trouverez toujours un SSD qui sera rapide, fiable et pas trop coûteux.
> Mais dans la majorité des cas, ce n'est pas vrai. Et du coup, je préfère
> dire "Attention à ce que vous achetez, évitez le SSD si vous pouvez" que
> "oui, pas de soucis, ce sont vos données après tout, pas les
> miennes :)".
>
> Pour faire bref, en grosse maille, je préfère conseiller d'éviter les
> SSD. Si jamais le système nécessite de très grosses performances, il est
> possible de les utiliser mais en choisissant bien son disque, en le
> testant fortement avant de le mettre en production.
>
> Encore une fois, c'est uniquement mon opinion.

Dans le cadre d'une utilisation plus avancée de PostgreSQL, le risque décroît,
Par exemple dans un cluster de plusieurs serveurs avec une réplication active.

On se dirige de plus en plus sur de la réplication ce qui permet réduire le
besoin de durabilité locale d'un serveur. En cas de crash, on bascule de toute
façon sur le prochain standby.

La durabilité est de plus achevée avec un archive continu par flux par exemple.
Si l'on a un seul serveur, le risque peut sembler plus important, mais c'est à
la mesure de la politique de sauvegarde mise en place...

Le cas le plus grave que nous ayons eu à fixer est une perte simultanée de 2
cartes fusionIO (en RAID1). Ca remonte maintenant....

Et très sincèrement le même problème existe aussi avec des disques durs (perte
simultanée), bien que la récupération de données sur disques durs soit plus
facile. Les conseils dans les achats sont de prendre des matériels issus de
différents lots (ainsi on réduit les chances de perte simultanée liée à un
problème de fabrication ou autre). Un bon intégrateur le fait naturellement,
on peut aussi le spécifier.

Niveau performances, il faut comparer avec un RAID10 et de plus nombreux
disques durs, cela peut-être plus intéressant pour certains type de charge.
J'utilise des iRAM et autres dans des serveurs de bases de données depuis des
années, et j'en suis bien content (il y a rarement juste un serveur
primaire... un ou des standbys très véloces c'est bien pratique aussi)
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation