Optimalkan biaya throughput yang disediakan di Azure Cosmos DB

BERLAKU UNTUK: NoSQL MongoDB Cassandra Gremlin Meja

Dengan menawarkan model throughput yang disediakan, Azure Cosmos DB menawarkan performa yang dapat diprediksi dalam skala apa pun. Memesan atau menyediakan throughput lebih dulu menghilangkan “efek tetangga berisik” pada performa Anda. Anda menentukan jumlah throughput pasti yang dibutuhkan dan Azure Cosmos DB menjamin throughput yang dikonfigurasi, didukung oleh SLA.

Anda dapat memulai dengan throughput minimum 400 RU/dtk dan menskalakan hingga puluhan juta permintaan per detik atau bahkan lebih. Setiap permintaan yang Anda terbitkan terhadap kontainer atau database Azure Cosmos DB Anda, seperti permintaan baca, permintaan tulis, permintaan kueri, prosedur tersimpan memiliki biaya yang sesuai yang dikurangi dari throughput yang disediakan. Jika Anda menyediakan 400 RU/dtk dan mengeluarkan kueri yang harganya 40 RU, Anda akan dapat mengeluarkan 10 kueri tersebut per detik. Setiap permintaan di luar yang mendapatkan tarif terbatas dan Anda harus mencoba kembali permintaan. Jika Anda menggunakan driver klien, mereka mendukung logika coba lagi otomatis.

Anda dapat menyediakan throughput pada database atau kontainer dan setiap strategi dapat membantu Anda menghemat biaya tergantung pada skenario.

Optimalkan dengan menyediakan throughput pada tingkat yang berbeda

• Jika Anda menyediakan throughput pada database, semua kontainer, misalnya koleksi/tabel/grafik dalam database tersebut dapat berbagi throughput berdasarkan beban. Throughput yang dicadangkan di tingkat database dibagikan secara tidak merata, tergantung pada beban kerja pada sekumpulan kontainer tertentu.

• Jika Anda menyediakan throughput pada kontainer, throughput dijamin untuk kontainer tersebut, didukung oleh SLA. Pilihan kunci partisi logis sangat penting untuk distribusi beban yang merata di semua partisi logis dari kontainer. Lihat artikel Mempartisi dan penskalaan horizontal untuk detail selengkapnya.

Berikut ini adalah beberapa panduan untuk memutuskan strategi throughput yang disediakan:

Pertimbangkan untuk menyediakan throughput pada database Azure Cosmos DB (berisi sekumpulan kontainer) jika:

1. Anda memiliki beberapa lusin kontainer Azure Cosmos DB dan ingin berbagi throughput di beberapa atau semuanya.

2. Anda bermigrasi dari database penyewa tunggal yang dirancang untuk berjalan pada VM atau lokal yang dihosting IaaS, misalnya, NoSQL atau database relasional ke Azure Cosmos DB. Dan jika Anda memiliki banyak koleksi/tabel/grafik dan Anda tidak ingin membuat perubahan apa pun pada model data Anda. Perhatikan, Anda mungkin harus membahayakan beberapa manfaat yang ditawarkan oleh Azure Cosmos DB jika Anda tidak memperbarui model data saat bermigrasi dari database lokal. Sebaiknya Anda selalu menilai kembali model data Anda untuk mendapatkan hasil maksimal dalam hal performa dan juga untuk mengoptimalkan biaya.

3. Anda ingin menyerap lonjakan beban kerja yang tidak direncanakan berdasarkan throughput yang terkumpul di tingkat database yang mengalami lonjakan beban kerja tidak terduga.

4. Alih-alih mengatur throughput tertentu pada masing-masing kontainer, Anda ingin mendapatkan throughput agregat di satu set kontainer dalam database.

Pertimbangkan untuk menyediakan throughput pada masing-masing kontainer jika:

1. Anda memiliki beberapa kontainer Azure Cosmos DB. Karena Azure Cosmos DB bersifat skema-agnostik, kontainer dapat berisi item yang memiliki skema heterogen dan tidak mengharuskan pelanggan untuk membuat beberapa jenis kontainer, satu untuk setiap entitas. Selalu merupakan opsi untuk mempertimbangkan apakah pengelompokan terpisah mengatakan 10-20 kontainer ke dalam satu kontainer masuk akal. Dengan minimum 400 RUs untuk kontainer, mengumpulkan seluruh 10-20 kontainer menjadi satu bisa lebih hemat biaya.

2. Anda ingin mengontrol throughput pada kontainer tertentu dan mendapatkan throughput yang dijamin pada kontainer tertentu yang didukung oleh SLA.

