Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Mengkonfigurasi klaster DAX Anda
Cluster DAX adalah cluster terkelola, tetapi Anda dapat menyesuaikan konfigurasinya agar sesuai dengan kebutuhan aplikasi Anda. Karena integrasi yang erat dengan operasi API DynamoDB, Anda harus mempertimbangkan aspek-aspek berikut saat mengintegrasikan aplikasi Anda dengan DAX.
Dalam bagian ini
Harga DAX
Biaya cluster tergantung pada jumlah dan ukuran node yang telah disediakan. Setiap node ditagih untuk setiap jam yang dijalankannya di cluster. Untuk informasi selengkapnya, lihat harga Amazon DynamoDB
Hit cache tidak dikenakan biaya DynamoDB, tetapi berdampak pada sumber daya cluster DAX. Kehilangan cache menimbulkan biaya baca DynamoDB dan memerlukan sumber daya DAX. Penulisan menimbulkan biaya penulisan DynamoDB dan berdampak pada sumber daya cluster DAX untuk memproksi penulisan.
Cache item dan cache kueri
DAX memelihara cache item dan cache ku eri. Memahami perbedaan antara cache ini dapat membantu Anda menentukan karakteristik kinerja dan konsistensi yang mereka tawarkan untuk aplikasi Anda.
| Karakteristik cache | Cache item | Cache kueri |
|---|---|---|
|
Tujuan |
Menyimpan hasil GetItem dan operasi BatchGetItem API. |
Menyimpan hasil operasi Query dan Scan API. Operasi ini dapat mengembalikan beberapa item berdasarkan kondisi kueri alih-alih kunci item tertentu. |
|
Jenis Akses |
Menggunakan akses berbasis kunci. Ketika aplikasi meminta data menggunakan |
Menggunakan akses berbasis parameter. DAX menyimpan kumpulan hasil |
|
Pembatalan Cache |
DAX secara otomatis mereplikasi item yang diperbarui ke dalam cache item node di cluster DAX dalam skenario berikut:
|
Cache kueri lebih menantang untuk dibatalkan daripada cache item. Pembaruan item mungkin tidak langsung dipetakan ke kueri atau pemindaian yang di-cache. Anda harus hati-hati menyetel TTL cache query untuk menjaga konsistensi data. Penulisan melalui DAX atau tabel dasar tidak tercermin dalam cache kueri sampai TTL mengakhiri respons cache sebelumnya dan DAX melakukan kueri baru terhadap DynamoDB. |
|
Indeks sekunder global |
Karena operasi GetItem API tidak didukung pada indeks sekunder lokal atau indeks sekunder global, cache item hanya menyimpan bacaan dari tabel dasar. |
Cache kueri menyimpan kueri terhadap tabel dan indeks. |
Memilih pengaturan TTL untuk cache
TTL menentukan periode di mana data disimpan dalam cache sebelum menjadi basi. Setelah periode ini, data secara otomatis diperbarui pada permintaan berikutnya. Memilih pengaturan TTL yang tepat untuk cache DAX Anda melibatkan penyeimbangan antara optimalisasi kinerja aplikasi dan konsistensi data. Karena tidak ada pengaturan TTL universal yang berfungsi untuk semua aplikasi, pengaturan TTL optimal bervariasi berdasarkan karakteristik dan persyaratan spesifik aplikasi Anda. Kami menyarankan Anda memulai dengan pengaturan TTL konservatif menggunakan panduan preskriptif ini. Kemudian, sesuaikan setelan TTL secara berulang berdasarkan data dan wawasan kinerja aplikasi Anda.
DAX mempertahankan daftar yang paling tidak digunakan baru-baru ini (LRU) untuk cache item. Daftar LRU melacak kapan item pertama kali ditulis atau terakhir dibaca dari cache. Ketika memori node DAX penuh, DAX mengusir item yang lebih lama meskipun belum kedaluwarsa untuk memberi ruang bagi item baru. Algoritma LRU selalu diaktifkan dan tidak dapat dikonfigurasi pengguna.
Untuk mengatur durasi TTL yang sesuai untuk aplikasi Anda, pertimbangkan hal-hal berikut:
Memahami pola akses data Anda
-
Read-heavy beban kerja — Untuk aplikasi dengan beban kerja yang banyak dibaca dan pembaruan data yang jarang terjadi, tetapkan durasi TTL yang lebih lama untuk mengurangi jumlah cache yang hilang. Durasi TTL yang lebih lama juga mengurangi kebutuhan untuk mengakses tabel DynamoDB yang mendasarinya.
-
Write-heavy beban kerja — Untuk aplikasi dengan pembaruan sering yang tidak ditulis melalui DAX, tetapkan durasi TTL yang lebih pendek untuk memastikan cache tetap konsisten dengan database. Durasi TTL yang lebih pendek juga mengurangi risiko menyajikan data basi.
Mengevaluasi persyaratan kinerja aplikasi Anda
-
Sensitivitas latensi — Jika aplikasi Anda memerlukan latensi rendah atas kesegaran data, gunakan durasi TTL yang lebih lama. Durasi TTL yang lebih lama memaksimalkan hit cache, yang mengurangi latensi baca rata-rata.
-
Throughput dan skalabilitas — Durasi TTL yang lebih lama mengurangi beban pada tabel DynamoDB dan meningkatkan throughput dan skalabilitas. Namun, Anda harus menyeimbangkan ini dengan kebutuhan akan data terkini.
Analisis penggusuran cache dan penggunaan memori
-
Batas memori cache — Pantau penggunaan memori cluster DAX Anda. Durasi TTL yang lebih lama dapat menyimpan lebih banyak data dalam cache, yang mungkin mencapai batas memori dan menyebabkan penggusuran LRU-based .
Gunakan metrik dan pemantauan untuk menyesuaikan TTL
Tinjau metrik secara teratur, misalnya, hit dan hilses cache, serta pemanfaatan CPU dan memori. Sesuaikan pengaturan TTL berdasarkan metrik ini untuk menemukan keseimbangan optimal antara kinerja dan kesegaran data. Jika cache melewatkan tinggi dan pemanfaatan memori rendah, tingkatkan durasi TTL untuk meningkatkan hit rate cache.
Pertimbangkan persyaratan bisnis dan kepatuhan
Kebijakan penyimpanan data mungkin menentukan durasi TTL maksimum yang dapat Anda tetapkan untuk informasi sensitif atau pribadi.
Perilaku cache jika Anda mengatur TTL ke nol
Jika Anda menyetel TTL ke 0, cache item dan cache query menyajikan perilaku berikut:
-
Cache item — Item dalam cache di-refeshed hanya ketika penggusuran LRU atau operasi penulisan terjadi.
-
Cache kueri — Respons kueri tidak di-cache.
Men-cache beberapa tabel dengan cluster DAX
Untuk beban kerja dengan beberapa tabel DynamoDB kecil yang tidak memerlukan cache individual, satu cluster DAX cache permintaan untuk tabel ini. Ini memberikan penggunaan DAX yang lebih fleksibel dan efisien, terutama untuk aplikasi yang mengakses beberapa tabel dan memerlukan pembacaan berkinerja tinggi.
Mirip dengan API bidang data DynamoDB, permintaan DAX memerlukan nama tabel. Jika Anda menggunakan beberapa tabel dalam cluster DAX yang sama, Anda tidak memerlukan konfigurasi khusus apa pun. Namun, Anda harus memastikan bahwa izin keamanan cluster memungkinkan akses ke semua tabel yang di-cache.
Pertimbangan untuk menggunakan DAX dengan beberapa tabel
Saat Anda menggunakan DAX dengan beberapa tabel DynamoDB, Anda harus mempertimbangkan hal-hal berikut:
-
Manajemen memori — Saat 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 cluster DAX dibagi di antara semua tabel yang di-cache. Namun, tabel lalu lintas tinggi dapat menyebabkan penggusuran data dari tabel kecil tetangga yang lebih kecil.
-
Skala ekonomi — Kelompokkan sumber daya yang lebih kecil ke dalam cluster DAX yang lebih besar untuk merata-ratakan lalu lintas ke pola yang lebih stabil. Untuk jumlah total sumber daya baca yang dibutuhkan cluster DAX, juga ekonomis untuk memiliki tiga atau lebih node. Ini juga meningkatkan ketersediaan semua tabel cache di cluster.
Replikasi data dalam tabel global DAX dan DynamoDB
DAX adalah Region-based layanan, jadi cluster hanya menyadari lalu lintas di dalamnya. Wilayah AWS Tabel global menulis di sekitar cache ketika mereka mereplikasi data dari Wilayah lain.
Durasi TTL yang lebih lama dapat menyebabkan data basi tetap berada di Wilayah sekunder Anda lebih lama daripada di Wilayah utama. Hal ini dapat mengakibatkan cache hilang di cache lokal dari Wilayah sekunder.
Diagram berikut menunjukkan replikasi data yang terjadi pada tingkat tabel global di Wilayah sumber A. Cluster DAX di Wilayah B tidak segera mengetahui data yang baru direplikasi dari sumber Wilayah A.
Ketersediaan DAX Region
Tidak semua Wilayah yang mendukung tabel DynamoDB mendukung penerapan klaster DAX. Jika aplikasi Anda memerlukan latensi baca rendah melalui DAX, tinjau terlebih dahulu daftar Wil ayah yang mendukung DA X. Kemudian, pilih Region untuk tabel DynamoDB Anda.
Perilaku caching DAX
DAX melakukan metadata dan cache negatif. Memahami perilaku caching ini akan membantu Anda mengelola metadata atribut item yang di-cache dan entri cache negatif secara efektif.
-
Caching metadata — Cluster DAX mempertahankan metadata tanpa batas waktu tentang nama atribut item yang di-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 kehabisan 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 stempel waktu, UUID, dan ID sesi. Meskipun Anda dapat menggunakan stempel waktu dan ID sesi sebagai nilai atribut, sebaiknya gunakan nama atribut yang lebih pendek dan lebih dapat diprediksi.
-
Caching negatif — Jika terjadi kesalahan cache dan pembacaan dari tabel DynamoDB tidak menghasilkan item yang cocok, DAX menambahkan entri cache negatif di item atau cache kueri masing-masing. Entri ini tetap ada sampai durasi TTL cache berakhir atau penulisan terjadi. DAX terus mengembalikan entri cache negatif ini untuk permintaan di masa mendatang.
Jika perilaku caching negatif tidak sesuai dengan pola aplikasi Anda, baca tabel DynamoDB secara langsung saat DAX mengembalikan hasil kosong. Kami juga menyarankan Anda menetapkan durasi cache TTL yang lebih rendah untuk menghindari hasil kosong jangka panjang di cache dan meningkatkan konsistensi dengan tabel.
