Item collection DynamoDB

Item collection adalah himpunan semua item dalam tabel (atau indeks) yang berbagi nilai partition key yang sama — properti yang muncul dari skema key Anda.

Saat dua item membawa partition key yang sama, mereka membentuk collection, dan collection itu menjadi unit yang DynamoDB izinkan Anda baca bersama dalam satu Query.

Dapatkan ini benar dan baca Anda kembali dalam satu round trip. Salah dan Anda terjebak dengan Scan.

Apa itu item collection DynamoDB?

Item collection DynamoDB adalah himpunan semua item yang berbagi nilai partition key yang sama, disimpan bersama dan diurutkan by sort key. Collection muncul dari skema key Anda. Collection adalah unit yang dibaca efisien oleh satu Query, sedangkan Scan menelusuri setiap partisi.

• Collection hanyalah "partition key yang sama." Dua atau lebih item dengan nilai partition key sama disimpan bersama, diurutkan by sort key.
• Itu unit Query yang efisien. Query membaca satu collection; Scan menelusuri setiap partisi. Itulah seluruh cerita performa.
• Tanpa sort key, tanpa collection. Tabel partition-key-only menampung satu item per key — tidak ada yang dikumpulkan.
• Dua limit yang menggigit: langit-langit 10 GB per-collection saat ada LSI, dan hot partition dari key kardinalitas rendah.

Masalahnya: membaca item terkait bersama

Katakan Anda menjalankan armada kendaraan, masing-masing men-stream telemetri — kecepatan, suhu coolant, level bahan bakar — setiap beberapa detik. Baca dominan adalah "beri saya pembacaan terbaru untuk kendaraan V-7741".

Datang dari SQL, Anda akan mengindeks kolom vehicle_id dan membiarkan planner bekerja. Key-value store polos tidak punya kemewahan itu.

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

Jawaban DynamoDB adalah menjadikan "semua pembacaan untuk satu kendaraan" sesuatu yang dikelompokkan secara fisik dan bisa dialamatkan langsung. Pengelompokan itu adalah item collection.

Apa sebenarnya collection itu

DynamoDB menyimpan item dalam partisi, dan merutekan tiap item ke partisi dengan meng-hash partition key-nya. Setiap item dengan nilai partition key sama disimpan bersama dan diurutkan by sort key. Mereka mulai di satu partisi, tetapi tanpa LSI DynamoDB bisa memecah collection besar atau panas lintas partisi pada batas sort key; hanya LSI yang menyematkan seluruh collection ke satu partisi (itulah mengapa langit-langit 10 GB di bawah khusus LSI).

AWS Developer Guide menamainya tepat. Item yang berbagi nilai partition key adalah item collection, disimpan bersama dan diurutkan by sort key.

Ini ide yang sama yang diperkenalkan paper Amazon Dynamo 2007 — consistent hashing untuk menugaskan key ke node — diperluas dengan dimensi sort agar item terkait duduk berdekatan di disk.

Karena mereka berdekatan dan terurut, DynamoDB mengembalikan run kontigu dengan satu seek. Itulah mengapa Query murah dan Scan tidak: Query membaca satu collection; Scan menelusuri setiap partisi.

Untuk membentuk collection Anda butuh composite primary key — partition key dan sort key. Tabel yang di-key hanya partition key punya tepat satu item per nilai key, jadi tidak ada yang dikumpulkan.

Contoh kerja kita: kendaraan → pembacaan telemetri

Model stream telemetri dengan composite key. Partition key mengidentifikasi kendaraan; sort key adalah timestamp pembacaan, yang menjaga pembacaan dalam urutan timestamp (naik by default; lewati ScanIndexForward=false untuk terbaru-dulu).

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.

Beri metadata sort key (META) yang mengurut sebelum nilai TS#... mana pun, dan satu Query pada PK = "VEH#V-7741" mengembalikan profil kendaraan dan pembacaannya bersama.

Itulah pattern parent-and-children di jantung single-table design.

Setiap kotak putus-putus adalah satu item collection: partition key sama, item diurutkan by sort key. Query membaca tepat satu kotak.