Pertimbangkan hibrida dari dua strategi di atas:

1. Seperti disebutkan sebelumnya, Azure Cosmos DB memungkinkan Anda untuk mencampur dan mencocokkan dua strategi di atas, sehingga Anda sekarang dapat memiliki beberapa kontainer dalam database Azure Cosmos DB, yang mungkin berbagi throughput yang disediakan pada database serta, beberapa kontainer dalam database yang sama, yang mungkin memiliki jumlah throughput khusus yang disediakan.

2. Anda dapat menerapkan strategi di atas untuk menghasilkan konfigurasi hibrida, dengan throughput tingkat database yang disediakan dan beberapa kontainer yang memiliki throughput khusus.

Seperti yang ditunjukkan dalam tabel berikut, tergantung pada pilihan API, Anda dapat menyediakan throughput pada granularitas berbeda.

API	Untuk throughput bersama, konfigurasikan	Untuk throughput khusus, konfigurasikan
API untuk NoSQL	Database	Kontainer
API Azure Cosmos DB untuk MongoDB	Database	Koleksi
API untuk Cassandra	Keyspace	Tabel
API untuk Gremlin	Akun database	Grafik
API untuk Tabel	Akun database	Tabel

Dengan menyediakan throughput pada tingkat berbeda, Anda dapat mengoptimalkan biaya berdasarkan karakteristik beban kerja Anda. Seperti disebutkan sebelumnya, Anda dapat secara terprogram dan kapan saja meningkatkan atau mengurangi throughput yang disediakan untuk setiap kontainer atau secara kolektif di satu set kontainer. Dengan menskalakan throughput secara elastis saat beban kerja berubah, Anda hanya membayar throughput yang telah dikonfigurasi. Jika kontainer atau satu set kontainer didistribusikan di beberapa wilayah, maka throughput yang Anda konfigurasikan pada kontainer atau satu set kontainer dijamin akan tersedia di semua wilayah.

Optimalkan dengan pembatasan tarif permintaan Anda

Untuk beban kerja yang tidak sensitif terhadap latensi, Anda dapat menyediakan throughput lebih sedikit dan membiarkan aplikasi menangani pembatasan tarif ketika throughput aktual melebihi throughput yang disediakan. Server akan secara mandiri mengakhiri permintaan dengan RequestRateTooLarge (kode status HTTP 429) dan mengembalikan header x-ms-retry-after-ms yang menunjukkan jumlah waktu, dalam milidetik, bahwa pengguna harus menunggu sebelum mencoba permintaan kembali.

HTTP Status 429, 
 Status Line: RequestRateTooLarge 
 x-ms-retry-after-ms :100

Logika coba lagi di SDK

SDK asli (.NET/.NET Core, Java, Node.js, dan Python) secara implisit menangkap respons ini, menghormati header retry-after yang ditentukan server, dan mencoba kembali permintaan. Kecuali akun Anda diakses secara bersamaan oleh beberapa klien, coba lagi berikutnya akan berhasil.

Jika Anda memiliki lebih dari satu klien yang secara kumulatif beroperasi secara konsisten di atas tingkat permintaan, jumlah coba lagi default, yang saat ini diatur ke 9, mungkin tidak cukup. Dalam kasus seperti itu, klien melemparkan RequestRateTooLargeException dengan kode status 429 ke aplikasi. Jumlah coba lagi default dapat diubah dengan mengatur RetryOptions pada instans ConnectionPolicy. Secara default, RequestRateTooLargeException dengan kode status 429 dikembalikan setelah waktu tunggu kumulatif 30 detik jika permintaan terus beroperasi di atas tingkat permintaan. Hal ini terjadi meskipun jumlah percobaan ulang saat ini kurang dari jumlah percobaan ulang maksimal, baik itu default 9 atau nilai yang ditentukan pengguna.

MaxRetryAttemptsOnThrottledRequests diatur ke 3, jadi dalam hal ini, jika operasi permintaan dibatasi dengan melebihi throughput cadangan kontainer, operasi permintaan mencoba kembali tiga kali sebelum melemparkan pengecualian ke aplikasi. MaxRetryWaitTimeInSeconds diatur ke 60, jadi dalam hal ini jika waktu tunggu coba kembali kumulatif dalam hitungan detik melebihi 60 detik karena permintaan pertama, pengecualian dilemparkan.

