Mode konektivitas Azure Cosmos DB SQL SDK

  • Artikel

BERLAKU UNTUK: NoSQL

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

Mode konektivitas yang tersedia

Dua mode konektivitas yang tersedia adalah:

  • Mode gateway

    Mode gateway didukung di semua platform SDK. 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 dari atau ditulis ke Azure Cosmos DB. Kami juga merekomendasikan mode koneksi gateway saat Anda menjalankan aplikasi di lingkungan yang memiliki koneksi soket dalam jumlah terbatas.

    Saat Anda menggunakan SDK di Azure Functions, terutama dalam Rencana konsumsi, ketahui batasan koneksi saat ini.

  • 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 sangat sedikit jaringan. Aplikasi terhubung langsung ke replika backend. Mode langsung saat ini hanya didukung pada platform .NET dan Java SDK.

Mode konektivitas Azure Cosmos DB

Mode konektivitas ini pada dasarnya mengondisikan rute yang diminta bidang data - dokumen membaca dan menulis - dari komputer klien Anda ke partisi di back-end Azure Cosmos DB. Mode langsung adalah opsi yang disukai untuk performa terbaik - memungkinkan klien Anda untuk membuka koneksi TCP langsung ke partisi di back-end Azure Cosmos DB dan mengirim permintaan secara langsung tanpa perantara. Sebaliknya, dalam mode Gateway, permintaan yang dibuat oleh klien Anda dirutekan ke server "Gateway" di front end Azure Cosmos DB, yang pada gilirannya menyebarkan permintaan Anda ke partisi yang sesuai di back-end Azure Cosmos DB.

Rentang port sumber

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 selain port gateway. Saat menggunakan mode langsung pada titik akhir privat, berbagai port TCP - dari 0 hingga 65535 dapat digunakan oleh Azure Cosmos DB. Jika port ini tidak terbuka pada klien Anda dan Anda mencoba menggunakan protokol TCP, Anda mungkin menerima kesalahan 503 Layanan 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 Pengantar, klien Mode langsung akan langsung terhubung ke simpul backend melalui protokol TCP. Setiap simpul backend mewakili replika dalam set replika yang termasuk dalam partisi fisik.

Perutean

Jika Azure Cosmos DB SDK pada Mode langsung melakukan operasi, ini harus menyelesaikan replika backend mana yang akan dihubungkan. Langkah pertama adalah mengetahui partisi fisik mana yang harus dituju operasi, dan untuk itu, SDK mendapatkan informasi kontainer yang menyertakan definisi kunci partisi dari simpul Gateway. Ini juga membutuhkan informasi perutean yang berisi alamat TCP replika. Informasi perutean juga tersedia dari simpul Gateway dan keduanya dianggap sebagai metadata Sarana Kontrol. Setelah mendapatkan informasi perutean, SDK dapat melanjutkan untuk membuka koneksi TCP ke replika yang termasuk dalam partisi fisik target dan menjalankan operasi.

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

Diagram yang menunjukkan cara S D K pada mode langsung mengambil kontainer dan merutekan informasi dari Gateway sebelum membuka sambungan T C P ke node backend

Karena informasi kontainer dan perutean tidak sering berubah, informasi ini di-cache secara lokal di 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 akan memastikan set replika mempertahankan konsistensinya akan tetapi pergerakan replika apa pun akan menyebabkan alamat TCP yang ada menjadi 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 empat replika, untuk memberikan kemungkinan performa terbaik, SDK pada akhirnya akan membuka koneksi ke semua replika untuk beban kerja yang menggabungkan operasi tulis dan baca. Operasi bersamaan diseimbangkan beban di seluruh koneksi yang ada untuk memanfaatkan throughput yang disediakan setiap replika.

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

  • Jumlah partisi fisik

    Dalam status stabil, SDK akan 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.

  • Volume permintaan bersamaan

    Setiap koneksi yang dibuat dapat melayani sejumlah operasi bersamaan yang dapat dikonfigurasi. Jika volume operasi bersamaan melebihi ambang ini, koneksi baru akan 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 CosmosClientOptions.MaxRequestsPerTcpConnection, dan untuk Java SDK, Anda dapat menyesuaikan menggunakan DirectConnectionConfig.setMaxRequestsPerConnection.

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

Detail implementasi khusus bahasa

Untuk detail implementasi lebih lanjut mengenai bahasa, lihat:

Langkah berikutnya

Untuk pengoptimalan performa platform SDK tertentu: