Vergesst SQS, RabbitMQ und Kafka. Nutzt einfach Postgres.

DeutschالعربيةEnglishEspañolFrançaisहिन्दीBahasa Indonesia日本語한국어PortuguêsРусский中文
BBetter Stack
컴퓨터/소프트웨어AI/미래기술

스크립트

00:00:00SQS, Kafka und RabbitMQ können direkt in die Tonne, denn du kannst deine Warteschlangen jetzt direkt
00:00:05in Postgres mit PGMQ verwalten. Und ich höre schon Leute sagen: Aber das skaliert doch nicht.
00:00:11Nun, tust tut es tatsächlich, denn Postgres kommt problemlos mit Millionen von Zeilen und
00:00:15tausenden Anfragen pro Sekunde klar. Wenn du deine Infrastruktur also einfach halten möchtest,
00:00:20schauen wir uns heute an, wie man hochvolumige, verteilte Apps mit PGMQ baut.
00:00:30Genug geredet, wir springen direkt in die Demo. Ich habe ein Projekt mit Docker aufgesetzt
00:00:34und PGMQ installiert. Du kannst das in zwei Varianten nutzen: entweder nur mit SQL oder über eine der
00:00:41offiziellen Client-Bibliotheken wie Rust oder Python sowie eine Reihe von Community-Bibliotheken wie Ruby oder
00:00:47verschiedenen TypeScript-Varianten. Da wir uns ohnehin nie auf eine Sprache einigen werden, zeige ich die Demo
00:00:52einfach mit der reinen SQL-Option. Beginnen wir mit dem Erstellen einer neuen Warteschlange. Wir führen select pgmq.create aus und übergeben
00:00:58dann den Namen der Warteschlange. Jede Warteschlange ist hier eine eigene Tabelle. Wenn wir direkt in die Datenbank schauen,
00:01:04sehen wir, dass die neue Tabelle jetzt existiert. Wir können dann Nachrichten an unsere Warteschlange senden, indem wir den Namen der Warteschlange
00:01:09und die Nachricht als JSON angeben. Du kannst optional eine Verzögerung hinzufügen. So wird die Nachricht in die
00:01:15Warteschlange gestellt, kann aber beispielsweise fünf Sekunden lang nicht konsumiert werden. Gut, die Nachrichten sind also jetzt in der Warteschlange.
00:01:20Verarbeiten wir sie. Das machen wir mit dem read-Befehl. VT steht für Visibility Timeout (Sichtbarkeitszeitüberschreitung).
00:01:26Hier bedeutet das, dass die von dir gelesenen Nachrichten 30 Sekunden lang sichtbar sind, sodass kein anderer Prozess sie abrufen kann.
00:01:31So garantiert PGMQ die zustellungsweise „Genau einmal“ (exactly once delivery). Quantity ist dann die Anzahl der Nachrichten, die wir
00:01:38lesen möchten. Und wenn sie innerhalb dieses Zeitfensters nicht gelöscht oder archiviert werden, werden sie wieder sichtbar. Und um
00:01:44das zu tun, kannst du entweder archive ausführen, was sie aus der Warteschlange löscht und der Archivtabelle hinzufügt, oder einfach
00:01:49delete aufrufen. Hier lösche ich zum Beispiel die Nachricht mit der ID 2. Und nur am Rande: Wenn du das
00:01:54nützlich findest, tu uns einen riesigen Gefallen und abonniere den Kanal. Das hilft uns dabei, weiterhin kostenlose Inhalte zu erstellen,
00:01:59um so vielen Entwicklern wie möglich zu helfen. Okay, unterziehen wir PGMQ also einem Stresstest. Als Erstes füge ich 100.000 Zeilen
00:02:06in die Warteschlange ein. Das dauert etwa 0,4 Sekunden. Jetzt starte ich 100 Worker, die jeweils einen Job in
00:02:13Batches von 10 verarbeiten, um zu sehen, wie lange es dauert, alle zu lesen. Hier liest jeder Worker
00:02:18lediglich die Nachricht, protokolliert, was er gelesen hat, und löscht sie dann. Natürlich würdest du mit diesen Daten noch etwas anfangen wollen,
00:02:23aber mir geht es hier nur darum, die Leistung von PGMQ direkt zu testen. Und das dauerte neun Sekunden.
00:02:29Jeder Worker hat im Durchschnitt 111 Nachrichten pro Sekunde verarbeitet. Zusammen also etwa 11.100 Nachrichten pro Sekunde.
00:02:37Ich habe den Docker-Container absichtlich auf zwei CPUs und zwei Gigabyte Arbeitsspeicher begrenzt, was typisch für einen Live-Dienst ist.
00:02:44Wie ich bereits erwähnt habe, kannst du auch die Client-Bibliotheken verwenden, um mit PGMQ zu interagieren.
00:02:49Mit TypeScript und Prisma können wir eine Warteschlange erstellen, eine Nachricht senden, eine Charge von Nachrichten lesen, und du kannst
00:02:55das Ganze natürlich auch mit Python machen. Wenn du also keine zusätzlichen Abhängigkeiten möchtest, kannst du Warteschlangen
00:03:01mit PGMQ tatsächlich im großen Stil direkt in Postgres betreiben. Und wir treiben das noch viel weiter, indem wir so viel wie möglich
00:03:08eines Stacks durch Postgres ersetzen, was ich in diesem Video zeige.

