DynoTable
Lanjutan6 menit baca

Parallel Scan DynamoDB

Sebuah parallel scan membagi satu Scan menjadi N request Scan independen, masing-masing mengklaim sebuah Segment dari tabel, sehingga beberapa worker membacanya sekaligus. Ini satu-satunya cara membaca seluruh tabel lebih cepat daripada yang diizinkan throughput satu partition.

Apa itu parallel scan DynamoDB?

Parallel scan DynamoDB membagi satu Scan menjadi N request independen, masing-masing mengklaim sebuah Segment dari tabel melalui Segment dan TotalSegments, sehingga beberapa worker membacanya secara bersamaan. Ini satu-satunya cara membaca seluruh tabel lebih cepat daripada yang diizinkan throughput satu partition — tetapi ini tetap pembacaan penuh, sehingga Anda membayar untuk setiap Item yang dipindai.

  • Sebuah Scan sekuensial membaca satu partition pada satu waktu — kecepatannya dibatasi pada throughput satu partition, sebesar apa pun tabelnya.
  • Segment + TotalSegments men-shard pembacaan ke TotalSegments worker; setiap worker memindai irisannya sendiri secara paralel.
  • DynamoDB meng-hash partition key untuk menetapkan segmen, jadi irisan bisa timpang — lebih banyak worker tidak selalu berarti lebih cepat.
  • Ia tetap sebuah Scan: Anda membayar untuk membaca setiap Item, dan sebuah parallel scan yang gemuk bisa menguras throughput tabel dari bawah lalu lintas langsung Anda.

Mengapa Scan sekuensial lambat

Datang dari SQL, pembacaan tabel-penuh terasa seperti satu operasi streaming. Di DynamoDB tidak. Data tabel tinggal di banyak partition fisik, tapi satu Scan menjelajahinya satu per satu, 1 MB per halaman.

Itu berarti sebuah Scan biasa hanya bisa menarik dari anggaran throughput satu partition pada satu saat — bahkan jika tabel tersebar di lusinan partition dengan kapasitas menganggur. Semakin besar tabel, semakin lama ia merangkak. (AWS: Parallel scan)

Bagi pembacaan dengan Segment dan TotalSegments

Sebuah parallel scan memperbaiki bottleneck-nya. Anda memilih jumlah worker, mengatur TotalSegments ke angka itu, dan memberi setiap worker sebuah Segment berbasis-nol yang berbeda. Setiap worker mengeluarkan Scan-nya sendiri; DynamoDB menyajikannya secara 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

Setiap worker tetap memberi halaman dengan LastEvaluatedKey secara independen — ia memiliki segmennya dari halaman pertama hingga terakhir. Aplikasi menjahit kembali keempat aliran tersebut. Anda kini membaca throughput senilai empat partition sekaligus alih-alih satu.

Sebuah contoh nyata: ekspor malam hari

Misalkan Anda menjalankan tabel telemetri, sensor-readings. Setiap Item adalah satu pembacaan dari sebuah perangkat lapangan:

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

Setiap malam sebuah cron job membuang seluruh tabel ke S3 untuk analytics warehouse. Sebuah Scan sekuensial atas 80 GB memakan waktu berjam-jam dan nyaris tak menyentuh kapasitas baca yang diprovisioning. Jadi Anda menyebarkannya ke delapan worker:

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

Delapan worker, delapan segmen, satu pembacaan tabel kira-kira delapan kali lebih cepat. Jika Anda hanya butuh pembacaan terkini, tambahkan sebuah FilterExpression untuk membuang timestamp lama sebelum baris mencapai kabel — bangun dan periksa expression itu di Expression Builder:

FilterExpression:  begins_with(SK, :today)

Bagaimana DynamoDB menetapkan Item ke segmen

Inilah bagian yang menyandung orang. DynamoDB menetapkan setiap Item ke sebuah segmen dengan meng-hash partition key-nya — bukan dengan jumlah baris, bukan dengan jumlah byte.

Jadi setiap Item yang berbagi sebuah PK mendarat di segmen yang sama. Di sensor-readings, semua pembacaan untuk DEVICE#a83f masuk ke satu worker, tanpa memandang berapa banyak timestamp yang dimiliki perangkat itu atau seberapa besar item collection-nya. (AWS: Parallel scan)

tabel sensor-readingshash partition keySegmen 0DEVICE#a83fDEVICE#1c20Segmen 1DEVICE#9be4Segmen 2 (kosong)

Konsekuensinya: segmen tidak merata. Satu worker mungkin memiliki tiga perangkat cerewet dengan jutaan pembacaan; yang lain mungkin menarik irisan kosong. Menaikkan TotalSegments lebih tinggi tidak akan membantu jika partition key Anda menggumpal — Anda hanya menambah worker menganggur yang menunggu yang panas. Distribusi key yang merata adalah yang membuat fan-out membuahkan hasil.

Lihat biaya baca sebelum Anda menjalankannya

Sebuah parallel scan adalah peristiwa throughput, bukan makan siang gratis. Pertanyaan jujurnya adalah "berapa banyak read unit yang akan dihabiskan untuk membaca seluruh tabel ini?" — dan DynoTable menunjukkan biaya baca terukur dari sebuah scan terhadap tabel nyata Anda, segmen demi segmen, sehingga pekerjaan malam hari tidak mengejutkan Anda di tagihan.

Jebakan dan kapan tak perlu repot

  • Tebing throughput. Sebuah scan ber-TotalSegments-tinggi bisa mengonsumsi seluruh kapasitas baca tabel dalam hitungan detik, mengkelaparkan lalu lintas langsung. Pada tabel yang melayani pengguna, throttle setiap worker dengan parameter Limit atau scan di luar jam sibuk. (AWS: Parallel scan)
  • Ia tetap alat yang salah untuk sebuah pola akses. Parallel scan untuk pekerjaan tabel-penuh yang disengaja — ekspor, backfill, migrasi. Jika Anda meraih satu untuk menjawab query berulang, itu sinyal pemodelan: tambahkan sebuah GSI dan jadikan ia sebuah Query alih-alih.
  • SELECT * di PartiQL adalah scan yang sama yang menyamar. Ia dikompilasi menjadi sebuah Scan sekuensial. Saat Anda benar-benar butuh analitik lintas-Item — sebuah GROUP BY, sebuah JOIN, sebuah agregat — SQL Workbench DynoTable menjalankannya di sisi-klien atas himpunan hasil yang terbatas, alih-alih menghantam tabel.
  • Strong consistency menggandakan tagihan. Sebuah Scan secara default eventually consistent. Untuk sebuah ekspor, biarkan ConsistentRead=false kecuali Anda benar-benar butuh snapshot pada satu titik waktu.

Langkah berikutnya

Modelkan key Anda sehingga pembacaan harian tidak pernah perlu sebuah scan — mulai dengan single-table design dan Query vs Scan. Saat sebuah pekerjaan tabel-penuh memang pilihan yang tepat, coba DynoTable untuk menjalankan parallel scan terhadap tabel Anda sendiri dan menyaksikan biaya baca secara real time.

Diperbarui