mardi 8 juillet 2008

PostgreSQL SAN etc...

Intégrer PostgreSQL dans un système d'information est une chose qui est aisée. L'utilisation de systèmes de stockages évolués tels que les SAN est un des points souvent mis en avant sur un système d'information car il permet de prendre des «snapshots» d'un système de fichiers et le transférer sur une autre baie de stockage. Je travaille actuellement sur la mise en place d'une solution PostgreSQL répliquée dont les disques sont en partie détachés. Voici quelques réflexion à priori sur le sujet. Un retour d'expérience suivra d'ici quelques semaines.

Une des prérogatives d'une base de données est la performance. Le fait de placer un réseau entre le serveur PostgreSQL (la machine) et un stockage (iSCSI) peut induire des latences importantes pouvant être rédhibitoires d'un prime abord. Mais si nous y regardons de plus près, la performance (et la sûreté de fonctionnement) de PostgreSQL est essentiellement basée sur le mécanisme de Write Ahead Logging (WAL) et c'est la performance de cette fonctionnalité qu'il va falloir préserver. A priori il faudra donc que les fichiers de WAL (répertoire $PGDATA/pg_xlog) se trouvent sur un sous système rapide (et de préférence rapide en écriture). En parallèle, un des points que j'ai du mal à évaluer, est l'impact du placement des index sur une baie SAN. Est-ce le goulot d'étranglement à éviter ou non? Dans ce cas peut-on sacrifier la sûreté de fonctionnement sur l'autel de la performance ou doit-on l'inverse? Seuls les tests permettront de définir si oui ou non le compromis est envisageable et à quel prix.

Aucun commentaire: