Du musst eine neue Spalte über zweihundert Millionen bestehende Zeilen in Produktion befüllen. Wie fährst du das?

Niemals als ein einziges Update-Statement. Füg die Spalte als nullable ohne Table Rewrite hinzu, backfill dann in kleinen Batches sortiert nach Primärschlüssel, commit jeden Batch, mit einer kurzen Pause dazwischen und einer Prüfung der Replikationsverzögerung. Mach den Job wiederaufnehmbar, indem du den Fortschritt festhältst, fahr ihn außerhalb der Spitzenzeiten, und lass die Anwendung die neue Spalte für neue und geänderte Zeilen schreiben, damit der Backfill nur die Historie einholen muss.

Ein Update über zweihundert Millionen Zeilen hält Locks, erzeugt enorm viel Write-Ahead-Log und schiebt Replicas so weit zurück, dass Lesezugriffe veraltete Daten liefern, die Seite leidet also, obwohl nichts abgestürzt ist. Stattdessen füge ich die Spalte als nullable hinzu, was auf einem modernen Postgres billig ist, weil es die Tabelle nicht neu schreibt, und ich deploye zuerst die Anwendungsänderung, die sie bei jedem Insert und Update befüllt. Damit muss der Backfill nur die Historie abarbeiten, und Historie bewegt sich nicht. Danach läuft der Job über den Primärschlüssel in Batches von ein paar tausend, committet jeden Batch, merkt sich die zuletzt erledigte id, damit er nach einem Neustart weitermachen kann, und pausiert, wenn Replikationsverzögerung oder Datenbanklast eine Schwelle überschreiten. Ich fahre ihn mit Rate Limit statt so schnell wie möglich. Wenn er durch ist, prüfe ich mit Counts und Stichproben, dass nichts null geblieben ist, schalte die Lesezugriffe hinter einem Flag auf die neue Spalte um und setze erst danach das Not-Null-Constraint, separat validiert, damit es kein langes Lock nimmt.