With the same algorithms. Not "close enough." The same fuck*ng algorithms.
(…)
Postgres has been doing this since before your startup existed. It will be doing it long after your Redis instance crashes.
En tout cas, rechercher la simplicité, ça me parle et dans un certain sens, ça semble s'y atteler: 1 service vs 7.
Maintenant, je suis hésitant: D'une part, c'est un peu à l'encontre du principe "un outil pour une tâche". Ensuite, si le serveur Postgres tombe en rade, c'est tous les autres services qui tombent aussi.
Et puis c'est surement pas aussi simple que ça :)
Merci pour le lien, fendard et intéressant. Je vais continuer d’explorer.
"Si tous les cons volaient, il ferait nuit" F. Dard
D'une part, c'est un peu à l'encontre du principe "un outil pour une tâche".
Si tu considères PG comme un outil : oui. Mais si tu considères l'extension PG comme un outil, tu auras presque un outil pour une tâche ;-)
Ensuite, si le serveur Postgres tombe en rade, c'est tous les autres services qui tombent aussi.
J'ai toujours été étonné du nombre d'applications distribuées qui étaient développées en considérant implicitement que "le Kafka" ou "le microservice-dont-j'ai-besoin" ne tombe jamais. Quand ça arrive, tu te rends compte que tu as juste un monolithe distribué.
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.
Le propos/argumentaire est un peu radical ; mais je pense que, comme beaucoup de règles, ça doit pouvoir se discuter au cas par cas… Je pense en fait que ça s’applique à la majorité (≠ tous) des projets de petite et moyenne taille que l’on croise souvent.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
disons que pour un projet simple, j'ai vraiment du mal à comprendre pourquoi il faudrait toute cette pile de technos (je n'y connais pas grand chose en fait).
La preuve, je n'ai pas trop idée de ce que c'est un moyen projet ;)
Concernant les gros projets, l'auteur admet honnêtement que ça va pas le faire pour imaginer concurrencer la machinerie Spotify !
J'en suis là.
"Si tous les cons volaient, il ferait nuit" F. Dard
Ce n'est pas ce qu'il a dit, je pense qu'il faut comprendre que les services tombent comme des dominos s'ils ne sont pas conçus pour fonctionner en cas de défailllance de l'un d'eux.
Un ".com", un site - blindé de React, pour plaider la simplicité, ça se pose là, derrière cloudflare, une invitation à "spread the word" sur github. Je me demande ce que cherche l'auteur : un peu de notoriété ?
Sur le fond
Rien de bien nouveau : oui PG est un système de stockage très puissant et qui pourra aller très loin en charge avant de nécessiter de séparer les usages.
# You need more than a database
Posté par devnewton 🍺 (site web personnel) . Évalué à 4 (+1/-0).
ElasticOpenSearch vient avec une IHM (OpenSearch Dashboard) qui n'a pas d'équivalent dans Postgresql, une gestion des permissions fines, des alertes…Airflow aussi a une belle IHM, permets de lancer tout type de programme, de gérer des dépendances…
Reconstruire tout ça par dessus Postgresql est possible, mais demande beaucoup de travail.
// et puis de toute façon, c'est pas l'équipe BUILD qui se réveille à 3h du mat /o\
Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board
[^] # Re: You need more than a database
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 6 (+4/-0).
Ah oui, il faut adjoindre sqlpage à la babase
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# Argumentaire séduisant
Posté par Luc-Skywalker . Évalué à 3 (+1/-0).
En tout cas, rechercher la simplicité, ça me parle et dans un certain sens, ça semble s'y atteler: 1 service vs 7.
Maintenant, je suis hésitant: D'une part, c'est un peu à l'encontre du principe "un outil pour une tâche". Ensuite, si le serveur Postgres tombe en rade, c'est tous les autres services qui tombent aussi.
Et puis c'est surement pas aussi simple que ça :)
Merci pour le lien, fendard et intéressant. Je vais continuer d’explorer.
"Si tous les cons volaient, il ferait nuit" F. Dard
[^] # Re: Argumentaire séduisant
Posté par bbo . Évalué à 4 (+2/-0).
Si tu considères PG comme un outil : oui. Mais si tu considères l'extension PG comme un outil, tu auras presque un outil pour une tâche ;-)
J'ai toujours été étonné du nombre d'applications distribuées qui étaient développées en considérant implicitement que "le Kafka" ou "le microservice-dont-j'ai-besoin" ne tombe jamais. Quand ça arrive, tu te rends compte que tu as juste un monolithe distribué.
[^] # Re: Argumentaire séduisant
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 6 (+4/-0).
Au lieu d’un SPOF (single) on a créé un SPOF (seven) (:
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Argumentaire séduisant
Posté par Luc-Skywalker . Évalué à 2 (+0/-0).
je comprends, mais j'imagine que c'est moins "plug and play" qu'un Redis ou
"Si tous les cons volaient, il ferait nuit" F. Dard
[^] # Re: Argumentaire séduisant
Posté par bbo . Évalué à 6 (+5/-1).
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 Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3 (+1/-0).
Le propos/argumentaire est un peu radical ; mais je pense que, comme beaucoup de règles, ça doit pouvoir se discuter au cas par cas… Je pense en fait que ça s’applique à la majorité (≠ tous) des projets de petite et moyenne taille que l’on croise souvent.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Argumentaire séduisant
Posté par Luc-Skywalker . Évalué à 4 (+2/-0).
disons que pour un projet simple, j'ai vraiment du mal à comprendre pourquoi il faudrait toute cette pile de technos (je n'y connais pas grand chose en fait).
La preuve, je n'ai pas trop idée de ce que c'est un moyen projet ;)
Concernant les gros projets, l'auteur admet honnêtement que ça va pas le faire pour imaginer concurrencer la machinerie Spotify !
J'en suis là.
"Si tous les cons volaient, il ferait nuit" F. Dard
[^] # Re: Argumentaire séduisant
Posté par Psychofox (Mastodon) . Évalué à 4 (+2/-1).
Nul part il est dit que tout devait tourner sur la même instance.
[^] # Re: Argumentaire séduisant
Posté par geegeek . Évalué à 2 (+1/-0).
Ce n'est pas ce qu'il a dit, je pense qu'il faut comprendre que les services tombent comme des dominos s'ils ne sont pas conçus pour fonctionner en cas de défailllance de l'un d'eux.
[^] # Re: Argumentaire séduisant
Posté par steph1978 . Évalué à 3 (+1/-0).
Si c'est pour avoir sept instances de PG toutes configurées différemment, ça ruine un peu le propos de départ.
[^] # Re: Argumentaire séduisant
Posté par Luc-Skywalker . Évalué à 2 (+0/-0).
on est d'accord
"Si tous les cons volaient, il ferait nuit" F. Dard
# CV ?
Posté par steph1978 . Évalué à 5 (+4/-1).
Sur la forme
Un ".com", un site - blindé de React, pour plaider la simplicité, ça se pose là, derrière cloudflare, une invitation à "spread the word" sur github. Je me demande ce que cherche l'auteur : un peu de notoriété ?
Sur le fond
Rien de bien nouveau : oui PG est un système de stockage très puissant et qui pourra aller très loin en charge avant de nécessiter de séparer les usages.
[^] # Re: CV ?
Posté par Luc-Skywalker . Évalué à 4 (+2/-0). Dernière modification le 08 mars 2026 à 00:29.
toutafé, il a compris les ficelles
toutafé, il a compris l'essentiel
"Si tous les cons volaient, il ferait nuit" F. Dard
[^] # Re: CV ?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3 (+2/-1).
compris ou découvert l’essentiel (il y a comme l’enthousiasme des nouveaux venus)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: CV ?
Posté par steph1978 . Évalué à 2 (+0/-0).
Enthousiasme probablement feint ; sinon, je lui revendrai facilement youjustneedsqlite.com.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.