Proyeksi Index DynamoDB: KEYS_ONLY, INCLUDE & ALL

Saat Anda membuat sebuah secondary index, DynamoDB tidak otomatis menyalin seluruh Item ke dalamnya. Anda memilih apa yang disalin — proyeksi index itu. Pilih terlalu sedikit dan query Anda membayar pembacaan kedua untuk mengambil sisanya; pilih semuanya dan Anda membayar biaya penyimpanan dan penulisan ekstra pada setiap pembaruan. Ini adalah trade-off yang Anda tetapkan sekali saat pembuatan index dan jalani seterusnya.

(Jangan bingungkan ini dengan projection expression, yang memangkas atribut yang dikembalikan sebuah pembacaan tunggal. Halaman ini tentang apa yang disimpan secara fisik oleh sebuah index — lihat projection expression untuk yang satunya.)

Apa itu proyeksi index DynamoDB?

Proyeksi adalah kumpulan atribut yang disalin DynamoDB dari tabel dasar ke dalam sebuah secondary index. Anda memilih salah satu dari tiga tipe: KEYS_ONLY (hanya key), INCLUDE (key ditambah daftar bernama berisi atribut), atau ALL (seluruh Item). Semakin banyak proyeksi berarti semakin sedikit pengambilan dari tabel dasar, tetapi biaya penyimpanan dan penulisan lebih tinggi.

• Sebuah proyeksi adalah kumpulan atribut yang disalin ke dalam sebuah secondary index.
• KEYS_ONLY — hanya key tabel dan key index. Terkecil, termurah.
• INCLUDE — key ditambah daftar bernama berisi atribut ekstra yang Anda pilih.
• ALL — setiap atribut Item. Terbesar; query tak pernah membutuhkan tabel dasar.
• Membaca atribut yang tidak diproyeksikan memaksa pengambilan dari tabel dasar untuk sebuah GSI — biaya ekstra yang senyap. (Sebuah LSI bisa mengambil atribut yang tidak diproyeksikan untuk Anda, dengan biaya baca ekstra.)
• Lebih banyak proyeksi = lebih banyak penyimpanan + lebih banyak biaya penulisan, karena setiap penulisan tabel-dasar berpropagasi ke index.

Masalahnya: index yang membuat Anda membaca dua kali

Misalkan Anda menjalankan meja dukungan dengan sebuah GSI yang memungkinkan Anda mendaftar tiket terbuka berdasarkan prioritas. Anda memproyeksikan KEYS_ONLY agar tetap ramping. Query mengembalikan hasil cepat — tetapi ia hanya memberi Anda ID tiket, dan layar antrean Anda membutuhkan subjek, penanggung jawab, dan usia setiap tiket.

Maka kini kode Anda melakukan putaran pembacaan kedua terhadap tabel dasar untuk mengisi setiap hasil. "Satu query" yang Anda rancang sebenarnya adalah sebuah query plus N get, dan latensi serta biaya yang coba Anda hemat kembali lagi. Proyeksinya terlalu tipis untuk pola akses itu.

Apa yang disalin setiap tipe proyeksi

• KEYS_ONLY menyimpan hanya key tabel-dasar dan key index. Gunakan saat query hanya perlu tahu Item mana yang cocok dan Anda akan mengambil detailnya di tempat lain — atau tidak sama sekali.
• INCLUDE menyimpan key ditambah daftar tetap berisi atribut yang Anda sebutkan. Titik optimalnya: proyeksikan persis field yang dibutuhkan query Anda untuk merender, dan tidak lebih.
• ALL menyalin seluruh Item. Query sepenuhnya dilayani sendiri dari index, dengan biaya menduplikasi seluruh penyimpanan dan write throughput Item ke dalamnya.

Untuk antrean meja-dukungan, INCLUDE dengan subject, assignee, dan age adalah pilihan tepat — antrean merender dari index saja, tanpa pengambilan kedua dan tanpa menduplikasi body tiket yang besar ke dalam index.

Biaya yang Anda pertukarkan

Setiap atribut yang Anda proyeksikan disimpan untuk kedua kalinya dan ditulis ulang di index setiap kali Item dasar berubah. Jadi proyeksi ALL yang royal pada tabel yang sering diperbarui menggandakan baik penyimpanan maupun write capacity. Disiplinnya: proyeksikan apa yang dibaca query, bukan "semuanya, untuk jaga-jaga."

Kehalusan yang patut diketahui: dengan index sparse, proyeksi tetap hanya memuat Item yang membawa key index — jadi INCLUDE/ALL pada sparse index tetap kecil karena index-nya sendiri kecil. Timbang pengali penyimpanan dan penulisan untuk proyeksi Anda dengan kalkulator harga DynamoDB, dan rangkai query index itu sendiri dengan DynamoDB expression builder.

Melihat sebuah proyeksi di DynoTable

DynoTable mendaftar setiap secondary index sebuah tabel dan memungkinkan Anda mem-query langsung melalui salah satunya. Jalankan pola akses yang sama terhadap tabel dasar dan terhadap sebuah GSI lalu bandingkan hasilnya — atribut yang hilang dari hasil index persis adalah yang tidak diproyeksikannya, jadi efek sebuah proyeksi terlihat tanpa membaca ulang definisi tabel.

Jebakan + langkah berikutnya

• Atribut yang tidak diproyeksikan pada GSI berarti pengambilan tabel-dasar — rancang proyeksi seputar apa yang dirender query.
• ALL jarang gratis — ia menduplikasi biaya penyimpanan dan penulisan; jadikan INCLUDE sebagai default kecuali index benar-benar membutuhkan setiap field.
• Proyeksi sebagian besar bersifat tetap. Anda tak bisa bebas menyunting proyeksi sebuah GSI nanti tanpa membuat ulang index-nya — pilih dengan saksama sejak awal.
• Terkait: GSI vs LSI dan sparse index membentuk berapa banyak yang sebenarnya disimpan sebuah proyeksi.

Ingin melihat apa yang sebenarnya dikembalikan setiap index Anda sebelum mendesain ulangnya? Unduh DynoTable dan query tabel Anda secara langsung.