핵심 요약

PGMQ ersetzt externe Message-Broker wie SQS oder Kafka durch direkte PostgreSQL-Tabellen und bewältigt Tausende von Anfragen pro Sekunde im Großbetrieb.

하이라이트

  • Warteschlangen lassen sich direkt in PostgreSQL mit PGMQ verwalten, wodurch dedizierte Tools wie SQS, Kafka oder RabbitMQ überflüssig werden.

  • Das Einfügen von 100.000 Zeilen in die Warteschlange dauert rund 0,4 Sekunden.

  • Hundert Worker verarbeiten in einem Stresstest auf einem Docker-Container mit zwei CPUs und zwei Gigabyte RAM etwa 11.100 Nachrichten pro Sekunde.

  • PGMQ garantiert mit dem Read-Befehl und einem Visibility Timeout von 30 Sekunden eine zustellungsweise Genau-einmal-Verarbeitung (exactly once delivery).

  • Client-Bibliotheken für Rust, Python, Ruby sowie TypeScript und SQL ermöglichen die flexible Interaktion mit PGMQ.

타임라인

Einführung in PGMQ und Postgres als Message-Broker

  • PostgreSQL ersetzt herkömmliche Warteschlangensysteme wie SQS, Kafka und RabbitMQ.
  • PostgreSQL verarbeitet problemlos Millionen von Zeilen und tausende Anfragen pro Sekunde.
  • PGMQ baut hochvolumige, verteilte Anwendungen direkt in der bestehenden Infrastruktur auf.

Traditionelle Nachrichtensysteme sind oft unnötig komplex. PGMQ nutzt die Leistungsfähigkeit von PostgreSQL, um Warteschlangen direkt in der Datenbank zu verwalten. Skeptiker bezweifeln die Skalierbarkeit, doch Postgres bewältigt Millionen von Zeilen mühelos und hält die Infrastruktur einfach.

Grundlegende SQL-Befehle und Steuerung von Nachrichten

  • Jede Warteschlange entspricht einer eigenen Tabelle in der Datenbank.
  • Nachrichten werden als JSON an die Warteschlange übergeben und können optional mit einer Verzögerung versehen werden.
  • Das Visibility Timeout (VT) von 30 Sekunden verhindert den gleichzeitigen Zugriff anderer Prozesse und sichert die Zustellung.

Die Interaktion erfolgt entweder über reine SQL-Befehle oder Client-Bibliotheken. Mit select pgmq.create wird eine neue Warteschlange erstellt. Der read-Befehl liest Nachrichten aus und sperrt sie temporär, während archive oder delete die Datensätze nach der Verarbeitung bereinigen.

Stresstest und Leistungsfähigkeit unter Last

  • Das Einfügen von 100.000 Zeilen in die Warteschlange beansprucht lediglich 0,4 Sekunden.
  • Hundert parallele Worker verarbeiten insgesamt rund 11.100 Nachrichten pro Sekunde in einem limitierten Docker-Container.
  • Client-Bibliotheken in TypeScript, Prisma und Python ermöglichen den produktiven Einsatz im großen Stil direkt in Postgres.

Ein Praxistest mit begrenzten Ressourcen von zwei CPUs und zwei Gigabyte RAM zeigt die hohe Leistungsfähigkeit von PGMQ. Hundert Worker verarbeiten Batches von Nachrichten in nur neun Sekunden. Zusätzliche Abhängigkeiten entfallen, wodurch der gesamte Stack direkt durch Postgres ersetzt werden kann.

커뮤니티 글

아직 글이 없습니다. 이 영상에 대한 첫 번째 글을 작성해 보세요!

이 영상에 대해 글쓰기