Pour les quelques fonctionnalités n'impliquant pas d'extensions, c'est assez immédiat (genre les unlogged table) mais sinon, oui c'est probablement moins facile à mettre en œuvre (et c'était une boutade, j'aurai pu te dire "postgres ne fait qu'une chose : gérer tes données" 😄)
Juste, je constate que les devs (moi le premier) connaissent assez mal leur SGBDR (et le SQL en passant). Je ne vois pas pourquoi on connaîtrait mieux notre Kafka ou notre Redis 😅
Je ne comprends pas comment on augmenterait la résilience ou même la performance d'un système en ajoutant des outils spécialisés pour pouvoir continuer d'utiliser basiquement l'outil généraliste en place, juste pour ne pas avoir à apprendre à l'utiliser mieux.
Donc, même si c'est moins immédiat, j'en arrive à penser qu'il vaut mieux parfois investir un peu dans la connaissance de son SGBDR. Car il y aura quand même des problèmes de prod qui impliqueront de se plonger dedans.
Mettre un Redis pour quelques centaines de sessions ou un Kafka pour quelques millions des messages par mois, juste parce que c'était pas assez user-friendly de faire un peu de (dé)normalisation ou d'analyse de perfs ou de lire la doc, c'est faire un refus d'obstacle (avec probablement l'argument de "l'innovation" ou la "scalabilité-qui-n'est-pas-encore-là-mais-qui-viendra-un-jour-c'est-sûr" pour la bonne conscience).
Cela s'applique aussi plutôt bien si la prod est gérée par une équipe de runners. Souvent, ça ira sur le SGBDR mais ça commencera à piquer sur le Kafka (par exemple, c'est pareil avec un Solr ou OpenSearch). La prolifération de middleware va pousser les runners à se spécialiser et ça n'empêchera pas certains incidents de remonter à l'équipe de développement qui sera totalement désarmée si le problème n'est pas fonctionnel.
[^] # Re: Argumentaire séduisant
Posté par bbo . En réponse au lien YOU JUST NEED POSTGRES. Stop building your own distributed systems nightmare.. Évalué à 6.
Pour les quelques fonctionnalités n'impliquant pas d'extensions, c'est assez immédiat (genre les unlogged table) mais sinon, oui c'est probablement moins facile à mettre en œuvre (et c'était une boutade, j'aurai pu te dire "postgres ne fait qu'une chose : gérer tes données" 😄)
Juste, je constate que les devs (moi le premier) connaissent assez mal leur SGBDR (et le SQL en passant). Je ne vois pas pourquoi on connaîtrait mieux notre Kafka ou notre Redis 😅
Je ne comprends pas comment on augmenterait la résilience ou même la performance d'un système en ajoutant des outils spécialisés pour pouvoir continuer d'utiliser basiquement l'outil généraliste en place, juste pour ne pas avoir à apprendre à l'utiliser mieux.
Donc, même si c'est moins immédiat, j'en arrive à penser qu'il vaut mieux parfois investir un peu dans la connaissance de son SGBDR. Car il y aura quand même des problèmes de prod qui impliqueront de se plonger dedans.
Mettre un Redis pour quelques centaines de sessions ou un Kafka pour quelques millions des messages par mois, juste parce que c'était pas assez user-friendly de faire un peu de (dé)normalisation ou d'analyse de perfs ou de lire la doc, c'est faire un refus d'obstacle (avec probablement l'argument de "l'innovation" ou la "scalabilité-qui-n'est-pas-encore-là-mais-qui-viendra-un-jour-c'est-sûr" pour la bonne conscience).
Cela s'applique aussi plutôt bien si la prod est gérée par une équipe de runners. Souvent, ça ira sur le SGBDR mais ça commencera à piquer sur le Kafka (par exemple, c'est pareil avec un Solr ou OpenSearch). La prolifération de middleware va pousser les runners à se spécialiser et ça n'empêchera pas certains incidents de remonter à l'équipe de développement qui sera totalement désarmée si le problème n'est pas fonctionnel.