Cache yang terintegrasi Azure Cosmos DB - Ringkasan

BERLAKU UNTUK: NoSQL

Cache terintegrasi Azure Cosmos DB adalah cache dalam memori yang membantu Anda memastikan biaya yang dapat dikelola dan latensi rendah selagi volume permintaan bertambah. Cache terintegrasi mudah diatur dan Anda tidak perlu menghabiskan waktu untuk menulis kode kustom untuk cache yang tidak valid atau mengelola infrastruktur backend. Cache terintegrasi menggunakan gateway khusus dalam akun Azure Cosmos DB Anda. Saat menyediakan gateway khusus, Anda dapat memilih jumlah simpul dan ukuran simpul berdasarkan jumlah inti dan memori yang diperlukan untuk beban kerja Anda. Setiap simpul gateway khusus memiliki cache terintegrasi terpisah dari yang lain.

Cache terintegrasi dikonfigurasi secara otomatis dalam gateway khusus. Cache terintegrasi memiliki dua bagian:

• Cache item untuk titik baca
• Cache kueri untuk kueri

Cache terintegrasi adalah cache read-through dan write-through dengan kebijakan pengeluaran Least Recently Used (LRU). Cache item dan cache kueri memiliki kapasitas yang sama dalam cache terintegrasi dan kebijakan pengeluaran LRU berlaku untuk keduanya. Data dikeluarkan dari cache secara ketat berdasarkan kapan data tersebut paling tidak baru digunakan, terlepas dari apakah itu titik baca atau kueri. Data yang di-cache dalam setiap node bergantung pada data terbaru yang ditulis atau dibaca melalui node tersebut. Jika item atau kueri ditembolok di satu node, belum tentu juga akan ditembolok di node lainnya.

Beban kerja yang mendapat manfaat dari cache terintegrasi

Tujuan utama dari cache terintegrasi adalah untuk mengurangi biaya untuk beban kerja yang berat dalam pembacaan. Latensi rendah, meskipun bermanfaat, bukanlah manfaat utama dari cache terintegrasi karena Azure Cosmos DB sudah cepat tanpa penembolokan.

Pembacaan titik dan kueri yang mengenai cache terintegrasi memiliki biaya RU 0. Hit cache memiliki biaya per operasi yang jauh lebih rendah daripada bacaan dari database backend.

Beban kerja yang sesuai dengan karakteristik berikut harus mengevaluasi apakah cache terintegrasi membantu menurunkan biaya:

• Beban kerja baca-berat
• Banyak titik baca berulang pada item besar
• Banyak kueri RU tinggi berulang
• Tombol pintasan partisi untuk pembacaan

Faktor terbesar dalam harapan penghematan adalah tingkat pengulangan pembacaan sendiri. Jika beban kerja Anda secara konsisten menjalankan titik baca atau kueri yang sama dalam waktu singkat, ini adalah kandidat yang bagus untuk cache terintegrasi. Saat menggunakan cache terintegrasi untuk pembacaan berulang, Anda hanya menggunakan RU untuk bacaan pertama. Bacaan berikutnya yang dirutekan melalui simpul gateway khusus yang sama (di dalam MaxIntegratedCacheStaleness jendela dan jika data belum dikeluarkan) tidak menggunakan throughput.

Beberapa beban kerja tidak boleh mempertimbangkan cache terintegrasi, termasuk:

• Beban kerja tulis-berat
• Titik baca atau kueri yang jarang terulang
• Beban kerja membaca umpan perubahan

Cache item

Cache item digunakan untuk pembacaan titik (pencarian kunci/nilai berdasarkan ID Item dan kunci partisi).

Mengisi cache item

• Penulisan, pembaruan, dan penghapusan baru secara otomatis diisi dalam cache item simpul yang dirutekan permintaannya
• Item dari permintaan baca titik di mana item belum ada di cache (cache miss) dari simpul yang dirutekan permintaan ditambahkan ke cache item
• Membaca permintaan untuk beberapa item, seperti ReadMany, mengisi cache kueri sebagai set, bukan cache item sebagai item individual
• Permintaan yang merupakan bagian dari batch transaksional atau dalam mode massal tidak mengisi cache item

Pengeluaran dan pelabelan tidak valid untuk cache item

Karena setiap simpul memiliki cache independen, kemungkinan item tidak valid atau dikeluarkan dalam cache satu simpul dan bukan yang lain. Item dalam cache simpul tertentu tidak valid dan dikeluarkan berdasarkan kriteria di bawah ini:

