Perilaku membaca cache

Shim seharusnya hanya menyimpan panggilan baca yang konsisten yang dilakukan ke DynamoDB. Produk ini mencakup get_item, batch_get_item, query, dan scan. Seharusnya tidak menyimpan panggilan baca yang sangat konsisten atau panggilan baca transaksional, karena panggilan tersebut secara inheren tidak ingin melihat versi data yang di-cache.

Entri cache harus memahami tanda tangan permintaan untuk mengidentifikasi permintaan tindak lanjut yang setara. Tanda tangan setiap panggilan terdiri dari semua parameter permintaan yang memengaruhi hasil. Untuk get_item panggilan, tanda tangan mencakupTableName,, KeyProjectionExpression, dan ExpressionAttributeNames parameter. Untuk panggilan kueri, itu termasukTableName,IndexName,KeyConditions,FilterExpression,ScanIndexForward, dan Limit parameter. Jika dua panggilan ke fungsi yang sama memiliki tanda tangan yang sama, itu kemungkinan terkena cache.

Berikut adalah aliran logika contoh untuk get_item panggilan:

Misalnya, asumsikan bahwa Anda memiliki kode ini:

cache_client.get_item(
  TableName='test',
  Key={ 'PK': { 'S': '123' } },
  ProjectionExpression='#attr1, #attr2',
  ExpressionAttributeNames={
    '#attr1': 'agent',
    '#attr2': 'count'
  },
  ConsistentRead=False
)

Di dalamcache_client, kode menghitung tanda tangan hash panggilan. Tanda tangan berasal dari hashing penggabunganTableName,,Key, ProjectionExpression dan parameter. ExpressionAttributeNames Setiap sistem hash dapat digunakan selama deterministik dan menghasilkan nilai string tunggal. Dalam hal ini, mari kita asumsikan bahwa itu hash ke0xad4c812a. Hash ini mengidentifikasi set parameter ini.

Bagaimana jika panggilan lain dibuat yang sama, kecuali #attr1 yang diganti namanya? #attribute1 Haruskah panggilan itu dianggap memiliki tanda tangan yang sama? Idealnya ya, karena identik secara semantik, tetapi overhead untuk mencari tahu kesetaraan semantik pada setiap panggilan tidak praktis. Jauh lebih cepat untuk melakukan hash nilai parameter secara membabi buta dan membutuhkan kecocokan yang tepat. Aturannya adalah: Panggilan memenuhi syarat untuk hit cache jika sebenarnya panggilan yang sama, tetapi tidak jika pada dasarnya panggilan yang sama.

Di dalamcache_client, kode kemudian ElastiCache mencari entri di cache item yang disimpan di bawah0xad4c812a. Jika entri ada, itu adalah hit cache. Jika tidak, nilainya diambil dari database dan disimpan ElastiCache untuk klik cache nanti.

Inilah tampilan cache untuk tiga get_item panggilan yang memiliki tiga set tabel, kunci, dan parameter proyeksi yang berbeda.

Panggilan lain, seperti query danscan, bekerja dengan cara yang sama, tetapi parameter yang berbeda membentuk tanda tangan mereka.

Desain ini mungkin mengingatkan Anda tentang cara kerja proxy caching HTTP. Jika melihat permintaan yang sama lagi, itu dapat mengembalikan respons dari permintaan sebelumnya. Definisi permintaan yang sama di HTTP sebagian besar didasarkan pada string kueri. Dengan DynamoDB, jenis panggilan dan set parameter yang diteruskan ke fungsi mempengaruhi hasilnya.

Ada satu langkah lagi. Penting bagi caching item untuk menjaga pemetaan antara kunci utama setiap item dan daftar hash yang secara aktif digunakan untuk menyimpan item tersebut. Ini akan berperan selama operasi penulisan, seperti yang dijelaskan di bagian selanjutnya. Jadi selain kunci dan nilai sebelumnya, akan ada entri cache tambahan seperti ini: