Tips performa untuk Azure Cosmos DB Sinkronisasi Java SDK v2

BERLAKU UNTUK: API SQL

Penting

Ini bukan Java SDK terbaru untuk Azure Cosmos DB! Anda harus meningkatkan proyek ke Azure Cosmos DB Java SDK v4 lalu membaca panduan tips performa Azure Cosmos DB Java SDK v4. Ikuti petunjuk dalam panduan Migrasi ke Azure Cosmos DB Java SDK v4 dan peningkatan Reactor vs RxJava.

Tips performa dalam artikel ini hanya untuk Azure Cosmos DB Async Java SDK v2. Lihat Catatan rilis Azure Cosmos DB Async Java SDK v2, repositori Maven, dan panduan pemecahan masalah Azure Cosmos DB Async Java SDK v2 untuk informasi selengkapnya.

Penting

Pada tanggal 31 Agustus 2024 Azure Cosmos DB Async Java SDK v2.x akan pensiun; SDK dan semua aplikasi yang menggunakan SDK akan terus berfungsi; Azure Cosmos DB hanya akan berhenti memberikan pemeliharaan dan dukungan lebih lanjut untuk SDK ini. Sebaiknya ikuti petunjuk di atas untuk bermigrasi ke Azure Cosmos DB Java SDK v4.

Azure Cosmos DB adalah database terdistribusi yang cepat dan fleksibel yang menskalakan secara mulus dengan latensi dan throughput terjamin. Anda tidak perlu membuat perubahan arsitektur besar atau menulis kode kompleks untuk menskalakan database dengan Azure Cosmos DB. Penskalaan naik dan turun semudah melakukan satu panggilan API atau panggilan metode SDK. Namun, karena Azure Cosmos DB diakses melalui panggilan jaringan, maka terdapat pengoptimalan sisi klien yang dapat Anda lakukan untuk mencapai performa puncak saat menggunakan Azure Cosmos DB Async Java SDK v2.

Jadi, jika Anda bertanya "Bagaimana cara meningkatkan performa database saya?" pertimbangkan opsi berikut:

Jaringan

  • Mode koneksi: Menggunakan mode langsung

    Cara klien terhubung ke Azure Cosmos DB memiliki implikasi performa penting, khususnya mengenai latensi sisi klien. ConnectionMode adalah pengaturan konfigurasi utama yang tersedia untuk mengonfigurasikan ConnectionPolicy klien. Untuk Azure Cosmos DB Async Java SDK v2, dua ConnectionModes yang tersedia adalah:

    Mode gateway didukung di semua platform SDK dan merupakan opsi yang dikonfigurasi secara default. Jika aplikasi Anda berjalan dalam jaringan perusahaan dengan pembatasan firewall ketat, mode Gateway adalah pilihan terbaik karena menggunakan port HTTPS standar dan satu titik akhir DNS. Namun, tradeoff performanya adalah mode gateway melibatkan hop jaringan tambahan setiap kali data dibaca atau ditulis dari atau ke Azure Cosmos DB. Karena itu, mode Direct menawarkan performa yang lebih baik karena lebih sedikit hop jaringan.

    ConnectionMode dikonfigurasikan selama konstruksi instans DocumentClient dengan parameter ConnectionPolicy.

Async Java SDK V2 (Maven com.microsoft.azure::azure-cosmosdb)

    public ConnectionPolicy getConnectionPolicy() {
        ConnectionPolicy policy = new ConnectionPolicy();
        policy.setConnectionMode(ConnectionMode.Direct);
        policy.setMaxPoolSize(1000);
        return policy;
    }

    ConnectionPolicy connectionPolicy = new ConnectionPolicy();
    DocumentClient client = new DocumentClient(HOST, MASTER_KEY, connectionPolicy, null);
  • Mengkolokasikan klien di wilayah Azure yang sama untuk performa

    Jika memungkinkan, tempatkan aplikasi apa pun yang memanggil Azure Cosmos DB di wilayah yang sama dengan database Azure Cosmos DB. Untuk perbandingan perkiraan, panggilan ke Azure Cosmos DB dalam wilayah yang sama selesai dalam 1-2 ms, tetapi latensi antara pantai Barat dan Timur AS >50 ms. Latensi ini dapat bervariasi dari permintaan ke permintaan tergantung pada rute yang diambil oleh permintaan saat melewati dari klien ke batas pusat data Azure. Latensi serendah mungkin dicapai dengan memastikan aplikasi panggilan berada di wilayah Azure yang sama dengan titik akhir Azure Cosmos DB yang tersedia. Untuk daftar wilayah yang tersedia, lihat Wilayah Azure.

    Ilustrasi kebijakan koneksi Azure Cosmos DB

