Postgresql

Le champ de recherche de la médiathèque renvoyait des résultats en 800 millisecondes en staging. En production, il y avait quarante fois plus de lignes. Le plan d’exécution révélait un sequential scan: aucun index sollicité, aucune façon d’y remédier avec un B-tree classique. L’équipe produit voulait aussi une recherche multi-mots: taper “interview président”, obtenir des résultats contenant les deux termes. Une requête LIKE avec des wildcards n’a pas de manière propre d’exprimer ça sans conditions indépendantes multiples, chacune nécessitant son propre scan. ...

Chaque mise à jour de contenu sur la plateforme crée une révision. C’est délibéré : les éditeurs ont besoin d’un historique sur lequel ils peuvent revenir, et la plateforme a besoin d’une piste d’audit. Ce que personne n’avait anticipé, c’était le rythme. Certains articles passent par quarante sauvegardes en un seul après-midi. Une pièce à fort trafic accumule des centaines de révisions sur sa durée de vie. Après quelques mois, la table de révisions avait plusieurs millions de lignes. ...