DynamoDB Scan di Python (boto3)

Sebuah scan di boto3 adalah dua keputusan: request-nya, dan bagaimana Anda memaginasinya. Cuplikan di bawah memakai paginator bawaan, yang bukan pembungkus buatan seseorang di sekitar loop Anda. Ia lima baris konfigurasi botocore, dan lima baris itulah yang menentukan apakah scan Anda benar dan berapa biayanya. (Apakah Anda memang seharusnya melakukan scan sama sekali adalah pertanyaan lain.)

Kode

import boto3

client = boto3.client("dynamodb")

paginator = client.get_paginator("scan")

items = []
for page in paginator.paginate(
    TableName="Music",
    FilterExpression="#filter0 >= :filterValue0",
    ExpressionAttributeNames={"#filter0": "Year"},
    ExpressionAttributeValues={":filterValue0": {"N": "2010"}},
):
    items.extend(page["Items"])

print(f"Matched {len(items)} items")

Penjelasan

Paginator-nya adalah data, bukan kode. botocore menyertakan satu entri per operasi di paginators-1.json; milik Scan berbunyi {"input_token": "ExclusiveStartKey", "output_token": "LastEvaluatedKey", "limit_key": "Limit", "result_key": ["Items", "Count", "ScannedCount"], "non_aggregate_keys": ["ConsumedCapacity"]}. Semua hal di bawah ini turun dari key-key itu.
PaginationConfig={"PageSize": n} menyetel Limit, karena Limit adalah limit_key-nya. Limit membatasi item yang dibaca, tak pernah item yang dikembalikan, jadi dengan sebuah FilterExpression sebuah halaman bisa kosong dan tetap berbiaya.
MaxItems menghitung item result_key dan mengembalikan NextToken yang bisa Anda lewatkan sebagai StartingToken di proses berikutnya. Ia tidak menghentikan request membaca melewati batas Anda.
build_full_result() hanya mengagregasi field result_key. Items, Count dan ScannedCount dijumlahkan; ConsumedCapacity adalah non_aggregate_key, jadi hasil gabungannya melaporkan kapasitas satu halaman seolah-olah itu kapasitas seluruh scan. Jumlahkan sendiri, per halaman, atau Anda akan melaporkannya terlalu rendah sebesar faktor jumlah halaman.
FilterExpression berjalan di sisi server setelah pembacaan, jadi Anda ditagih berdasarkan ScannedCount, bukan Count. #filter0 memberi alias pada Year karena ia sebuah reserved word; tanpa alias itu request-nya gagal sebelum membaca apa pun.
Semua error datang sebagai botocore.exceptions.ClientError. Cabangkan berdasarkan e.response["Error"]["Code"]; kelas per-error hanya ada sebagai atribut yang dihasilkan pada client (client.exceptions.ProvisionedThroughputExceededException), tak pernah sebagai simbol yang bisa di-import.
Resource API adalah ergonomi yang satunya. Table.scan menerima tipe Python native, mengembalikan angka sebagai decimal.Decimal, dan membangun filter dengan Attr("Year").gte(2010) alih-alih map placeholder.

Berapa sebenarnya biaya satu halaman terfilter

60 item berukuran sekitar 2 KB masing-masing, Year = 2024 cocok pada dua di antaranya, PageSize=10, dijalankan terhadap DynamoDB Local:

page 1: Count=0 ScannedCount=10 CU=2.5 LastEvaluatedKey=yes
page 2: Count=1 ScannedCount=10 CU=2.5 LastEvaluatedKey=yes
page 3: Count=0 ScannedCount=10 CU=2.5 LastEvaluatedKey=yes
page 4: Count=1 ScannedCount=10 CU=2.5 LastEvaluatedKey=yes
page 5: Count=0 ScannedCount=10 CU=2.5 LastEvaluatedKey=yes
page 6: Count=0 ScannedCount=10 CU=2.5 LastEvaluatedKey=yes
page 7: Count=0 ScannedCount=0 CU=0.0 LastEvaluatedKey=no
total CU across pages: 15.0

Empat dari enam halaman sungguhan tidak mengembalikan apa-apa, dengan harga penuh. Itulah bentuk bug yang keberadaan paginator-nya mencegahnya: loop buatan tangan yang berhenti saat Items kosong akan menyerah di halaman 1 dan melaporkan dua lagu yang cocok sebagai nol.

Halaman 7 adalah separuh lainnya. Halaman 6 mencapai Limit-nya tepat pada item terakhir di tabel, jadi DynamoDB tetap mengembalikan sebuah LastEvaluatedKey dan paginator-nya menghabiskan satu round trip lagi untuk mengetahui tak ada apa-apa lagi. Sebuah LastEvaluatedKey berarti "saya berhenti", bukan "masih ada lagi".

Memanggil build_full_result() pada scan yang sama melaporkan CapacityUnits: 2.5. Keenam halamannya memakan 15,0.

Paginasi tanpa menulis loop-nya

DynamoDB Query Builder merakit filter, map alias, dan loop paginasinya sebagai satu program yang siap dijalankan, jadi jebakan Limit-versus-Count di atas sudah tertangani sebelum Anda menempelkannya. Untuk memaginasi tabel sungguhan secara interaktif alih-alih dari sebuah skrip, unduh DynoTable.

Panduan terkait

Query vs. Scan — kapan (jarang) sebuah scan bisa dibenarkan.
Mengapa Scan DynamoDB saya lambat dan mahal? — model biayanya dan cara menghindarinya.
Parallel scan — memecah tabel dengan Segment / TotalSegments, satu paginator per segmen.
DynamoDB ProvisionedThroughputExceededException — apa yang dilakukan scan seluruh tabel terhadap kapasitas tabel provisioned.

Referensi

Terakhir diverifikasi 2026-07-28 terhadap dokumentasi resmi AWS yang ditautkan di atas.