Utilisez simplement Postgres partout

 (amazingcto.com)
50 points par xguru 2022-12-13 | 13 commentaires | Partager sur WhatsApp
  • Postgres peut remplacer de nombreuses technologies backend (jusqu’à des millions d’utilisateurs)
    → Kafka, RabbitMQ, Mongo, Redis, ..
  • Pour le cache, utiliser du TEXT au format JSON dans des tables UNLOGGED au lieu de Redis
    • Définir une durée d’expiration pour les données avec des procédures stockées
  • File de messages (Kafka) : SKIP LOCKED
  • Pour l’entrepôt de données, utiliser Postgres + TimescaleDB
  • Au lieu de Mongo, stocker du JSONB et utiliser la recherche ainsi que l’indexation
  • Utiliser pg_cron comme démon CRON pour l’envoi d’e-mails, par exemple
  • Utiliser pour les requêtes géospatiales
  • Utiliser pour la recherche full-text à la place d’Elastic
  • Générer du JSON dans la base de données pour le transmettre directement à l’API sans code côté serveur
  • Support de GraphQL également via un adaptateur GraphQL

À lire aussi

13 commentaires

 
bbulbum 2022-12-15

Hum… il semble que l’idée de base soit que Postgres suffit, à moins d’avoir besoin de davantage de fonctionnalités prises en charge par chaque application.
Après tout, chaque application peut utiliser plus de fonctionnalités que le flux remplacé ci-dessus.
 
colossus 2022-12-14

Je pense que ce n’est pas si absurde, à condition de bien définir l’interface. Cela dit, je trouve qu’on peut tout à fait laisser Redis gérer au moins le cache et la file de messages.
 
gninggoon 2022-12-14

Moi aussi, j’ai récemment eu une réflexion similaire à celle de l’article ci-dessus. Bien sûr, pour des services à grande échelle, il vaut mieux répartir au maximum pour distribuer les risques, mais lors de petites missions en sous-traitance, le fait d’utiliser le type jsonb de Postgres sans recourir à un NoSQL séparé s’est souvent révélé bien plus polyvalent. On obtenait une expérience proche d’un usage combiné de RDB + NoSQL, avec des performances largement suffisantes dans de petits projets.
 
a9t84j1k5j2j1 2022-12-13

À force de tout faire avec un seul outil, tous les points de risque se retrouvent au même endroit... !
 
ehlegeth 2022-12-13

À l’époque où il n’existait pas vraiment de produits de remplacement, certaines de ces tâches étaient effectivement réalisées avec un SGBDR, mais pour Redis, Kafka ou Cron, on dirait que cela ne remplace pas leurs principaux avantages. Cela ressemble surtout à une idée amusante à parcourir pour le plaisir.
 
ifmkl 2022-12-13

Ça devrait parfaitement convenir à ceux qui aiment tout faire avec un seul outil.
 
s0400615 2022-12-13

J’utilisais Postgres pour le géospatial.
C’était environ 10 à 100 fois plus rapide que les autres bases de données. Sur le volet géo, c’était vraiment écrasant.

En revanche, comme tout le monde le sait, quand le volume de données augmente et que le vacuum tourne mal, c’est l’enfer...
 
kbumsik 2022-12-13

Oh, il y a pas mal d’astuces.

Cela dit, pour la première combinaison entre UNLOGGED et les procédures stockées, j’ai l’impression qu’utiliser Redis serait bien plus propre, haha.
 
youknowone 2022-12-13

C’était il y a quelques années, mais j’avais déjà travaillé en utilisant JSONB, puis quand la charge devenait trop importante, en choisissant ce qui correspondait au modèle clé-valeur pour le déporter vers Redis, et ça avait été une expérience très agréable.
 
sangheon 2022-12-13

C’est une opinion intéressante.
 
xguru 2022-12-13

Le titre est accrocheur, mais le sujet mérite quand même réflexion, donc je l’ai repris tel quel.
Après tout, introduire trop de composants dès le MVP initial peut aussi être un problème.
 
jujumilk3 2022-12-13

Cela semble être un bon concept.
 
devo209 2022-12-20

Merci.