Die Debatte DynamoDB gegen Postgres wird meist wie eine Religion geführt. Die eine Seite sagt, relationale Daten gehören in eine relationale Datenbank, und Single-Table-Design sei ein Rätsel, das man einmal löst und für immer bereut. Die andere Seite sagt, Postgres skaliere nicht ohne Pfleger, und DynamoDB sei der einzige Speicher, bei dem man aufhören kann, über Kapazität nachzudenken. Beide haben recht für die Fälle, die sie im Kopf haben, und beide irren darin, dass es eine einzige Antwort gäbe.
Wir betreiben beides, auf derselben Plattform, für einen US-Kunden. Sechs DynamoDB-Tabellen und ein Aurora Serverless v2 Postgres-Cluster, Workload für Workload gewählt. Hier ist die Regel, die wir verwenden, die vier Workloads, die sie ergab, der eine, den wir in den falschen Speicher gelegt und umgezogen haben, und die Kosten beider Seiten.
Die Regel
Stellen Sie zwei Fragen zum Workload, und die Antwort ergibt sich.
1. Kennen Sie die Zugriffsmuster, und sind es weniger als etwa zehn? DynamoDB ist ein Key-Value-Speicher mit Sekundärindizes. Sie entwerfen die Tabelle um die Abfragen herum. Wenn die Abfragen bekannt und wenige sind, ist dieser Entwurf ein angenehmer Nachmittag, und die Tabelle bedient sie in jeder Größenordnung zu festen, niedrigen Kosten pro Anfrage. Wenn die Abfragen unbekannt sind, sich entwickeln oder ad hoc kommen (ein Admin, der „alle Bestellungen von Kunden in Texas, die im März Produkt X gekauft haben“ braucht), ist jede neue Frage ein neuer Index oder ein Scan, und Sie werden binnen eines Jahres eine zweite Kopie der Daten an einem abfragbaren Ort bauen.
2. Brauchen Sie Transaktionen über viele Zeilen, Joins oder Aggregate? DynamoDB hat Transaktionen, bis zu 100 Elemente. Es hat keine Joins und kein GROUP BY. Wenn der Workload „Umsatz pro Produkt pro Woche summieren“ lautet oder „Bestellung, Bestand und Hauptbuch atomar aktualisieren“, macht Postgres das in einer Anweisung, und DynamoDB macht es in Anwendungscode, den Sie mindestens einmal subtil falsch schreiben werden.
Bekannte und wenige Zugriffsmuster, keine Joins oder Aggregate: DynamoDB. Alles andere: Postgres. Bei Gleichstand gewinnt Postgres, weil der Preis des Irrtums asymmetrisch ist: Eine Postgres-Tabelle, die sich als heißes Key-Value-Muster entpuppt, bekommt einen Index oder einen Cache; eine DynamoDB-Tabelle, die sich als Join-bedürftig entpuppt, braucht eine Migration.
Die vier Workloads
Sessions und Rate-Limit-Buckets → DynamoDB. Je ein Zugriffsmuster: nach Schlüssel lesen, nach Schlüssel schreiben, per TTL ablaufen lassen. Millionen kleiner Elemente, spitzenlastiger Verkehr, null Interesse, sie je nach etwas anderem als dem Schlüssel abzufragen. Das ist der DynamoDB-Workload aus dem Lehrbuch, und er kostet bei unserem Volumen etwa 4 $ im Monat, On-Demand, ohne Kapazität, über die man nachdenken müsste. In Postgres wäre das eine Tabelle, die 90 % des Schreibvolumens für 0 % des Geschäftswerts ausmacht, plus ein Vacuum-Job, damit sie nicht aufbläht.
Produktkatalog und Konfiguration pro Mandant → DynamoDB, Single-Table. Sieben Zugriffsmuster, alle bekannt: Produkt nach ID, Produkte nach Mandant, Produkte nach Mandant und Kategorie, Konfiguration nach Mandant, ein paar mehr. Leselastig, selten geschrieben, und die Form eines Produkts ist ein Dokument, keine Menge gejointer Zeilen. Eine Tabelle mit zusammengesetztem Schlüssel und zwei GSIs bedient alle sieben. Die Restore-Übung zeigte die Falle mit den verlorenen Einstellungen, aber die Tabelle selbst brauchte in achtzehn Monaten keine Änderung.
Bestellungen, Zahlungen, Hauptbuch → Postgres. Das ist der Workload, bei dem die zweite Frage Nein sagt. Eine Bestellung berührt die Bestellung, ihre Positionen, die Bestandsreservierung und den Hauptbucheintrag in einer Transaktion; die Finanzabteilung will Umsatz pro Produkt pro Region pro Woche; der Support will „jede Bestellung dieses Kunden mit einer Rückerstattung in den letzten 90 Tagen“. Joins, Aggregate, Ad-hoc-Fragen und eine starke Vorliebe für die Invarianten, die Fremdschlüssel und Constraints liefern. Aurora Serverless v2 mit 0,5 ACU Minimum, separat besprochen.
Ereignisprotokoll für den Suchindex → DynamoDB mit Streams. Nur anhängen, nur vom Stream-Consumer gelesen, nach 30 Tagen ablaufen. Bekanntes Muster, keine Joins, und Streams liefert den Änderungs-Feed kostenlos.
Der, den wir falsch hatten
Kundenprofile begannen in DynamoDB. Die Zugriffsmuster sahen bekannt aus: Profil nach ID, Profil nach E-Mail, Profile nach Mandant. Drei Muster, eine Dokumentform, offensichtliche Passung.
Dann wuchs das Produkt. Der Support wollte Kunden nach Registrierungsdatum. Das Marketing wollte Kunden, die seit 60 Tagen nicht bestellt hatten, also einen Join gegen Bestellungen. Die Finanzabteilung wollte den Customer Lifetime Value, ein Aggregat. Jede Anfrage wurde entweder ein neuer GSI (wir fügten drei hinzu), ein Scan mit Filter, der Minuten dauerte und echtes Geld kostete, oder ein nächtlicher Export nach Postgres, der bis zum Morgen veraltet war. Bei der vierten Anfrage hatten wir zwei Kopien der Kundendaten, eine davon immer leicht falsch.
Wir zogen die Profile nach Postgres um. Die Migration dauerte eine Woche: ein paar Tage doppelt schreiben, Backfill, Lesezugriffe umschalten, DynamoDB-Schreibzugriffe entfernen, die Tabelle einen Monat später löschen. Die drei GSIs verschwanden. Der nächtliche Export verschwand. Jede Frage, die seither jemand zu Kunden gestellt hat, war eine Abfrage, kein Projekt.
Die Lektion steckt in der ersten Frage. „Bekannte Zugriffsmuster“ heißt bekannt für die Lebensdauer der Daten, nicht bekannt heute. Profile sind die Entität, die irgendwann jeder im Unternehmen anders schneiden will. Sessions nicht. Der Speicher sollte dem folgen.
Was jede Seite ehrlich kostet
| DynamoDB (4 Tabellen) | Aurora Serverless v2 Postgres | |
|---|---|---|
| Monatsrechnung | ~13 $ On-Demand | ~45 $ am 0,5-ACU-Boden, mehr unter Last |
| Kapazitätsplanung | Keine | Min- und Max-ACU setzen; der Boden ist die Rechnung |
| Schemaänderungen | Kostenlos für Attribute; ein neues Zugriffsmuster ist ein neuer GSI mit Backfill | ALTER TABLE, Migrationen, gelegentlich eine Sperre, um die man planen muss |
| Backups | PITR an, Restore verliert Einstellungen | PITR an, Restore ist ein neuer Cluster |
| Ad-hoc-Fragen | Scan, oder Export woandershin | Eine Abfrage |
| Betriebliche Überraschungen in 18 Monaten | Eine: heiße Partition auf einem schlecht gewählten Mandantenschlüssel, mit einem Suffix behoben | Eine: eine lange Transaktion hielt während einer Migration eine Sperre |
| Was Sie nicht tun können | Joins, Aggregate, ungeplante Abfragen | Ganz aufhören, darüber nachzudenken |
Die DynamoDB-Seite ist billiger und ruhiger für das, worin sie gut ist. Die Postgres-Seite kostet mehr und beantwortet mehr. Keine der Zahlen ist das Argument; der Workload ist es.
Die Kurzfassung
Pro Workload zwei Fragen: Sind die Zugriffsmuster bekannt und wenige, für die Lebensdauer der Daten; und braucht es Joins, Aggregate oder breite Transaktionen. Ja und Nein heißt DynamoDB. Alles andere heißt Postgres. Rechnen Sie damit, einen falsch zu erwischen, und rechnen Sie damit, dass der falsche die Entität ist, die irgendwann jeder im Unternehmen anders schneiden will.
Wenn Sie einen Speicher für eine neue Plattform wählen oder eine DynamoDB-Tabelle mit ihrem vierten GSI und einem nächtlichen Export haben, helfen wir Ihnen, die Workloads zu sortieren. Das ist eine Whiteboard-Sitzung, keine Religion.