Penggunaan SDK

  • Menginstal SDK terbaru

    Azure Cosmos DB SDK terus ditingkatkan untuk memberikan performa terbaik. Lihat halaman Catatan Rilis Azure Cosmos DB Async Java SDK v2 untuk menentukan SDK terbaru dan meninjau peningkatan.

  • Gunakan klien database tunggal Azure Cosmos DB selama masa pakai aplikasi Anda

    Setiap instans AsyncDocumentClient merupakan utas yang aman dan melakukan manajemen koneksi serta penembolokan alamat yang efisien. Untuk memungkinkan manajemen koneksi yang efisien dan performa yang lebih baik oleh AsyncDocumentClient, disarankan untuk menggunakan satu instans AsyncDocumentClient per AppDomain untuk masa pakai aplikasi.

  • Menyesuaikan ConnectionPolicy

    Secara default, permintaan Cosmos DB mode langsung dibuat melalui TCP saat menggunakan Azure Cosmos DB Async Java SDK v2. Secara internal SDK menggunakan arsitektur mode Direct khusus untuk mengelola sumber daya jaringan secara dinamis dan mendapatkan performa terbaik.

    Dalam Azure Cosmos DB Async Java SDK v2, mode Direct adalah pilihan terbaik untuk meningkatkan performa database dengan sebagian besar beban kerja.

    • Gambaran umum mode Direct

    Ilustrasi arsitektur mode Direct

    Arsitektur sisi klien yang digunakan dalam mode Direct memungkinkan pemanfaatan jaringan yang dapat diprediksi dan akses multipleks ke replika Azure Cosmos DB. Diagram di atas menunjukkan bagaimana mode Direct merutekan permintaan klien ke replika di backend Cosmos DB. Arsitektur Mode langsung mengalokasikan hingga 10 Saluran di sisi klien per replika DB. Saluran adalah koneksi TCP yang didahului oleh buffer permintaan, yang merupakan 30 permintaan dalam. Saluran milik replika dialokasikan secara dinamis sesuai kebutuhan oleh Endpoint Layanan replika. Ketika pengguna mengeluarkan permintaan dalam mode Langsung, TransportClient merutekan permintaan ke titik akhir layanan yang tepat berdasarkan kunci partisi. Permintaan Antrian buffer permintaan sebelum Titik Akhir Layanan.

    • Opsi Konfigurasi ConnectionPolicy untuk mode Direct

      Sebagai langkah pertama, gunakan pengaturan konfigurasi yang direkomendasikan berikut ini di bawah ini. Silakan hubungi tim Azure Cosmos DB jika Anda mengalami masalah pada topik khusus ini.

      Jika Anda menggunakan Azure Cosmos DB sebagai database referensi (artinya, database digunakan untuk banyak operasi baca titik dan beberapa operasi penulisan), mungkin dapat diterima untuk mengatur idleEndpointTimeout ke 0 (artinya, tidak ada waktu habis).

      Opsi konfigurasi Default
      bufferPageSize 8192
      connectionTimeout "PT1M"
      idleChannelTimeout "PT0S"
      idleEndpointTimeout "PT1M10S"
      maxBufferCapacity 8388608
      maxChannelsPerEndpoint 10
      maxRequestsPerChannel 30
      receiveHangDetectionTime "PT1M5S"
      requestExpiryInterval "PT5S"
      requestTimeout "PT1M"
      requestTimerResolution "PT0.5S"
      sendHangDetectionTime "PT10S"
      shutdownTimeout "PT15S"
  • Tips pemrograman untuk mode Direct

    Tinjau artikel Pemecahan Masalah Azure Cosmos DB Async Java SDK v2 sebagai garis dasar untuk menyelesaikan masalah SDK apa pun.

    Beberapa tips pemrograman penting saat menggunakan mode Direct:

    • Gunakan multithreading di aplikasi Anda untuk transfer data TCP yang efisien - Setelah membuat permintaan, aplikasi Anda harus berlangganan untuk menerima data di utas lain. Tidak melakukannya memaksa operasi "setengah dupleks" yang tidak diinginkan dan permintaan berikutnya diblokir menunggu balasan permintaan sebelumnya.

    • Lakukan beban kerja intensif komputasi pada benang khusus - Untuk alasan yang sama dengan tip sebelumnya, operasi seperti pemrosesan data yang kompleks paling baik ditempatkan di utas terpisah. Permintaan yang menarik data dari penyimpanan data lain (misalnya jika utas menggunakan penyimpanan data Azure Cosmos DB dan Spark secara bersamaan) mungkin mengalami peningkatan latensi dan disarankan untuk menelurkan utas tambahan yang menunggu respons dari penyimpanan data lainnya.

    • Pemodelan data - Azure Cosmos DB SLA mengasumsikan ukuran dokumen kurang dari 1 KB. Mengoptimalkan model data dan pemrograman Anda untuk mendukung ukuran dokumen yang lebih kecil umumnya akan menyebabkan penurunan latensi. Jika Anda memerlukan penyimpanan dan pengambilan dokumen yang lebih besar dari 1 KB, pendekatan yang disarankan adalah agar dokumen ditautkan ke data di Azure Blob Storage.

  • Menyesuaikan kueri paralel untuk kumpulan yang dipartisi

    Azure Cosmos DB Async Java SDK v2 mendukung kueri paralel, yang memungkinkan Anda mengkueri kumpulan yang dipartisi di paralel. Untuk informasi selengkapnya, lihat sampel kode yang bekerja dengan SDK. Kueri paralel dirancang untuk memberikan latensi dan throughput kueri yang lebih baik daripada rekanan serinya.

    • Menyesuaikan setMaxDegreeOfParallelism:

      Kueri paralel bekerja dengan membuat kueri beberapa partisi secara paralel. Namun, data dari koleksi yang dipartisi individu diambil secara serial sehubungan dengan kueri. Jadi, gunakan setMaxDegreeOfParallelism untuk mengatur jumlah partisi yang memiliki peluang maksimum untuk mencapai kueri yang paling memiliki performa, asalkan semua kondisi sistem lainnya tetap sama. Jika Anda tidak tahu jumlah partisi, Anda dapat menggunakan setMaxDegreeOfParallelism untuk mengatur angka tinggi dan sistem memilih minimum (jumlah partisi, input yang diberikan pengguna) sebagai tingkat paralelisme maksimum.

      Perlu diingat bahwa kueri paralel menghasilkan manfaat terbaik jika data didistribusikan secara merata di semua partisi sehubungan dengan kueri. Jika koleksi yang dipartisi dipartisi sedemikian rupa sehingga semua atau sebagian besar data yang dikembalikan oleh kueri terkonsentrasi di beberapa partisi (dalam kasus terburuk satu partisi), maka performa kueri akan terhambat oleh partisi tersebut.

    • Menyesuaikan setMaxBufferedItemCount:

      Kueri paralel dirancang untuk mengambil hasil sebelumnya saat batch hasil saat ini sedang diproses oleh klien. Pengambilan sebelumnya membantu dalam peningkatan latensi kueri keseluruhan. setMaxBufferedItemCount membatasi jumlah hasil yang diambil sebelumnya. Mengatur setMaxBufferedItemCount ke jumlah hasil yang diharapkan yang dikembalikan (atau angka yang lebih tinggi), memungkinkan kueri untuk menerima manfaat maksimum dari pengambilan sebelumnya.

      Pengambilan sebelunya bekerja dengan cara yang sama terlepas dari tingkat paralelisme dan ada satu buffer untuk data dari semua partisi.

  • Menerapkan backoff di interval getRetryAfterInMilliseconds

    Selama pengujian performa, Anda harus meningkatkan beban sampai tingkat permintaan yang kecil dibatasi. Jika dibatasi, aplikasi klien harus melakukan backoff untuk interval coba lagi yang ditentukan server. Memperhatikan backoff akan memastikan bahwa Anda menghabiskan sedikit waktu menunggu di antara upaya ulang.

  • Meluaskan skala beban kerja klien Anda

    Jika Anda menguji pada tingkat throughput tinggi (>50.000 RU/dtk), aplikasi klien dapat menjadi hambatan karena mesin berhenti di CPU atau pemanfaatan jaringan. Jika mencapai titik ini, Anda dapat terus mendorong akun Azure Cosmos DB lebih lanjut dengan meluaskan skala aplikasi klien di beberapa server.

  • Menggunakan alamat berbasis nama

    Gunakan alamat berbasis nama, di mana tautan memiliki format dbs/MyDatabaseId/colls/MyCollectionId/docs/MyDocumentId, bukan SelfLinks (_self), yang memiliki format untuk menghindari dbs/<database_rid>/colls/<collection_rid>/docs/<document_rid> mengambil ResourceIds dari semua sumber daya yang digunakan untuk membangun tautan. Selain itu karena sumber daya ini dibuat ulang (mungkin dengan nama yang sama), penembolokannya mungkin tidak membantu.

  • Menyesuaikan ukuran halaman untuk kueri/membaca umpan untuk kinerja yang lebih baik

    Saat melakukan bacaan massal dokumen dengan menggunakan fungsi umpan baca (misalnya, readDocuments) atau saat mengeluarkan kueri SQL, hasilnya dikembalikan secara tersegmentasi jika hasilnya diatur terlalu besar. Secara default, hasil dikembalikan dalam gugus 100 item atau 1 MB, batas mana pun yang tercapai lebih dahulu.

    Untuk mengurangi jumlah perjalanan pulang pergi jaringan yang diperlukan untuk mengambil semua hasil yang berlaku, Anda dapat meningkatkan ukuran halaman menggunakan header permintaan x-ms-max-item-count hingga 1000. Dalam kasus di mana Anda hanya perlu menampilkan beberapa hasil, misalnya, jika antarmuka pengguna atau API aplikasi Anda hanya mengembalikan 10 hasil dalam satu waktu, Anda dapat mengurangi ukuran halaman menjadi 10 untuk mengurangi throughput yang digunakan untuk bacaan dan kueri.

    Anda juga dapat mengatur ukuran halaman menggunakan metode setMaxItemCount.

  • Menggunakan Scheduler yang Sesuai (Hindari mencuri perulangan Peristiwa utas IO Netty)

    Azure Cosmos DB Async Java SDK v2 menggunakan netty untuk IO non-blocking. SDK menggunakan sejumlah utas perulangan peristiwa jelatang IO (sebanyak yang digunakan oleh core CPU yang anda miliki) untuk menjalankan operasi IO. Observable yang dikembalikan oleh API memancarkan hasil pada salah satu utas netty perulangan peristiwa IO bersama. Jadi penting untuk tidak memblokir utas jelatang perulangan peristiwa IO bersama. Melakukan pekerjaan intensif CPU atau memblokir operasi pada utas netty perulangan event IO dapat menyebabkan kebuntuan atau mengurangi throughput SDK secara signifikan.

    Misalnya kode berikut menjalankan pekerjaan intensif cpu pada utas jelatang IO perulangan peristiwa:

    Async Java SDK V2 (Maven com.microsoft.azure::azure-cosmosdb)

      Observable<ResourceResponse<Document>> createDocObs = asyncDocumentClient.createDocument(
        collectionLink, document, null, true);
    
      createDocObs.subscribe(
        resourceResponse -> {
          //this is executed on eventloop IO netty thread.
          //the eventloop thread is shared and is meant to return back quickly.
          //
          // DON'T do this on eventloop IO netty thread.
          veryCpuIntensiveWork();
        });
    

    Setelah hasil diterima jika Anda ingin melakukan pekerjaan intensif CPU pada hasilnya, Anda harus menghindari melakukannya pada utas jelatang IO perulangan peristiwa. Sebagai gantinya, Anda dapat menyediakan Scheduler Anda sendiri untuk menyediakan utas Anda sendiri untuk menjalankan pekerjaan Anda.

    Async Java SDK V2 (Maven com.microsoft.azure::azure-cosmosdb)

      import rx.schedulers;
    
      Observable<ResourceResponse<Document>> createDocObs = asyncDocumentClient.createDocument(
        collectionLink, document, null, true);
    
      createDocObs.subscribeOn(Schedulers.computation())
      subscribe(
        resourceResponse -> {
          // this is executed on threads provided by Scheduler.computation()
          // Schedulers.computation() should be used only when:
          //   1. The work is cpu intensive 
          //   2. You are not doing blocking IO, thread sleep, etc. in this thread against other resources.
          veryCpuIntensiveWork();
        });
    

    Berdasarkan jenis pekerjaan Anda, Anda harus menggunakan RxJava Scheduler yang ada sesuai untuk pekerjaan Anda. Baca di sini Schedulers.

    Untuk Informasi Lebih Lanjut, Silakan lihat halaman GitHub untuk Azure Cosmos DB Async Java SDK v2.

  • Menonaktifkan penglogan netty

    Pengelogan pustaka netty cerewet dan perlu dimatikan (menekan masuk konfigurasi mungkin tidak cukup) untuk menghindari biaya CPU tambahan. Jika Anda tidak dalam mode penelusuran kesalahan, nonaktifkan pengelogan netty sama sekali. Jadi jika Anda menggunakan log4j untuk menghapus biaya CPU tambahan yang timbul oleh org.apache.log4j.Category.callAppenders() dari netty, tambahkan baris berikut ke basis kode Anda:

    org.apache.log4j.Logger.getLogger("io.netty").setLevel(org.apache.log4j.Level.OFF);
    
  • Batas Sumber Daya file Terbuka OS

    Beberapa sistem Linux (seperti Red Hat) memiliki batas atas jumlah file yang terbuka dan juga jumlah koneksi. Jalankan yang berikut untuk melihat batas saat ini:

    ulimit -a
    

    Jumlah file yang terbuka (nofile) harus cukup besar agar memiliki cukup ruang untuk ukuran kumpulan koneksi yang Anda konfigurasikan dan file terbuka lainnya oleh OS. Ini dapat dimodifikasi untuk memungkinkan ukuran kumpulan koneksi yang lebih besar.

    Buka file limits.conf:

    vim /etc/security/limits.conf
    

    Tambahkan/ubah baris berikut:

    * - nofile 100000
    

