Optimalkan biaya throughput yang disediakan di Azure Cosmos DB

  • Artikel

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/s dan menerbitkan kueri seharga 40 RUs, Anda akan dapat mengeluarkan 10 kueri tersebut per detik. Setiap permintaan di luar itu akan mendapatkan tarif terbatas dan Anda harus mencoba kembali permintaannya. 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 memigrasi dari database penyewa tunggal yang dirancang untuk berjalan pada VM yang di-hosting IaaS atau lokal, misalnya, NoSQL atau database relasional ke Azure Cosmos DB. Dan jika Anda memiliki banyak koleksi/tabel/grafik dan tidak ingin membuat perubahan apa pun pada model data Anda. Catatan, Anda mungkin membahayakan beberapa manfaat yang ditawarkan Azure Cosmos DB jika tidak memperbarui model data saat melakukan migrasi 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 agnostik skema, kontainer dapat berisi item yang memiliki skema heterogen dan tidak mengharuskan pelanggan untuk membuat beberapa jenis kontainer, satu untuk setiap entitas. Selalu pertimbangkan apakah pengelompokan terpisah masuk akal, misal 10-20 kontainer ke dalam satu kontainer. 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 dapat 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 Graph
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. Ini terjadi bahkan ketika jumlah coba lagi saat ini kurang dari jumlah coba lagi maksimum, 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 pembuatan partisi 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 ke arah tombol partisi tertentu. Kunci dominan dalam penyimpanan diekspos melalui metrik tetapi kuncinya akan 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 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 akan 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 akan dikenakan biaya lebih dibanding operasi pada item yang lebih kecil.

Pola akses data

Sebaiknya pisahkan data Anda 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 menggunakan Azure Cosmos DB, dan tahu bahwa Anda tidak akan mencari berdasarkan nilai data tertentu atau jarang 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 rekaman besar dengan ribuan properti, membayar biaya throughput untuk mengindeks setiap properti mungkin tidak berguna, terutama jika Anda hanya mengueri 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 RUs yang disediakan, jumlah permintaan terbatas tarif serta jumlah RUs yang telah Anda konsumsi di portal Microsoft Azure. Gambar berikut menunjukkan contoh metrik penggunaan:

Memantau unit permintaan di portal Microsoft Azure

Anda juga dapat mengatur peringatan untuk memeriksa apakah jumlah permintaan terbatas tarif melebihi ambang batas tertentu. Lihat artikel Cara memantau Azure Cosmos DB untuk detail selengkapnya. Peringatan ini dapat mengirim email ke administrator akun atau memanggil Webhook HTTP kustom atau Azure Function untuk meningkatkan throughput yang disediakan secara otomatis.

Skalakan throughput Anda secara elastis dan sesuai permintaan

Karena ditagih untuk throughput yang disediakan, mencocokkan throughput yang disediakan dengan kebutuhan 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 RUs dan rasio permintaan terbatas tarif dapat mengungkapkan bahwa Anda tidak perlu terus menyediakan secara konstan setiap hari atau minggu. 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, Anda ditagih per jam, sehingga tidak akan hemat jika Anda mengubah throughput yang disediakan lebih sering dari satu jam.

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 bekerja pada 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. yang dikonsumsi 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 umum terhadap kontainer atau database Azure Cosmos DB perwakilan yang digunakan oleh aplikasi Anda dan kemudian memperkirakan jumlah operasi yang Anda antisipasi untuk dilakukan 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.

  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 memiliki banyak kontainer dan kontainer ini tidak memerlukan SLA, Anda dapat menggunakan penawaran berbasis database ketika 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: