Parallel Scan DynamoDB

Parallel scan membagi satu Scan menjadi N request Scan independen; masing-masing mengklaim sebuah Segment dari tabel, sehingga banyak worker membacanya sekaligus. Itu satu-satunya cara API Scan menawarkan untuk membaca seluruh tabel lebih cepat daripada yang diizinkan throughput satu partisi.

Apa itu parallel scan DynamoDB?

Parallel scan DynamoDB membagi satu Scan menjadi N request independen; masing-masing mengklaim Segment tabel lewat Segment dan TotalSegments, sehingga banyak worker membaca secara bersamaan. Itu satu-satunya cara API Scan menawarkan untuk membaca seluruh tabel lebih cepat daripada throughput satu partisi — tetapi tetap baca penuh, jadi Anda membayar setiap item yang di-scan.

Scan berurutan membaca satu partisi pada satu waktu — kecepatannya dibatasi throughput satu partisi, berapa pun besar tabelnya.
Segment + TotalSegments memecah baca lintas TotalSegments worker; tiap worker men-scan potongannya sendiri secara paralel.
DynamoDB meng-hash untuk menugaskan segment, jadi potongan bisa timpang — lebih banyak worker tidak selalu lebih cepat.
Tetap Scan: Anda membayar untuk membaca setiap item, dan parallel scan besar bisa menguras throughput tabel dari bawah traffic live Anda.

Mengapa Scan berurutan lambat

Datang dari SQL, baca full-table terasa seperti satu operasi streaming. Di DynamoDB tidak. Data tabel hidup lintas banyak partisi fisik, tetapi satu Scan menelusurinya satu per satu, 1 MB per halaman.

Artinya Scan biasa hanya bisa menarik dari anggaran throughput satu partisi pada satu momen — bahkan jika tabel tersebar di puluhan partisi dengan kapasitas menganggur. Semakin besar tabel, semakin lama ia merangkak. (AWS: Scan paralel)

Bagi baca dengan Segment dan TotalSegments

Parallel scan memperbaiki bottleneck itu. Anda pilih jumlah worker, set TotalSegments ke angka itu, dan beri tiap worker Segment berbasis nol yang berbeda. Setiap worker mengeluarkan Scan-nya sendiri; DynamoDB melayaninya bersamaan.

Worker 0 →  Scan  Segment=0  TotalSegments=4
Worker 1 →  Scan  Segment=1  TotalSegments=4
Worker 2 →  Scan  Segment=2  TotalSegments=4
Worker 3 →  Scan  Segment=3  TotalSegments=4

Tiap worker masih memaginasi dengan LastEvaluatedKey secara independen — ia memiliki segment dari halaman pertama sampai terakhir. Aplikasi menjahit empat stream kembali menjadi satu. Anda sekarang membaca throughput senilai empat partisi sekaligus alih-alih satu.

Contoh kerja: ekspor malam

Katakan Anda menjalankan tabel telemetri, sensor-readings. Tiap item adalah satu pembacaan dari perangkat lapangan:

PK = "DEVICE#a83f"          (partition key — the device id)
SK = "TS#2026-06-22T03:14"  (sort key — ISO timestamp)
batteryMv  = 3120
tempC      = 41.8
firmwareTag = "fw-7.2.1"

Setiap malam cron job membuang seluruh tabel ke S3 untuk warehouse analitik. Scan berurutan 80 GB memakan jam dan hampir tidak menyentuh kapasitas baca provisioned Anda. Jadi Anda fan-out ke delapan worker:

Scan  sensor-readings  Segment=0  TotalSegments=8  ConsistentRead=false
…
Scan  sensor-readings  Segment=7  TotalSegments=8  ConsistentRead=false

Delapan worker, delapan segment, satu baca tabel kira-kira delapan kali lebih cepat. Jika Anda hanya butuh pembacaan terbaru, tambahkan FilterExpression untuk membuang timestamp lama sebelum baris menyentuh wire — bangun dan periksa expression itu di Expression Builder:

FilterExpression:  begins_with(SK, :today)

Bagaimana DynamoDB menugaskan item ke segment

DynamoDB menugaskan tiap item ke segment dengan meng-hash partition key-nya — bukan by jumlah baris, bukan by jumlah byte.

Jadi setiap item yang berbagi PK mendarat di segment yang sama. Di sensor-readings, semua pembacaan untuk DEVICE#a83f pergi ke satu worker, terlepas berapa banyak timestamp perangkat itu miliki atau seberapa besar -nya. (AWS: Scan paralel)

Segment berakhir tidak merata. Satu worker mungkin memiliki tiga perangkat cerewet dengan jutaan pembacaan; yang lain mungkin mendapat potongan kosong. Menaikkan TotalSegments tidak membantu jika partition key Anda menggumpal — Anda hanya menambah worker menganggur yang menunggu yang panas. Distribusi key yang merata yang membuat fan-out berharga.

Lihat biaya baca sebelum menjalankannya

Parallel scan adalah peristiwa throughput, bukan makan siang gratis. Pertanyaan jujurnya: "berapa banyak dari seluruh tabel ini yang akan saya baca?" — dan sebelum DynoTable menjalankan baca full-table ia mengunci Anda dengan dialog konfirmasi yang menampilkan perkiraan ukuran tabel dan jumlah item plus peringatan kapasitas baca, lalu men-stream progres items-scanned secara live saat baca berjalan, agar job malam tidak mengejutkan Anda.

Jebakan dan kapan tidak perlu

Tebing throughput. Scan TotalSegments tinggi bisa mengonsumsi seluruh kapasitas baca tabel dalam detik, membuat lapar traffic live. Pada tabel yang melayani pengguna, throttle tiap worker dengan parameter Limit atau scan off-peak. (AWS: Scan paralel)
Tetap alat yang salah untuk access pattern. Parallel scan untuk job full-table yang disengaja — ekspor, backfill, migrasi. Jika Anda menjangkaunya untuk menjawab query berulang, itu sinyal pemodelan: tambah GSI dan jadikan Query.
SELECT * di PartiQL adalah scan yang sama berkedok. Ia dikompilasi menjadi Scan berurutan. Saat Anda benar-benar butuh analitik lintas-item — GROUP BY, JOIN, agregat — SQL Workbench DynoTable menjalankannya di sisi klien atas result set terbatas, alih-alih menghantam tabel.
Strong consistency menggandakan tagihan. Scan default ke baca . Untuk ekspor, biarkan ConsistentRead=false kecuali tiap halaman harus mencerminkan write terbaru — dan catat bahkan scan strongly consistent mencakup menit, jadi bukan snapshot point-in-time (pakai PITR/Export untuk itu).

Langkah selanjutnya

Model key Anda agar baca sehari-hari tidak pernah butuh scan — mulai dengan single-table design dan Query vs Scan. Saat job full-table benar-benar pilihan yang tepat, coba DynoTable untuk menjalankan baca full-table dengan peringatan ukuran-dan-biaya di depan dan progres scan live.