PostgreSQL-Partitionierung für Ereignistabellen: lerne, wann sie sich lohnt, wie du Partitionierungsschlüssel auswählst und was sich für Admin-Filter und Retention ändert.
Ereignis- und Audit-Tabellen sehen ähnlich aus, existieren aber aus unterschiedlichen Gründen.
Eine Ereignistabelle zeichnet auf, was passiert: Seitenaufrufe, versendete E-Mails, Webhook-Aufrufe, Job-Ausführungen. Eine Audittabelle protokolliert, wer was wann geändert hat: Statuswechsel, Berechtigungsupdates, Auszahlungsfreigaben, oft mit „vorher“ und „nachher“-Details.
Beide wachsen schnell, weil sie append-only sind. Einzelne Zeilen löscht man selten, und neue Zeilen kommen jede Minute dazu. Schon ein kleines Produkt kann innerhalb von Wochen Millionen Log-Zeilen produzieren, wenn Hintergrundjobs und Integrationen hinzukommen.
Das Problem zeigt sich im Alltag. Admin-Panels brauchen schnelle Filter wie „Fehler von gestern“ oder „Aktionen dieses Nutzers“. Wenn die Tabelle wächst, beginnen solche Basisansichten zu stocken.
Meistens fallen dir zuerst ein paar Symptome auf:
Partitionierung ist ein Weg, damit umzugehen. Einfach gesagt: sie teilt eine große Tabelle in viele kleinere Tabellen (Partitionen) auf, die einen gemeinsamen logischen Namen teilen. PostgreSQL leitet jede neue Zeile anhand einer Regel (meist Zeit) in die richtige Partition.
Deshalb schauen Teams bei Ereignistabellen oft auf PostgreSQL-Partitionierung: sie hält neuere Daten in kleineren Stücken, sodass PostgreSQL ganze Partitionen überspringen kann, wenn eine Abfrage nur ein Zeitfenster braucht.
Partitionierung ist kein magischer Performance-Schalter. Sie hilft stark bei Abfragen wie „letzte 7 Tage“ und macht Retention einfacher (Alte Partitionen droppen ist schnell). Sie kann aber auch neue Probleme schaffen:
Wenn euer Admin-Panel stark auf Datumsfilter und vorhersehbare Aufbewahrungsregeln angewiesen ist, kann Partitionierung wirklich sinnvoll sein. Wenn die meisten Abfragen „alle Aktionen von Nutzer X über die gesamte Historie“ sind, kann sie Kopfschmerzen bereiten, sofern die UI und Indizes nicht sorgfältig gestaltet werden.
Ereignis- und Audittabellen wachsen in eine Richtung: nach oben. Es gibt einen stetigen Strom von Inserts und fast keine Updates. Die meisten Zeilen werden einmal geschrieben und später gelesen — bei Support-Anfragen, Vorfallanalysen oder Compliance-Checks.
Diese „append-only“-Form ist wichtig. Schreibleistung ist ständig relevant, weil Inserts den ganzen Tag passieren, während Leseperformance in Spitzenphasen zählt (Support oder Ops braucht schnell Antworten).
Die meisten Lesevorgänge sind Filter, keine zufälligen Lookups. Im Admin-Panel beginnt man meist breit (letzte 24 Stunden) und verengt dann auf einen Nutzer, eine Entität oder eine Aktion.
Gängige Filter sind:
Der Zeitbereich ist der natürliche „erste Schnitt“, weil er fast immer vorhanden ist. Das ist die wichtigste Einsicht hinter PostgreSQL-Partitionierung für Ereignistabellen: viele Abfragen wollen einen Zeitabschnitt, und alles andere ist ein zweiter Filter innerhalb dieses Abschnitts.
Retention ist die andere Konstante. Logs bleiben selten für immer. Teams behalten Detail-Events oft 30 oder 90 Tage, dann werden sie gelöscht oder archiviert. Audits können längere Anforderungen haben (365 Tage oder mehr), aber auch dann will man eine vorhersehbare Methode, alte Daten zu entfernen, ohne die Datenbank zu blockieren.
Audit-Logging bringt außerdem zusätzliche Erwartungen mit sich. Historie sollte im Allgemeinen unveränderlich sein, jeder Datensatz nachvollziehbar (wer/was/wann plus Request- oder Session-Kontext), und der Zugriff sollte kontrolliert sein (nicht jeder sollte sicherheitsrelevante Events sehen dürfen).
Diese Muster zeigen sich direkt im UI-Design. Die Filter, die standardmäßig erwartet werden — Datumswähler, Nutzer-Selektoren, Entitätssuche, Aktions-Dropdowns — sind die gleichen Filter, die eure Tabelle und Indizes unterstützen müssen, wenn das Admin-Erlebnis bei wachsendem Volumen schnell bleiben soll.
Partitionierung ist keine allgemeine Standardempfehlung für Audit-Logs. Sie lohnt sich, wenn eine Tabelle so groß wird, dass Alltagsabfragen und Routinemanagement sich gegenseitig behindern.
Eine einfache Größenregel: Sobald eine Ereignistabelle Zehn- bis Hunderttausende bis Millionen Zeilen erreicht (oder mehrere zehn Millionen), lohnt es sich zu messen. Wenn Tabelle und Indizes in den zweistelligen Gigabyte-Bereich wachsen, können selbst „einfache“ Datumsbereichssuchen langsam oder unvorhersehbar werden, weil viele Datenblöcke von der Platte gelesen werden und Indizes teuer zu pflegen sind.
Das klarste Abfrage-Signal ist, wenn ihr regelmäßig einen kleinen Zeitabschnitt anfordert (letzter Tag, letzte Woche), aber PostgreSQL trotzdem große Teile der Tabelle berührt. Das zeigt sich in langsamen „Recent activity“-Bildschirmen oder Audits, die nach Datum plus Nutzer, Aktionstyp oder Entitäts-ID gefiltert werden. Wenn Abfragepläne große Scans zeigen oder Buffer-Reads dauerhaft hoch sind, lest ihr mehr Daten als nötig.
Wartungssignale sind genauso wichtig:
Betriebliche Kosten sind der langsame Tropfen, der Teams zur Partitionierung treibt. Backups und Restores werden langsamer, Storage steigt, und Retention-Jobs werden teuer, weil große DELETEs Bloat erzeugen und zusätzliches Vacuum erfordern.
Wenn eure Ziele saubere Retention-Policies und schnellere „Recent period“-Abfragen sind, lohnt sich Partitionierung meist ernsthaft. Wenn die Tabelle moderat ist und Abfragen mit guten Indizes bereits schnell sind, bringt Partitionierung Komplexität ohne klaren Gewinn.
Für die meisten Audit- und Ereignisdaten ist die einfachste Wahl Range-Partitionierung nach Zeit. Logs kommen in Zeitreihen, Abfragen zielen oft auf „letzte 24 Stunden“ oder „letzte 30 Tage“ ab, und Retention ist meist zeitbasiert. Bei Zeit-Partitionen kann das Entfernen alter Daten so einfach sein wie das Löschen einer alten Partition statt eines großen DELETEs, das die Tabelle aufbläht.
Zeitbereich-Partitionierung hält Indizes auch kleiner und fokussierter. Jede Partition hat eigene Indizes, also muss eine Abfrage für die letzte Woche nicht einen riesigen Index über Jahre durchsuchen.
Andere Partitionierungsstile existieren, passen aber seltener für Logs und Audits:
Wenn ihr Zeitbereiche wählt, passt die Partitionsgröße an euer Browsing- und Retention-Verhalten an. Tägliche Partitionen machen Sinn bei sehr hohem Volumen oder strikter Retention. Monatliche Partitionen sind bei moderatem Volumen leichter zu handhaben.
Ein praktisches Beispiel: Wenn das Admin-Team jeden Morgen fehlgeschlagene Logins prüft und nach den letzten 7 Tagen filtert, sorgen tägliche oder wöchentliche Partitionen dafür, dass die Abfrage nur die neuesten Partitionen berührt. PostgreSQL kann den Rest ignorieren.
Was auch immer ihr wählt: plant die langweiligen Teile mit ein: zukünftige Partitionen erzeugen, verspätete Events behandeln und klar definieren, was an jeder Grenze passiert (Tagesende, Monatsende). Partitionierung zahlt sich aus, wenn diese Routinen einfach bleiben.
Ein guter Partitionierungsschlüssel passt zu eurer Leseweise, nicht zum Schema-Diagramm.
Bei Ereignis- und Audit-Logs startet ihr am Admin-Panel: Welches Filterfeld nutzen Menschen zuerst, fast immer? Für die meisten Teams ist das ein Zeitbereich (letzte 24 Stunden, letzte 7 Tage, benutzerdefinierte Daten). Wenn das bei euch zutrifft, bringt zeitbasierte Partitionierung meist den größten und verlässlichsten Gewinn, weil PostgreSQL ganze Partitionen außerhalb dieses Bereichs überspringen kann.
Betrachte den Schlüssel als langfristiges Versprechen. Du optimierst für die Abfragen, die ihr über Jahre laufen lassen werdet.
Die meisten Admin-Ansichten folgen einem Muster: Zeitbereich plus optional Nutzer, Aktion, Status oder Ressource. Partitioniere nach dem, was früh und konstant die Ergebnisse einschränkt.
Eine schnelle Realitätprüfung:
tenant_id sinnvoll sein — aber nur, wenn Tenants groß genug sind, um es zu rechtfertigen.user_id zwar verlockend, erzeugt aber typischerweise zu viele Partitionen.Partitionierung funktioniert am besten, wenn jede Partition ein sinnvolles Datenstück darstellt. Keys wie user_id, session_id, request_id oder device_id führen oft zu Tausenden oder Millionen Partitionen. Das erhöht den Metadatenaufwand, erschwert Wartung und bremst oft die Planung.
Zeitbasierte Partitionen halten die Partitionsanzahl vorhersehbar. Du wählst täglich, wöchentlich oder monatlich je nach Volumen. Zu wenige Partitionen (eine pro Jahr) helfen wenig. Zu viele (eine pro Stunde) erzeugen schnell Overhead.
Sei explizit, was die Zeit bedeutet:
occurred_at: wann das Ereignis im Produkt passiert ist.created_at: wann die Datenbank es aufgezeichnet hat.Bei Audits interessiert Admins oft das „occurred“-Datum. Verzögerte Zustellungen (Offline-Clients, Retries, Queues) bedeuten aber, dass occurred_at verspätet ankommen kann. Wenn verspätete Events üblich sind, ist Partitionierung nach created_at und Indexierung von occurred_at für Filter oft stabiler. Die andere Möglichkeit ist eine klare Backfill-Policy und die Akzeptanz, dass alte Partitionen gelegentlich verspätete Events erhalten.
Entscheide auch, wie du Zeit speicherst. Verwende einen konsistenten Typ (häufig timestamptz) und behandle UTC als Quelle der Wahrheit. Zeitzonen für den Betrachter formatiert ihr in der UI. So bleiben Partitionsgrenzen stabil und Probleme durch Sommerzeit entfallen.
Partitionierung ist am einfachsten, wenn man sie wie ein kleines Migrationsprojekt behandelt, nicht als schnellen Tweak. Ziel sind einfache Writes, vorhersehbare Reads und Retention, die Routine wird.
Wähle eine Partitionsgröße passend zum Volumen. Monatliche Partitionen reichen bei einigen hunderttausend Zeilen pro Monat. Wenn du Zehnmillionen Inserts pro Monat hast, sind wöchentliche oder tägliche Partitionen sinnvoll, damit Indizes kleiner bleiben und Vacuum-Arbeit begrenzt wird.
Designe Keys und Constraints für partitionierte Tabellen. In PostgreSQL muss ein Unique-Constraint die Partitionierspalte enthalten (oder anders durchgesetzt werden). Ein gängiges Muster ist (created_at, id), wobei id generiert wird und created_at der Partitionierschlüssel ist. Das vermeidet Überraschungen, wenn sich später herausstellt, dass eine erwartete Einschränkung nicht erlaubt ist.
Erstelle zukünftige Partitionen, bevor du sie brauchst. Warte nicht, bis Inserts fehlschlagen, weil keine passende Partition existiert. Entscheide, wie weit voraus du Partitionen erzeugen willst (z. B. 2–3 Monate) und mache das zu einem regelmäßigen Job.
Halte Per-Partition-Indizes klein und gezielt. Partitionierung macht Indizes nicht kostenlos. Die meisten Ereignistabellen brauchen den Partitionierschlüssel plus ein oder zwei Indizes, die echte Admin-Filter abdecken, z. B. actor_id, entity_id oder event_type. Verzichte auf „nur für den Fall“-Indizes. Du kannst Indizes später zu neuen Partitionen hinzufügen und ältere nachträglich backfillen.
Plane Retention um das Droppen von Partitionen, nicht um das Löschen von Zeilen. Wenn du 180 Tage Log-Level halten willst, ist das Entfernen alter Partitionen schnell und vermeidet lang laufende DELETEs und Bloat. Schreibe die Retentionregel auf, wer sie ausführt und wie du prüfst, dass sie funktioniert.
Wenn deine Audittabelle 5 Millionen Zeilen pro Woche bekommt, sind wöchentliche Partitionen auf created_at ein guter Start. Erstelle Partitionen 8 Wochen im Voraus und behalte zwei Indizes pro Partition: einen für häufige Suchen nach actor_id und einen für entity_id. Wenn die Aufbewahrungsfrist abläuft, droppe die älteste Wochenpartition statt Millionen Zeilen zu löschen.
Wenn du interne Tools in AppMaster baust, hilft es, Partitionierschlüssel und Constraints früh zu entscheiden, damit das Datenmodell und der generierte Code von Anfang an dieselben Annahmen treffen.
Nach der Partitionierung einer Log-Tabelle werden Admin-Panel-Filter nicht mehr „nur UI“. Sie entscheiden maßgeblich, ob eine Abfrage wenige Partitionen berührt oder Monate an Daten scannt.
Die größte praktische Veränderung: Zeit kann nicht mehr optional sein. Wenn Nutzer eine unbegrenzte Suche erlauben (kein Datumsbereich, nur „zeige alles für Nutzer X“), muss PostgreSQL möglicherweise jede Partition prüfen. Selbst wenn jede Prüfung schnell ist, summiert sich das und die Seite fühlt sich langsam an.
Eine erfolgreiche Regel: erfordere einen Zeitbereich für Log- und Audit-Suchen und setze eine sinnvolle Voreinstellung (z. B. letzte 24 Stunden). Wenn jemand wirklich „gesamte Zeit“ braucht, mache das zur bewussten Wahl und weise auf mögliche Verzögerungen hin.
Partition-Pruning hilft nur, wenn die WHERE-Klausel den Partitionierschlüssel in einer für PostgreSQL nutzbaren Form enthält. Filter wie created_at BETWEEN X AND Y prunen sauber. Muster, die Pruning oft brechen, sind: das Casten von Timestamps auf date, das Einwickeln der Spalte in Funktionen oder das Filtern primär auf eine andere Zeitspalte als die Partitionierspalte.
Innerhalb jeder Partition sollten Indizes zu den tatsächlich genutzten Filtern passen. In der Praxis sind Kombinationen aus Zeit plus einer weiteren Bedingung wichtig: Tenant/Workspace, Nutzer, Aktionstyp, Entitäts-ID oder Status.
Partitionierung löst nicht von allein langsame Paginierung. Wenn das Admin-Panel nach Neueste zuerst sortiert und Nutzer bis Seite 5000 springen, zwingt tiefe OFFSET-Paginierung PostgreSQL, viele Zeilen zu überspringen. Cursor-Paginierung ist für Logs meist besser: „lade Events vor diesem Timestamp/ID“. So bleiben Indizes im Einsatz statt große Offsets zu überspringen.
Voreinstellungen helfen ebenfalls. Ein paar sinnvolle Optionen genügen meist: letzte 24 Stunden, letzte 7 Tage, heute, gestern, benutzerdefinierter Bereich. Voreinstellungen reduzieren unbeabsichtigte „Scan alles“-Suchen und machen die Admin-Erfahrung vorhersehbarer.
Die meisten Partitionierungsprojekte scheitern an einfachen Gründen: Die Partitionierung „funktioniert“, aber Abfragen und Admin-UI passen nicht dazu. Wenn Partitionierung zahlen soll, entwirf sie um reale Filter und echte Retention.
Pruning passiert nur, wenn die WHERE-Klausel zum Partitionierschlüssel passt. Ein häufiger Fehler ist, nach created_at zu partitionieren, während die UI nach event_time filtert (oder umgekehrt). Wenn das Support-Team immer fragt „was geschah zwischen 10:00 und 10:15“, die Tabelle aber nach Ingestionszeit partitioniert ist, berührt ihr trotzdem mehr Daten als erwartet.
Stündliche (oder kleinere) Partitionen wirken sauber, bringen aber Overhead: mehr Objekte, mehr Planung für den Query Planner und mehr Chancen für fehlende Indizes oder falsche Berechtigungen.
Sofern kein extrem hohes Schreibvolumen und keine sehr strikte Retention nötig sind, sind tägliche oder monatliche Partitionen einfacher zu betreiben.
Partitionierte Tabellen haben Einschränkungen: manche Unique-Indizes müssen den Partitionierschlüssel enthalten, sonst kann PostgreSQL sie nicht global durchsetzen.
Das überrascht Teams, die erwarten, dass event_id immer global einzigartig ist. Wenn ihr eine globale ID braucht, verwendet eine UUID und sorgt für die Einzigartigkeit auf Anwendungsebene oder in einem passenden zusammengesetzten Index.
Admin-Panels liefern oft eine freundliche Suchbox, die ohne Filter läuft. Auf einer partitionierten Log-Tabelle kann das bedeuten, alle Partitionen zu scannen.
Volltextsuche über Payloads ist besonders riskant. Setzt Guardrails: zwinge einen Zeitbereich, begrenze den Standardbereich und mache „gesamte Zeit“ zur bewussten Wahl.
Partitionierung löst Retention nicht von selbst. Ohne Policy sammelt ihr alte Partitionen an, Storage und Wartung werden unübersichtlich.
Ein einfaches Regelwerk verhindert das: definiere, wie lange Roh-Events bleiben, automatisiere das Erstellen zukünftiger Partitionen und das Löschen alter, wende Indizes konsistent an, überwache Partitionenzahl und Grenzdaten und teste die langsamsten Admin-Filter mit realistischen Datenmengen.
Partitionierung kann für Audit-Logs ein großer Gewinn sein, sie bringt aber routinemäßige Arbeit mit sich. Bevor du das Schema änderst, prüfe ehrlich, wie die Tabelle genutzt wird.
Wenn dein Hauptproblem ist, dass Admin-Seiten beim Öffnen von „Letzte 24 Stunden“ oder „Diese Woche“ in Timeouts laufen, bist du nahe an einer guten Lösung. Wenn die meisten Abfragen „Nutzer-ID über gesamte Historie“ sind, hilft Partitionierung weniger, sofern du die UI nicht dazu bringst, Suchen anders zu lenken.
Eine kurze Checkliste:
Ein praktischer Test: Schau dir die drei Filter an, die Support oder Ops am meisten nutzt. Wenn zwei davon normalerweise durch „Zeitbereich + eine weitere Bedingung“ abgedeckt sind, ist PostgreSQL-Partitionierung für Ereignistabellen oft eine sehr sinnvolle Überlegung.
Ein Support-Team hält zwei Bildschirme offen: „Login-Events“ (erfolgreiche und fehlgeschlagene Anmeldungen) und „Security-Audits“ (Passwort-Resets, Rollenänderungen, API-Key-Aktualisierungen). Bei verdächtigen Meldungen filtert das Team nach Benutzer, prüft die letzten Stunden und exportiert einen kurzen Bericht.
Vor der Partitionierung liegt alles in einer großen events-Tabelle. Sie wächst schnell, und selbst einfache Suchen ziehen, weil die DB viele alte Zeilen durcharbeitet. Retention ist mühselig: ein nächtlicher Job löscht alte Zeilen, aber große DELETEs dauern lange, erzeugen Bloat und konkurrieren mit Normalbetrieb.
Nach der Partitionierung nach Monat (mithilfe des Event-Timestamps) verbessert sich der Ablauf. Das Admin-Panel verlangt einen Zeitfilter, sodass die meisten Abfragen nur eine oder zwei Partitionen berühren. Seiten laden schneller, weil PostgreSQL Partitionen außerhalb des Bereichs ignoriert. Retention wird Routine: statt Millionen Zeilen zu löschen, droppst du alte Partitionen.
Eine Sache bleibt schwer: Volltextsuche über „gesamte Zeit“. Wenn jemand eine IP-Adresse oder eine vage Phrase ohne Datumsgrenze sucht, macht Partitionierung das nicht günstig. Die Lösung liegt meist im Produkt: standardmäßige Suche auf einen Zeitbereich begrenzen und „letzte 24 Stunden / 7 Tage / 30 Tage“ prominent anbieten.
Praktische nächste Schritte, die sich bewährt haben:
Wenn du ein internes Admin-Panel mit AppMaster (appmaster.io) baust, lohnt es sich, diese Annahmen früh im Modell abzubilden: Behandle zeitlich begrenzte Filter als Teil des Datenmodells, nicht nur als UI-Option. Diese kleine Entscheidung schützt die Abfrageperformance, wenn das Log-Volumen wächst.
When is PostgreSQL partitioning actually worth it for event or audit tables?Partitionierung hilft am meisten, wenn eure häufigen Abfragen zeitlich begrenzt sind (z. B. „letzte 24 Stunden“ oder „letzte 7 Tage“) und die Tabelle so groß ist, dass Indizes und Wartung zur Belastung werden. Wenn die Hauptabfragen „gesamte Historie für Nutzer X“ sind, kann Partitionierung mehr Aufwand bringen, es sei denn, ihr erzwingt Zeitfilter in der UI und legt passende Per-Partition-Indizes an.
What partitioning method is the best fit for logs and audit data?Range-Partitionierung nach Zeit ist in den meisten Fällen die beste Standardwahl für Logs und Audits: Schreibvorgänge kommen in Zeitreihen an, Abfragen beginnen oft mit einem Zeitfenster und die Aufbewahrung ist zeitbasiert. List- oder Hash-Partitionierung können in Spezialfällen passen, machen aber das Browsen und die Retention bei Audit-Workflows oft komplizierter.
How do I choose the right partition key for an audit table?Wähle das Feld, nach dem Benutzer zuerst filtern und das sie fast immer verwenden. In den meisten Admin-Panels ist das ein Zeitbereich, daher ist zeitbasierte Partitionierung die verlässlichste Wahl. Sieh das als langfristige Verpflichtung — das Ändern des Partitionierungs-Schlüssels später ist ein echtes Migrationsprojekt.
Why is partitioning by user_id usually a bad idea?Verwende nur solche Keys, die eine handhabbare Anzahl von Partitionen erzeugen. Vermeide hochgradig kardinale Keys wie user_id, session_id oder request_id, weil sie Tausende von Partitionen erzeugen können, die Planungs- und Betriebsaufwand erhöhen, ohne konsistente Vorteile zu bringen.
Should I partition by created_at or occurred_at?Partitioniere nach created_at, wenn du betriebliche Stabilität brauchst und verspätete Ereignisse (Queues, Retries, Offline-Clients) nicht vertrauenswürdig sind. Partitioniere nach occurred_at, wenn die Hauptfrage „Was passierte in diesem Zeitraum?“ ist und die Ereigniszeit zuverlässig ist. Ein gängiger Kompromiss ist, nach created_at zu partitionieren und occurred_at für Filter zu indexieren.
Do I really need to require a time range filter in the admin UI?Ja: Die meisten Admin-Panels sollten nach Partitionierung einen Zeitbereich verlangen. Ohne Zeitfilter muss PostgreSQL viele oder alle Partitionen prüfen, was Seiten langsam macht. Eine sinnvolle Voreinstellung ist „letzte 24 Stunden“, während „gesamte Zeit“ als bewusste Option angeboten wird.
What can accidentally break partition pruning in my queries?Oft ja. Das Einhüllen der Partitionierspalte in eine Funktion (z. B. Cast auf date) kann Pruning verhindern. Auch Filter auf einer anderen Zeitspalte als der Partitionierspalte zwingen oft dazu, zusätzliche Partitionen zu scannen. Halte Filter in einer einfachen Form wie created_at BETWEEN X AND Y, damit Pruning zuverlässig funktioniert.
What’s the best pagination approach for partitioned event tables?Vermeide tiefe OFFSET-Paginierung für Log-Ansichten, weil die Datenbank viele Zeilen überspringen muss. Verwende Cursor-Paginierung wie „lade Events vor diesem (timestamp, id)“, das indexfreundlich bleibt und die Performance stabil hält, während die Tabelle wächst.
How does partitioning affect unique constraints and IDs?Bei partitionierten Tabellen müssen einige eindeutige Einschränkungen den Partitionierungsschlüssel einschließen, sonst kann PostgreSQL sie nicht global durchsetzen. Ein praktisches Muster ist eine zusammengesetzte Eindeutigkeit wie (created_at, id), wenn created_at die Partitionierspalte ist. Für externe eindeutige Identifikatoren behalte eine UUID und stelle globale Einzigartigkeit gezielt sicher.
What’s the simplest retention strategy once a table is partitioned?Das Löschen alter Partitionen ist schnell und vermeidet das Bloat- und Vacuum-Problem großer DELETEs. Der Schlüssel ist, Retentionsregeln an Partitionierungsgrenzen auszurichten und die Routine zu automatisieren: erstelle zukünftige Partitionen vorab und entferne abgelaufene nach Plan. Ohne Automatisierung wird Partitionierung zur manuellen Mehrarbeit.
21. Jan. 2026
8 Min
20. Jan. 20268 Min
20. Jan. 20268 MinExperimentieren Sie mit AppMaster mit kostenlosem Plan.
Wenn Sie fertig sind, können Sie das richtige Abonnement auswählen.
