DynoTable
Pemula7 menit baca

Item Collection DynamoDB

Sebuah item collection adalah himpunan semua Item dalam sebuah tabel (atau index) yang berbagi nilai partition key yang sama. Ini bukan fitur yang Anda aktifkan — ini adalah properti yang muncul dari key schema Anda.

Begitu dua Item membawa partition key yang sama, mereka membentuk sebuah collection, dan collection itu menjadi satuan yang diizinkan DynamoDB untuk Anda baca bersama dalam satu Query.

Lakukan ini dengan benar dan pembacaan Anda kembali dalam satu round trip. Lakukan salah dan Anda terjebak dengan sebuah Scan.

Apa itu item collection DynamoDB?

Item collection DynamoDB adalah himpunan semua Item yang berbagi nilai partition key yang sama, disimpan bersama dan terurut berdasarkan sort key. Ini bukan fitur yang Anda aktifkan — ia muncul dari key schema Anda. Collection adalah satuan yang dibaca sebuah Query tunggal secara efisien, sedangkan sebuah Scan menjelajahi setiap partition.

  • Sebuah collection hanyalah "partition key yang sama". Dua Item atau lebih dengan nilai partition key yang sama disimpan bersama, terurut berdasarkan sort key.
  • Ia adalah satuan Query yang efisien. Query membaca satu collection; Scan menjelajahi setiap partition. Itulah seluruh cerita performanya.
  • Tanpa sort key, tanpa collection. Tabel yang hanya ber-partition-key menampung satu Item per key — tak ada yang dikumpulkan.
  • Dua batas menggigit: plafon 10 GB per collection saat ada LSI, dan hot partition dari key bercardinality rendah.

Masalahnya: membaca Item terkait bersama

Misalkan Anda menjalankan armada kendaraan, masing-masing menstreamkan telemetri — kecepatan, suhu coolant, level bahan bakar — tiap beberapa detik. Pembacaan dominan adalah "berikan pembacaan terbaru untuk kendaraan V-7741".

Datang dari SQL, Anda akan meng-index kolom vehicle_id dan membiarkan planner mengerjakannya. Key-value store polos tak punya kemewahan seperti itu.

Ia memperlakukan setiap pembacaan sebagai catatan terisolasi, jadi pertanyaan itu berarti men-scan seluruh tabel dan memfilter. Lambat, mahal, dan makin buruk saat armada bertumbuh.

Jawaban DynamoDB adalah menjadikan "semua pembacaan untuk satu kendaraan" sebuah hal yang dikelompokkan secara fisik dan dapat dialamati langsung. Pengelompokan itulah item collection.

Apa sebenarnya sebuah collection

DynamoDB menyimpan Item dalam partition, dan ia merutekan setiap Item ke sebuah partition dengan melakukan hash terhadap partition keynya. Setiap Item dengan nilai partition key yang sama karena itu mendarat di partition yang sama, terurut berdasarkan sort key.

AWS Developer Guide menamainya tepat: Item yang berbagi nilai partition key adalah sebuah item collection, disimpan bersama dan diurut berdasarkan sort key.

Ini adalah ide yang sama yang diperkenalkan makalah Amazon Dynamo 2007 — consistent hashing untuk menugaskan key ke node — diperluas dengan dimensi sort agar Item terkait duduk berdampingan pada disk.

Karena mereka berdampingan dan terurut, DynamoDB mengembalikan rentang menyatu dari mereka dengan satu seek. Itulah mengapa Query murah dan Scan tidak: Query membaca satu collection; Scan menjelajahi setiap partition.

Untuk membentuk sebuah collection Anda butuh composite primary key — sebuah partition key dan sebuah sort key. Tabel yang berkey partition key saja punya tepat satu Item per nilai key, jadi tak ada yang dikumpulkan.

Contoh nyata kita: kendaraan → pembacaan telemetri

Modelkan stream telemetri dengan composite key. Partition key mengidentifikasi kendaraan; sort key adalah timestamp pembacaan, yang menjaga pembacaan terurut dari terbaru ke terlama di dalam collection.

PK (vehicleId)   SK (recordedAt)        attributes
VEH#V-7741       META                    plate, model, depotCode
VEH#V-7741       TS#2026-06-23T09:00:01Z speedKph, coolantC, fuelPct
VEH#V-7741       TS#2026-06-23T09:00:06Z speedKph, coolantC, fuelPct
VEH#V-7741       TS#2026-06-23T09:00:11Z speedKph, coolantC, fuelPct
VEH#V-7742       META                    plate, model, depotCode
VEH#V-7742       TS#2026-06-23T09:00:02Z speedKph, coolantC, fuelPct

Dua collection hidup di sini — satu per kendaraan. Item META (metadata kendaraan) dan semua pembacaan V-7741 membentuk satu collection; Item V-7742 membentuk yang lain.

Perhatikan triknya: beri metadata sebuah sort key (META) yang terurut sebelum nilai TS#... mana pun, dan satu Query pada PK = "VEH#V-7741" mengembalikan profil kendaraan dan pembacaannya bersama-sama.

Itu adalah pola induk-dan-anak di jantung single-table design.