• Pembaruan atau penghapusan item
• Least recently used (LRU)
• Waktu penyimpanan cache (dengan kata lain, MaxIntegratedCacheStaleness)

Cache kueri

Cache kueri digunakan untuk menyimpan kueri. Cache kueri mengubah kueri menjadi pencarian kunci/nilai di mana kunci adalah teks kueri dan nilainya adalah hasil kueri. Cache terintegrasi tidak memiliki mesin kueri, cache hanya menyimpan pencarian kunci/nilai untuk setiap kueri. Hasil kueri disimpan sebagai set, dan cache tidak melacak item individual. Item tertentu dapat disimpan dalam cache kueri beberapa kali jika muncul dalam kumpulan hasil beberapa kueri. Pembaruan pada item yang mendasar tidak tercermin dalam hasil kueri kecuali keusangan cache terintegrasi maksimum untuk kueri tercapai dan kueri dilayani dari database backend.

Mengisi cache kueri

• Jika cache tidak memiliki hasil untuk kueri tersebut (cache miss) pada simpul yang dirutekan, kueri dikirim ke backend. Setelah kueri dijalankan, cache akan menyimpan hasil untuk kueri tersebut
• Kueri dengan bentuk yang sama tetapi parameter atau opsi permintaan yang berbeda yang memengaruhi hasil (jumlah item ex. max) disimpan sebagai pasangan kunci/nilai mereka sendiri
• Membaca permintaan untuk beberapa item, seperti ReadMany, mengisi cache kueri. Hasil ReadMany disimpan sebagai satu set, dan permintaan dengan input yang berbeda akan disimpan sebagai pasangan kunci/nilai mereka sendiri

Pengeluaran cache kueri

Pengeluaran cache kueri didasarkan pada simpul yang dirutekan permintaan. Kemungkinan kueri dapat dikeluarkan atau disegarkan pada satu simpul dan bukan yang lain.

• Least recently used (LRU)
• Waktu penyimpanan cache (dengan kata lain, MaxIntegratedCacheStaleness)

Bekerja dengan cache kueri

Anda tidak memerlukan kode khusus saat bekerja dengan cache kueri, bahkan jika kueri Anda memiliki beberapa halaman hasil. Praktik terbaik dan kode untuk penentuan halaman kueri tetap sama terlepas kueri Anda mengenai cache terintegrasi atau pun dieksekusi pada mesin kueri backend.

Cache kueri secara otomatis menyimpan token kelanjutan kueri jika berlaku. Jika Anda memiliki kueri dengan beberapa halaman hasil, halaman apa pun yang disimpan dalam cache terintegrasi memiliki biaya RU 0. Jika halaman hasil kueri berikutnya memerlukan eksekusi backend, halaman tersebut akan memiliki token kelanjutan dari halaman sebelumnya sehingga dapat menghindari duplikasi pekerjaan sebelumnya.

Konsistensi cache terintegrasi

Cache terintegrasi hanya mendukung permintaan baca dengan sesi dan konsistensi kejadian. Jika bacaan memiliki awalan yang konsisten, keusangan terikat, atau konsistensi yang kuat, bacaan melewati cache terintegrasi dan dilayani dari backend.

Cara termudah untuk mengonfigurasi sesi atau konsistensi akhir untuk semua pembacaan adalah dengan mengaturnya di tingkat akun. Namun, jika Anda hanya ingin beberapa bacaan Anda memiliki konsistensi tertentu, Anda juga dapat mengonfigurasi konsistensi pada tingkat permintaan.

Konsistensi sesi

Konsistensi sesi adalah tingkat konsistensi yang paling banyak digunakan untuk satu wilayah dan akun Azure Cosmos DB yang didistribusikan secara global. Dengan konsistensi sesi, sesi klien tunggal dapat membaca tulisan mereka sendiri. Setiap bacaan dengan konsistensi sesi yang tidak memiliki token sesi yang cocok akan dikenakan biaya RU. Ini termasuk permintaan pertama untuk item atau kueri tertentu saat aplikasi klien dimulai atau dimulai ulang, kecuali Anda secara eksplisit meneruskan token sesi yang valid. Klien di luar sesi yang melakukan penulisan akan melihat konsistensi akhir saat mereka menggunakan cache terintegrasi.

