Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Bagian ini menjelaskan kapan dan mengapa menggunakan DAX. Menggunakan panduan ini membantu Anda menentukan apakah mengintegrasikan DAX dengan DynamoDB menguntungkan untuk pola beban kerja aplikasi Anda, persyaratan kinerja, dan kebutuhan konsistensi data. Ini juga mencakup skenario di mana DAX mungkin tidak cocok, misalnya, beban kerja berat tulis dan data yang jarang diakses.
Dalam bagian ini
Kapan dan mengapa memilih DAX
Anda dapat mempertimbangkan untuk menambahkan DAX ke tumpukan aplikasi Anda dalam beberapa skenario. Misalnya, gunakan DAX untuk mengurangi latensi keseluruhan permintaan baca terhadap DynamoDB atau untuk meminimalkan pembacaan berulang data yang sama dari tabel. Daftar berikut menyajikan contoh skenario di mana Anda dapat memanfaatkan mengintegrasikan DAX dengan DynamoDB:
-
Persyaratan kinerja tinggi
-
Pembacaan latensi rendah — Anda harus mempertimbangkan untuk menggunakan DAX jika aplikasi Anda memerlukan waktu respons dalam mikrodetik untuk pembacaan yang konsisten. DAX juga dapat secara drastis mengurangi waktu respons untuk mengakses data yang sering dibaca.
-
-
Beban kerja intensif baca
-
Aplikasi baca-berat — Untuk aplikasi dengan read-to-write rasio tinggi, misalnya, 10:1 atau lebih, DAX menghasilkan lebih banyak klik cache dan data yang kurang basi. Ini mengurangi pembacaan terhadap tabel. Untuk menghindari membaca data basi dari cache jika aplikasi Anda berat tulis, pastikan untuk mengatur lebih rendah Menggunakan time to live (TTL) di DynamoDB untuk cache.
-
Caching query umum — Jika aplikasi Anda sering membaca data yang sama, misalnya, produk populer di platform e-commerce, DAX dapat melayani permintaan ini langsung dari cache-nya.
-
-
Pola lalu lintas meledak
-
Penskalaan tabel yang lebih halus — DAX membantu menghaluskan dampak lonjakan lalu lintas mendadak. DAX menyediakan buffer untuk meningkatkan kapasitas tabel DynamoDB dengan anggun, yang mengurangi risiko pelambatan baca.
-
Throughput baca yang lebih tinggi untuk setiap item - DynamoDB mengalokasikan partisi individu untuk setiap item. Namun, partisi mulai membatasi pembacaan item ketika mencapai 3.000 unit kapasitas baca (RCU). DAX memungkinkan Anda menskalakan pembacaan satu item di luar 3.000 RCU.
-
-
Optimalisasi biaya
-
Mengurangi biaya DynamoDB - Membaca dari DAX dapat mengurangi pembacaan yang dikirim ke tabel DynamoDB, yang kemudian dapat berdampak langsung pada biaya. Dengan hit rate cache yang tinggi, pengurangan biaya baca tabel dapat melebihi biaya cluster DAX, yang menghasilkan pengurangan biaya bersih.
-
-
Persyaratan konsistensi data
-
Konsistensi akhirnya - DAX mendukung pembacaan yang konsisten pada akhirnya. Hal ini membuat DAX cocok untuk kasus penggunaan di mana konsistensi langsung tidak penting.
-
Write-through caching — Menulis yang Anda buat terhadap DAX adalah write-through. Setelah DAX mengonfirmasi bahwa item tersebut ditulis ke DynamoDB, ia tetap mempertahankan versi item tersebut di cache item. Mekanisme penulisan ini membantu menjaga konsistensi data yang lebih ketat antara cache dan database, tetapi menggunakan sumber daya cluster DAX tambahan.
-
Kapan tidak menggunakan DAX
Meskipun DAX kuat, itu tidak cocok untuk semua skenario. Daftar berikut menyajikan contoh skenario di mana mengintegrasikan DAX dengan DynamoDB tidak cocok:
-
Beban kerja berat tulis — Keuntungan utama DAX adalah mempercepat pembacaan, tetapi menulis menggunakan lebih banyak sumber daya DAX daripada membaca. Jika aplikasi Anda sebagian besar ditulis berat, manfaat DAX mungkin terbatas.
-
Jarang membaca data — Jika aplikasi Anda jarang mengakses data atau berbagai data yang jarang digunakan kembali (data dingin), Anda mungkin akan mengalami penurunan. cache hit ratio Dalam hal ini, overhead pemeliharaan cache mungkin tidak membenarkan peningkatan kinerja.
-
Bacaan atau tulis massal - Jika aplikasi Anda melakukan penulisan massal lebih banyak daripada penulisan individual, Anda harus menulis di sekitar DAX. Selain itu, untuk pembacaan massal, Anda harus menjalankan pemindaian tabel penuh langsung terhadap tabel DynamoDB.
-
Konsistensi atau persyaratan transaksi yang kuat — DAX meneruskan pembacaan dan TransactGetItemspanggilan yang sangat konsisten ke tabel DynamoDB. Anda harus membuat pembacaan ini di sekitar cluster DAX untuk menghindari penggunaan sumber daya klaster. Item yang dibaca dengan cara ini tidak akan di-cache; oleh karena itu, merutekan item tersebut melalui DAX tidak ada gunanya.
-
Aplikasi sederhana dengan persyaratan kinerja sederhana - Untuk aplikasi dengan persyaratan kinerja sederhana dan toleransi untuk latensi DynamoDB langsung, kompleksitas dan biaya penambahan DAX mungkin tidak diperlukan. Dengan sendirinya, DynamoDB menangani throughput tinggi dan memberikan kinerja milidetik satu digit.
-
Kebutuhan kueri kompleks di luar akses nilai kunci — DAX dioptimalkan untuk pola akses nilai kunci. Jika aplikasi Anda memerlukan kemampuan kueri yang kompleks dengan pemfilteran yang kompleks, seperti operasi Kueri dan Pemindaian, manfaat caching DAX mungkin terbatas.
Dalam situasi ini, gunakan Amazon ElastiCache (Redis OSS) sebagai alternatif. ElastiCache (Redis OSS) mendukung struktur data tingkat lanjut, seperti, daftar, set, dan hash. Ini juga menawarkan fitur, seperti pub/sub, indeks geospasial, dan skrip.
-
Persyaratan kepatuhan — DAX saat ini tidak menawarkan akreditasi kepatuhan yang sama seperti DynamoDB. Misalnya, DAX belum memperoleh akreditasi SOC.
