DynamoDB-Item-Collections

Eine Item Collection ist die Menge aller Items in einer Tabelle (oder einem Index), die denselben Partition-Key-Wert teilen — eine emergente Eigenschaft deines Key Schema.

Sobald zwei Items denselben Partition Key tragen, bilden sie eine Collection, und diese Collection wird die Einheit, die DynamoDB dich zusammen in einer einzelnen Query lesen lässt.

Mach das richtig und deine Reads kommen in einem Round Trip zurück. Mach es falsch und du steckst mit einem Scan fest.

Was ist eine DynamoDB-Item-Collection?

Eine DynamoDB-Item-Collection ist die Menge aller Items, die denselben Partition-Key-Wert teilen, zusammen gespeichert und nach Sort Key sortiert. Die Collection entsteht aus deinem Key Schema. Die Collection ist die Einheit, die eine einzelne Query effizient liest, während ein Scan jede Partition abläuft.

• Eine Collection ist einfach „derselbe Partition Key“. Zwei oder mehr Items mit demselben Partition-Key-Wert werden zusammen gespeichert, sortiert nach Sort Key.
• Sie ist die Einheit einer effizienten Query. Query liest eine Collection; Scan läuft jede Partition ab. Das ist die ganze Performance-Story.
• Kein Sort Key, keine Collection. Eine Partition-Key-only-Tabelle hält ein Item pro Key — nichts zu collecten.
• Zwei Limits beißen: die 10-GB-Per-Collection-Decke, wenn ein LSI existiert, und Hot Partitions von low-cardinality Keys.

Das Problem: related Items zusammen lesen

Angenommen, du betreibst eine Flotte von Vehicles, die jeweils Telemetrie streamen — Speed, Coolant Temperature, Fuel Level — alle paar Sekunden. Der dominante Read ist „gib mir die recent Readings für Vehicle V-7741“.

Aus SQL würdest du eine vehicle_id-Column indexieren und den Planner arbeiten lassen. Ein plain Key-Value-Store hat keinen solchen Luxus.

Er behandelt jedes Reading als isolierten Record, also heißt diese Frage, die ganze Tabelle zu scannen und zu filtern. Langsam, teuer und schlechter, wenn die Flotte wächst.

DynamoDBs Antwort ist, „alle Readings für ein Vehicle“ zu einer physisch gruppierten, direkt addressierbaren Sache zu machen. Diese Gruppierung ist die Item Collection.

Was eine Collection wirklich ist

DynamoDB speichert Items in Partitionen und routet jedes Item zu einer Partition, indem es seinen Partition Key hasht. Jedes Item mit demselben Partition- Key-Wert wird zusammen gespeichert und nach Sort Key sortiert. Sie starten auf einer Partition, aber ohne LSI kann DynamoDB eine große oder heiße Collection an einer Sort-Key-Grenze über Partitionen splitten; nur ein LSI pinnt die ganze Collection an eine einzelne Partition (weshalb die 10-GB-Cap unten LSI-only ist).

Der AWS Developer Guide nennt das genau so. Items, die einen Partition-Key-Wert teilen, sind eine Item Collection, zusammen gespeichert und nach Sort Key geordnet.

Das ist dieselbe Idee, die das 2007 Amazon Dynamo Paper einführte — Consistent Hashing, um Keys Nodes zuzuweisen — erweitert um eine Sort-Dimension, sodass related Items adjacent on Disk sitzen.

Weil sie adjacent und geordnet sind, gibt DynamoDB einen contiguous Run von ihnen mit einem Seek zurück. Deshalb ist Query günstig und Scan nicht: Query liest eine einzelne Collection; Scan läuft jede Partition ab.

Um eine Collection zu bilden, brauchst du einen zusammengesetzten Primary Key — einen Partition Key und einen Sort Key. Eine Tabelle, die nur auf Partition Key gekeyed ist, hat genau ein Item pro Key-Wert, also gibt es nichts zu collecten.

Unser Praxisbeispiel: Vehicle → Telemetrie-Readings

Modelliere den Telemetrie-Stream mit einem Composite Key. Der Partition Key identifiziert das Vehicle; der Sort Key ist der Timestamp des Readings, der Readings in Timestamp-Ordnung hält (aufsteigend by Default; übergib ScanIndexForward=false für newest-first).

Zwei Collections leben hier — eine pro Vehicle. Das META-Item (Vehicle- Metadata) und alle Readings von V-7741 bilden eine Collection; die Items von V-7742 bilden eine andere.

Gib den Metadata einen Sort Key (META), der vor jedem TS#...-Wert sortiert, und eine einzelne Query auf PK = "VEH#V-7741" gibt das Profil des Vehicle und seine Readings zusammen zurück.

Das ist das Parent-and-Children-Pattern im Herzen von Single-Table Design.

Jede gestrichelte Box ist eine Item Collection: derselbe Partition Key, Items nach Sort Key sortiert. Eine Query liest genau eine Box.