ConnectionPolicy connectionPolicy = new ConnectionPolicy(); 
connectionPolicy.RetryOptions.MaxRetryAttemptsOnThrottledRequests = 3; 
connectionPolicy.RetryOptions.MaxRetryWaitTimeInSeconds = 60;

Strategi pemartisian dan biaya throughput yang disediakan

Strategi partisi yang baik itu penting untuk mengoptimalkan biaya di Azure Cosmos DB. Pastikan bahwa tidak ada condong partisi, yang diekspos melalui metrik penyimpanan. Pastikan bahwa tidak ada condong throughput untuk partisi, yang diekspos dengan metrik throughput. Pastikan bahwa tidak ada condong terhadap kunci partisi tertentu. Kunci dominan dalam penyimpanan diekspos melalui metrik tetapi kuncinya tergantung pada pola akses aplikasi Anda. Sebaiknya pikirkan kunci partisi logis yang tepat. Kunci partisi yang baik diharapkan memiliki karakteristik berikut:

• Pilih kunci partisi yang menyebarkan beban kerja ke semua partisi dari waktu ke waktu secara merata. Dengan kata lain, Anda tidak boleh memiliki beberapa kunci dengan sebagian besar data dan beberapa kunci dengan sedikit atau tanpa data.

• Pilih kunci partisi yang memungkinkan pola akses tersebar secara merata di partisi logika. Beban kerjanya cukup merata di semua kunci. Dengan kata lain, sebagian besar beban kerja tidak boleh difokuskan pada beberapa kunci tertentu.

• Pilih kunci partisi yang memiliki rentang nilai lebar.

Intinya adalah menyebarkan data dan aktivitas kontainer di seluruh set partisi logis, sehingga sumber daya untuk penyimpanan dan throughput data dapat didistribusikan ke seluruh partisi logis. Kandidat untuk kunci partisi mungkin menyertakan properti yang sering muncul sebagai filter dalam kueri Anda. Kueri dapat dirutekan secara efisien dengan memasukkan kunci partisi dalam predikat filter. Dengan strategi partisi seperti itu, mengoptimalkan throughput yang disediakan jauh lebih mudah.

Rancang item lebih kecil untuk throughput lebih tinggi

Biaya permintaan atau biaya pemrosesan permintaan suatu operasi secara langsung berkorelasi dengan ukuran item. Operasi pada item besar lebih mahal daripada operasi pada item yang lebih kecil.

Pola akses data

Ini selalu merupakan praktik yang baik untuk memisahkan data Anda secara logis ke dalam kategori logis berdasarkan seberapa sering Anda mengakses data. Dengan mengategorikannya sebagai data panas, sedang, atau dingin, Anda dapat menyempurnakan konsumsi penyimpanan dan throughput yang diperlukan. Tergantung frekuensi akses, Anda dapat menempatkan data ke dalam kontainer terpisah (misalnya, tabel, grafik, dan koleksi) dan menyempurnakan throughput yang disediakan untuk mengakomodasi kebutuhan segmen data tersebut.

Selain itu, jika Anda menggunakan Azure Cosmos DB, dan Anda tahu bahwa Anda tidak akan mencari berdasarkan nilai data tertentu atau jarang akan mengaksesnya, Anda harus menyimpan nilai terkompresi dari atribut ini. Dengan metode ini Anda menghemat ruang penyimpanan, ruang indeks, dan throughput yang disediakan dan menghasilkan biaya lebih rendah.

Optimalkan dengan mengubah kebijakan pengindeksan

Secara default, Azure Cosmos DB secara otomatis mengindeks setiap properti dari setiap rekaman. Ini agar memudahkan pengembangan dan memastikan performa sangat baik di berbagai jenis kueri ad hoc. Jika Anda memiliki catatan besar dengan ribuan properti, membayar biaya throughput untuk mengindeks setiap properti mungkin tidak berguna, terutama jika Anda hanya meminta terhadap 10 atau 20 properti tersebut. Ketika Anda semakin dekat untuk menangani beban kerja spesifik, panduan kami adalah untuk menyetel kebijakan indeks Anda. Perincian lengkap tentang kebijakan pengindeksan Azure Cosmos DB dapat ditemukan di sini.

Memantau throughput yang disediakan dan dikonsumsi

Anda dapat memantau jumlah total unit permintaan yang disediakan, jumlah permintaan terbatas tarif, dan jumlah RU yang telah Anda gunakan dalam portal Azure. Untuk mempelajari selengkapnya, lihat Menganalisis metrik Azure Cosmos DB. Gambar berikut menunjukkan contoh metrik penggunaan:

