Atribut Type di DynamoDB
Di SQL, tabel sebuah baris adalah tipenya — sebuah baris di documents adalah
sebuah document. Sebuah single table DynamoDB mencampur setiap entitas di bawah
satu schema, jadi sebuah Item tidak membawa jawaban bawaan untuk "ini apa?".
Atribut Type mengembalikan jawaban itu: sebuah string biasa pada setiap Item yang menamai entitas yang diwakilinya.
Apa itu atribut Type di DynamoDB?
Atribut Type adalah string biasa yang Anda stempel pada setiap Item — seperti EntityType: "Document" — untuk menamai entitas yang diwakili Item tersebut. Karena single table mencampur banyak entitas di bawah satu schema, Item tidak memiliki tipe bawaan. Atribut Type mengembalikannya, sehingga kode Anda dapat mengidentifikasi baris, memfilter GSI menjadi satu entitas, dan bertahan dari migrasi.
- Stempel sebuah Type pada setiap tulisan. Satu atribut —
EntityType: "Document"— pada setiap Item, tanpa pengecualian. Biayanya beberapa byte dan menyelamatkan Anda nanti. - Ia mengidentifikasi entitas dalam partition campuran. Sebuah
Querymengembalikan workspace, document, dan comment sekaligus; Type memberi tahu kode Anda mana yang mana tanpa mem-parsing prefix key. - Ia memungkinkan pemfilteran satu-entitas pada sebuah GSI. Proyeksikan Type ke dalam sebuah index dan Anda bisa mempersempit index yang di-overload menjadi tepat satu tipe entitas.
- Ia adalah jalan keluar darurat Anda untuk migrasi. Saat Anda mengekspor untuk memodelkan ulang atau memindahkan sebuah entitas ke tabelnya sendiri, Type adalah kolom tempat Anda memecahnya.
Mengapa tabel campuran kehilangan tipe
Single-table design menyimpan setiap entitas dalam
satu tabel di balik key generik seperti PK dan SK. Itulah seluruh intinya —
satu Query mengembalikan sebuah induk dan anak-anaknya sekaligus. Tapi itu berarti
sebuah partition bersifat heterogen.
Ambil sebuah aplikasi kolaborasi-dokumen SaaS. Satu partition workspace menampung record workspace, document-nya, dan comment pada document tersebut:
| PK | SK | attributes |
|---|---|---|
| WS#acme | META | name, plan, seats |
| WS#acme | DOC#a1#META | title, owner, wordCount |
| WS#acme | DOC#a1#CMT#0007 | author, body, createdAt |
| WS#acme | DOC#a1#CMT#0008 | author, body, createdAt |
Query PK = "WS#acme" mengembalikan keempat Item dalam satu pembacaan yang ditagih.
Kini kode Anda memiliki daftar Item mentah dan tak ada cara andal untuk mengatakan
mana yang document dan mana yang comment — selain mencocokkan string SK, yang
rapuh begitu format key Anda berubah.
Stempel Type pada setiap Item
Solusinya adalah satu atribut pada setiap tulisan, menamai entitasnya:
| PK | SK | EntityType | title |
|---|---|---|---|
| WS#acme | META | Workspace | — |
| WS#acme | DOC#a1#META | Document | Q3 Roadmap |
| WS#acme | DOC#a1#CMT#0007 | Comment | — |
Bercabang pada item.EntityType === "Document" adalah pemeriksaan kesetaraan yang
stabil. Mem-parsing SK.startsWith("DOC#") && SK.includes("#CMT#") adalah tebakan
yang rusak saat Anda mengubah versi key. Type melepaskan logika pembacaan Anda dari
encoding key — itulah kemenangan sebenarnya.
Satu pembacaan mengembalikan tiga tipe entitas; atribut Type merutekan setiap Item ke handler yang tepat tanpa menyentuh key.
Filter sebuah GSI menjadi satu entitas
Type membuktikan kegunaannya pada index. Misalkan Anda menambahkan sebuah GSI
yang di-key pada GSI1PK = WS#acme, GSI1SK = updatedAt untuk membuat daftar
"semua yang baru-baru ini berubah di workspace ini, yang terbaru dulu". Sebuah
index yang di-overload menyapu masuk document dan comment — tapi sebuah UI feed
mungkin hanya menginginkan document.
Dua cara untuk mempersempitnya, dan perbedaannya adalah uang:
| Pendekatan | Apa biayanya | Kapan digunakan |
|---|---|---|
FilterExpression pada Type | Membaca semua Item yang cocok, menagih semuanya, membuang yang tidak cocok setelah pembacaan | Entitas campuran jarang ada dalam hasil; cepat dikapalkan |
Sparse index (Type di GSI1PK) | Hanya entitas yang Anda inginkan yang pernah masuk ke index | Satu entitas mendominasi; Anda ingin nol pemborosan |
Sebuah FilterExpression berjalan setelah Item dibaca dan setelah kapasitas
dikonsumsi — AWS eksplisit bahwa pemfilteran tidak mengurangi biaya pembacaan
(DynamoDB Developer Guide: FilterExpression).
Memfilter pada Type itu jujur, bukan gratis: Anda membayar comment yang Anda buang.
Untuk mempersempit feed menjadi document, query membawa sebuah condition pada
atribut Type. Susun FilterExpression, names, dan values dengan
DynamoDB expression builder — ia memancarkan
placeholder #t = :doc sehingga Anda tidak salah ketik kata yang direservasi.
KeyConditionExpression GSI1PK = :ws
FilterExpression #t = :doc
ExpressionAttributeNames { "#t": "EntityType" }
ExpressionAttributeValues { ":ws": "WS#acme", ":doc": "Document" }
Ingin index membawa hanya document dan melewati filter sepenuhnya? Tulis GSI1PK
hanya pada Item document — sebuah sparse index. Item tanpa key GSI tidak pernah
direplikasi ke index, sehingga pembacaan hanya menyentuh document. Atribut Type
adalah yang memberi tahu penulis Anda Item mana yang memenuhi syarat.
Jaga nilainya stabil dan tunggal
Pilih nilai sekali dan perlakukan sebagai enum. Document, jangan kadang Doc dan
kadang document — nilai yang menyimpang lebih buruk daripada tanpa nilai, karena
pemeriksaan kesetaraan Anda lolos pada satu casing dan diam-diam meleset pada yang
lain.
Satu Type per Item. Jika sebuah Item terasa seperti dua entitas, itu biasanya bau pemodelan — seharusnya itu dua Item, masing-masing di collection atau rentang sort-key-nya sendiri, bukan satu baris yang memakai dua topi.
Imbalan migrasi
Alasan untuk menstempel Type sebelum Anda membutuhkannya: pemodelan ulang. Jalur pemodelan-ulang yang direkomendasikan adalah ekspor, transform, impor ulang — dan AWS mendokumentasikan ekspor massal ke S3 untuk persis jenis pembentukan-ulang offline ini (Exporting DynamoDB to S3).
Saat hari itu tiba, Type adalah kolom yang Anda GROUP BY. Ingin mengangkat comment
ke tabelnya sendiri, atau menormalkan ulang ekspor menjadi file per-entitas untuk
sebuah analytics warehouse? Anda memecah dump pada EntityType. Tanpa itu, Anda
kembali ke me-reverse-engineer key di jutaan baris.
Langkah berikutnya
Atribut Type adalah asuransi murah: identifikasi entitas dalam pembacaan campuran, filter sebuah GSI yang di-overload, dan pecah dengan rapi saat Anda memodelkan ulang. Stempel pada setiap tulisan sejak hari pertama — memasangnya ke tabel yang sudah aktif berarti backfill penuh.
Bacaan terkait: single-table design untuk pola
partition-campuran yang dilayaninya, GSI vs LSI untuk memilih
bentuk index di balik sparse index, dan
Query vs Scan untuk alasan mengapa sebuah FilterExpression
tidak pernah menghemat biaya pembacaan Anda.
Bangun filter pada Type dengan DynamoDB expression builder, dan coba DynoTable untuk menjelajahi tabel multi-entitas yang nyata dan melihat kolom Type berjajar di setiap Item.