Mengoptimalkan biaya permintaan di Azure Cosmos DB

BERLAKU UNTUK: Nosql MongoDB Cassandra Gremlin Meja

Artikel ini menjelaskan bagaimana permintaan baca dan tulis diterjemahkan ke dalam Unit Permintaan dan cara mengoptimalkan biaya permintaan ini. Operasi baca mencakup bacaan titik dan kueri. Operasi tulis termasuk menyisipkan, mengganti, menghapus, dan menambah-sisipkan item.

Azure Cosmos DB menawarkan serangkaian operasi database yang kaya yang beroperasi pada item dalam kontainer. Biaya yang terkait dengan masing-masing operasi ini bervariasi berdasarkan CPU, IO, dan memori yang diperlukan untuk menyelesaikan operasi. Alih-alih memikirkan dan mengelola sumber daya perangkat keras, Anda dapat menganggap permintaan unit (RU) sebagai ukuran tunggal untuk sumber daya yang diperlukan untuk melakukan berbagai operasi database guna melayani permintaan.

Mengukur biaya RU atas permintaan

Penting untuk mengukur biaya RU atas permintaan Anda untuk memahami biaya aktual mereka dan juga mengevaluasi efektivitas pengoptimalan Anda. Anda dapat mengambil biaya ini dengan menggunakan portal Microsoft Azure atau memeriksa respons yang dikirim kembali dari Azure Cosmos DB melalui salah satu SDK. Lihat Menemukan biaya unit permintaan di Azure Cosmos DB untuk instruksi terperinci tentang cara mengetahuinya.

Membaca data: titik membaca dan kueri

Operasi baca di Azure Cosmos DB biasanya diurutkan dari yang tercepat/paling efisien hingga lebih lambat/kurang efisien dalam hal konsumsi RU sebagai berikut:

  • Poin terbaca (pencarian kunci / nilai pada satu ID item dan kunci partisi).
  • Kueri dengan klausul filter pada satu kunci partisi.
  • Kueri tanpa klausul filter persamaan atau rentang pada properti apa pun.
  • Kueri tanpa filter.

Peran tingkat konsistensi

Saat menggunakan tingkat konsistensikejenuhan terikat atau kuat, maka biaya RU dari setiap operasi baca (pembacaan titik atau kueri) akan digandakan.

Baca titik

Satu-satunya faktor yang mempengaruhi tagihan RU dari baca titik (selain tingkat konsistensi yang digunakan) adalah ukuran item yang diambil. Tabel berikut menunjukkan biaya RU baca titik untuk item yang berukuran 1 KB dan 100 KB.

Ukuran item Biaya satu baca titik
1 KB 1 RU
100 KB 10 RU

Karena pembacaan titik (pencarian kunci/nilai pada ID item dan kunci partisi) adalah jenis baca yang paling efisien, Anda harus memastikan ID item Anda memiliki nilai yang bermakna sehingga Anda dapat mengambil item Anda dengan titik baca (bukan kueri) jika memungkinkan.

Catatan

Dalam API untuk NoSQL, pembacaan titik hanya dapat dilakukan menggunakan REST API atau SDK. Kueri yang memfilter ID satu item dan kunci partisi tidak dianggap sebagai titik baca. Untuk melihat contoh menggunakan .NET SDK, lihat membaca item di Azure Cosmos DB untuk NoSQL.

Kueri

Unit permintaan untuk kueri tergantung pada sejumlah faktor. Misalnya, jumlah item Azure Cosmos DB yang dimuat/dikembalikan, jumlah pencarian terhadap indeks, waktu kompilasi kueri, dll. Rincian. Azure Cosmos DB menjamin bahwa kueri yang sama ketika dijalankan pada data yang sama akan selalu menggunakan jumlah unit permintaan yang sama bahkan dengan eksekusi berulang. Profil kueri menggunakan metrik eksekusi kueri memberi Anda gambaran yang jelas tentang bagaimana unit permintaan digunakan.

Dalam beberapa kasus Anda mungkin melihat urutan respons 200 dan 429, dan unit permintaan variabel dalam eksekusi kueri per halaman, hal itu karena kueri akan berjalan secepat mungkin berdasarkan RUs yang tersedia. Anda mungkin melihat eksekusi kueri terpecah ke dalam beberapa halaman/alur bolak-balik antara server dan klien. Misalnya, 10.000 item bisa dilaporkan dalam beberapa halaman, masing-masing ditagih berdasarkan perhitungan pada tiap halaman tersebut. Ketika Anda menjumlahkan seluruh halaman ini, seharusnya Anda memperoleh jumlah RUS yang sama seperti yang akan Anda dapatkan dari seluruh kueri.

Metrik untuk kueri pemecahan masalah

Kinerja dan throughput yang dikonsumsi oleh kueri (termasuk fungsi yang ditentukan pengguna) sebagian besar tergantung pada badan fungsi. Cara termudah untuk mengetahui berapa banyak waktu yang dihabiskan eksekusi kueri di UDF dan jumlah RUs yang digunakan, adalah dengan mengaktifkan metrik kueri. Jika Anda menggunakan .NET SDK, berikut adalah contoh metrik kueri yang dilaporkan oleh SDK:

