Bagikan melalui

Modus konektivitas Azure Cosmos DB SQL SDK

  • Berlaku untuk: ✅ NoSQL

Bagaimana klien terhubung ke Azure Cosmos DB memiliki implikasi performa penting, terutama untuk latensi sisi klien yang diamati. Azure Cosmos DB menawarkan model pemrograman RESTful yang sederhana dan terbuka melalui HTTPS yang disebut mode gateway . Selain itu, ia menawarkan protokol TCP yang efisien, yang juga RESTful dalam model komunikasinya dan menggunakan TLS untuk autentikasi awal dan mengenkripsi lalu lintas, yang disebut mode langsung .

Mode konektivitas yang tersedia

Dua mode konektivitas yang tersedia adalah:

  • Mode gerbang

    Mode gateway didukung di semua platform SDK. Jika aplikasi Anda berjalan dalam jaringan perusahaan dengan pembatasan firewall yang ketat, mode gateway adalah pilihan terbaik karena menggunakan port HTTPS standar dan satu titik akhir DNS. Namun, kompromi performa adalah bahwa mode gateway melibatkan hop jaringan tambahan setiap kali data dibaca dari atau ditulis ke Azure Cosmos DB. Kami juga merekomendasikan mode koneksi gateway saat Anda menjalankan aplikasi di lingkungan yang memiliki jumlah koneksi soket terbatas.

    Saat Anda menggunakan SDK di Azure Functions, terutama dalam paket Konsumsi, ketahui batas saat ini pada koneksi.

  • Mode langsung

    Mode langsung mendukung konektivitas melalui protokol TCP, menggunakan TLS untuk autentikasi awal dan mengenkripsi lalu lintas, dan menawarkan performa yang lebih baik karena ada lebih sedikit hop jaringan. Aplikasi terhubung langsung ke replika backend. Mode langsung saat ini hanya didukung pada platform .NET dan Java SDK.

Diagram mode konektivitas Azure Cosmos DB.

Mode konektivitas ini pada dasarnya menyesuaikan rute jalur data (pembacaan dan penulisan dokumen) dari komputer klien Anda ke partisi pada backend Azure Cosmos DB. Mode langsung adalah opsi yang disukai untuk performa terbaik; ini memungkinkan klien Anda untuk membuka koneksi TCP langsung ke partisi di backend Azure Cosmos DB dan mengirim permintaan secara langsungtanpa perantara. Sebaliknya, dalam mode gateway, permintaan yang dibuat oleh klien Anda dirutekan ke server yang disebut Gateway di bagian frontend dari Azure Cosmos DB, yang kemudian menyebarkan permintaan Anda ke partisi yang sesuai di bagian backend Azure Cosmos DB.

Rentang port layanan

Saat Anda menggunakan mode langsung, Anda perlu memastikan bahwa klien Anda dapat mengakses port berkisar antara 10000 dan 20000 karena Azure Cosmos DB menggunakan port TCP dinamis. Ini adalah tambahan terhadap port gateway. Saat menggunakan mode langsung pada titik akhir privat, Azure Cosmos DB dapat menggunakan berbagai port TCP dari 0 hingga 65535. Jika port ini tidak terbuka pada klien Anda dan Anda mencoba menggunakan protokol TCP, Anda mungkin menerima kesalahan "Layanan 503 Tidak Tersedia".

Tabel berikut menunjukkan ringkasan mode konektivitas yang tersedia untuk berbagai API dan port layanan yang digunakan untuk setiap API:

Mode koneksi Protokol yang didukung SDK yang didukung Port API/Layanan
Gateway HTTPS Semua SDK SQL (443), MongoDB (10255), Tabel (443), Cassandra (10350), Grafik (443)
Langsung TCP (Dienkripsi melalui TLS) .NET SDK Java SDK Saat menggunakan titik akhir publik/layanan: port dalam rentang 10000 hingga 20000

Saat menggunakan titik akhir privat: port dalam rentang 0 hingga 65535

Arsitektur koneksi mode langsung

Seperti yang dijelaskan dalam pengenalan, klien mode langsung terhubung langsung ke node backend melalui protokol TCP. Setiap node backend mewakili replika dalam set replika milik partisi fisik.

Pengaturan Rute

