Unit Permintaan di Azure Cosmos DB

  • Artikel

BERLAKU UNTUK: Nosql MongoDB Cassandra Gremlin Meja

Azure Cosmos DB mendukung banyak API, seperti SQL, MongoDB, Cassandra, Gremlin, dan Table. Setiap API memiliki set operasi database sendiri. Operasi ini berkisar dari titik baca dan tulis sederhana hingga kueri yang kompleks. Setiap operasi database menggunakan sumber daya sistem berdasarkan kompleksitas operasi.

Azure Cosmos DB menormalkan biaya semua operasi database menggunakan Unit Permintaan (atau RU, singkatnya) dan mengukur biaya berdasarkan throughput (Unit Permintaan per detik, RU/dtk).

Unit permintaan adalah performa mata uang yang saat ini mengabstraksi sumber daya sistem seperti CPU, IOPS, dan memori yang diperlukan untuk melakukan operasi database yang didukung oleh Azure Cosmos DB. Apakah operasi database adalah tulis, baca titik, atau kueri, operasi selalu diukur dalam RU. Misalnya, titik baca (mengambil satu item dengan ID dan nilai kunci partisinya) untuk item 1 KB adalah satu Unit Permintaan (atau satu RU), tidak peduli API mana yang Anda gunakan untuk berinteraksi dengan kontainer Azure Cosmos DB Anda. Anda dapat memodelkan biaya throughput menggunakan Kalkulator Kapasitas Azure Cosmos DB.

Citra berikut menunjukkan ide RU tingkat tinggi:

Database operations consume Request Units

Untuk mengelola dan merencanakan kapasitas, Azure Cosmos DB memastikan bahwa jumlah RU untuk operasi database tertentu melalui set data tertentu adalah deterministik. Anda dapat memeriksa header respons untuk melacak jumlah RU yang digunakan oleh operasi database apa pun. Jika Anda memahami faktor yang memengaruhi biaya RU dan persyaratan throughput aplikasi, Anda dapat menjalankan aplikasi yang hemat biaya.

Jenis akun Azure Cosmos DB yang Anda gunakan menentukan cara RU yang digunakan ditagih. Ada tiga mode di mana Anda dapat membuat akun:

  1. Mode throughput yang disediakan: Dalam mode ini, Anda menetapkan jumlah RU untuk aplikasi Anda secara per detik dengan kenaikan 100 RU per detik. Untuk menskalakan throughput yang tersedia untuk aplikasi, Anda dapat menambah atau mengurangi jumlah RU kapan saja dalam penaikan atau penurunan 100 RU. Anda dapat membuat perubahan baik secara terprogram atau dengan menggunakan portal Microsoft Azure. Anda akan ditagih per jam untuk jumlah RU per detik yang telah Anda sediakan. Untuk mempelajari selengkapnya, lihat artikel Throughput yang ditentukan.

    Anda dapat menetapkan throughput pada dua granularitas yang berbeda:

  2. Mode tanpa server: Dalam mode ini, Anda tidak perlu menetapkan throughput apa pun saat membuat sumber daya di akun Azure Cosmos DB Anda. Di akhir periode penagihan, Anda akan ditagih sejumlah Unit Permintaan yang digunakan oleh operasi database Anda. Untuk mempelajari selengkapnya, lihat artikel Throughput tanpa server.

  3. Mode Autoscale: Dalam mode ini, Anda dapat secara otomatis dan instan menskalakan throughput (RU/dtk) database atau kontainer Anda berdasarkan penggunaannya. Operasi penskalaan ini tidak memengaruhi ketersediaan, latensi, throughput, atau performa beban kerja. Mode ini sangat cocok untuk beban kerja misi-kritis yang memiliki pola lalu lintas variabel atau tidak dapat diprediksi, dan memerlukan SLA pada performa dan skala tinggi. Untuk mempelajari selengkapnya, lihat artikel throughput skala otomatis.

Pertimbangan Unit Permintaan

Meskipun Anda memperkirakan jumlah RU yang digunakan oleh beban kerja Anda, pertimbangkan faktor-faktor berikut:

  • Ukuran item: Seiring bertambahnya ukuran item, jumlah RUs yang digunakan untuk membaca atau menulis item juga meningkat.

  • Pengindeksan item: Secara default, setiap item secara otomatis diindeks. Lebih sedikit RUs yang dikonsumsi jika Anda memilih untuk tidak mengindeks beberapa item Anda dalam kontainer.

  • Jumlah properti item: Dengan asumsi pengindeksan default ada di semua properti, jumlah RUs yang digunakan untuk menulis item meningkat saat jumlah properti item meningkat.

  • Properti terindeks: Kebijakan indeks pada setiap kontainer menentukan properti mana yang terindeks secara default. Untuk mengurangi konsumsi RU untuk operasi menulis, batasi jumlah properti terindeks.

  • Konsistensi data: Tingkat konsistensi kedaluwarsa yang kuat dan terikat menggunakan sekitar dua kali lebih banyak RU saat melakukan operasi baca jika dibandingkan dengan tingkat konsistensi santai lainnya.

  • Jenis bacaan: Titik baca membutuhkan biaya lebih sedikit RU daripada kueri.

  • Pola kueri: Kompleksitas sebuah kueri memengaruhi jumlah RUs yang digunakan pada sebuah operasi. Faktor-faktor yang mempengaruhi biaya operasi kueri meliputi:

    • Jumlah hasil kueri
    • Jumlah predikat
    • Sifat predikat
    • Jumlah fungsi yang ditentukan pengguna
    • Ukuran data sumber
    • Ukuran kumpulan hasil
    • Proyeksi

    Kueri yang sama pada data yang sama selalu dikenakan biaya jumlah RU yang sama pada eksekusi berulang.

  • Penggunaan skrip: Seperti halnya kueri, prosedur yang disimpan, dan pemicu menggunakan RU didasarkan pada kompleksitas operasi yang dilakukan. Saat Anda mengembangkan aplikasi, periksa header biaya permintaan untuk lebih memahami berapa banyak kapasitas RU yang dikonsumsi setiap operasi.

Unit permintaan dan beberapa wilayah

Jika Anda menetapkan RU 'R' pada kontainer Azure Cosmos DB (atau database), Azure Cosmos DB memastikan bahwa RU 'R' tersedia di setiap wilayah yang terkait dengan akun Azure Cosmos DB Anda. Anda tidak dapat secara selektif menetapkan RU ke wilayah tertentu. RU yang disediakan pada kontainer Azure Cosmos DB (atau database) disediakan di semua wilayah yang terkait dengan akun Azure Cosmos DB Anda.

Dengan asumsi bahwa kontainer Azure Cosmos DB dikonfigurasi dengan RU 'R' dan ada wilayah 'N' yang terkait dengan akun Azure Cosmos DB, total RU yang tersedia secara global pada kontainer = R x N.

Pilihan model konsistensi Anda juga memengaruhi throughput. Anda dapat memperoleh sekitar 2x throughput baca untuk tingkat konsistensi yang lebih santai (sesi, prefiks konsisten dan konsistensi peristiwa) dibandingkan dengan tingkat konsistensi yang lebih kuat (misalnya, kedaluwarsa terikat atau konsistensi kuat).

Langkah berikutnya