DynamoDB Scan di Node.js (AWS SDK v3)

do/while di bawah ini bukan kode defensif. Satu halaman Scan yang terfilter bisa kembali dengan array Items kosong padahal masih ada sisa tabel, jadi berhenti pada respons pertama adalah cara sebuah scan melaporkan nol kecocokan pada tabel yang sebenarnya punya kecocokan. Query vs. Scan membahas kapan harus menghindari operasi ini sama sekali.

Kode

import {DynamoDBClient, ScanCommand} from '@aws-sdk/client-dynamodb';

const client = new DynamoDBClient({region: 'us-east-1'});

const items = [];
let lastEvaluatedKey;

do {
  const response = await client.send(
    new ScanCommand({
      TableName: 'Music',
      FilterExpression: '#filter0 >= :filterValue0',
      ExpressionAttributeNames: {
        '#filter0': 'Year'
      },
      ExpressionAttributeValues: {
        ':filterValue0': {N: '2010'}
      },
      ExclusiveStartKey: lastEvaluatedKey
    })
  );

  items.push(...(response.Items ?? []));
  lastEvaluatedKey = response.LastEvaluatedKey;
} while (lastEvaluatedKey);

console.log(`Matched ${items.length} items`);

Dua halaman kosong, 284,5 read unit, 8 item

Fixture-nya adalah 600 lagu berukuran sekitar 3,9 KB masing-masing, yang persis 8 di antaranya punya Year >= 2010, dan semuanya berada di urutan terakhir. Inilah yang sebenarnya diterima loop di atas:

Round trip	`Items.length`	`ScannedCount`	Read unit	`LastEvaluatedKey`
1	0	271	128,5	ada
2	0	271	128,5	ada
3	8	58	27,5	tidak ada

Dua halaman berturut-turut tidak mengembalikan apa pun dan masing-masing menghabiskan 128,5 read unit. Kode yang melakukan if (!response.Items.length) return melaporkan tabel kosong. Referensi API menyatakan aturannya terus terang: "a scan result can result in no items meeting the criteria and the Count will result in zero", dan secara terpisah bahwa "a FilterExpression is applied after the items have already been read; the process of filtering does not consume any additional read capacity units".

Bacalah kalimat kedua itu seperti tagihan Anda membacanya. Filter-nya gratis, dan segala yang ia buang tidak: 284,5 read unit untuk menyerahkan 8 item, tagihan yang sama dengan yang Anda bayar tanpa filter sama sekali.

Diukur 2026-07-28 terhadap DynamoDB Local (amazon/dynamodb-local) dengan @aws-sdk/client-dynamodb 3.1095.0 pada node v24.18.0. Hitungan dan kapasitasnya adalah field respons milik mesin itu sendiri.

Penjelasan

ExclusiveStartKey: lastEvaluatedKey bernilai undefined pada lintasan pertama. Serializer v3 membuang anggota undefined, jadi satu objek literal mencakup permintaan pertama dan semua lanjutannya. Mengoper {} sebagai gantinya gagal dengan ValidationException: The provided starting key is invalid.
response.Items ?? [] melakukan pekerjaan nyata. Padukan dengan tabel di atas: nullish coalescing menjaga akumulatornya tetap jujur pada halaman yang tidak menemukan apa pun, dan while menjaga loop-nya tetap hidup melewati halaman-halaman itu.
#filter0 bukan hiasan. Year ada dalam daftar reserved word AWS, dan memakainya tanpa alias mengembalikan ValidationException: Invalid FilterExpression: Attribute name is a reserved keyword; reserved keyword: Year.
Limit menghitung item yang dibaca, bukan item yang dikembalikan. Dengan filter ini, Limit: 10 menghasilkan Count: 0 dan ScannedCount: 10. Ia adalah tombol pengerem untuk lonjakan kapasitas, bukan cara meminta sepuluh hasil.
Segment / TotalSegments membelah scan seluruh tabel ke beberapa worker. Itu membagi wall clock, bukan biayanya — 284,5 unit yang sama tetap dihabiskan, cuma lebih cepat dan lebih paralel.

Berapa biayanya pada tabel sungguhan

284,5 read unit untuk 8 item adalah bentuk masalahnya, dan ia menskala linier terhadap tabelnya, bukan terhadap hasilnya. Sebelum mengirim scan terfilter ke jalur panas, hargai pembacaan seluruh tabel pada ukuran item dan trafik Anda di kalkulator harga DynamoDB, lalu bandingkan dengan GSI yang mengubah pola akses yang sama menjadi sebuah Query.

Untuk menjelajahi tabel di GUI, dengan grid hasil yang terfilter dan berpaginasi, unduh DynoTable alih-alih melakukan scan membabi buta dari sebuah skrip.

Panduan terkait

Query vs. Scan — kapan (jarang) sebuah Scan bisa dibenarkan.
Mengapa Scan DynamoDB saya lambat dan mahal? — model biayanya dan cara menghindarinya.
DynamoDB ProvisionedThroughputExceededException — apa yang dilakukan scan seluruh tabel terhadap kapasitas tabel provisioned.
DynamoDB ThrottlingException — throttle yang satunya, dan bagaimana exponential backoff menanganinya.