Eine Collection querien

Weil die Collection nach Sort Key sortiert ist, bekommst du Range-Reads gratis. Um die Readings in einem Zehn-Minuten-Fenster für ein Vehicle zu pullen, boundest du den Sort Key:

# Query
KeyConditionExpression   vehicleId = :v AND recordedAt BETWEEN :from AND :to
ScanIndexForward         false        # newest first

Die Key Condition beschränkt dich auf eine Collection (vehicleId = :v) und dann auf einen contiguous Slice davon (recordedAt BETWEEN ...). DynamoDB liest nur diese Items und rechnet nur sie ab. Willst du nur die Metadata? recordedAt = "META" fetcht das einzelne META-Item.

Diese Key Conditions und Projection Expressions von Hand zu bauen ist fiddly. Der DynamoDB Expression Builder generiert die KeyConditionExpression, die ExpressionAttributeNames und die ExpressionAttributeValues für dich, sodass Reserved-Word- und Placeholder- Details nicht beißen.

Collections auf Indexes

Ein Secondary Index hat sein eigenes Key Schema, also bildet er seine eigenen Item Collections.

Füge einen Global Secondary Index keyed on depotCode (Partition) und recordedAt (Sort) hinzu, und „alle Readings vom Depot DEP-LON-3, newest first“ wird eine einzelne Query gegen die Collection dieses Index — ein Read, den die Base Table nicht bedienen kann.

Deshalb zählt der Index-Typ: er steuert, welche Collections du bilden kannst und wie sie sich verhalten. Siehe GSI vs LSI für den Trade-off.

Eine scharfe Unterscheidung: ein Local Secondary Index (LSI) teilt den Partition Key der Base Table, also ist seine Collection physisch an die Base- Item-Collection gebunden — und diese Bindung erzeugt ein hartes Limit, unten.

Die Limits, die beißen

Item Collections sind mächtig, aber zwei Constraints entscheiden, wie du Keys formst:

• Das 10-GB-LSI-Limit. Wenn eine Tabelle einen oder mehrere local Secondary Indexes hat, darf eine einzelne Item Collection — die Base-Items plus ihre LSI- Projektionen für einen Partition Key — 10 GB nicht überschreiten. Überschreite es und Writes, die die Collection wachsen lassen, beginnen mit ItemCollectionSizeLimitExceededException zu failen. Eine Tabelle ohne LSI hat keine solche Per-Collection-Decke. Genau deshalb ist ein unbegrenzter, immer wachsender Stream (Telemetrie, die nie stoppt) ein schlechter Fit für ein LSI: die Collection wächst nur. Ein GSI bekommt eigene Partitionen und umgeht das Limit.
• Hot Partitions. Eine Collection lebt in einer Partition, und eine einzelne Partition hat endlichen Throughput. Wenn ein Vehicle (oder ein depotCode) einen wild disproportionaten Anteil Traffic anzieht, kannst du diese Partition hot-spotten, selbst wenn die Tabelle als Ganzes gut unter ihrem provisionierten Throughput liegt. Adaptive Capacity — in AWS' „Advanced Design Patterns for DynamoDB“-re:Invent-Deep-Dives abgedeckt — isoliert und boostet Hot Keys automatisch, kann aber einen Key ohne Spread überhaupt nicht retten. Wähle Partition Keys mit hoher Kardinalität, sodass Traffic über viele Collections fächert.

In DynoTable ansehen

Der schnellste Weg, Intuition für Collections zu bauen, ist, eine anzuschauen. In DynoTable rendert das Querien eines Partition Key die ganze Collection als contiguous, Sort-Key-geordnete Liste — das META-Item sitzt direkt vor seinen timestamped Readings, on Screen, keine mentale Rekonstruktion nötig.

Fallstricke und nächste Schritte

• Kein Sort Key, keine Collection. Eine Partition-Key-only-Tabelle kann related Items nicht gruppieren. Brauchst du, Items zusammen zu lesen, brauchst du einen Composite Key.
• Lass eine LSI-Collection nicht unbegrenzt wachsen. Append-only Streams gehören auf einen GSI (oder einen time-bucketed Partition Key), nicht auf ein LSI, wegen der 10-GB-Decke.
• Spread deine Partition Keys. Eine Collection ist nur so skalierbar wie die Partition, in der sie lebt. Low-cardinality Partition Keys erzeugen Hot Spots.
• Greif zu Query, nicht Scan. Collections existieren, damit du related Items mit einer gezielten Query lesen kannst; auf einen Scan zurückzufallen wirft diesen Vorteil weg — siehe Query vs Scan.

Skizziere dein eigenes Key Schema, fahre eine Query gegen einen echten Partition Key und sieh die Collection geordnet zurückkommen. Lade DynoTable herunter und erkunde die Collections deiner Tabellen direkt.