DynamoDB Single-Table Design Tool
Gib deine Entitäten ein und wie du sie lesen musst — der Planer schlägt entitätspräfixierte PK/SK-Schlüsselvorlagen vor, zeigt eine Vorschau der Item-Collections und fügt nur dort einen GSI hinzu, wo die Basistabelle ein Muster nicht bedienen kann.
Von Zugriffsmustern zu einem Schlüsselschema
Single-Table-Design beginnt bei den Lesevorgängen, nicht bei den Entitäten: Statt Tabellen zu normalisieren und zur Query-Zeit zu joinen, listest du jede Art auf, wie die Anwendung Daten abrufen muss — einen Benutzer über die ID holen, die Bestellungen eines Benutzers nach Neuestem zuerst auflisten, ein Konto per E-Mail finden — und formst die Schlüssel so, dass jede davon ein einziges GetItem oder eine einzige Query ist. Jedes Muster, das die Basistabelle nicht beantworten kann, kostet dich einen Index, und dieser Kompromiss sollte sichtbar sein, bevor du die Tabelle erstellst.
Dieser Planer macht den Kompromiss explizit. Er wendet die üblichen Single-Table-Regeln deterministisch an — entitätspräfixierte zusammengesetzte Schlüssel, Item-Collections für One-to-Many-Muster, invertierte oder attributgebundene GSIs für den Rest — und wo ein Muster nicht sauber bedient werden kann, sagt er das, statt es vorzutäuschen. Die Beispiel-Items-Tabelle zeigt, wie die resultierenden Zeilen tatsächlich innerhalb einer Partition nebeneinander liegen.
Die Ausgabe ist ein schlichtes CreateTable-JSON-Dokument mit generischen, string-typisierten Schlüsselattributen — nichts Tool-Spezifisches, das man später auseinandernehmen müsste — plus Kostenhinweise, die genau dieselbe 4-KB-Lese-/1-KB-Schreib-Rundung wiederverwenden wie unsere Preis- und Item-Größenrechner.
Neu bei den Konzepten oder unsicher, ob der Ansatz zu deiner Workload passt? Unser Single-Table-Design-Guide erklärt die Idee von Grund auf, und wann man sie NICHT einsetzen sollte behandelt die ehrlichen Gegenfälle. Sobald das Schema steht, stelle den eigentlichen Request im DynamoDB Query Builder zusammen oder schätze die volle monatliche Rechnung mit dem DynamoDB-Preisrechner.
Häufig gestellte Fragen
Was ist Single-Table-Design in DynamoDB?
Ein Modellierungsansatz, bei dem alle Entitätstypen einer Anwendung eine Tabelle mit generischen Partition- und Sort-Key-Attributen (PK/SK) teilen. Verwandte Items teilen sich einen Partition Key, sodass eine einzige Query sie gemeinsam abruft — das Design wird von deinen Zugriffsmustern bestimmt und nicht von normalisierten Entitätsformen.
Wie entscheidet dieser Planer über das Schlüssel-Design?
Mit festen, veröffentlichten Regeln — deterministisch, nicht generativ. Jede Entität beginnt als Wurzel ihrer eigenen Item-Collection mit entitätspräfixierten Schlüsseln; das erste List-Children-Muster verschiebt das Kind über einen zusammengesetzten Sort-Key in die Partition seines Elternteils; Lookups nach anderen Attributen, zweite Elternteile und List-Everything-Muster werden zu GSI-Vorschlägen; und ein Muster, das die Regeln nicht sauber bedienen können, wird als nicht unterstützt markiert, statt ein erfundenes Design zu erhalten.
Wann braucht ein Zugriffsmuster einen Global Secondary Index?
Wenn das Schlüssel-Layout der Basistabelle es nicht beantworten kann: das Abrufen eines umgesiedelten Kindes über seine eigene ID, das Auflisten derselben Items unter einem zweiten Elternteil, das Finden eines Items über ein Nicht-Schlüssel-Attribut wie eine E-Mail oder das Auflisten jedes Items eines Typs. Jedes davon verschlüsselt dieselben Daten neu, was nur ein Index kann — der Planer schlägt einen pro Schlüsselform vor und verwendet ihn über Muster hinweg wieder, die dieselbe Form teilen.
Wie wirken sich GSIs auf die DynamoDB-Kosten aus?
Jeder GSI pflegt seine eigene projizierte Kopie der Items, die er abdeckt, sodass jeder Tabellenschreibvorgang auch Schreibkapazität auf jedem GSI verbraucht, der das Item projiziert, und Speicher wird pro Kopie abgerechnet. Die Kostenkarte zeigt eine Schätzung für die Basistabelle und eine mit inbegriffener GSI-Schreibreplikation, mit derselben 4-KB-Lese-/1-KB-Schreib-Rundung wie unsere Preis- und Item-Größenrechner.
Lädt der Planer mein Datenmodell irgendwohin hoch?
Nein. Die Seite ist statisch und das Design wird vollständig in deinem Browser berechnet — Entitätsnamen, ID-Attribute und Zugriffsmuster erreichen niemals einen Server. Der einzige Weg, auf dem ein Design die Seite verlässt, ist die „Link kopieren“-URL, die es in den Link packt, sodass das Teilen eine bewusste Handlung bleibt.