Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Mengkonfigurasi klaster Anda DAX
DAXCluster adalah cluster terkelola, tetapi Anda dapat menyesuaikan konfigurasinya agar sesuai dengan kebutuhan aplikasi Anda. Karena integrasinya yang erat dengan operasi API DynamoDB, Anda harus mempertimbangkan aspek-aspek berikut saat mengintegrasikan aplikasi Anda. DAX
Dalam bagian ini
Harga DAX
Biaya cluster tergantung pada jumlah dan ukuran node yang telah disediakannya. Setiap node ditagih untuk setiap jam berjalan di cluster. Untuk informasi selengkapnya, lihat harga Amazon DynamoDB
Hit cache tidak menimbulkan biaya DynamoDB, tetapi berdampak pada sumber daya klaster. DAX Kesalahan cache menimbulkan biaya baca DynamoDB dan membutuhkan sumber daya. DAX Penulisan menimbulkan biaya penulisan DynamoDB dan DAX memengaruhi sumber daya klaster untuk mem-proxy penulisan.
Cache item dan cache kueri
DAXmemelihara cache item dan cache kueri. Memahami perbedaan antara cache ini dapat membantu Anda menentukan karakteristik kinerja dan konsistensi yang mereka tawarkan ke aplikasi Anda.
| Karakteristik cache | Cache item | Cache kueri |
|---|---|---|
|
Tujuan |
Menyimpan hasil GetItemdan BatchGetItemAPIoperasi. |
Menyimpan hasil API operasi Query dan Scan. Operasi ini dapat mengembalikan beberapa item berdasarkan kondisi kueri alih-alih kunci item tertentu. |
|
Jenis Akses |
Menggunakan akses berbasis kunci. Saat aplikasi meminta data menggunakan |
Menggunakan akses berbasis parameter. DAXcache set hasil |
|
Pembatalan Cache |
DAXsecara otomatis mereplikasi item yang diperbarui ke dalam cache item node di DAX cluster dalam skenario berikut:
|
Cache kueri lebih sulit untuk dibatalkan daripada cache item. Pembaruan item mungkin tidak langsung dipetakan ke kueri atau pindaian yang di-cache. Anda harus hati-hati menyetel cache kueri TTL untuk menjaga konsistensi data. Menulis melalui DAX atau tabel dasar tidak tercermin dalam cache kueri sampai TTL kedaluwarsa respons cache sebelumnya dan DAX melakukan kueri baru terhadap DynamoDB. |
|
Indeks sekunder global |
Karena GetItem API operasi tidak didukung pada indeks sekunder lokal atau indeks sekunder global, cache item hanya cache yang dibaca dari tabel dasar. |
Cache kueri menyimpan kueri terhadap tabel dan indeks. |
Memilih TTL pengaturan untuk cache
TTLmenentukan periode penyimpanan data dalam cache sebelum menjadi basi. Setelah periode ini, data secara otomatis di-refresh pada permintaan berikutnya. Memilih TTL pengaturan yang tepat untuk DAX cache Anda melibatkan keseimbangan antara optimalisasi kinerja aplikasi dan konsistensi data. Karena tidak ada TTL pengaturan universal yang berfungsi untuk semua aplikasi, TTL pengaturan optimal bervariasi berdasarkan karakteristik dan persyaratan spesifik aplikasi Anda. Kami menyarankan Anda memulai dengan TTL pengaturan konservatif menggunakan panduan preskriptif ini. Kemudian, sesuaikan TTL setelan Anda secara berulang berdasarkan data kinerja dan wawasan aplikasi Anda.
DAXmemelihara daftar (LRU) yang paling tidak baru digunakan untuk cache item. LRUDaftar melacak kapan item pertama kali ditulis atau terakhir dibaca dari cache. Saat memori DAX node penuh, DAX mengusir item yang lebih lama meskipun belum kedaluwarsa untuk memberi ruang bagi item baru. LRUAlgoritma selalu diaktifkan dan tidak dapat dikonfigurasi pengguna.
Untuk menetapkan TTL durasi yang berfungsi untuk aplikasi Anda, pertimbangkan hal-hal berikut:
Memahami pola akses data Anda
-
Beban kerja baca-berat - Untuk aplikasi dengan beban kerja baca-berat dan pembaruan data yang jarang terjadi, tetapkan TTL durasi yang lebih lama untuk mengurangi jumlah cache yang hilang. TTLDurasi yang lebih lama juga mengurangi kebutuhan untuk mengakses tabel DynamoDB yang mendasarinya.
-
Beban kerja berat tulis — Untuk aplikasi dengan pembaruan yang sering tidak ditulisDAX, tetapkan TTL durasi yang lebih pendek untuk memastikan cache tetap konsisten dengan database. TTLDurasi yang lebih pendek juga mengurangi risiko menyajikan data basi.
Evaluasi persyaratan kinerja aplikasi Anda
-
Sensitivitas latensi — Jika aplikasi Anda memerlukan latensi rendah atas kesegaran data, gunakan durasi yang lebih lama. TTL TTLDurasi yang lebih lama memaksimalkan klik cache, yang mengurangi latensi baca rata-rata.
-
Throughput dan skalabilitas - TTL Durasi yang lebih lama mengurangi beban pada tabel DynamoDB dan meningkatkan throughput dan skalabilitas. Namun, Anda harus menyeimbangkan ini dengan kebutuhan akan up-to-date data.
Menganalisis penggusuran cache dan penggunaan memori
-
Batas memori cache - Pantau penggunaan memori DAX cluster Anda. TTLDurasi yang lebih lama dapat menyimpan lebih banyak data dalam cache, yang mungkin mencapai batas memori dan menyebabkan penggusuran LRU berbasis.
Gunakan metrik dan pemantauan untuk menyesuaikan TTL
Tinjau metrik secara teratur, misalnya, klik dan kesalahan cache, dan dan CPU pemanfaatan memori. Sesuaikan TTL pengaturan Anda berdasarkan metrik ini untuk menemukan keseimbangan optimal antara kinerja dan kesegaran data. Jika kesalahan cache tinggi dan pemanfaatan memori rendah, tingkatkan TTL durasinya untuk meningkatkan kecepatan hit cache.
Pertimbangkan persyaratan dan kepatuhan bisnis
Kebijakan penyimpanan data mungkin menentukan TTL durasi maksimum yang dapat Anda tetapkan untuk informasi sensitif atau pribadi.
Perilaku cache jika Anda menyetel TTL ke nol
Jika Anda menyetel TTL ke 0, cache item dan cache kueri menyajikan perilaku berikut:
-
Cache item — Item dalam cache di-refeshed hanya ketika LRU penggusuran atau operasi write-through terjadi.
-
Cache kueri - Respons kueri tidak di-cache.
Caching beberapa tabel dengan cluster DAX
Untuk beban kerja dengan beberapa tabel DynamoDB kecil yang tidak memerlukan cache individual, DAX satu cluster cache meminta tabel ini. Ini memberikan penggunaan yang lebih fleksibel dan efisienDAX, terutama untuk aplikasi yang mengakses beberapa tabel dan memerlukan pembacaan berkinerja tinggi.
Mirip dengan APIs bidang data DynamoDBDAX, permintaan memerlukan nama tabel. Jika Anda menggunakan beberapa tabel di DAX cluster yang sama, Anda tidak memerlukan konfigurasi tertentu. Namun, Anda harus memastikan bahwa izin keamanan klaster memungkinkan akses ke semua tabel yang di-cache.
Pertimbangan untuk menggunakan DAX dengan beberapa tabel
Bila Anda menggunakan DAX dengan beberapa tabel DynamoDB, Anda harus mempertimbangkan hal-hal berikut:
-
Manajemen memori — Bila Anda menggunakan DAX dengan beberapa tabel, Anda harus mempertimbangkan ukuran total kumpulan data kerja Anda. Semua tabel dalam kumpulan data Anda akan berbagi ruang memori yang sama dari jenis node yang Anda pilih.
-
Alokasi sumber daya - Sumber daya DAX cluster dibagi di antara semua tabel yang di-cache. Namun, tabel lalu lintas tinggi dapat menyebabkan penggusuran data dari tabel kecil tetangga.
-
Skala ekonomi — Kelompokkan sumber daya yang lebih kecil ke dalam DAX cluster yang lebih besar untuk rata-rata lalu lintas ke pola yang lebih stabil. Untuk jumlah total sumber daya baca yang dibutuhkan DAX cluster, juga ekonomis untuk memiliki tiga atau lebih node. Ini juga meningkatkan ketersediaan semua tabel cache di cluster.
Replikasi data dalam DAX dan tabel global DynamoDB
DAXadalah layanan berbasis Wilayah, jadi cluster hanya mengetahui lalu lintas di dalamnya. Wilayah AWS Tabel global menulis di sekitar cache ketika mereka mereplikasi data dari Wilayah lain.
TTLDurasi yang lebih lama dapat menyebabkan data basi tetap berada di Wilayah sekunder Anda lebih lama daripada di Wilayah primer. Hal ini dapat mengakibatkan kesalahan cache di cache lokal Wilayah sekunder.
Diagram berikut menunjukkan replikasi data yang terjadi pada tingkat tabel global di sumber Wilayah A. DAX Cluster di Wilayah B tidak segera menyadari data yang baru direplikasi dari sumber Wilayah A.
DAXKetersediaan wilayah
Tidak semua Wilayah yang mendukung tabel DynamoDB mendukung penerapan cluster. DAX Jika aplikasi Anda memerlukan latensi baca rendahDAX, tinjau dulu daftar Wilayah yang mendukung DAX. Kemudian, pilih Region untuk tabel DynamoDB Anda.
DAXperilaku caching
DAXmelakukan metadata dan caching negatif. Memahami perilaku caching ini akan membantu Anda mengelola metadata atribut item cache dan entri cache negatif secara efektif.
-
Metadata caching — DAX cluster mempertahankan metadata tanpa batas tentang nama atribut item cache. Metadata ini tetap ada bahkan setelah item kedaluwarsa atau diusir dari cache.
Seiring waktu, aplikasi yang menggunakan jumlah nama atribut yang tidak terbatas dapat menyebabkan kelelahan memori di cluster. DAX Batasan ini hanya berlaku untuk nama atribut tingkat atas, tetapi tidak untuk nama atribut bersarang. Contoh nama atribut tak terbatas termasuk cap waktu,, UUIDs dan sesi. IDs Meskipun Anda dapat menggunakan stempel waktu dan sesi IDs sebagai nilai atribut, kami sarankan untuk menggunakan nama atribut yang lebih pendek dan lebih dapat diprediksi.
-
Caching negatif - Jika kehilangan cache terjadi dan pembacaan dari tabel DynamoDB tidak menghasilkan item yang cocokDAX, tambahkan entri cache negatif di item masing-masing atau cache kueri. Entri ini tetap sampai TTL durasi cache berakhir atau write-through terjadi. DAXterus mengembalikan entri cache negatif ini untuk permintaan future.
Jika perilaku caching negatif tidak sesuai dengan pola aplikasi Anda, baca tabel DynamoDB secara langsung DAX saat mengembalikan hasil kosong. Kami juga menyarankan Anda mengatur durasi TTL cache yang lebih rendah untuk menghindari hasil kosong yang tahan lama di cache dan meningkatkan konsistensi dengan tabel.
