Verwenden Sie einfach überall Postgres

 (amazingcto.com)
50 Punkte von xguru 2022-12-13 | 13 Kommentare | Auf WhatsApp teilen
  • Postgres kann zahlreiche Backend-Technologien ersetzen (bis hin zu Millionen von Nutzern)
    → Kafka, RabbitMQ, Mongo, Redis, ..
  • Für Caching statt Redis TEXT im JSON-Format in einer UNLOGGED-Tabelle verwenden
    • Die Ablaufzeit für Daten per Stored Procedure festlegen
  • Message Queue (Kafka): SKIP LOCKED
  • Data Warehouse mit Postgres + TimescaleDB
  • Statt Mongo JSONB speichern sowie durchsuchen und indizieren
  • Mit pg_cron als CRON-Daemon für Dinge wie den Versand von E-Mails verwenden
  • Für Geospatial-Abfragen verwenden
  • Statt Elastic für Full-Text-Suche verwenden
  • JSON in der DB erzeugen und ohne serverseitigen Code direkt an die API übergeben
  • Mit einem GraphQL-Adapter auch GraphQL unterstützen

Verwandte Beiträge

13 Kommentare

 
bbulbum 2022-12-15

Hm … wenn man nicht mehr Funktionen braucht, als die einzelnen Apps unterstützen, scheint das Grundkonzept zu sein, dass Postgres allein ausreicht.
Die einzelnen Apps können schließlich mehr Funktionen nutzen als der oben ersetzte Flow.
 
colossus 2022-12-14

Wenn man nur die Schnittstellen sauber definiert und es verwendet, halte ich das nicht für völlig abwegig. Cache/Message Queue kann man aber meiner Meinung nach ruhig Redis überlassen.
 
gninggoon 2022-12-14

Ich habe mir in letzter Zeit ähnliche Gedanken wie im obigen Artikel gemacht. Natürlich ist es bei großen Services besser, das Risiko durch möglichst starke Verteilung zu streuen, aber bei kleineren Auftragsprojekten war es oft viel praktischer, kein separates NoSQL zu verwenden und stattdessen den jsonb-Typ von Postgres zu nutzen. Das bot eine Nutzungserfahrung wie eine Kombination aus RDB + NoSQL und innerhalb kleiner Projekte auch eine völlig ausreichende Performance.
 
a9t84j1k5j2j1 2022-12-13

Wenn man alles mit einem einzigen System erledigt, landen auch alle Risikopunkte an einem Ort..!
 
ehlegeth 2022-12-13

Einige Dinge wurden tatsächlich früher mit einer RDB gemacht, als es noch keine passenden Ersatzprodukte gab, aber bei Dingen wie Redis, Kafka oder Cron scheint es so, als könnten deren zentrale Vorteile dadurch nicht ersetzt werden. Das wirkt eher wie eine Idee zum Spaß, über die man einfach hinwegsehen kann.
 
ifmkl 2022-12-13

Für Leute, die gern alles mit nur einer Sache erledigen, dürfte das genau das Richtige sein.
 
s0400615 2022-12-13

Ich habe Postgres wegen Geodaten verwendet.
Im Vergleich zu anderen Datenbanken war es etwa 10- bis 100-mal schneller. Im Geo-Bereich ist es wirklich überragend.

Aber wie alle wissen: Wenn die Datenmenge wächst und vacuum falsch läuft, erlebt man die Hölle..
 
kbumsik 2022-12-13

Oh, da gibt es einige Tricks.

Allerdings wirkt die Kombination aus dem ersten UNLOGGED und Stored Procedures so, als wäre es viel sauberer, stattdessen einfach Redis zu verwenden, haha.
 
youknowone 2022-12-13

Das ist zwar schon ein paar Jahre her, aber ich habe einmal mit JSONB gearbeitet und, wenn die Last zu hoch wurde, passend zum KV-Muster etwas ausgewählt und nach Redis ausgelagert — das war eine sehr angenehme Erfahrung.
 
sangheon 2022-12-13

Eine interessante Meinung.
 
xguru 2022-12-13

Der Titel ist zwar bewusst provokant, aber es ist durchaus ein Thema, über das man nachdenken kann, daher habe ich ihn unverändert übernommen.
Gerade bei einem frühen MVP kann es schließlich auch ein Problem sein, zu viele Komponenten einzuführen.
 
jujumilk3 2022-12-13

Scheint ein gutes Konzept zu sein.
 
devo209 2022-12-20

Danke.