HALLO
Ich arbeite an einem Workflow, der tausende Datensätze auf einmal verarbeitet, und ich versuche, die effizienteste Möglichkeit zu finden, PostgreSQL zu aktualisieren, ohne die Leistung zu beeinträchtigen.
UPDATE workflow_jobs
SET status = ‘completed’
WHERE job_id = 1001;
Ich frage mich, ob das Batching von Updates ein besserer Ansatz ist, wenn man mit großen Datenmengen umgeht.
Verarbeitet ihr Datensätze in Batches oder alle auf einmal?
Wie groß sollte eine Batch-Größe in der Produktion sein?
Habt ihr Probleme mit der Leistung oder dem Sperren bei großen Batch-Updates bemerkt?
Gibt es Best Practices für PostgreSQL oder n8n zur effizienten Verarbeitung von hochvolumigen Updates?
Das Problem/den Fehler/die Frage beschreiben
Was ist die Fehlermeldung (falls vorhanden)?
Bitte teilen Sie Ihren Workflow
(Wählen Sie die Knoten auf Ihrer Canvas aus und verwenden Sie die Tastaturkürzel CMD+C/STRG+C und CMD+V/STRG+V, um den Workflow zu kopieren und einzufügen.)
Nach meiner Erfahrung funktioniert die Verarbeitung von Datensätzen in kleineren Batches in der Regel viel besser, als wenn man versucht, alles in einer großen Transaktion zu aktualisieren.
UPDATE workflow_jobs
SET status = ‘completed’
WHERE job_id IN (1001, 1002, 1003);
Durch kurze Transaktionen wird die Sperrkonkurrenz verringert und die Wahrscheinlichkeit verringert, dass andere Workflows beeinträchtigt werden, die gleichzeitig laufen.
Ich würde auch empfehlen, die Spalten, nach denen du filterst, zu indizieren und die Abfrageleistung zu überwachen, wenn deine Daten wachsen. Die ideale Batch-Größe hängt wirklich von deiner Workload ab, daher lohnt es sich, ein paar verschiedene Größen zu testen, um zu sehen, was am besten funktioniert.
Kleinere, gut verwaltete Batches sind in der Regel zuverlässiger und leichter zu skalieren als ein großes Update.
Danke, aber wie entscheidest du normalerweise in der Produktion für die richtige Batch-Größe? Fängst du mit einer festen Anzahl von Zeilen an und passt sie basierend auf der Performance an, oder verwendest du Metriken wie Abfragezeit, CPU-Auslastung oder Lock-Wartezeiten, um die optimale Größe zu bestimmen?
Ich beginne normalerweise mit einer angemessenen Batch-Größe basierend auf der Workload und passe sie dann basierend auf Performance-Metriken an. Es gibt keine universelle Zahl, da sie von Faktoren wie Tabellengröße, Abfragekomplexität, Indizes und verfügbaren Ressourcen abhängt.
Ich überwache normalerweise: Ausführungszeit der Abfrage
Sperrwartezeit
Datenbank-CPU- und Speicherauslastung
Transaktionsdauer
Wenn Batches zu groß sind, können sie Sperren länger halten und andere Workflows beeinträchtigen. Wenn sie zu klein sind, können unnötige Overhead-Kosten durch zu viele Transaktionen entstehen.
Das Ziel ist, ein Gleichgewicht zu finden, bei dem jeder Batch schnell abgeschlossen wird und die Datenbank reaktionsschnell bleibt. In der Produktion funktioniert eine schrittweise Optimierung basierend auf echten Workload-Daten normalerweise besser als die Wahl einer festen Batch-Größe im Voraus.