Menengah6 menit baca

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 Query mengembalikan 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:

PKSKattributes
WS#acmeMETAname, plan, seats
WS#acmeDOC#a1#METAtitle, owner, wordCount
WS#acmeDOC#a1#CMT#0007author, body, createdAt
WS#acmeDOC#a1#CMT#0008author, 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:

PKSKEntityTypetitle
WS#acmeMETAWorkspace
WS#acmeDOC#a1#METADocumentQ3 Roadmap
WS#acmeDOC#a1#CMT#0007Comment

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.

Query PK = 'WS#acme'Partition campuranEntityType: 'Workspace'EntityType: 'Document'EntityType: 'Comment'Rutekan berdasarkan Type

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:

PendekatanApa biayanyaKapan digunakan
FilterExpression pada TypeMembaca semua Item yang cocok, menagih semuanya, membuang yang tidak cocok setelah pembacaanEntitas campuran jarang ada dalam hasil; cepat dikapalkan
Sparse index (Type di GSI1PK)Hanya entitas yang Anda inginkan yang pernah masuk ke indexSatu 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.

Diperbarui