Communauté francophone de PostgreSQL

La communauté francophone de PostgreSQL

Outils pour utilisateurs

Outils du site


pgday2008:gsmet

4 ans de PostgreSQL chez Cityvox

Introduction

  • *Très* rapide présentation de ma personne, d'OW et de PostgreSQL chez OW
  • Présentation de Cityvox et panorama de la galaxie des sites Cityvox

Génèse du projet

  • Il s'agit d'une migration complète de Apache/Vignette/Oracle vers PHP/PostgreSQL
  • Pourquoi cette migration ? Quels enjeux ?
  • Pourquoi PostgreSQL ?

Sortir du monde Oracle

  • Migration de la base pénible car peu d'outils
  • Migration du schéma
  • Migration des données, extraction des photos de la base
  • Problèmes rencontrés
  • Quels composants aujourd'hui pour faciliter ces migrations ?

La transition vers PostgreSQL

  • Réécriture des requêtes
  • Prise en main par le client
  • Ce qui a marqué le client lors de sa prise en main

L'architecture complète

  • Avant / Après
  • Ensemble des composants Open Source mis en oeuvre

La mise en production

  • Janvier 2005
  • Un succès total

Les premiers soucis

  • Problème de scalabilité de la version 7.4 sur les architectures quadri Xeon : très difficile à quantifier jusqu'à la mise en orbite du site pour la St Valentin 2006.
  • Explosion du site suite à la lenteur de certaines requêtes : manque de visibilité sur ce qu'il se passe sur la base : quelles requêtes posent problèmes ? Comment diagnostiquer ?
  • Le cache du site était sous forme de fichiers / serveur : problème de scalabilité. On éteignait des serveurs pour mieux tenir la charge…
  • SPOF sur la base de données - on se repose sur les sauvegardes

Et des solutions

  • Migration vers la version 8.1 : une seconde jeunesse
  • Quelques rapports PQA, Thomas Favier d'Accelance MSP contribue à permettre l'usage de PQA sur des sites à forte charge. Réécriture complète de PQA sous la forme de pgFouine afin d'en régler les problèmes structurelles : industrialisation de la génération des statistiques
  • Mise en place de Memcached pour avoir du cache distribué (avec quelques ratés)
  • Mise en place d'un serveur PostgreSQL en standby

Jusqu'à un autre souci

  • On commence à voir apparaître de grosses lenteurs sur le site sans croissance du nombre de visiteurs (mesure estat)
  • Aucun problème de lenteur spécifique
  • Difficulté à analyser les logs de par leur taille et la diversité des URLs (AWStats et Webalizer ont du mal) → peu de visibilité
  • Après quelques temps, on se rend compte que c'est Google qui génère un trafic énorme
  • Décision de mettre en place un serveur web et un réplicat quotidien de la base de données dédiés à Google
  • Dommage qu'on ne puisse accéder en lecture au serveur en standby…

Quelques lenteurs chroniques sur des requêtes

  • Requêtes géographiques : on met en place cube et earthdistance : mieux mais pas totalement satisfaisant car répartition très inégale et statistiques constantes
  • Recherche plein texte dans le backoffice : quelques essais sont faits avec tsearch2 mais complexe à maintenir (les joies des migrations de contrib/) et toujours en dessous de Lucene

Après 3 ans, on atteint les limites

  • de garantie…
  • de performances principalement au niveau de la base de données
  • de flexibilité et de capacité à maintenir une plate-forme qui a beaucoup évolué en 3 ans (principalement au niveau des applications périphériques)
  • bon timing pour le passage en 8.3 qui promet beaucoup

Refonte totale

  • on a beaucoup appris en 3 ans, on en profite pour régler tous les problèmes structurels :
  1. utilisation des delay_pools de Squid 2.6 pour canaliser les robots d'indexation : plus de serveur dédié et de base dédiée (manque de test lors des mises en production de nouveaux sites, *..)
  2. recentralisation de tous les sites sur les serveurs frontaux principaux : plus de fiabilité mais aussi plus de connexions parallèles
  3. utilisation de vservers pour contenir toutes les applications périphériques
  4. mise en place de toutes les bonnes pratiques PostgreSQL du moment

Les bonnes pratiques PostgreSQL

  • en 3 ans, PostgreSQL s'est très industrialisée
  • mise en place de l'autovacuum
  • mise en place de phpPgAdmin
  • mise en place de pgBouncer (merci Skype) pour limiter le nombre de

connexions à la base

  • mise en place de walmgr (Skytools, merci Skype) pour gérer le warm standby
  • mise en place de PostGIS pour les requêtes géographiques
  1. l'ensemble en packaging RPM

La validation de la montée de version PostgreSQL

  • étalée sur plusieurs mois en amont de décembre (date de sortie prévue)
  • détection de régressions au cours du cycle de test, régressions très

vite corrigées (je donnerai le détail)

  • le retard de la sortie de la 8.3 ne nous arrange pas…
  • mise en production le jour de la sortie de la 8.3, sécurisée par toute

la phase de test amont

  1. importance de cette démarche de test au cours de la phase de

développement

Les dernières réalisations

  • mise en place de Solr (serveur de recherche basé sur Lucene interrogeable en HTTP) pour adresser le besoin fonctionnel de recherche full text et proposer des moyens de navigation différents différents
  • forcément moins intégré à la BDD que tsearch2 mais état de l'art en ce qui concerne les fonctionnalités de recherche (faceting, recherche approximative…)

Mise en production de la nouvelle plate-forme

  • grande réussite en terme de performances, fiabilité, administrabilité de la plate-forme
  • PostgreSQL 8.3 est une grande release !

Conclusion globale

  • PostgreSQL a été le bon choix : tout au long de ces années, les nouvelles versions ont permis d'absorber la croissance du trafic
  • La confiance du client a été un des facteurs clés de réussite (choix initiaux, confiance dans la mise en production de la 8.3…)
  • La communauté PostgreSQL est une richesse : implication, disponibilité, qualité des échanges…
  • Elle a produit en 3 ans énormément d'outils de qualité permettant de régler des problèmes concrets.
pgday2008/gsmet.txt · Dernière modification: 2008/09/18 09:51 de sas