Vous n'êtes pas identifié(e).
Pages : 1
Bonjour à tous!
Je me pose des questions sur la scalabilité de Postgresql, est ce que c'est facile?
Avec mon équipe, nous créons une app, et pour le backend, nous avons choisi nodejs + postgresql.
Ce qui a de particulier je pense par rapport à ce qui se fait en général, c'est que nous avons fait le choix d'utiliser des procédures plsql pour la plus grosse partie de notre application.
On utilise postgresql + posgis pour le traitement géographique.
Globalement, pour chaque call qui arrive sur notre API, nous avons une fonction d'entrée associée dans la base de données.
L'idée était d'éviter d'avoir plein de micro-requette et des aller-retours entre nodejs et postgresql, ce que je trouvais pas très pratique.
Mais d'un point de vue performance, je n'ai aucune idée si c'est une bonne stratégie ?
Si les fonctions stockées existent, c'est quelles doivent bien remplir leurs roles!
Nous avons environ 60 tables, et 500 fonctions stockées.
Je recherche votre avis, et votre expérience.
Merci d'avance!
Hors ligne
Bonjour,
Il n'y a bien évidemment pas de réponse magique, mais de mon expérience il est tout à fait possible d'avoir de très bonnes performances avec postgres pour peu que vous fassiez les bons choix d'architecture.
Concernant le ppgsql, cela existe et cela remplit son rôle, mais son rôle est plutôt d'avoir un langage simple à apprendre et présentant beaucoup de ressemblance avec certains autres langages, plutôt que d'être axé sur les performances. Les plus gros problèmes de performances viennent généralement des parties "impératives" et évaluations des expressions. Si c'est un gros besoin pour vous, vous pourriez faire des tests de performance comparatifs avec d'autres langages, notamment plv8 qui pourrait se révéler plus rapide en plus d'être un langage que vous devriez déjà matriser.
Cela dit, il est tout à faot possible qu'une bonne configuration, mise en place d'un pooler applicatif, modèle de données adapté et touts les autres bonnes pratiques suffisent à rendre l'utilisation de plpgsql tout à fait acceptable pour vos besoins.
Julien.
https://rjuju.github.io/
En ligne
Merci pour ton retour julien,
As tu des conseils pour le choix d'architecture?
Pour l'instant, j'utilise docker, mais tu parles surement de hardware?
Globalement les performances sont assez bonne pour l'instant, ma peur vient plutôt pour la suite, lors d'une croissance rapide,
Est ce qu'il n'y a pas de risque de fil d'attente?
Merci pour la découverte de plv8 ! je ne connaissais pas.
Ma question pour être un peu plus direct : vaut mieux mettre le code dans la base de donnée, où le laisser en dehors, donc NodeJS?
En tout cas, la réponse me rassure, car je trouve que on développe rapidement avec psql car on est en contact avec la donnée
Hors ligne
Docker n'est à ma connaissance pas spécialement réputé pour ses performances non plus.
Je parlais plutôt d'architecture purement côté postgres (modèle bien pensé, formes normales, contraintes, index etc), et côté applicatif (requêtes bien écrites, éviter l'utilisation d'ORM, privilégier des requêtes ensemblistes à du traitement procédural...), que le code soit dans un client ou dans une procédure stockée, même si effectivement la configuration matérielle et logicielle du serveur est très importante.
J'imagine que vous avez implémenté avec des procédures stockées plpgsql une API, il devrait donc être relativement simple de simuler une montée en charge et voir comment cela se passe ? Si vous n'avez pas d'outil pour cela, il devrait être assez simple de faire un prototype rapide en utilisant pgbench (https://www.postgresql.org/docs/current/pgbench.html) vu que votre api est disponible en SQL.
Pour répondre à votre question, c'est vraiment au cas par cas. Il faut également prendre en compte qu'il est bien plus facile de déployer au besoin des dizaines d'applicatif stateless si le code est relativement gourmand alors que votre serveur de base de données nécessitera bien plus d'efforts.
Julien.
https://rjuju.github.io/
En ligne
Pages : 1
