PostgreSQL, la quatrième base de données et SGBD le plus populaire de l'année en 2017, a explosé en popularité parmi les communautés de développement et de bases de données à travers le monde. Volant des parts de marché aux leaders Oracle, MySQL et Microsoft SQL Server, l'hébergement PostgreSQL est également fortement exploité par de nouvelles entreprises dans des domaines passionnants tels que l'IoT, le commerce électronique, le SaaS, l'analyse, etc.
Alors, quelle est la tendance dans la gestion PostgreSQL ?
Nous avons participé à PostgresOpen à San Francisco le mois dernier pour découvrir les dernières tendances des experts eux-mêmes.
Tâches de gestion PostgreSQL les plus chronophages
Alors, qu'est-ce qui vous prend du temps sur le front de la gestion de PostgreSQL ? Bien qu'il existe des milliers de tâches impliquées dans la gestion de vos déploiements de production PostgreSQL, la gestion des requêtes était le leader avec plus de 30 % des répondants.
La gestion de l'espace arrivait loin derrière, 15 % des utilisateurs de PostgreSQL la considérant comme leur tâche la plus difficile, suivie de la réplication, des mises à niveau et de la surveillance. 23 % des utilisateurs de PostgreSQL appartenaient à la catégorie "Tous les autres", composée de tâches telles que l'application de correctifs, les récupérations, le partitionnement et les migrations.
Gestion de la répartition des requêtes PostgreSQL
Avec l'avance sur la gestion des requêtes PostgreSQL, nous avons approfondi pour voir quelles tâches spécifiques prenaient leur temps. Les résultats se sont répartis sur l'ensemble du processus de gestion des requêtes, de la structuration lors de la configuration à l'optimisation après analyse.
Pour expliquer cela plus en détail, commençons par le début du processus de gestion des requêtes :
Structure de la requête
Le plus petit segment, la gestion des structures de requête, représentait 22 % des réponses des utilisateurs de PostgreSQL qui ont sélectionné les requêtes comme leur tâche de gestion la plus chronophage.
Avant de commencer, vous devez créer un plan de requête PostgreSQL autour de vos clusters pour faire correspondre votre structure de requête avec vos propriétés de données. Ceux-ci se composent de nœuds, allant des nœuds d'analyse au niveau inférieur pour les retours de table de lignes brutes, ainsi que des lignes non-tables telles que des valeurs.
Analyse lente des requêtes
Une fois que vous avez établi votre structure, l'étape suivante consiste à analyser vos requêtes pour identifier les requêtes lentes qui peuvent affecter les performances de votre application. Par défaut, les "requêtes lentes" sont définies comme des requêtes qui durent plus de 100 ms.
Optimisation des requêtes
Maintenant que vous avez identifié vos requêtes lentes, le vrai travail commence :optimiser vos requêtes PostgreSQL. Le réglage des performances de Postgres peut être une tâche épouvantable, mais avec une identification et une analyse appropriées, vous pouvez vous concentrer sur les goulots d'étranglement et apporter les modifications de requête nécessaires et ajouter des index si nécessaire pour améliorer votre exécution. Voici un excellent article sur les requêtes de réglage des performances dans PostgreSQL.
Dernières tendances PostgreSQL :tâches les plus chronophages et métriques importantes pour suivreClick To Tweet
Métriques les plus importantes à suivre pour les performances de PostgreSQL
Maintenant que nous avons identifié la tâche de gestion PostgreSQL qui prend le plus de temps, examinons plus en détail les métriques importantes que les utilisateurs de PostgreSQL suivent pour optimiser leurs performances.
Les résultats des métriques PostgreSQL les plus importantes étaient nettement plus uniformes que les tâches de gestion, ce qui a entraîné un lien à quatre voies entre les statistiques de réplication, l'utilisation du processeur et de la RAM, les transactions par seconde (TPS) , et requêtes lentes :
Statistiques de réplication
Surveiller l'état de votre réplication PostgreSQL est une tâche cruciale pour garantir que vos réplications sont correctement exécutées et que vos déploiements de production restent hautement disponibles. Le processus de réplication doit être personnalisé pour répondre au mieux aux besoins de votre application, et la surveillance continue des terminaux est le meilleur moyen de garantir que vos données sont sécurisées et prêtes à être récupérées.
Il est important de suivre les métriques à la fois sur vos serveurs de secours et sur vos serveurs principaux. Vos serveurs de secours doivent être surveillés pour la réplication entrante et l'état de récupération, et vos serveurs principaux doivent être surveillés pour la réplication sortante et les emplacements de réplication. Si vous utilisez la réplication en continu PostgreSQL, les emplacements de réplication ne sont pas toujours requis. La réplication en continu garantit la disponibilité immédiate des données sur vos serveurs de secours et est idéale pour les serveurs à faible TPS.
Utilisation du processeur et de la RAM
Le suivi de l'utilisation de votre CPU et de votre RAM (mémoire) sont des mesures cruciales à surveiller pour garantir la santé de vos serveurs PostgreSQL. Si votre utilisation CPU est trop élevée, votre application connaîtra des ralentissements faisant souffrir vos utilisateurs. C'est souvent le résultat de requêtes mal optimisées, voire de parallélismes de requêtes élevés. La surveillance de la RAM est très importante pour vous assurer que vous disposez de suffisamment d'espace disque et pour comprendre exactement à quoi sert votre RAM. Il est recommandé d'allouer environ 25 % de votre mémoire aux buffers_partagés. PostgreSQL définit également par défaut la taille de la mémoire tampon de travail sur 4 Mo, ce qui est souvent trop petit et entraîne des temps d'exécution élevés.
Transactions par seconde
La surveillance du nombre de transactions par seconde vous permet de déterminer la charge sur le système et le débit actuel. En analysant cette métrique, on peut décider d'adapter le système en conséquence pour atteindre le débit souhaité. Vous pouvez également déterminer comment une modification des paramètres de configuration ou des ressources système affecte le débit.
Requêtes lentes
Des requêtes inefficaces peuvent ralentir les performances de PostgreSQL même si le système est configuré avec des ressources adéquates. C'est toujours une bonne pratique d'analyser ces requêtes inefficaces et de les corriger. PostgreSQL fournit un paramètre appelé log_min_duration_statement . Lorsque cette option est définie, la durée de chaque instruction terminée est enregistrée si l'instruction a été exécutée pendant au moins le nombre de millisecondes spécifié. Une fois les requêtes lentes obtenues, vous pouvez exécuter EXPLAIN ANALYZE pour comprendre le plan d'exécution. Cela vous permettra de suivre le problème et d'optimiser la requête en conséquence. Par conséquent, la surveillance régulière des requêtes lentes évitera la lenteur des performances.
Retrouvez-nous la semaine prochaine à l'événement PostgresConf Silicon Valley 2018 où nous espérons découvrir plus d'informations sur les tendances dans l'espace de gestion PostgreSQL. Si vous avez des questions ou des commentaires, n'hésitez pas à les partager avec nous ici dans nos commentaires ou sur Twitter à @scalegridio.
