Eine einzelne Tabelle ist auf mehrere Milliarden Zeilen gewachsen, und die Writes werden langsamer. Welche Optionen hast du?

Schöpf erst die billigeren Optionen aus: bessere Indizes, kalte Zeilen archivieren, große Spalten auslagern und Read Replicas für die Leselast. Dann partitionier die Tabelle, meistens nach Zeit oder Mandant, damit jede Partition klein bleibt und alte Partitionen sofort verworfen werden können. Sharding über getrennte Datenbanken kommt zuletzt, weil es dich Cross-Shard-Queries, verteilte Transaktionen und Rebalancing kostet, und die Wahl des Shard Keys ist später sehr schwer zu ändern.

Zuerst würde ich herausfinden, was tatsächlich langsam ist, denn eine große Tabelle ist nicht automatisch ein Problem. Meistens ist es Indexpflege bei jedem Insert, oder ein paar ungenutzte Indizes, oder Autovacuum, das hinterherhinkt. Ich starte also mit den billigen Gewinnen: Indizes löschen, die niemand nutzt, eine große Text- oder JSON-Spalte in eine Nebentabelle verschieben, damit die Hauptzeilen kompakt bleiben, und alles archivieren, was älter als die Aufbewahrungsfrist ist. Ist sie dann wirklich noch zu groß, partitioniere ich, normalerweise nach Zeit bei ereignisartigen Daten, was jede Partition klein hält, dem Planner erlaubt, auf den relevanten Bereich zu prunen, und aus dem Löschen der Vorjahresdaten ein Drop einer Partition macht statt eines Deletes, das einen Tag läuft. Sharding ist die letzte Option, weil es das Programmiermodell ändert: Cross-Shard-Joins fallen weg, Transaktionen werden verteilt, und Rebalancing ist ein Projekt. Wenn ich sharde, wird der Key gründlich überlegt, denn eine Events-Tabelle nach Kunden-id zu sharden gibt dir einen Hot Shard, sobald ein Kunde zehnmal größer ist als der Rest.