Query sebuah collection

Karena collection diurutkan by sort key, Anda mendapat range read gratis. Untuk menarik pembacaan dalam jendela sepuluh menit untuk satu kendaraan, batasi sort key:

# Query
KeyConditionExpression   vehicleId = :v AND recordedAt BETWEEN :from AND :to
ScanIndexForward         false        # newest first

Key condition membatasi Anda ke satu collection (vehicleId = :v) lalu ke irisan kontigu darinya (recordedAt BETWEEN ...). DynamoDB hanya membaca item itu dan hanya menagih mereka. Hanya butuh metadata? recordedAt = "META" mengambil satu item META.

Membangun key condition dan projection expression dengan tangan itu rumit. DynamoDB Expression Builder menghasilkan KeyConditionExpression, ExpressionAttributeNames, dan ExpressionAttributeValues untuk Anda, agar detail reserved-word dan placeholder tidak menggigit.

Collection pada indeks

Secondary index punya skema key sendiri, jadi ia membentuk item collection sendiri.

Tambah global secondary index di-key pada depotCode (partition) dan recordedAt (sort), dan "semua pembacaan dari depot DEP-LON-3, terbaru dulu" menjadi satu Query terhadap collection indeks itu — baca yang tabel dasar tidak bisa layani.

Itulah mengapa tipe indeks penting: ia mengatur collection apa yang bisa Anda bentuk dan bagaimana perilakunya. Lihat GSI vs LSI untuk trade-off.

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

Limit yang menggigit

Item collection kuat, tetapi dua constraint memutuskan bagaimana Anda membentuk key:

• Limit LSI 10 GB. Saat tabel punya satu atau lebih local secondary index, satu item collection — item dasar plus proyeksi LSI mereka untuk satu partition key — tidak boleh melebihi 10 GB. Melampauinya dan write yang menumbuhkan collection mulai gagal dengan ItemCollectionSizeLimitExceededException. Tabel tanpa LSI tidak punya langit-langit per-collection seperti itu. Inilah tepatnya mengapa stream yang tumbuh tanpa batas (telemetri yang tidak pernah berhenti) cocok buruk untuk LSI: collection hanya tumbuh. GSI mendapat partisi sendiri, jadi ia menghindari limit.
• Hot partition. Collection hidup di partisi, dan satu partisi punya throughput terbatas. Jika satu kendaraan (atau satu depotCode) menarik porsi traffic yang liar tidak proporsional, Anda bisa hot-spot partisi itu bahkan saat tabel secara keseluruhan jauh di bawah throughput provisioned. Adaptive capacity — dibahas di deep-dive re:Invent AWS "Advanced Design Patterns for DynamoDB" — mengisolasi dan meningkatkan hot key secara otomatis, tetapi tidak bisa menyelamatkan key tanpa sebaran sama sekali. Pilih partition key dengan kardinalitas tinggi agar traffic menyebar lintas banyak collection.

Lihat di DynoTable

Cara tercepat membangun intuisi untuk collection adalah melihatnya. Di DynoTable, Query partition key merender seluruh collection sebagai daftar kontigu terurut sort key — item META duduk tepat di depan pembacaan bertimestamp, di layar, tanpa rekonstruksi mental.

Jebakan dan langkah selanjutnya

• Tanpa sort key, tanpa collection. Tabel partition-key-only tidak bisa mengelompokkan item terkait. Jika Anda perlu membaca item bersama, Anda butuh composite key.
• Jangan biarkan collection LSI tumbuh tanpa batas. Stream append-only milik GSI (atau partition key ber-bucket waktu), bukan LSI, karena langit-langit 10 GB.
• Sebarkan partition key Anda. Collection hanya seskalabel partisi tempat ia hidup. Partition key kardinalitas rendah menciptakan hot spot.
• Jangkau Query, bukan Scan. Collection ada agar Anda bisa membaca item terkait dengan satu Query tertarget; jatuh ke Scan membuang keunggulan itu — lihat Query vs Scan.

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