Azure batas confidential ledger

Azure confidential ledger membatasi jumlah ledger dalam langganan dan data dan kode yang disimpan ledger, untuk menjaga performa dan ketersediaan setiap ledger dapat diprediksi. Artikel ini menjelaskan batasan ini, bagaimana ledger merespons ketika permintaan melebihi batas tersebut, dan performa apa yang diharapkan dari ledger.

Note

Batas dalam artikel ini adalah default. Dalam kasus tertentu, ledger individu dapat memiliki batas yang berbeda, misalnya, ledger yang dibuat sebelum batas diperkenalkan. Untuk meminta batasan yang lebih tinggi atau membahas batasan, hubungi Azure support.

Batas langganan

Batas berikut berlaku untuk setiap langganan Azure.

Limit Value
Ledger per langganan 2

Batas data ledger

Batas berikut berlaku untuk setiap ledger secara default.

Limit Nilai standar Kode kesalahan
Koleksi per ledger 5.000 CollectionCapacityExceeded
Panjang ID Koleksi 256 byte CollectionIdTooLong
Ukuran isi entri ledger 8 KiB (8.192 byte) EntrySizeCapacityExceeded
Tag per ledger (hanya ledger publik) 10,000 TagCapacityExceeded
  • Koleksi per ledger: Koleksi default tidak dihitung. Ketika ledger mencapai batas, tulisan yang akan membuat koleksi baru ditolak. Menulis ke koleksi yang ada masih berhasil.
  • Panjang ID koleksi: Panjang diukur dalam byte ID yang dikodekan UTF-8, setelah decoding URL. Batas hanya berlaku ketika penulisan membuat koleksi baru, sehingga Anda dapat terus menulis ke dan membaca dari koleksi yang dibuat sebelum batas ini diperkenalkan.
  • Ukuran isi entri ledger: Ukuran diukur dalam byte nilai yang dikodekan contents UTF-8, setelah decoding JSON. Konten tepat 8.192 byte diterima. Batas berlaku untuk menulis ke koleksi baru dan yang sudah ada. ID koleksi, tag, dan bidang permintaan lainnya tidak dihitung dalam batas ini. Seluruh permintaan juga tunduk pada ukuran isi permintaan maksimum ledger.
  • Tag per ledger: Tag dihitung sekali untuk setiap koleksi yang menggunakannya. Misalnya, tag chocolate yang digunakan dalam dua koleksi dihitung sebagai dua tag. Ketika ledger mencapai batas, tulisan yang akan menambahkan tag baru ke koleksi ditolak. Menulis tanpa tag, atau dengan tag yang sudah digunakan koleksi, masih berhasil.

Penulisan yang melebihi batas ditolak dengan kode status HTTP 400 (Permintaan Buruk), dan tidak ada dalam permintaan yang ditulis ke ledger. Respons berisi kode kesalahan dan pesan yang menyertakan batas yang berlaku untuk ledger. Contohnya:

{
  "error": {
    "code": "EntrySizeCapacityExceeded",
    "message": "Entry contents of 9000 bytes exceed the limit of 8192 bytes."
  }
}

Batas tag per tulis

Tag hanya didukung pada ledger publik. Batas berikut berlaku untuk setiap ledger publik.

Limit Value
Tag per tulis 5
Panjang tag 63 karakter

Tag tidak boleh kosong dan hanya dapat berisi karakter A–, –zZ, a0–9, -, _, ., dan ~. Penulisan yang melebihi batas ini atau berisi tag yang tidak valid ditolak dengan kode status HTTP 400 dan NotAllowed kode kesalahan.

Batas fungsi yang ditentukan pengguna

Batas berikut berlaku untuk fungsi yang ditentukan pengguna (UDF) di setiap ledger. Permintaan yang melebihinya ditolak dengan kode status HTTP 400.

