Share via

Praktik terbaik untuk Azure Cosmos DB Java SDK

  • Artikel

BERLAKU UNTUK: NoSQL

Artikel ini membahas praktik terbaik untuk menggunakan Azure Cosmos DB Java SDK. Mengikuti praktik ini akan membantu meningkatkan latensi, ketersediaan, dan meningkatkan performa Anda secara keseluruhan.

Daftar periksa

Dicentang Topik Detail/Tautan
Versi SDK Selalu gunakan versi terbaru Azure Cosmos DB SDK yang tersedia untuk performa optimal.
Klien Tunggal Gunakan instans tunggalCosmosClient selama penggunaan aplikasi Anda untuk performa yang lebih baik.
Wilayah Pastikan untuk menjalankan aplikasi Anda di wilayah Azure yang sama dengan akun Azure Cosmos DB Anda, jika memungkinkan untuk mengurangi latensi. Aktifkan 2-4 wilayah dan tiru akun Anda di beberapa wilayah untuk ketersediaan terbaik. Untuk beban kerja produksi, aktifkan failover yang dikelola layanan. Jika konfigurasi ini tidak ada, akun akan mengalami kehilangan ketersediaan tulis selama penghentian wilayah tulis, karena kegagalan manual tidak akan berhasil karena kurangnya konektivitas wilayah. Untuk mempelajari cara menambahkan beberapa wilayah menggunakan Java SDK kunjungi di sini
Ketersediaan dan Failover Atur preferredRegions di SDK v4. Selama failover, operasi tulis dikirim ke wilayah penulisan saat ini dan semua bacaan dikirim ke wilayah pertama dalam daftar wilayah pilihan Anda. Untuk informasi selengkapnya tentang mekanika failover regional, lihat panduan pemecahan masalah ketersediaan.
CPU Anda mungkin mengalami masalah konektivitas/ketersediaan karena kurangnya sumber daya pada mesin klien Anda. Pantau pemanfaatan CPU Anda pada node yang menjalankan klien Azure Cosmos DB dan skalakan jika penggunaan sangat tinggi.
Hosting Untuk sebagian besar kasus beban kerja produksi yang umum, kami sangat menyarankan untuk menggunakan setidaknya VM memori 4-core dan 8 GB jika memungkinkan.
Mode Konektivitas Gunakan Mode langsung untuk performa terbaik. Untuk petunjuk tentang cara melakukannya, lihat dokumentasi SDK V4.
Jaringan Jika menggunakan mesin virtual untuk menjalankan aplikasi Anda, aktifkan Jaringan Percepatan di mesin virtual Anda untuk membantu penyempitan karena lalu lintas tinggi dan mengurangi latensi atau jitter CPU. Anda mungkin juga ingin mempertimbangkan untuk menggunakan Mesin Virtual kelas atas di mana penggunaan CPU maksimal di bawah 70%.
Kelelahan port sementara Untuk koneksi yang jarang atau sporadis, sebaiknya atur idleEndpointTimeout ke nilai yang lebih tinggi. Properti idleEndpointTimeout di DirectConnectionConfig membantu mengontrol waktu koneksi yang tidak digunakan agar ditutup. Ini akan mengurangi jumlah koneksi yang tidak digunakan. Secara default, koneksi diam ke titik akhir tetap terbuka selama 1 jam. Jika tidak ada permintaan ke titik akhir tertentu untuk durasi waktu tunggu titik akhir diam, klien langsung menutup semua koneksi ke titik akhir tersebut untuk menghemat sumber daya dan biaya I/O.
Menggunakan Scheduler yang Sesuai (Hindari mencuri perulangan Event utas Netty IO) Hindari memblokir panggilan: .block(). Seluruh tumpukan panggilan tidak sinkron untuk mendapatkan manfaat dari pola API asinkron dan penggunaan threading dan penjadwal yang sesuai
Batas Waktu End-to-End Untuk mendapatkan batas waktu end-to-end, terapkan kebijakan batas waktu end-to-end di Java SDK. Untuk detail selengkapnya tentang batas waktu dengan Azure Cosmos DB kunjungi di sini
Logika Coba Lagi Kesalahan sementara adalah kesalahan yang memiliki penyebab mendasar yang segera teratasi dengan sendirinya. Aplikasi yang tersambung ke database Anda harus dibangun untuk memperkirakan kesalahan sementara ini. Untuk menanganinya, terapkan logika coba lagi dalam kode Anda alih-alih menampilkannya kepada pengguna sebagai kesalahan aplikasi. SDK memiliki logika bawaan untuk menangani kegagalan sementara ini pada permintaan yang dapat dicoba lagi seperti operasi baca atau kueri. SDK tidak akan mencoba lagi penulisan untuk kegagalan sementara karena penulisan tidak idempoten. SDK memungkinkan pengguna untuk mengonfigurasi logika coba lagi untuk pembatasan. Untuk detail tentang kesalahan mana yang harus dicoba lagi kunjungi di sini
Database penembolokan/nama koleksi Ambil nama database dan kontainer Anda dari konfigurasi atau simpan nama tersebut di cache saat memulai. Panggilan seperti CosmosAsyncDatabase#read() atau CosmosAsyncContainer#read() akan menghasilkan panggilan metadata ke layanan, yang menggunakan batas RU yang dicadangkan sistem. createDatabaseIfNotExists() juga hanya boleh digunakan sekali untuk menyiapkan database. Secara keseluruhan, operasi ini tidak boleh dilakukan terlalu sering.
Kueri Paralel Azure Cosmos DB SDK mendukung menjalankan kueri secara paralel untuk latensi dan throughput yang lebih baik pada kueri Anda. Kami menyarankan untuk mengatur properti maxDegreeOfParallelism dalam CosmosQueryRequestsOptions ke jumlah partisi yang Anda miliki. Jika Anda tidak mengetahui jumlah partisi, atur nilainya ke -1 yang akan memberi Anda latensi terbaik. Juga atur maxBufferedItemCount jumlah hasil yang diharapkan kembali untuk membatasi jumlah hasil yang telah diambil sebelumnya.
Backoff Pengujian Performa Saat melakukan pengujian pada aplikasi Anda, Anda harus menerapkan backoff pada interval RetryAfter. Memperhatikan backoff akan memastikan bahwa Anda menghabiskan sedikit waktu tunggu di antara upaya ulang.
Pengindeksan Kebijakan pengindeksan Azure Cosmos DB juga memungkinkan Anda menentukan jalur dokumen mana yang akan disertakan atau dikecualikan dari pengindeksan menggunakan jalur pengindeksan IndexingPolicy#getIncludedPaths() dan IndexingPolicy#getExcludedPaths(). Pastikan Anda mengecualikan jalur yang tidak digunakan dari pengindeksan untuk penulisan yang lebih cepat. Untuk sampel tentang cara membuat indeks menggunakan SDK kunjungi di sini
Ukuran Dokumen Biaya permintaan dari operasi tertentu berkorelasi langsung dengan ukuran dokumen. Sebaiknya kurangi ukuran dokumen Anda karena operasi pada dokumen besar lebih mahal daripada operasi pada dokumen yang lebih kecil.
Ukuran Halaman Secara default, hasil kueri dikembalikan dalam potongan 100 item atau 4 MB, batas mana pun yang terpukul terlebih dahulu. Jika kueri akan mengembalikan lebih dari 100 item, tingkatkan ukuran halaman untuk mengurangi jumlah perjalanan pulang pergi yang diperlukan. Konsumsi memori akan meningkat seiring bertambahnya ukuran halaman.
Mengaktifkan Metrik Kueri Untuk pengelogan tambahan dari eksekusi kueri backend Anda, ikuti petunjuk tentang cara mengambil Metrik Kueri SQL menggunakan Java SDK
Pengelogan SDK Gunakan pengelogan SDK untuk menangkap informasi diagnostik tambahan dan memecahkan masalah latensi. Catat CosmosDiagnostics di Java SDK untuk informasi diagnostik Azure Cosmos DB yang lebih rinci untuk permintaan saat ini ke layanan. Sebagai contoh kasus penggunaan, rekam Diagnostik pada pengecualian apa pun dan pada operasi yang diselesaikan jika CosmosDiagnostics#getDuration() lebih besar dari nilai ambang yang ditentukan (yaitu jika Anda memiliki SLA 10 detik, lalu rekam diagnostik saat getDuration()> 10 detik). Disarankan untuk hanya menggunakan diagnostik ini selama pengujian performa. Untuk informasi selengkapnya, ikuti diagnostik pengambilan di Java SDK
Hindari menggunakan karakter khusus dalam pengidentifikasi Beberapa karakter dibatasi dan tidak dapat digunakan dalam beberapa pengidentifikasi: '/', '\', '?', '#'. Rekomendasi umumnya adalah untuk tidak menggunakan karakter khusus dalam pengidentifikasi seperti nama database, nama koleksi, id item, atau kunci partisi untuk menghindari perilaku yang tidak terduga.

