Fallstudie · Vertrauliche Analytics-Plattform, Nordamerika
Wie UnlockLive mit PostgreSQL-UNLOGGED-Tabellen, gebatchter COPY-Ingestion und einem disziplinierten Zwei-Tabellen-Muster eine hochvolumige Analytics-Pipeline von 8 Tsd. auf 80 Tsd. Ereignisse/Sek. gesteigert hat – ohne die Datenintegritätsgarantien zu verlieren, die der auditierte Pfad verlangte.
Eine Analytics-Plattform erfasste Produktereignisse einer wachsenden Kundenbasis in einer einzigen Tabelle „raw_events“. Das ursprüngliche Schema war korrekt, aber langsam: Jedes Ereignis landete in einer protokollierten Tabelle mit sieben Indizes, das WAL war der Engpass, und der Ingest-Durchsatz hatte bei etwa 8.000 Ereignissen pro Sekunde seine Grenze erreicht. Die RDS-IOPS waren der dominierende Kostenblock, und eine geplante Verdreifachung der Kundenzahl hätte die Pipeline gesprengt, noch bevor der nächste Vertrag unterzeichnet war.
Das Team hatte die üblichen Ratschläge gelesen – „eine Queue verwenden“, „die Tabelle shardieren“, „auf eine dedizierte TSDB umziehen“ –, aber all diese Antworten bedeuteten eine Migration über mehrere Quartale. Die eigentliche Frage lautete: Kann PostgreSQL mithalten, wenn wir aufhören, dagegen anzukämpfen? Der Haken war eine harte Anforderung: Alles, was die auditierten Reporting-Tabellen erreichte, musste dauerhaft, konsistent und indiziert sein. Wir durften die Integrität auf der Analytics-Seite nicht opfern, um die Ingest-Seite zu entlasten.
Wir haben die Pipeline in zwei klar getrennte Stufen mit zwei unterschiedlichen Dauerhaftigkeitsverträgen aufgeteilt.
Stufe 1 (Ingest): eine UNLOGGED-Staging-Tabelle, die den Datenstrom aufnimmt. UNLOGGED-Tabellen in PostgreSQL überspringen WAL-Schreibvorgänge bei Inserts, was für kurzlebige Staging-Daten genau der richtige Kompromiss ist – wir erhalten den 5- bis 10-fachen reinen Insert-Durchsatz und nehmen dafür in Kauf, die gestageten Zeilen bei einem Serverabsturz zu verlieren. In Kombination mit gebatchtem COPY (nicht INSERT) aus einem Python-Ingest-Service und der bewussten Regel „keine Indizes auf der Staging-Tabelle“ stieg der reine Ingest auf derselben RDS-Instanz von 8 Tsd. auf über 80 Tsd. Ereignisse/Sek.
Stufe 2 (dauerhaft): Ein Celery-Worker leert die Staging-Tabelle in Mikro-Batches in die echte, vollständig protokollierte, indizierte Tabelle `events`, innerhalb einer einzigen Transaktion mit idempotenten Upserts. Der auditierte Reporting-Pfad liest ausschließlich aus der dauerhaften Tabelle. Stürzt der Server mitten im Ingest ab, verlieren wir höchstens einige Sekunden an Ereignissen in der Staging-Tabelle – und die vorgelagerten Produzenten wiederholen, sodass die dauerhafte Tabelle wieder zum korrekten Zustand konvergiert.
Dazu haben wir eine kleine, aber sorgfältige Betriebsschicht ergänzt: ein Grafana-Dashboard für die Füllrate von Stufe 1, einen harten Alarm, falls der Drainer zurückfällt, Partitionsrotation auf der dauerhaften Tabelle und ein schriftliches Runbook für die drei relevanten Fehlerfälle.
Bevor wir das Schema anfassten, haben wir eine Woche lang pg_stat_statements, RDS Performance Insights und einen eigenen WAL-Durchsatz-Tracker laufen lassen. Die Daten waren eindeutig: WAL-Schreibvorgänge und Indexpflege auf der einen, überladenen Events-Tabelle machten 78 % der Schreibzeit aus. CPU und Arbeitsspeicher waren nicht das Problem – die Dauerhaftigkeit war es.
Wir haben ein kurzes Design-Dokument verfasst, das genau festhielt, was uns UNLOGGED brachte, was es uns kostete und welche Garantien die vorgelagerten Producer liefern mussten (At-least-once-Zustellung, idempotente Event-IDs). Der Vertrag machte das Verlustprofil explizit, sodass das Audit-Team vorab zustimmen konnte – „bei einem RDS-Failover können bis zu N Sekunden gestagter Events verloren gehen; die dauerhafte Tabelle ist nicht betroffen.“
Wir haben zeilenweise Inserts durch einen Python-Ingest-Service ersetzt, der Events bis zu 250 ms im Speicher puffert und sie per PostgreSQL COPY in die UNLOGGED-Staging-Tabelle schreibt. Ein Celery-Drainer übernimmt Micro-Batches mit 5.000 Zeilen in einer einzigen Transaktion in die dauerhafte Tabelle, mit ON CONFLICT DO NOTHING für Idempotenz.
Wir haben die dauerhafte Tabelle um monatliche Partitionierung ergänzt (damit Vacuum und Index-Rebuilds günstig bleiben), Grafana-Dashboards für die Ende-zu-Ende-Verzögerung, Alarme für den Füllstand des Staging und die Verzögerung des Drainers sowie ein schriftliches Runbook zu den drei realen Fehlerszenarien: Drainer-Absturz, RDS-Failover und Producer-Back-Pressure. Die Übergabe an das On-Call-Team des Kunden erfolgte mit Shadowing.
“Wir hatten erwartet, ein Quartal für die Migration zu einer dedizierten Zeitreihendatenbank aufzuwenden. Stattdessen hat UnlockLive uns gezeigt, wie Postgres die Aufgabe übernimmt – und unsere Auditoren haben das neue Design freigegeben, bevor wir es ausgeliefert haben.”
Ja – für die richtige Aufgabe. UNLOGGED-Tabellen überspringen WAL-Schreibvorgänge, was einen 5- bis 10-fachen Roh-Insert-Durchsatz bringt, im Austausch gegen ein dokumentiertes Verlustprofil: Zeilen gehen bei einem Serverabsturz verloren und werden nicht repliziert. Sie eignen sich hervorragend für kurzlebige Staging-Daten, wenn ein vorgelagertes System Ereignisse erneut abspielen kann. Für alles, was Sie verlässlich zurücklesen müssen, sind sie ungeeignet. Wir koppeln sie stets mit einer dauerhaften, protokollierten Tabelle, aus der der geprüfte Pfad tatsächlich liest.
Weil die Migrationskosten und die betriebliche Angriffsfläche real sind. Wenn Ihr Team PostgreSQL bereits gut betreibt und Ihr Durchsatzziel im Bereich von zehntausenden Ereignissen pro Sekunde liegt, bringt Sie das Muster aus UNLOGGED + gebatchtem COPY oft in Wochen statt Quartalen ans Ziel. Wir empfehlen eine dedizierte TSDB, wenn die Last tatsächlich spaltenorientierten Speicher, zeitpartitionierte Indizes oder Bereichsabfragen im Millisekundenbereich im großen Maßstab erfordert.
Sie können, sollten es aber fast nie. Der ganze Sinn der Staging-Ebene ist rohe Insert-Geschwindigkeit; jeder Index, den Sie hinzufügen, kostet Ingest-Durchsatz. Wir halten die Staging-Tabelle indexfrei und legen alle Indizes auf die nachgelagerte dauerhafte Tabelle, gegen die die Analyseabfragen tatsächlich laufen.
Zwei Regeln. Erstens: Die vorgelagerten Produzenten müssen At-least-once-Zustellung mit idempotenten Ereignis-IDs liefern, damit Wiederholungen sicher sind. Zweitens: Die dauerhafte Seite der Pipeline liest immer nur aus der vollständig protokollierten nachgelagerten Tabelle, nie aus der UNLOGGED-Staging-Tabelle. Im schlimmsten Fall gehen bei einem Absturz wenige Sekunden wiederholbarer Staging-Ereignisse verloren – nie ein fehlender Bericht.
Das hängt von Zeilengröße, Netzwerk und Instanzklasse ab, aber auf einer bescheidenen AWS RDS db.r6g.xlarge sehen wir mit genau diesem Zwei-Tabellen-Muster regelmäßig 60.000-100.000 Ereignisse pro Sekunde im Dauerbetrieb bei einer p95-Insert-Latenz der Stufe 1 unter 50 ms. Darüber hinaus würden wir die Staging-Tabelle partitionieren oder mit einem Write-Router horizontal skalieren.
SaaS8x p95-Latenzrückgang bei stark genutzten Endpunkten (1,8 s → 220 ms)Wie wir eine stark belastete Python/FastAPI-API mit einer mehrstufigen Redis-Caching-Schicht neu aufgebaut haben, um die p95-Latenz von 1,8 s auf 220 ms zu senken und die PostgreSQL-Last für ein nordamerikanisches B2B-SaaS um 70 % zu reduzieren.
Bildung50K+ Tägliche Canvas-API-Aufrufe – komfortabel innerhalb des Kontingents der UniversitätWie UnlockLive eine fragile nächtliche Canvas-LMS-Synchronisierung durch eine ereignisgesteuerte Python- und FastAPI-Integration ersetzt hat, die über 50.000 API-Aufrufe pro Tag verarbeitet, keine Rate-Limit-Vorfälle verursacht und das Synchronisierungsfenster um 90 % verkürzt – ohne ein einziges nachgelagertes System zu beeinträchtigen.
Bildung80% Reduktion des administrativen Aufwands für LehrunterstützungWie UnlockLive eine vollautomatische Plattform zur Vorlesungsaufzeichnung mit Canvas LMS und Panopto auf Basis von Python und FastAPI gebaut hat – rund 3.000 Vorlesungen pro Semester werden automatisch veröffentlicht, der Verwaltungsaufwand sinkt um 80 %, und jede Aufzeichnung erhält einen nachprüfbaren Audit-Trail.
Sprechen Sie mit demselben Team, das gebaut hat 10-facher Ingest-Durchsatz in einer PostgreSQL-Analytics-Pipeline mit UNLOGGED-Tabellen. Wir grenzen Ihr Projekt ein, erstellen ein Festpreisangebot und zeigen Ihnen das passendste Beispiel aus unserem Portfolio.
Strategiegespräch buchenUnlockLive IT Limited – Hauptsitz in Toronto für Kundenkontakt und Projektmanagement; dediziertes Engineering-Center in Dhaka, Bangladesh. Im Vereinigten Königreich eingetragenes Unternehmen Nr. 15563368 (UnlockLive IT Limited, London).
Copyright© UnlockLive . Alle Rechte vorbehalten 2008 - 2026