MaxIntegratedCacheStaleness

MaxIntegratedCacheStaleness adalah kebuntuan maksimum yang dapat diterima untuk pembacaan dan kueri titik di-cache, terlepas dari konsistensi yang dipilih. MaxIntegratedCacheStaleness dapat dikonfigurasi pada tingkat permintaan. Misalnya, jika Anda mengatur MaxIntegratedCacheStaleness dari 2 jam, permintaan Anda hanya akan mengembalikan data cache jika data tersebut berusia kurang dari 2 jam. Untuk meningkatkan kemungkinan pembacaan berulang menggunakan cache terintegrasi, Anda harus mengatur MaxIntegratedCacheStaleness ​​setinggi yang diizinkan oleh persyaratan bisnis Anda.

MaxIntegratedCacheStaleness, ketika dikonfigurasi pada permintaan yang akhirnya mengisi cache, tidak memengaruhi berapa lama permintaan tersebut di-cache. MaxIntegratedCacheStaleness memberlakukan konsistensi saat Anda mencoba membaca data cache. Tidak ada pengaturan retensi TTL atau cache global, sehingga data hanya dikeluarkan dari cache jika cache terintegrasi penuh atau bacaan baru dijalankan dengan lebih rendah MaxIntegratedCacheStaleness dari usia entri cache saat ini.

Ini adalah peningkatan dari cara kerja sebagian besar cache dan memungkinkan penyesuaian lainnya berikut:

• Anda dapat mengatur persyaratan keusangan yang berbeda untuk setiap pembacaan poin atau kueri
• Klien yang berbeda, meskipun menjalankan pembacaan titik atau kueri yang sama, dapat mengonfigurasi nilai MaxIntegratedCacheStaleness yang berbeda
• Jika Anda ingin memodifikasi konsistensi baca untuk data yang di-cache, perubahan MaxIntegratedCacheStaleness memiliki efek langsung pada konsistensi baca

Untuk lebih memahami parameter MaxIntegratedCacheStaleness, perhatikan contoh berikut:

Pelajari cara mengonfigurasi MaxIntegratedCacheStaleness.

Melewati cache terintegrasi

Cache terintegrasi memiliki kapasitas penyimpanan terbatas yang ditentukan oleh SKU gateway khusus yang disediakan. Secara default, semua permintaan dari klien yang dikonfigurasi dengan gateway khusus string koneksi melalui cache terintegrasi dan mengambil ruang cache. Anda dapat mengontrol item dan kueri mana yang di-cache dengan opsi permintaan cache terintegrasi bypass. Opsi permintaan ini berguna untuk penulisan item atau permintaan baca yang tidak diharapkan sering diulang. Melewati cache terintegrasi untuk item dengan akses jarang menghemat ruang cache untuk item dengan lebih banyak pengulangan, meningkatkan potensi penyimpanan RU dan mengurangi pengeluaran. Permintaan yang melewati cache masih dirutekan melalui gateway khusus. Permintaan ini dilayani dari backend dan RU biaya.

Pelajari cara melewati cache terintegrasi.

Metrik

Sangat membantu untuk memantau beberapa kunci DedicatedGateway dan IntegratedCache metrik untuk cache terintegrasi. Untuk mempelajari tentang metrik ini, lihat Metrik yang didukung untuk Microsoft.DocumentDB/DatabaseAccounts.

Semua metrik yang ada tersedia, secara default, dari Metrik di portal Azure (bukan Metrik klasik):

Metrik adalah rata-rata, maksimum, atau jumlah di semua node gateway khusus. Misalnya, jika Anda menyediakan kluster gateway khusus dengan lima node, metrik mencerminkan nilai agregat di kelima node. Tidak dimungkinkan untuk menentukan nilai metrik untuk setiap node secara individu.

Pemecahan masalah umum

Contoh di bawah ini menunjukkan cara melakukan debug pada beberapa skenario umum:

Saya tidak tahu apakah aplikasi saya menggunakan gateway khusus

Periksa DedicatedGatewayRequests. Metrik ini mencakup semua permintaan yang menggunakan gateway khusus, terlepas dari apakah metrik mencapai cache terintegrasi. Jika aplikasi Anda menggunakan gateway standar atau mode langsung dengan string koneksi asli, Anda tidak akan melihat pesan kesalahan, tetapi DedicatedGatewayRequests akan menjadi nol. Jika aplikasi Anda menggunakan mode langsung dengan gateway khusus string koneksi, Anda mungkin masih melihat beberapa DedicatedGatewayRequests.