Praktik terbaik saat menggunakan mode Gateway

Permintaan Azure Cosmos DB dibuat melalui HTTPS/REST saat Anda menggunakan mode Gateway. Mereka tunduk pada batas koneksi default per nama host atau alamat IP. Anda mungkin perlu mengubah maxConnectionPoolSize ke nilai yang berbeda (dari 100 hingga 1.000) sehingga pustaka klien dapat menggunakan beberapa koneksi simultan ke Azure Cosmos DB. Di Java v4 SDK, nilai default untuk GatewayConnectionConfig#maxConnectionPoolSize adalah 1000. Untuk mengubah nilai, Anda dapat mengatur GatewayConnectionConfig#maxConnectionPoolSize ke nilai yang berbeda.

Praktik terbaik untuk beban kerja tulis-berat

Untuk beban kerja yang memiliki muatan buat berat, atur opsi permintaan CosmosClientBuilder#contentResponseOnWriteEnabled() ke false. Layanan tidak akan lagi mengembalikan sumber daya yang dibuat atau diperbarui ke SDK. Biasanya, karena aplikasi memiliki objek yang sedang dibuat, layanan tidak perlu mengembalikannya. Nilai header masih dapat diakses, seperti biaya permintaan. Menonaktifkan respons konten dapat membantu meningkatkan performa, karena SDK tidak lagi perlu mengalokasikan memori atau serialisasi isi respons. Ini juga mengurangi penggunaan bandwidth jaringan untuk lebih membantu performa.

Langkah berikutnya

Untuk mempelajari selengkapnya tentang tips performa untuk Java SDK, lihat Tips performa untuk Azure Cosmos DB Java SDK v4.

Untuk mempelajari selengkapnya tentang perancangan aplikasi Anda untuk skala dan kinerja tinggi, lihat Pemartisian dan penyekalaan di Azure Cosmos DB.

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.