Saat Azure Cosmos DB SDK dalam mode langsung melakukan operasi, ia perlu menentukan replika backend mana yang akan dihubungkan. Langkah pertama adalah mengetahui partisi fisik mana yang harus digunakan operasi, dan untuk itu, SDK mendapatkan informasi kontainer yang menyertakan definisi kunci partisi dari simpul gateway. Ini juga membutuhkan informasi routing yang memuat alamat TCP replika. Informasi perutean tersedia juga dari simpul gateway dan keduanya dianggap sebagai metadata sarana kontrol. Setelah SDK mendapatkan informasi perutean, SDK dapat melanjutkan untuk membuka koneksi TCP ke replika milik partisi fisik target dan menjalankan operasi.

Setiap set replika berisi satu replika utama dan tiga sekunder. Operasi tulis selalu dirutekan ke simpul replika utama sementara operasi baca dapat dilayani dari simpul primer atau sekunder.

Diagram yang memperlihatkan bagaimana SDK dalam mode langsung mengambil kontainer dan informasi perutean dari Gateway sebelum membuka koneksi TCP ke simpul backend.

Karena informasi kontainer dan perutean tidak sering berubah, informasi tersebut di-cache secara lokal pada SDK sehingga operasi berikutnya dapat memperoleh manfaat dari informasi ini. Koneksi TCP yang sudah dibuat juga digunakan kembali di seluruh operasi. Kecuali dikonfigurasi lain melalui opsi SDK, koneksi dipertahankan secara permanen selama masa pakai instans SDK.

Seperti halnya arsitektur terdistribusi, mesin yang memegang replika mungkin mengalami peningkatan atau pemeliharaan. Layanan ini memastikan set replika mempertahankan konsistensi tetapi pergerakan replika apa pun akan menyebabkan alamat TCP yang ada berubah. Dalam kasus ini, SDK perlu merefresh informasi perutean dan menyambungkan kembali ke alamat baru melalui permintaan Gateway baru. Peristiwa ini seharusnya tidak memengaruhi SLA P99 secara keseluruhan.

Volume koneksi

Setiap partisi fisik memiliki set replika yang terdiri dari empat replika, guna memberikan performa sebaik mungkin, SDK pada akhirnya membuka koneksi ke semua replika untuk beban kerja yang mengombinasikan operasi tulis dan baca. Operasi bersamaan didistribusikan secara seimbang di seluruh koneksi yang ada untuk memanfaatkan throughput yang disediakan oleh masing-masing replika.

Ada dua faktor yang menentukan jumlah koneksi TCP yang dibuka SDK:

  • Jumlah partisi fisik

    Dalam keadaan stabil, SDK memiliki satu koneksi per replika per partisi fisik. Semakin besar jumlah partisi fisik dalam kontainer, semakin besar jumlah koneksi terbuka. Karena operasi dirutekan di berbagai partisi, koneksi dibuat sesuai permintaan. Jumlah rata-rata koneksi kemudian akan menjadi jumlah partisi fisik sebanyak empat kali.

  • Jumlah permintaan bersamaan

    Setiap koneksi yang dibuat dapat melayani sejumlah operasi bersamaan yang dapat dikonfigurasi. Jika volume operasi bersamaan melebihi ambang batas ini, koneksi baru terbuka untuk melayaninya, dan ada kemungkinan bahwa untuk partisi fisik, jumlah koneksi terbuka melebihi nomor status stabil. Perilaku ini diharapkan untuk beban kerja yang mungkin memiliki lonjakan volume operasionalnya. Untuk .NET SDK, konfigurasi ini diatur oleh MaxRequestsPerTcpConnection, dan untuk Java SDK, Anda dapat menyesuaikan menggunakan kelas DirectConnectionConfig.

Secara default, koneksi dipertahankan secara permanen untuk menguntungkan performa operasi di masa mendatang (membuka koneksi memiliki overhead komputasi). Mungkin ada beberapa skenario di mana Anda mungkin ingin menutup koneksi yang tidak digunakan untuk beberapa waktu memahami bahwa ini mungkin sedikit memengaruhi operasi di masa mendatang. Untuk .NET SDK, konfigurasi ini diatur oleh IdleTcpConnectionTimeout, dan untuk Java SDK, Anda dapat menyesuaikan menggunakan Kelas DirectConnectionConfig. Tidak disarankan untuk mengatur konfigurasi ini ke nilai rendah karena dapat menyebabkan koneksi sering ditutup dan memengaruhi performa keseluruhan.

Detail implementasi khusus bahasa

Untuk detail implementasi mengenai bahasa, lihat:

Langkah selanjutnya

Untuk pengoptimalan performa platform SDK tertentu:

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.

  • Last updated on