Anda juga dapat mengatur peringatan untuk memeriksa apakah jumlah permintaan terbatas tarif melebihi ambang batas tertentu. Untuk mempelajari selengkapnya tentang pemberitahuan, lihat Pemberitahuan Azure Monitor.

Skalakan throughput Anda secara elastis dan sesuai permintaan

Karena Anda ditagih untuk throughput yang disediakan, mencocokkan throughput yang disediakan dengan kebutuhan Anda dapat membantu Anda menghindari biaya untuk throughput yang tidak digunakan. Anda dapat menskalakan throughput yang disediakan ke atas atau ke bawah kapan saja, sesuai kebutuhan. Jika kebutuhan throughput sangat mudah diprediksi, Anda dapat menggunakan Azure Functions dan Pemicu Timer untuk menambah atau mengurangi throughput sesuai jadwal.

• Memantau konsumsi RU Anda dan rasio permintaan terbatas tarif mungkin mengungkapkan bahwa Anda tidak perlu tetap disediakan sepanjang hari atau dalam seminggu. Anda mungkin menerima lebih sedikit lalu lintas di malam hari atau selama akhir pekan. Dengan menggunakan portal Microsoft Azure atau Azure Cosmos DB native SDK atau REST API, Anda dapat menskalakan throughput yang disediakan kapan saja. REST API Azure Cosmos DB menyediakan titik akhir untuk memperbarui tingkat performa kontainer Anda secara terprogram sehingga mudah untuk menyesuaikan throughput dari kode tergantung jam atau hari. Operasi dilakukan tanpa downtime, dan biasanya berlaku dalam waktu kurang dari satu menit.

• Salah satu area yang harus diskalakan throughputnya adalah ketika Anda menelan data ke Azure Cosmos DB, misalnya, selama migrasi data. Setelah menyelesaikan migrasi, Anda dapat menskalakan throughput yang disediakan untuk menangani steady state.

• Ingat, penagihan berada pada granularitas satu jam, sehingga Anda tidak menghemat uang jika Anda mengubah throughput yang disediakan lebih sering dari satu jam pada satu waktu.

Tentukan throughput yang diperlukan untuk beban kerja baru

Untuk menentukan throughput yang disediakan untuk beban kerja baru, Anda bisa menggunakan langkah-langkah berikut:

1. Lakukan evaluasi awal kasar menggunakan perencana kapasitas dan sesuaikan perkiraan Anda dengan bantuan Azure Cosmos DB Explorer di portal Microsoft Azure.

2. Disarankan untuk membuat kontainer dengan throughput lebih tinggi dari yang diharapkan lalu menurunkan skala sesuai kebutuhan.

3. Disarankan untuk menggunakan salah satu SDK asli Azure Cosmos DB untuk mendapatkan manfaat dari coba kembali otomatis ketika permintaan dibatasi tarif. Jika Anda mengerjakan platform yang tidak didukung dan menggunakan REST API Azure Cosmos DB, terapkan kebijakan coba lagi Anda sendiri menggunakan x-ms-retry-after-ms header .

4. Pastikan bahwa kode aplikasi Anda dengan anggun mendukung kasus ini ketika semua coba lagi gagal.

5. Anda dapat mengonfigurasi peringatan dari portal Microsoft Azure untuk mendapatkan pemberitahuan pembatasan tarif. Anda dapat memulai dengan batas konservatif seperti 10 permintaan terbatas tarif selama 15 menit terakhir dan beralih ke aturan yang lebih luas setelah Anda mengetahui konsumsi aktual. Pembatasan tarif yang jarang itu tidak apa-apa, karena menunjukkan bahwa Anda bermain dengan batas yang telah ditetapkan dan itulah yang ingin Anda lakukan.

6. Gunakan pemantauan untuk memahami pola lalu lintas, sehingga Anda dapat mempertimbangkan perlunya menyesuaikan penyediaan throughput Anda secara dinamis selama sehari atau seminggu.

7. Pantau rasio throughput yang disediakan vs. digunakan secara teratur untuk memastikan Anda belum menyediakan lebih dari jumlah kontainer dan database yang diperlukan. Agar aman, sebaiknya Anda memiliki lebih sedikit throughput yang disediakan.

Praktik terbaik untuk mengoptimalkan throughput yang disediakan

Langkah-langkah berikut ini membuat solusi Anda sangat terukur dan hemat biaya saat menggunakan Azure Cosmos DB.

1. Jika Anda memiliki throughput yang terlalu disediakan di seluruh kontainer dan database, Anda harus meninjau RUs yang disediakan Vs RUs yang dikonsumsi dan menyempurnakan beban kerja.