Retrieved Document Count                 :               1              
Retrieved Document Size                  :           9,963 bytes        
Output Document Count                    :               1              
Output Document Size                     :          10,012 bytes        
Index Utilization                        :          100.00 %            
Total Query Execution Time               :            0.48 milliseconds 
  Query Preparation Times 
    Query Compilation Time               :            0.07 milliseconds 
    Logical Plan Build Time              :            0.03 milliseconds 
    Physical Plan Build Time             :            0.05 milliseconds 
    Query Optimization Time              :            0.00 milliseconds 
  Index Lookup Time                      :            0.06 milliseconds 
  Document Load Time                     :            0.03 milliseconds 
  Runtime Execution Times 
    Query Engine Execution Time          :            0.03 milliseconds 
    System Function Execution Time       :            0.00 milliseconds 
    User-defined Function Execution Time :            0.00 milliseconds 
  Document Write Time                    :            0.00 milliseconds 
  Client Side Metrics 
    Retry Count                          :               1              
    Request Charge                       :            3.19 RUs  

Praktik terbaik untuk mengoptimalkan biaya kueri

Pertimbangkan praktik terbaik berikut saat mengoptimalkan kueri atas biaya:

  • Mengumpulkan beberapa jenis entitas

    Cobalah untuk menempatkan bersama-sama beberapa jenis entitas dalam jumlah kontainer tunggal atau lebih kecil. Metode ini menghasilkan manfaat tidak hanya dari perspektif harga, tetapi juga untuk eksekusi dan transaksi kueri. Kueri ditempatkan ke satu kontainer tunggal; dan transaksi atom atas beberapa rekaman melalui prosedur/pemicu yang tersimpan ditempatkan ke satu kunci partisi dalam satu kontainer tunggal. Mengumpulkan entitas dalam kontainer yang sama dapat mengurangi jumlah perjalanan pulang pergi jaringan untuk menyelesaikan relasi antar rekaman. Sehingga meningkatkan kinerja end-to-end, memungkinkan transaksi atom atas beberapa rekaman untuk set data yang lebih besar, dan dengan demikian menurunkan biaya. Jika mengumpulkan beberapa jenis entitas dalam satu kontainer tunggal atau jumlah yang sedikit sulit untuk skenario Anda, biasanya karena Anda harus memigrasikan aplikasi yang ada dan tidak ingin membuat perubahan kode apa pun - maka Anda mungkin perlu mempertimbangkan penyediaan throughput di tingkat database.

  • Mengukur dan menyetel untuk unit permintaan yang lebih rendah/penggunaan kedua

    Kompleksitas kueri memengaruhi berapa banyak unit permintaan (RU) yang dikonsumsi untuk suatu operasi. Jumlah predikat, sifat predikat, jumlah UDF, dan ukuran kumpulan data sumber. Semua faktor ini memengaruhi biaya operasi kueri.

Azure Cosmos DB memberikan kinerja yang dapat diprediksi dalam hal throughput dan latensi dengan menggunakan model throughput yang disediakan. Throughput yang disediakan diwujudkan dalam bentukUnit Permintaan per detik, atau RU/s. Unit Permintaan (RU) adalah abstraksi logis melalui sumber daya komputasi seperti CPU, memori, IO, dll yang diperlukan untuk melakukan permintaan. Throughput sediaan (RUs) disisihkan dan didedikasikan untuk kontainer atau database Anda untuk memberikan throughput dan latensi yang dapat diprediksi. Throughput yang disediakan memungkinkan Azure Cosmos DB untuk memberikan kinerja yang dapat diprediksi dan konsisten, latensi rendah yang dijamin, dan ketersediaan tinggi dalam skala apa pun. Unit permintaan mewakili mata uang yang dinormalkan yang menyederhanakan penalaran tentang berapa banyak sumber daya yang dibutuhkan aplikasi.

Biaya permintaan yang disampaikan di header permintaan menunjukkan biaya kueri yang diberikan. Misalnya, jika kueri mengembalikan 1000 item 1-KB, biaya operasi adalah 1000. Dengan demikian, dalam satu detik server hanya menerima dua permintaan seperti itu sebelum membatasi tarif permintaan selanjutnya. Untuk informasi lebih lanjut, lihat artikel unit permintaan dan kalkulator unit permintaan.

Data tulis

Biaya RU menulis item tergantung pada:

Menyisipkan item 1 KB tanpa mengindeks biaya sekitar ~ 5.5 RUs. Mengganti biaya item dua kali pengisian daya yang diperlukan untuk memasukkan item yang sama.

Mengoptimalkan penulisan

Cara terbaik untuk mengoptimalkan biaya operasi penulisan RU adalah dengan mengubah ukuran item Anda dan jumlah properti yang terindeks.

  • Menyimpan item yang sangat besar di Azure Cosmos DB menghasilkan biaya RU yang tinggi dan dapat dianggap sebagai anti-pola. Secara khusus, jangan simpan konten biner atau potongan teks besar yang tidak perlu Anda kueri. Praktik terbaik adalah menempatkan data semacam ini di Azure Blob Storage dan menyimpan referensi (atau tautan) ke blob dalam item yang Anda tulis ke Azure Cosmos DB.
  • Mengoptimalkan kebijakan pengindeksan Anda hanya untuk mengindeks properti yang filter kuerinya dapat membuat perbedaan besar dalam RUs yang digunakan oleh operasi menulis Anda. Saat membuat kontainer baru, kebijakan pengindeksan default mengindeks masing-masing dan tiap properti yang ditemukan dalam item Anda. Meskipun ini adalah default yang baik untuk kegiatan pengembangan, sangat disarankan untuk mengevaluasi kembali dan menyesuaikan kebijakan pengindeksan Anda saat akan memulai produksi atau ketika beban kerja Anda mulai menerima lalu lintas yang signifikan.

Saat melakukan konsumsi data secara massal, disarankan juga untuk menggunakan pustaka pelaksana massal Azure Cosmos DB karena dirancang untuk mengoptimalkan konsumsi RU dari operasi tersebut. Secara opsional, Anda juga dapat menggunakan Azure Data Factory yang dibangun di perpustakaan yang sama.

Langkah berikutnya

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