Partition · VEH#V-7742META — profil kendaraanTS#09:00:02Partition · VEH#V-7741META — profil kendaraanTS#09:00:01TS#09:00:06TS#09:00:11

Setiap kotak putus-putus adalah satu item collection: partition key sama, Item terurut berdasarkan sort key. Sebuah Query membaca tepat satu kotak.

Mem-query sebuah collection

Karena collection terurut berdasarkan sort key, Anda mendapatkan range read secara gratis. Untuk menarik pembacaan yang terekam dalam jendela sepuluh menit untuk satu kendaraan, Anda membatasi sort key:

Query
  KeyConditionExpression: vehicleId = :v AND recordedAt BETWEEN :from AND :to
  ScanIndexForward: false        # terbaru lebih dulu

Kondisi key membatasi Anda pada satu collection (vehicleId = :v) lalu pada irisan menyatu darinya (recordedAt BETWEEN ...). DynamoDB membaca hanya Item tersebut dan menagih Anda hanya untuk mereka. Mau hanya metadata? recordedAt = "META" mengambil satu Item META tunggal.

Membangun kondisi key dan projection expression ini dengan tangan memang merepotkan. DynamoDB Expression Builder menghasilkan KeyConditionExpression, ExpressionAttributeNames, dan ExpressionAttributeValues untuk Anda, jadi detail reserved-word dan placeholder tak menggigit.

Collection pada index

Sebuah secondary index punya key schema-nya sendiri, jadi ia membentuk item collection-nya sendiri.

Tambahkan global secondary index berkey depotCode (partition) dan recordedAt (sort), dan "semua pembacaan dari depot DEP-LON-3, terbaru lebih dulu" menjadi satu Query terhadap collection index itu — pembacaan yang tak bisa dilayani tabel dasar.

Itulah mengapa tipe index penting: ia menentukan collection apa yang bisa Anda bentuk dan bagaimana mereka berperilaku. Lihat GSI vs LSI untuk trade-off-nya.

Satu perbedaan tajam: sebuah local secondary index (LSI) berbagi partition key tabel dasar, jadi collection-nya terikat secara fisik pada item collection dasar — dan ikatan itu menciptakan batas keras, di bawah.

Batas yang menggigit

Item collection bertenaga, tetapi dua kendala menentukan bagaimana Anda membentuk key:

  • Batas LSI 10 GB. Saat sebuah tabel punya satu atau lebih local secondary index, satu item collection — Item dasar plus proyeksi LSI-nya untuk satu partition key — tak boleh melebihi 10 GB. Lewati itu dan penulisan yang menumbuhkan collection mulai gagal dengan ItemCollectionSizeLimitExceeded. Tabel tanpa LSI tak punya plafon per-collection semacam itu. Inilah persis mengapa stream yang tak terbatas dan terus tumbuh (telemetri yang tak pernah berhenti) buruk untuk LSI: collection-nya hanya tumbuh. Sebuah GSI mendapat partition-nya sendiri, jadi ia mengelak dari batas itu.
  • Hot partition. Sebuah collection hidup di sebuah partition, dan satu partition punya throughput terbatas. Jika satu kendaraan (atau satu depotCode) menarik pangsa trafik yang sangat tidak proporsional, Anda bisa menjadikan partition itu hot-spot bahkan saat tabel secara keseluruhan kekurangan provision. Adaptive capacity — dibahas dalam deep-dive re:Invent AWS "Advanced Design Patterns for DynamoDB" — mengisolasi dan mendongkrak hot key secara otomatis, tetapi ia tak bisa menyelamatkan key yang tak punya sebaran sama sekali. Pilih partition key bercardinality tinggi agar trafik menyebar ke banyak collection.

Lihat di DynoTable

Cara tercepat membangun intuisi tentang collection adalah melihat satu. Di DynoTable, mem-query sebuah partition key merender seluruh collection sebagai daftar yang menyatu dan terurut sort-key — Item META duduk tepat di depan pembacaan bertimestampnya, di layar, tanpa rekonstruksi mental.

Sebuah Query pada satu partition key, menampilkan setiap Item dalam collection terurut berdasarkan sort key.
Sebuah Query pada satu partition key, menampilkan setiap Item dalam collection terurut berdasarkan sort key.

Jebakan dan langkah berikutnya

  • Tanpa sort key, tanpa collection. Tabel yang hanya ber-partition-key tak bisa mengelompokkan Item terkait. Jika Anda perlu membaca Item bersama, Anda butuh composite key.
  • Jangan biarkan collection LSI tumbuh tanpa batas. Stream append-only berada di GSI (atau partition key ber-time-bucket), bukan LSI, karena plafon 10 GB.
  • Sebarkan partition key Anda. Sebuah collection seskalabel partition tempatnya hidup. Partition key bercardinality rendah menciptakan hot spot.
  • Raih Query, bukan Scan. Collection ada agar Anda bisa membaca Item terkait dengan satu Query bertarget; kembali ke Scan membuang keuntungan itu — lihat Query vs Scan.

Sketsa key schema Anda sendiri, jalankan sebuah Query terhadap partition key nyata, dan saksikan collection kembali terurut. Unduh DynoTable dan jelajahi collection tabel Anda secara langsung.

Diperbarui