2. Salah satu metode untuk memperkirakan jumlah throughput yang dipesan yang diperlukan oleh aplikasi Anda adalah merekam biaya RU unit permintaan yang terkait dengan menjalankan operasi khas terhadap kontainer atau database Azure Cosmos DB yang representatif yang digunakan oleh aplikasi Anda dan kemudian memperkirakan jumlah operasi yang Anda antisipasi melakukan setiap detik. Pastikan untuk mengukur dan menyertakan kueri biasa dan penggunaannya juga. Untuk mempelajari cara memperkirakan biaya RU kueri secara terprogram atau menggunakan portal lihat Mengoptimalkan biaya kueri.

3. Cara lain untuk mendapatkan operasi dan biaya RUs adalah dengan mengaktifkan log Azure Monitor, yang akan memberi Anda rincian operasi/durasi dan biaya permintaan. Azure Cosmos DB menyediakan biaya permintaan untuk setiap operasi, sehingga setiap biaya operasi dapat disimpan kembali dari respons lalu digunakan untuk analisis.

4. Anda dapat secara elastis menskalakan throughput yang disediakan ke atas dan ke bawah karena Anda perlu mengakomodasi kebutuhan beban kerja.

5. Anda dapat menambahkan dan menghapus wilayah yang terkait dengan akun Azure Cosmos DB sesuai kebutuhan dan biaya kontrol Anda.

6. Pastikan Anda memiliki distribusi data dan beban kerja di seluruh partisi logis kontainer. Jika Anda memiliki distribusi partisi yang tidak merata, ini dapat menyebabkan penyediaan jumlah throughput yang lebih tinggi daripada nilai yang diperlukan. Jika Anda mengetahui distribusi condong, kami sarankan untuk mendistribusikan ulang beban kerja secara merata di seluruh partisi atau mempartisi ulang data.

7. Jika Anda memiliki banyak kontainer dan kontainer ini tidak memerlukan SLA, Anda dapat menggunakan penawaran berbasis database untuk kasus di mana SLA throughput per kontainer tidak berlaku. Anda harus mengidentifikasi kontainer Azure Cosmos DB mana yang ingin Anda migrasikan ke penawaran throughput tingkat database lalu memigrasikannya dengan menggunakan solusi berbasis umpan perubahan.

8. Pertimbangkan untuk menggunakan "Tingkat Gratis Azure Cosmos DB" (gratis selama satu tahun), Coba Azure Cosmos DB (hingga tiga wilayah) atau emulator Azure Cosmos DB yang dapat diunduh untuk skenario dev/test. Dengan menggunakan opsi ini untuk test-dev, Anda dapat menurunkan biaya secara substansial.

9. Anda selanjutnya dapat melakukan pengoptimalan biaya khusus beban kerja – misalnya, meningkatkan ukuran batch, pembacaan load-balancing di beberapa wilayah, dan de-duplicating data, jika berlaku.

10. Dengan kapasitas cadangan Azure Cosmos DB, Anda bisa mendapat diskon signifikan hingga 65% selama tiga tahun. Model kapasitas cadangan Azure Cosmos DB merupakan komitmen di muka pada unit permintaan yang diperlukan seiring waktu. Diskonnya berjenjang sehingga semakin banyak unit permintaan yang Anda gunakan selama periode lama, semakin banyak diskonnya. Diskon ini langsung diterapkan. Setiap RUs yang digunakan di atas nilai yang Anda cantumkan dibebankan berdasarkan biaya kapasitas yang tidak dipesan. Lihat Kapasitas cadangan Azure Cosmos DB) untuk detail selengkapnya. Pertimbangkan untuk membeli kapasitas cadangan agar lebih menurunkan biaya throughput yang Anda urus.

Langkah berikutnya

Berikutnya, Anda dapat lanjut mempelajari pengoptimalan biaya di Microsoft Azure Cosmos DB dengan artikel berikut:

• 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
• Pelajari selengkapnya tentang Mengoptimalkan pengembangan dan pengujian
• Pelajari selengkapnya tentang Memahami tagihan Microsoft Azure Cosmos DB Anda
• Pelajari selengkapnya tentang Mengoptimalkan biaya penyimpanan
• Pelajari selengkapnya tentang Mengoptimalkan biaya baca dan tulis
• Pelajari selengkapnya tentang Mengoptimalkan biaya kueri
• Pelajari selengkapnya tentang Mengoptimalkan biaya akun Azure Cosmos DB multi-wilayah