Saya tidak tahu apakah permintaan saya mencapai hit cache terintegrasi

Periksa IntegratedCacheItemHitRate dan IntegratedCacheQueryHitRate. Jika kedua nilai ini nol, maka permintaan tidak mencapai cache terintegrasi. Periksa apakah Anda menggunakan gateway khusus string koneksi, menyambungkan dengan mode gateway, dan menggunakan sesi atau konsistensi akhir.

Saya ingin mengetahui apakah gateway khusus saya terlalu kecil

Periksa IntegratedCacheItemHitRate dan IntegratedCacheQueryHitRate. Nilai tinggi (misalnya, di atas 0,7-0,8) adalah pertanda baik bahwa gateway khusus cukup besar.

Jika IntegratedCacheItemHitRate atau IntegratedCacheQueryHitRate rendah, lihat IntegratedCacheEvictedEntriesSize. Jika IntegratedCacheEvictedEntriesSize tinggi, hal ini dapat berarti bahwa Anda dapat menggunakan ukuran gateway khusus yang lebih besar. Anda dapat bereksperimen dengan meningkatkan ukuran gateway khusus dan membandingkan IntegratedCacheItemHitRate dan IntegratedCacheQueryHitRate yang baru. Jika gateway khusus yang lebih besar tidak meningkatkan IntegratedCacheItemHitRate atau IntegratedCacheQueryHitRate, mungkin saja pembacaan tidak cukup berulang agar cache terintegrasi dapat berdampak.

Saya ingin mengetahui apakah gateway khusus saya terlalu besar

Lebih sulit untuk mengukur jika gateway khusus terlalu besar daripada mengukur jika gateway khusus terlalu kecil. Secara umum, Anda harus memulai dari yang kecil dan perlahan-lahan meningkatkan ukuran gateway khusus hingga IntegratedCacheItemHitRate dan IntegratedCacheQueryHitRate berhenti meningkat. Dalam beberapa kasus, hanya satu dari dua metrik hit cache yang penting, bukan keduanya. Misalnya, jika beban kerja Anda utamanya adalah kueri, daripada pembacaan titik, IntegratedCacheQueryHitRate jauh lebih penting daripada IntegratedCacheItemHitRate.

Jika sebagian besar data dikeluarkan dari cache karena melebihi MaxIntegratedCacheStaleness dan bukan LRU, cache Anda mungkin lebih besar dari yang diperlukan. Jika gabungan IntegratedCacheItemExpirationCount dan IntegratedCacheQueryExpirationCount hampir sebesar IntegratedCacheEvictedEntriesSize, Anda dapat bereksperimen dengan ukuran gateway khusus yang lebih kecil dan membandingkan performa.

Saya ingin memahami apakah saya perlu menambahkan lebih banyak node gateway khusus

Dalam beberapa kasus, jika latensi tiba-tiba tinggi, Anda mungkin memerlukan lebih banyak node gateway khusus daripada node yang lebih besar. Periksa DedicatedGatewayCPUUsage dan DedicatedGatewayMemoryUsage untuk menentukan apakah menambahkan lebih banyak node gateway khusus akan mengurangi latensi. Sebaiknya diingat bahwa karena semua instans cache terintegrasi saling independen satu sama lain, menambahkan lebih banyak node gateway khusus tidak akan mengurangi IntegratedCacheEvictedEntriesSize. Menambahkan lebih banyak node akan meningkatkan volume permintaan yang dapat ditangani oleh kluster gateway khusus Anda.

Langkah berikutnya

• FAQ cache terintegrasi
• Mengonfigurasi cache terintegrasi
• Gateway khusus
• Mencoba melakukan perencanaan kapasitas untuk migrasi ke Azure Cosmos DB? Anda dapat menggunakan informasi tentang kluster database Anda yang ada saat ini untuk membuat perencanaan kapasitas.
  • Jika Anda hanya mengetahui jumlah vCore dan server di kluster database yang ada, baca tentang memperkirakan unit permintaan menggunakan vCore atau vCPU
  • Jika Anda mengetahui rasio permintaan umum untuk beban kerja database Anda saat ini, baca memperkirakan unit permintaan menggunakan perencana kapasitas Azure Cosmos DB