Kebijakan Pengindeksan

  • Mengecualikan jalur yang tidak digunakan dari pengindeksan untuk penulisan yang lebih cepat

    Kebijakan pengindeksan Azure Cosmos DB memungkinkan Anda menentukan jalur dokumen mana yang akan disertakan atau dikecualikan dari pengindeksan dengan memanfaatkan Jalur Pengindeksan (setIncludedPaths dan setExcludedPaths). Penggunaan jalur pengindeksan dapat menawarkan peningkatan performa tulis dan penyimpanan indeks yang lebih rendah untuk skenario di mana pola kueri diketahui sebelumnya, karena biaya pengindeksan secara langsung berkorelasi dengan jumlah jalur unik yang diindeks. Misalnya, kode berikut menunjukkan cara mengecualikan seluruh bagian dokumen (juga dikenal sebagai subtree) dari pengindeksan menggunakan wildcard "*".

    Async Java SDK V2 (Maven com.microsoft.azure::azure-cosmosdb)

    Index numberIndex = Index.Range(DataType.Number);
    numberIndex.set("precision", -1);
    indexes.add(numberIndex);
    includedPath.setIndexes(indexes);
    includedPaths.add(includedPath);
    indexingPolicy.setIncludedPaths(includedPaths);
    collectionDefinition.setIndexingPolicy(indexingPolicy);
    

    Untuk informasi selengkapnya, lihat kebijakan pengindeksan Azure Cosmos DB.