Limit Value Kode kesalahan
UDF per ledger 100 UserDefinedFunctionCapacityExceeded
Panjang ID UDF 256 byte InvalidFunctionId
Ukuran kode UDF 64 KiB (65.536 byte) InvalidInput
Pra-kait per tulisan 5 InvalidInput
Pasca-kait per tulisan 5 InvalidInput

Batas jumlah UDF dan panjang ID hanya berlaku saat Anda membuat UDF. Anda masih dapat memperbarui UDF yang ada jika kodenya sesuai dalam 64 KiB.

Untuk opsi runtime yang berlaku saat UDF berjalan, lihat Menjalankan UDF. Untuk informasi selengkapnya tentang pra-kait dan pasca-kait, lihat Kait transaksi.

Opsi runtime titik akhir yang ditentukan pengguna

Nilai yang diatur dengan PATCH /app/userDefinedEndpoints/runtimeOptions harus berada dalam rentang berikut. Jika tidak, permintaan ditolak dengan kode status HTTP 400 dan InvalidInput kode kesalahan. Hanya opsi yang nilainya perubahan permintaan yang dicentang.

Opsi runtime Nilai yang diizinkan
max_heap_bytes Hingga 209.715.200 (200 MiB)
max_stack_bytes 1 hingga 10.485.760 (10 MiB)
max_execution_time_ms Hingga 10.000 (10 detik)
max_cached_interpreters 1 hingga 20

Performance

Performa ledger tergantung pada beban kerja Anda, seperti ukuran entri Anda, berapa banyak permintaan yang Anda kirim secara bersamaan, dan campuran bacaan dan tulis. Panduan berikut memberikan gambaran umum tentang apa yang diharapkan. Ini bukan jaminan.

Daya Tampung

  • Ledger dapat mempertahankan ratusan tulisan per detik. Entri yang lebih kecil dan permintaan yang lebih bersamaan meningkatkan tarif. Penulisan yang menjalankan fungsi yang ditentukan pengguna membutuhkan waktu lebih lama, tergantung pada kode fungsi.
  • Membaca entri terbaru koleksi menggunakan lebih sedikit sumber daya daripada tulis, sehingga ledger biasanya dapat melayani lebih banyak permintaan ini. Mendapatkan entri berdasarkan ID transaksi, mendapatkan tanda terima, dan kueri rentang menggunakan lebih banyak sumber daya daripada membaca entri terbaru, karena ledger terlebih dahulu memuat data dari penyimpanan. Tingkat permintaan ini yang tinggi mengurangi throughput yang tersisa untuk penulisan.
  • Klien yang menunggu setiap respons sebelum mengirim permintaan berikutnya dibatasi oleh waktu pulang perginya ke ledger. Untuk mendapatkan hasil maksimal dari ledger, kirim permintaan secara bersamaan dan gunakan kembali koneksi.

Jika beban kerja Anda membutuhkan throughput tinggi berkelanjutan, uji pada ledger sebelum Anda pergi ke produksi. Jika Anda membutuhkan lebih banyak throughput, hubungi Azure support.

Keterlambatan

  • Secara default, permintaan tulis akan kembali segera setelah ledger menerima tulisan, dan ledger menerapkan penulisan segera setelahnya. Sebelum Anda mengandalkan tulis, misalnya untuk mendapatkan tanda terimanya, periksa apakah statusnya adalah Committed. Pustaka klien dapat menunggu penerapan untuk Anda.
  • Mendapatkan entri berdasarkan ID transaksi, mendapatkan tanda terima, dan kueri rentang dapat kembali terlebih Loading dahulu, sementara ledger memuat data. Ulangi permintaan dalam waktu satu menit hingga mengembalikan hasilnya.
  • Latensi juga tergantung pada jarak dan beban. Setiap koneksi baru memerlukan jabat tangan TLS dengan ledger, jadi gunakan kembali koneksi dan jalankan klien Anda dekat dengan wilayah ledger. Harapkan latensi meningkat saat beban pada ledger mendekati apa yang dapat dipertahankan.

Konten terkait

  • Terakhir diperbarui pada