Alle Items aus DynamoDB in Python holen (boto3)

Eine ganze Tabelle in boto3 zu lesen heißt, einen scan bis zum Ende zu paginieren. Jede Antwort ist bei 1 MB gedeckelt, und der eingebaute Paginator des Low-Level-Clients folgt LastEvaluatedKey über alle Seiten für dich (wie DynamoDB-Cursor funktionieren).

Welche boto3-API du wählst, zählt hier mehr als die Paginierung — und der Paginator ist nur die halbe Begründung.

Code

import boto3

client = boto3.client("dynamodb")

paginator = client.get_paginator("scan")

items = []
for page in paginator.paginate(TableName="Music"):
    items.extend(page["Items"])

print(f"Table holds {len(items)} items")

Erklärung

• Paginatoren gehören zum Client, nicht zur Resource — boto3.resource("dynamodb").Table(…).scan hat überhaupt keinen Paginator, dort schreibst du die LastEvaluatedKey-Schleife also selbst. Schon das ist ein guter Grund, für einen vollständigen Read den Low-Level-Client zu nehmen.
• Die Resource-API wandelt Zahlen in Decimal — ein gespeichertes {"N": "1994"} kommt als Decimal('1994') zurück, was json.dumps ohne eigenen Encoder nicht serialisieren will. Der Client oben gibt dir das rohe {"N": "1994"} und überlässt dir die Umwandlung (die Kodierung).
• Stell den Paginator ein, statt ihn zu ersetzen — paginator.paginate(TableName="Music", PaginationConfig={"PageSize": 500, "MaxItems": 10000}). Boto3 definiert PageSize als "the number of items returned per page of each result" und MaxItems als Obergrenze für die Gesamtzahl, was ein NextToken erzeugt, mit dem du über StartingToken fortsetzt.
• Parallel Scans brauchen einen Client pro Thread, sorgfältig gebaut — Segment und TotalSegments teilen die Arbeit auf, und boto3s eigene Empfehlung lautet, dass Clients thread-safe sind, Sessions und Resources aber nicht. Es warnt außerdem, dass "Invoking boto3.client() inside of a concurrent context may result in response ordering issues". Baue den Client, bevor du auffächerst, oder gib jedem Worker seine eigene boto3.session.Session() (wann sich parallel lohnt).
• items wächst auf die Größe der Tabelle — verarbeite jede page innerhalb der Schleife, statt eine Liste zu füllen, die du behältst, es sei denn, du weißt bereits, dass die Tabelle klein ist.
• Ein Scan berechnet jedes gelesene Byte, bei jedem Lauf — ProjectionExpression verkleinert die Antwort, nicht die Rechnung (warum); eine FilterExpression verwirft Items, nachdem sie gelesen und berechnet wurden (Scan mit Filter). Auf einem heißen Pfad willst du eine Query.

Mach es visuell

Die Rechnung eines vollständigen Scans ist Item-Größe mal Item-Anzahl, aufgerundet in 4-KB-Einheiten. Der Item-Size-Rechner liefert dir aus einem eingefügten Item die Hälfte pro Item.

DynoTable blättert stattdessen in einem endlos scrollenden Grid durch eine Live-Tabelle, und sein SQL-Editor nennt dir die Operation, zu der deine Abfrage kompiliert, bevor du sie ausführst. Die RCU-Schätzung erscheint nur, wenn die Tabellen-Metadaten sie hergeben. DynoTable herunterladen.

Verwandte Beispiele

• Alle Items in Node.js holen — derselbe vollständige Read mit expliziter Schleife.
• Alle Items mit der AWS CLI holen — die CLI blättert für dich.
• DynamoDB Scan in Python — scannen mit einer FilterExpression.
• Parallel Scans — Segment/TotalSegments, Worker-Anzahl und wann es sich lohnt.
• Warum ist mein DynamoDB Scan langsam und teuer? — das Kostenmodell und wie du es umgehst.
• DynamoDB ProvisionedThroughputExceededException — die ganze Tabelle zu lesen ist der klassische Weg dorthin.
• "The provided starting key is invalid" — ein zerschossener Fortsetzungs-Key in der Paginierungsschleife.

Referenzen

• Scan — Amazon DynamoDB API Reference
• DynamoDB.Paginator.Scan — Boto3 documentation
• Scanning tables in DynamoDB — Amazon DynamoDB Developer Guide
• DynamoDB read and write operations (capacity unit consumption) — Amazon DynamoDB Developer Guide
• Paginators — Boto3 documentation
• Clients (thread safety) — Boto3 documentation

Zuletzt verifiziert am 2026-07-28 gegen die oben verlinkte offizielle AWS-Dokumentation.