DynoTable
Pemula4 menit baca

Query vs Scan di DynamoDB

Query membaca satu koleksi Item berdasarkan partition key (opsional mempersempit sort key); Scan membaca seluruh tabel dan memfilter sesudahnya. Keduanya terlihat mirip di API tetapi keduanya menagih — dan menskala — secara benar-benar berbeda.

Kapan sebaiknya saya menggunakan Query vs Scan di DynamoDB?

Gunakan Query setiap kali Anda dapat menyebutkan partisi yang Anda butuhkan — ia membaca satu koleksi Item dan hanya menagih untuk Item yang cocok. Gunakan Scan hanya untuk ekspor sekali pakai atau tabel kecil; ia membaca setiap Item dan menagih seluruh tabel sebelum FilterExpression apa pun berjalan. Pada data nyata, Query selalu menang.

  • Query bersifat tertarget: Anda membayar untuk Item dalam partisi yang cocok.
  • Scan bersifat menyeluruh: Anda membayar untuk membaca setiap Item, lalu membuang sebagian besar dengan FilterExpression yang berjalan setelah pembacaan dihitung.

Pada tabel berukuran nyata apa pun, sebuah Scan dengan filter adalah jebakan klasik "kenapa tagihan saya besar dan latensi saya lebih buruk daripada RDS".

Berdampingan

QueryScan
PembacaanSatu partisi (berdasarkan PK)Setiap Item dalam tabel
Kapasitas ditagihItem yang cocok dalam partisiSeluruh tabel, sebelum pemfilteran
FilterExpressionDiterapkan setelah pembacaan — tetap ditagih untuk pembacaanSama — pemfilteran tak pernah memangkas biaya
LatensiDatar seiring tabel bertumbuhBertumbuh seiring ukuran tabel
Paginasi1 MB/halaman → LastEvaluatedKey1 MB/halaman; dapat diparalelkan
Gunakan untukPola akses yang diketahuiEkspor sekali pakai, tabel config kecil

Jebakan utama: sebuah FilterExpression berjalan setelah DynamoDB menghitung pembacaan, pada kedua operasi. Sebuah Scan yang "mengembalikan 10 baris" dapat menagih untuk membaca satu juta — pemfilteran adalah kenyamanan, bukan pengendali biaya.

Gunakan Query

Query  PK = "USER#42"  AND  SK begins_with "ORDER#"

Jika Anda mendapati diri Anda meraih Scan untuk menjawab pola akses yang umum, itu adalah sinyal pemodelan: tambahkan Global Secondary Index sehingga pola itu menjadi sebuah Query.

Pilihannya bermuara pada satu pertanyaan — bisakah Anda menyebutkan partisi yang Anda butuhkan?

YesNoYesNoAccess patternPartition key known?Query — reads one partitionCan a GSI key it?Add a GSIScan — reads the whole table

Jika key-nya diketahui, Anda Query; jika tidak, tambahkan GSI untuk menjadikannya satu, dan kembali ke Scan hanya saat tidak ada key yang cocok.

Kapan Scan baik-baik saja

Ekspor sekali pakai, tabel config kecil, dan job latar belakang yang mem-paging seluruh tabel secara sengaja. Gunakan Segment/TotalSegments untuk membagi sebuah Scan di antara worker (sebuah parallel scan) saat Anda benar-benar harus membaca semuanya.

Sebuah SELECT * FROM table refleksif atas DynamoDB adalah anti-pola yang sama dalam balutan PartiQL — ia dikompilasi menjadi sebuah Scan. Saat Anda benar-benar membutuhkan analitik lintas Item (sebuah GROUP BY, sebuah JOIN, sebuah agregat), SQL Workbench DynoTable menjalankannya di sisi klien atas kumpulan hasil yang terbatas alih-alih menggempur tabel.

Perkirakan read unit yang akan dikeluarkan pola mana pun dengan kalkulator kapasitas, dan coba DynoTable untuk menjalankan dan memeriksa query-query ini terhadap tabel Anda sendiri.

Diperbarui