Perilaku menulis cache - AWS Bimbingan Preskriptif

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Perilaku menulis cache

Panduan ini menjelaskan cache baca-melalui tempat item di-cache saat pertama kali dibaca. Cache write-through akan mendorong entri ke dalam cache selama operasi penulisan, tetapi panduan ini tidak menyarankan melakukan itu karena dua alasan:

  • Ketika sebuah item ditulis, tidak ada indikasi bahwa itu akan dibaca dalam waktu dekat, dan itu sia-sia untuk menulis entri cache yang tidak digunakan.

  • Item yang di-cache mungkin di-cache beberapa kali di bawah kunci tanda tangan yang berbeda. Misalnya, ekspresi proyeksi yang berbeda menghasilkan entri cache yang berbeda. Jadi, tidak jelas kunci tanda tangan mana yang harus Anda simpan entri sebelum permintaan masuk. Anda mungkin menganggapnya lebih elegan untuk menyimpan item hanya sekali secara keseluruhan, dan, jika permintaan menentukan ProjectionExpression parameter, terapkan proyeksi secara langsung di dalam pembungkus caching. Sayangnya, ini menambah kompleksitas yang signifikan karena memerlukan penerapan tata bahasa non-sepeleProjectionExpression. Lebih mudah untuk menjaga pembungkus caching sangat sederhana sehingga hanya menyimpan permintaan cache yang terjadi sebelumnya, dan mencoba menghindari menciptakan respons baru sebanyak mungkin. Biarkan database menjadi satu-satunya tempat yang ProjectionExpression pernah ditafsirkan. Itu menghilangkan model cache write-through yang mudah.

Namun, operasi tulis bisa cerdas, dan mereka dapat secara proaktif membatalkan entri cache item apa pun yang disimpan sebelumnya yang relevan dengan item tertulis. Ini membuat cache item tetap segar tanpa harus menunggu TTL kedaluwarsa. Entri cache diisi kembali pada pembacaan berikutnya.

catatan

Keuntungan utama dari integrasi DynamoDB ini, dibandingkan dengan integrasi cache database relasional yang dirancang serupa, adalah bahwa setiap penulisan ke DynamoDB selalu menentukan kunci utama item yang sedang ditulis. Cache read-through dapat menonton panggilan tulis dan melakukan pembatalan cache item yang tepat dan langsung. Saat Anda menggunakan database relasional, UPDATE pernyataan tidak mengidentifikasi item yang mungkin terpengaruh, dan tidak ada cara pasif untuk membatalkan entri baris yang di-cache selain melalui TTL.

Panggilan tulis mengimplementasikan alur logika ini:

  • Lakukan operasi tulis terhadap database.

  • Jika operasi berhasil, ekstrak tabel dan kunci utama untuk penulisan.

  • Membatalkan entri cache item apa pun yang relevan dengan kunci utama.

Ada sedikit tata graha yang diperlukan untuk membuat langkah terakhir ini menjadi mungkin. Entri cache item disimpan di bawah hash tanda tangan mereka, jadi penting untuk mengetahui kunci mana yang akan dibatalkan. Anda dapat melakukannya dengan mempertahankan dalam cache pemetaan antara kunci utama item dan daftar tanda tangan tersimpan yang terkait dengan kunci utama tersebut. Itu daftar item yang harus dibatalkan.

Berikut tabel dari sebelumnya:

Pseudocode

ElastiCache perhitungan kunci

ElastiCache nilai

get_item(t1, k1, p1)

hash('get', t1, k1, p1) = 0xad4c812a

{ 'Item': … }

get_item(t1, k1, p2)

hash('get', t1, k2, p2) = 0x045deaab

{ 'Item': … }

get_item(t1, k2, p1)

hash('get', t1, k2, p1) = 0x9cda78af

{ 'Item': … }

Dan meja tata graha sebelumnya:

Operasi

ElastiCache perhitungan kunci

ElastiCache nilai

Lacak daftar entri untuk tabelt1, kunci k1

hash('list', t1, k1)

( 0xad4c812a, 0x045deaab )

Lacak daftar entri untuk tabelt1, kunci k2

hash('list', t1, k2)

( 0x9cda78af )

Mari kita asumsikan bahwa ada operasi tulis di atas meja t1 dan item memiliki kunci utamak1. Langkah selanjutnya adalah membatalkan entri yang relevan dengan item tersebut.

Berikut logika lengkapnya:

  • Lakukan operasi tulis terhadap database.

  • Jika operasi berhasil, ekstrak tabel dan kunci utama untuk penulisan.

  • Tarik dari cache daftar tanda tangan hash tersimpan yang terkait dengan kunci utama tersebut.

  • Membatalkan entri cache item tersebut.

  • Hapus daftar rumah tangga untuk kunci utama itu.

Akan luar biasa memiliki cara untuk secara proaktif membatalkan entri cache kueri sebagai bagian dari operasi penulisan item. Namun, menciptakan desain untuk ini sangat sulit karena hampir tidak mungkin untuk menentukan, efisien dan andal, hasil kueri yang di-cache mana yang akan dipengaruhi oleh item yang diperbarui. Untuk alasan ini, entri cache kueri tidak memiliki opsi yang lebih baik daripada kedaluwarsa melalui pengaturan TTL.