Throughput

  • Mengukur dan menyesuaikan unit permintaan/penggunaan kedua yang lebih rendah

    Azure Cosmos DB menawarkan set operasi database yang kaya termasuk kueri relasional dan hierarkis dengan UDF, prosedur tersimpan, dan pemicu – semuanya beroperasi pada dokumen dalam koleksi database. Biaya yang terkait dengan masing-masing operasi ini bervariasi berdasarkan CPU, IO, dan memori yang dibutuhkan untuk menyelesaikan operasi. Alih-alih memikirkan dan mengelola sumber daya perangkat keras, Anda dapat memikirkan unit permintaan (RU) sebagai ukuran tunggal untuk sumber daya yang diperlukan untuk melakukan berbagai operasi database dan melayani permintaan aplikasi.

    Throughput disediakan berdasarkan jumlah unit permintaan yang diatur untuk setiap kontainer. Konsumsi unit permintaan dievaluasi sebagai tarif per detik. Aplikasi yang melebihi tarif unit permintaan yang disediakan untuk kontainernya akan dibatasi hingga tarifnya turun di bawah tingkat yang disediakan untuk kontainer tersebut. Jika aplikasi Anda memerlukan tingkat throughput yang lebih tinggi, Anda dapat meningkatkan throughput dengan provisi unit permintaan tambahan.

    Kompleksitas kueri memengaruhi berapa banyak unit permintaan yang dikonsumsi untuk sebuah operasi. Jumlah predikat, sifat predikat, jumlah UDF, dan ukuran set data sumber semuanya memengaruhi biaya operasi kueri.

    Untuk mengukur overhead operasi apa pun (buat, perbarui, atau hapus), periksa header x-ms-request-charge untuk mengukur jumlah unit permintaan yang dikonsumsi oleh operasi ini. Anda juga dapat melihat properti RequestCharge yang setara di ResourceResponse <T> atau FeedResponse <T>.

    Async Java SDK V2 (Maven com.microsoft.azure::azure-cosmosdb)

    ResourceResponse<Document> response = asyncClient.createDocument(collectionLink, documentDefinition, null,
                                                     false).toBlocking.single();
    response.getRequestCharge();
    

    Biaya permintaan yang dikembalikan di header ini adalah sebagian kecil dari throughput yang Anda sediakan. Misalnya, jika Anda memiliki 2000 RU/dtk tersedia dan jika kueri sebelumnya mengembalikan 1000 dokumen 1 KB, biaya operasinya adalah 1000. Dengan demikian, dalam satu detik server hanya menerima dua permintaan seperti itu sebelum membatasi tarif permintaan selanjutnya. Untuk informasi selengkapnya, lihat Unit permintaan dan kalkulator unit permintaan.

  • Tangani pembatasan tarif/tarif permintaan yang terlalu besar

    Saat klien mencoba untuk melebihi throughput yang dicadangkan untuk sebuah akun, tidak ada penurunan kinerja di server dan tidak ada penggunaan kapasitas throughput di luar tingkat yang dicadangkan. Server akan terlebih dahulu mengakhiri permintaan dengan RequestRateTooLarge (kode status HTTP 429) dan mengembalikan header x-ms-retry-after-ms yang menunjukkan jumlah waktu, dalam milidetik, yang pengguna harus menunggu sebelum mencoba kembali permintaan tersebut.

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

    SDK secara implisit menangkap respons ini, mematuhi header retry-after yang ditentukan server, dan mencoba kembali permintaan tersebut. 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 ditetapkan ke 9 secara internal oleh klien mungkin tidak cukup; dalam keadaan ini, klien melempar DocumentClientException dengan kode status 429 ke aplikasi. Jumlah coba lagi default dapat diubah dengan menggunakan setRetryOptions di instans ConnectionPolicy. Secara default, DocumentClientException dengan kode status 429 dikembalikan setelah waktu tunggu kumulatif 30 detik jika permintaan terus beroperasi di atas kecepatan permintaan. Hal ini terjadi bahkan ketika jumlah coba lagi saat ini kurang dari jumlah coba lagi maksimum, baik itu default 9 atau nilai yang ditentukan pengguna.

    Meskipun perilaku percobaan ulang otomatis membantu meningkatkan ketahanan dan kegunaan untuk sebagian besar aplikasi, perilaku tersebut mungkin bertentangan saat melakukan tolok ukur performa, terutama saat mengukur latensi. Latensi yang diamati klien akan melonjak jika eksperimen mencapai pembatasan server dan menyebabkan SDK klien mencoba ulang secara diam-diam. Untuk menghindari lonjakan latensi selama eksperimen performa, ukur biaya yang dikembalikan oleh setiap operasi dan pastikan bahwa permintaan beroperasi di bawah tarif permintaan yang dipesan. Untuk informasi selengkapnya, lihat Unit permintaan.

  • Mendesain dokumen yang lebih kecil untuk throughput yang lebih tinggi

    Biaya permintaan (biaya pemrosesan permintaan) dari operasi tertentu berkorelasi langsung dengan ukuran dokumen. Operasi pada dokumen besar lebih mahal daripada operasi untuk dokumen kecil.

Langkah berikutnya

Untuk mempelajari selengkapnya tentang mendesain aplikasi Anda untuk skala dan performa tinggi, lihat Pemartisian dan penskalaan di Azure Cosmos DB.