Praktik terbaik throughput penyerapan data

Halaman ini menjelaskan praktik terbaik untuk mengoptimalkan throughput data saat menyerap data ke dalam Cloud Healthcare API. Rekomendasi ini ditujukan bagi praktisi teknis yang memiliki pengalaman dalam mengelola throughput data untuk sistem berskala besar.

Throughput data

throughput data adalah jumlah resource, seperti resource FHIR atau instance DICOM, atau byte yang diserap Cloud Healthcare API setiap detik.

Batasan throughput data

Daftar berikut menjelaskan alasan kemungkinan throughput data dibatasi:

Anda tidak merencanakan permintaan dalam jumlah besar yang menyebabkan lonjakan traffic.
Batasan bandwidth memperlambat penyerapan volume data besar yang dikirim dalam waktu singkat.
Beberapa transaksi serentak mengubah resource Cloud Healthcare API yang sama, yang menyebabkan pertentangan data.
Terlalu banyak permintaan kecil yang dibuat. Untuk mengetahui informasi selengkapnya, lihat Menghindari permintaan ekspor dan impor dalam jumlah kecil.
Terlalu banyak operasi yang berjalan lama (LRO) yang dijalankan secara serentak dan bandwidth dibatasi.
Terlalu banyak LRO yang dijadwalkan secara bersamaan yang menyebabkan kegagalan.

Mencoba lagi permintaan yang gagal

Jika klien dengan cepat dan berulang kali mencoba ulang permintaan setelah kegagalan, permintaan tersebut dapat melebihi kuota Cloud Healthcare API. Bagian berikut menjelaskan cara mencoba kembali permintaan yang gagal secara efisien.

Menggunakan backoff eksponensial dengan jitter dan antrean percobaan ulang persisten

Backoff eksponensial dengan jitter yang diperkenalkan adalah strategi penanganan error standar untuk aplikasi jaringan. Klien secara berkala mencoba lagi permintaan yang gagal dengan penundaan yang meningkat secara eksponensial antara percobaan ulang dan penundaan acak yang kecil.

Pastikan implementasi backoff eksponensial Anda bersifat idempoten untuk setiap percobaan ulang, terutama jika Anda menggunakan logika kustom untuk mengabaikan kondisi kegagalan. Baca 9.2.2 Metode Idempoten di spesifikasi HTTP untuk mengetahui informasi lebih lanjut.

Sebagian besar bahasa pemrograman menawarkan library untuk menyederhanakan penerapan backoff eksponensial dan strategi percobaan ulang serupa. Untuk percobaan ulang jangka panjang atau multi-proses, terapkan antrean percobaan ulang persisten. Antrean ini dapat mereset mekanisme percobaan ulang jika Anda melebihi waktu backoff maksimum.

Gunakan backoff eksponensial saat mencoba kembali permintaan ini:

Operasi yang mengubah resource FHIR atau paket resource FHIR.
Permintaan LRO sinkron. Coba lagi jika terjadi error saat LRO dimulai atau jika LRO gagal.

LRO memiliki error unik yang mungkin mengharuskan Anda menerapkan strategi percobaan ulang berikut:
- Gunakan paket terpisah untuk menyimpan data yang gagal diimpor atau membuat operasi.
- Menggunakan permintaan sinkron untuk data yang gagal diproses.

Contoh algoritma backoff eksponensial

Algoritma backoff eksponensial mencoba ulang permintaan secara eksponensial, meningkatkan waktu tunggu antar-percobaan ulang hingga waktu backoff maksimum. Algoritma berikut mengimplementasikan backoff eksponensial terpotong dengan jitter:

Mengirim permintaan ke Cloud Healthcare API.
Jika permintaan gagal, tunggu 1 + random-fraction detik, lalu coba lagi permintaan tersebut.
Jika permintaan gagal, tunggu 2 + random-fraction detik, lalu coba lagi permintaan tersebut.
Jika permintaan gagal, tunggu 4 + random-fraction detik, lalu coba lagi permintaan tersebut.
Lanjutkan pola ini, menunggu 2ⁿ + random-fraction detik setelah setiap percobaan ulang, hingga waktu maximum-backoff.
Setelah deadline detik, berhenti mencoba lagi permintaan tersebut.

Gunakan nilai berikut saat Anda mengimplementasikan algoritme:

Sebelum setiap percobaan ulang, waktu tunggu adalah min((2ⁿ + random-fraction), maximum-backoff), dengan n dimulai dari 0 dan bertambah 1 untuk setiap percobaan ulang.
Ganti random-fraction dengan nilai pecahan acak yang kurang dari atau sama dengan 1. Gunakan nilai yang berbeda untuk setiap percobaan ulang. Menambahkan nilai acak ini akan mencegah klien disinkronkan dan mengirim banyak percobaan ulang secara bersamaan.
Ganti maximum-backoff dengan jumlah waktu maksimum, dalam detik, untuk menunggu di antara percobaan ulang. Nilai yang umum adalah 32 atau 64 (2⁵ atau 2⁶) detik. Pilih nilai yang paling sesuai untuk kasus penggunaan Anda.
Ganti deadline dengan jumlah detik maksimum untuk terus mengirim percobaan ulang. Pilih nilai yang mencerminkan kasus penggunaan Anda.

Klien dapat mencoba lagi setelah mencapai waktu maximum-backoff menggunakan nilai yang sama dengan backoff. Misalnya, jika waktu maximum-backoff adalah 64 detik, coba lagi setiap 64 detik. Pastikan klien tidak mencoba lagi tanpa batas waktu.

Menerapkan pembatasan kapasitas sisi klien dengan pembentukan traffic

Pembatasan kapasitas melindungi sistem berskala besar dengan mencegah sistem kewalahan oleh permintaan yang berlebihan. Jika pembatasan kapasitas sisi klien tidak cukup, sistem kuota Cloud Healthcare API dapat membatasi throughput data. Untuk mengetahui informasi lebih lanjut, baca bagian Praktik terbaik untuk pengelolaan kuota.

Jika Anda memiliki persyaratan tambahan, seperti penayangan terjamin di seluruh percobaan ulang, strategi dalam Coba lagi permintaan yang gagal mungkin tidak memadai. Pembentukan traffic adalah teknik pembatasan kapasitas yang mempertahankan tingkat permintaan sisi klien dalam batasan bandwidth. Hal ini menyebarkan lonjakan beban selama beberapa jam atau menit, sehingga meningkatkan throughput. Saat kuota dibatasi, pembentukan traffic dapat mencapai throughput yang lebih tinggi daripada hanya menggunakan percobaan ulang karena menghindari pushback dan melacak unit pekerja.

Anda dapat mengimplementasikan pembentukan traffic untuk operasi pembuatan, penghapusan, update, dan penghapusan (CRUD) yang sinkron, termasuk fhir.executeBundle.

Persyaratan pembentukan traffic

Untuk menerapkan pembentukan traffic, sistem Anda harus mengimplementasikan hal berikut:

Antrean pemrosesan yang didukung penyimpanan dengan redundansi untuk menghindari kegagalan disk.
Pekerja terkoordinasi untuk mengambil dari antrean pemrosesan.
Deteksi penggunaan keseluruhan untuk menyesuaikan jumlah pekerja dan kecepatan pemrosesannya berdasarkan batas kuota.
Pemulihan dari bencana (disaster recovery) untuk antrean pemrosesan yang didukung penyimpanan. Jika terjadi bencana, sistem Anda harus dapat menghapus permanen atau memulihkan antrean.
Penurunan LRO selama jam sibuk. Untuk mengetahui informasi selengkapnya, lihat Merencanakan dan menggunakan kuota secara efisien serta Membuat antrean dan mengelola LRO.

Dalam kasus berikut, pembentukan traffic mungkin hanya diperlukan untuk satu tahap pipeline:

Membatasi jumlah pekerja yang menarik dari langkah pipeline sebelumnya.
Membatasi setiap pekerja satu per satu.
Menggunakan koordinator kumpulan pekerja untuk menyesuaikan kecepatan pemrosesan setiap unit kerja, seperti kueri per detik (QPS) atau byte yang diserap per detik.

Menerapkan pembatasan kapasitas di area lain dalam sistem Anda

Anda dapat menggunakan bahasa pemrograman dan framework yang ada untuk menerapkan pembentukan traffic. Pertimbangkan project open source dan solusi bawaan berikut:

Throttling sisi klien di Apache Beam. Lihat Penskalaan horizontal otomatis untuk mengetahui informasi cara mengontrol throttling menggunakan tanda numWorkers dan maxNumWorkers.
Class RateLimiter Java dari kumpulan library Java inti Google Guava.
Modul ratelimiter Python.

Untuk kontrol alur, gunakan library klien Pub/Sub tingkat tinggi.

Memilih antara pemrosesan asinkron dan sinkron

Lapisan proxy sisi klien yang menggabungkan permintaan ke Cloud Healthcare API, yang ditunjukkan dalam Menangani error di beberapa lapisan, juga dapat mengontrol throttling di seluruh layanan yang menggunakan Cloud Healthcare API. Bergantung pada jenis pembentukan traffic yang diperlukan, gunakan salah satu opsi berikut:

Asinkron

Gunakan pemrosesan asinkron untuk mengantrekan permintaan dan mengontrol pekerja. Lapisan proxy menulis permintaan masuk ke antrean dan menampilkan respons 200 OK setelah setiap permintaan diantrekan. Ini berfungsi paling baik untuk permintaan tulis, tetapi dapat digunakan untuk permintaan baca dalam framework LRO jika klien dapat menerima hasil operasi baca.

Sinkron

Pemrosesan sinkron memberikan mekanisme masukan yang sederhana jika unit pekerjaan bergantung pada penyelesaian unit sebelumnya. Lapisan proxy menunda permintaan keluar berdasarkan batas throughput atau QPS atau byte, dan klien memblokir serta menunggu respons lapisan proxy.

Lapisan proxy dapat menyesuaikan pembatasan kapasitas berdasarkan jumlah instance, atau dapat berkoordinasi dengan proses pengontrol yang menyesuaikan batas kapasitas setiap beberapa detik. Agar lapisan proxy dapat melacak jumlah instance dan batas kapasitasnya, setiap instance proxy dapat secara rutin membaca file atau melakukan panggilan prosedur jarak jauh (RPC) dengan batas kapasitas yang dienkode.

Pemrosesan sinkron terkadang memiliki kekurangan berikut:

Resource di lapisan klien dan proxy tidak tersedia saat klien memblokir dan menunggu respons. Hal ini dapat menyebabkan error, waktu tunggu habis, dan penurunan throughput data, sehingga mempersulit penskalaan.
Jika lapisan klien dan proxy terputus, perlu upaya lebih banyak untuk memastikan data telah dimodifikasi sesuai permintaan.

Menggunakan Cloud Tasks

Gunakan Cloud Tasks untuk memindahkan permintaan ke antrean. Cloud Tasks secara otomatis menetapkan dan memantau kuota Google Cloud berikut:

Ukuran burst maksimum dan permintaan serentak maksimum menggunakan objek RateLimits
Mencoba ulang batas menggunakan objek RetryConfig

Lihat bagian Membuat antrean untuk membuat antrean di Cloud Tasks. Resource Queue menampilkan opsi yang dapat Anda tetapkan pada antrean. Misalnya, Anda dapat menggunakan objek RetryConfig untuk mengimplementasikan backoff eksponensial. Lihat library klien Cloud Tasks untuk library khusus bahasa.

Saat menggunakan Cloud Tasks, pertimbangkan hal-hal berikut:

Cloud Tasks tidak menjamin pengiriman persis sekali. Tepat sekali dikirim, permintaan apa pun yang berisi data duplikat akan dikenali sebagai duplikat dan diabaikan oleh server. Untuk mengetahui informasi selengkapnya, lihat Setelah Lambda: tepat setelah pemrosesan di Dataflow, Bagian 1.
Ukuran tugas maksimum mungkin jauh lebih kecil daripada ukuran paket FHIR maksimum di Cloud Healthcare API. Untuk mengetahui informasi selengkapnya, lihat Kuota dan batas Cloud Tasks serta kuota dan batas Cloud Healthcare API.
Cloud Tasks memiliki masalah dan batasan.

Gabungkan paket FHIR dengan pembatas kapasitas

Mencoba kembali paket FHIR dengan backoff eksponensial dan pembatas kapasitas dapat membantu mempertahankan throughput data yang tinggi dan mengelola lonjakan beban.

Klien dapat mengirim paket FHIR batch dan transaksi ke Cloud Tasks, yang mengirim permintaan dalam paket ke Cloud Healthcare API. Jika pembatasan kapasitas penuh atau melebihi kuota karena telah mencapai ukuran antrean maksimum dan kehabisan ruang disk, klien dapat mengimplementasikan backoff eksponensial untuk mengantrekan paket.

Cegah antrean pembatas kapasitas menjadi penuh dengan memantau referensi berikut:

Kuota operasi FHIR di Cloud Healthcare API
Kuota pembatas kapasitas
Error pembatas kapasitas

Jika antrean pembatas kapasitas penuh, sistem Anda harus memberi tahu manusia dan menghentikan klien agar tidak mengirim permintaan.

Menggunakan koneksi HTTP persisten (keep-alive yang dapat digunakan kembali)

Secara default, Cloud Healthcare API membuka koneksi TCP baru untuk setiap permintaan CRUD. Ini memerlukan handshake TCP, yang dapat menyebabkan overhead dan menurunkan performa. Untuk meningkatkan performa, gunakan HTTP keep-alive agar koneksi TCP tetap terbuka untuk beberapa permintaan.

Untuk menggunakan HTTP keep-alive di HTTP/1.1, setel header Connection ke keep-alive:

Connection: keep-alive

HTTP/2 menggunakan satu koneksi TCP untuk permintaan berurutan dan serentak, yang otomatis menghindari overhead.

Library requests python menggunakan keep-alive HTTP secara default. Jika Anda menggunakan Node.js, tetapkan keepAlive ke true saat Anda membuat objek http.Agent, lalu teruskan objek tersebut dalam permintaan Anda.

Menggunakan framework pengujian

Framework pengujian memastikan kode Anda berfungsi dan membantu Anda melakukan hal berikut:

Bersiap menghadapi lonjakan traffic tiba-tiba dalam aplikasi atau pipeline.
Uji apakah backoff eksponensial dan pembatasan kapasitas sisi klien meningkatkan performa. Pengujian dapat menunjukkan apakah implementasi ini membuat backlog tugas yang harus ditangani secara terpisah.
Pisahkan dan kontrol traffic prioritas tinggi. Misalnya, jika pengguna menunggu respons, beban kerja pada tugas pemrosesan latar belakang dapat dikurangi untuk memastikan pengalaman pengguna tidak menurun.
Uji strategi antrean sinkron dan asinkron untuk mengatur aliran traffic, atau uji apakah lapisan proxy menangani penolakan.
Merencanakan pemulihan dari bencana. Proses ini biasanya memerlukan reset traffic masuk atau penggunaan antrean untuk melanjutkan traffic setelah bencana berakhir.

Menggunakan Cloud Monitoring

Gunakan Cloud Monitoring untuk memantau lingkungan pengujian dan produksi Anda. Ikuti rekomendasi berikut:

Integrasikan Cloud Tasks dengan layanan logging dan pemantauan Google Cloud lainnya, seperti Cloud Audit Logs.
Buat metrik kustom dengan Cloud Monitoring API untuk melacak metrik utama seperti percobaan ulang, ukuran antrean, dan usia antrean.
Buat tujuan tingkat layanan (SLO) dan indikator tingkat layanan (SLI) untuk lingkungan Anda. Lihat Pengantar SLI untuk mendapatkan rekomendasi.
Buat kebijakan pemberitahuan menggunakan Kemampuan Observasi Google Cloud. Kebijakan pemberitahuan memberi tahu Anda tentang masalah seperti jika sistem Anda sedang stres atau memerlukan intervensi manusia.
Buat playbook operasional sehingga administrator sistem mengetahui apa yang harus dilakukan jika kebijakan pemberitahuan mengirimkan notifikasi.
Gunakan playbook operasional di lingkungan staging untuk merespons skenario berikut:
- Backlog yang disebabkan oleh pembatasan kapasitas
- Penolakan disebabkan oleh melampaui batas kuota
- Lonjakan traffic masuk

Cegah `429 Resource Exhausted operation_too_costly` error

Membuat ribuan update paralel setiap hari pada resource FHIR dapat menyebabkan pertentangan kunci, latensi, dan mencegah transaksi diselesaikan. Transaksi yang tidak dapat diselesaikan dapat membuat backlog error 429 Resource Exhausted operation_too_costly:

HTTP/1.1 429 Too many requests
...

{
  "issue": [
    {
      "code": "too-costly",
      "details": {
        "text": "operation_too_costly"
      },
      "diagnostics": "aborted due to lock contention while executing transactional bundle. Resource type: FHIR_RESOURCE_TYPE",
      "severity": "error"
    }
  ],
  "resourceType": "OperationOutcome"
}

Dalam error tersebut, "biaya" mengacu pada penggunaan resource dan throughput data, bukan biaya penagihan.

Error 429 Too Many Requests tidak selalu menunjukkan masalah kuota. Error ini dapat terjadi saat server FHIR Cloud Healthcare API mendeteksi pertentangan kunci yang berlebihan pada kumpulan data database. Hal ini dapat terjadi karena banyak operasi dalam paket FHIR atau kombinasi operasi CRUD.

Pertimbangkan skenario berikut:

Paket transaksi FHIR yang memperbarui resource Pasien dan resource FHIR lainnya akan mengunci resource Pasien hingga transaksi selesai.
Beberapa paket FHIR mencoba mengupdate resource Pasien secara paralel, dan terjadi pertentangan kunci. Respons error menyertakan kolom diagnostics dengan teks Resource type: PATIENT.

Anda dapat mencoba lagi mengupdate resource Pasien dengan backoff eksponensial, tetapi periode pertentangan kunci yang lama dapat menyebabkan waktu tunggu habis, throughput berkurang, dan peningkatan penggunaan resource.
Server FHIR Cloud Healthcare API pada akhirnya mendeteksi backlog transaksi dan load-shed dengan menampilkan error operation_too_costly. Tindakan ini akan membatasi traffic dan mencegah error lebih lanjut.

Error operation_too_costly membatasi semua operasi FHIR CRUD di project Google Cloud Anda, yang memengaruhi semua aplikasi yang terhubung ke project Anda.

Memecahkan masalah `429 Too Many Requests` error

Untuk memecahkan masalah error 429 Too Many Requests, telusuri Cloud Logging. Error yang berisi operation_too_costly menunjukkan pertentangan kunci. Jika error disebabkan oleh kehabisan resource, periksa masalah kuota.

Jika throttling terjadi, paket transaksi mungkin gagal karena tingkat pertentangan kunci yang tinggi dan menghasilkan error berikut:

HTTP/1.1 429 Too many requests
...

{
  "issue": [
    {
      "code": "too-costly",
      "details": {
        "text": "operation_too_costly"
      },
      "diagnostics": "aborted due to cumulative heavy load or lock contention in this project while executing transactional bundle, please see https://cloud.google.com/healthcare-api/docs/troubleshooting#fhir_transaction_bundle_heavy_load for more information",
      "severity": "error"
    }
  ],
  "resourceType": "OperationOutcome"
}

Untuk memecahkan masalah error ini, buka link Paket transaksi FHIR dibatalkan karena beban berat kumulatif di kolom diagnostics.

Hindari paket besar

Error 429 Too Many Requests cenderung terjadi pada paket transaksi yang besar. Paket dengan berbagai ukuran dapat menyebabkan bottleneck throughput. Uji berbagai paket untuk menemukan ukuran yang optimal.

Paket besar yang memiliki percobaan ulang dapat menurunkan hasil performa dan lebih rentan mengalami beberapa kegagalan. Klien harus menerapkan logika tambahan untuk mengelola subset resource FHIR yang gagal dalam transaksi.

Paket batch dapat mengalami error 429 Too Many Requests dan 413 Request Entity Too Large serta bottleneck throughput jika paket tersebut besar atau memiliki QPS tinggi.

Hindari menggunakan paket besar dengan ribuan transaksi. Sebagai gantinya, lakukan hal berikut:

Gunakan paket transaksi yang lebih kecil yang mendukung konsistensi data. Jika resource FHIR tidak saling bergantung, perbarui secara terpisah. Misalnya, resource FHIR mungkin tidak bergantung pada versi spesifik resource lain dalam paket yang sama.
Gunakan beberapa pengelompokan dalam paket dan hindari permintaan individual. Pengelompokan dapat meningkatkan performa, tetapi batch besar dapat menyebabkan error dan menurunkan throughput data. Paket batch yang berukuran serupa memiliki lebih sedikit pertentangan karena tidak menyimpan kunci di seluruh update resource FHIR.

Paket transaksi kecil menghindari pertentangan karena hanya menyimpan beberapa kunci dalam satu waktu dan selesai dengan cepat. Hal ini membantu mencegah tumpukan transaksi yang ditumpuk.

Throughput LRO

Lihat throughput data LRO.

Opsi penyimpanan data FHIR

Jika volume data FHIR Anda kecil hingga sedang, gunakan fhir.create untuk menyimpan data. Untuk menyimpan resource FHIR dalam volume besar, gunakan fhir.executeBundle atau fhirStores.import. Untuk mengetahui informasi tentang setiap metode, lihat Opsi impor FHIR.

Mengimpor resource FHIR

Pertimbangkan hal berikut saat memutuskan apakah akan menggunakan impor FHIR:

Impor FHIR tidak membatasi ukuran total data yang diimpor. Jika paket FHIR melebihi 50 MB, Anda dapat mengupload resource FHIR ke Cloud Storage dan mengimpornya. Hindari latensi tinggi atau impor besar secara serentak, atau throughput data mungkin terbatas.
Impor FHIR memiliki lebih sedikit kompleksitas dibandingkan dengan menggunakan paket FHIR. Misalnya, Anda tidak perlu melakukan hal berikut:
- Mempartisi paket besar menjadi paket yang lebih kecil
- Kelola jadwal
- Mencoba lagi error sementara di tingkat resource atau paket
Impor FHIR tidak menerapkan integritas referensial. Untuk mengetahui informasi selengkapnya, lihat Integritas referensial FHIR.
Jangan gunakan impor FHIR saat keaktualan data menjadi prioritas yang tinggi. Proses impor bisa cepat, tetapi dapat tertunda selama berjam-jam atau berhari-hari.
Impor FHIR akan berperforma lebih baik jika ada sedikit LRO di project Google Cloud Anda.
Impor FHIR dapat mencapai throughput data yang tinggi jika aplikasi Anda dapat menangani error dan kegagalan massal pada subset resource.

Menggunakan paket FHIR

Gunakan paket FHIR, bukan impor FHIR dalam kasus berikut:

Untuk membuat pipeline guna menyimpan data di Cloud Storage dan mengimpornya, biaya penagihan atau bandwidth jaringan terlalu mahal.
Integritas referensial harus ditegakkan.
Validasi profil FHIR harus diterapkan.
Anda harus mengirimkan notifikasi Pub/Sub saat resource FHIR disimpan. Impor FHIR tidak mendukung notifikasi Pub/Sub.
Keaktualan data merupakan prioritas dan data harus diserap dalam hitungan detik atau menit. Namun, bahkan dalam sistem yang dirancang dengan baik, throughput data dapat dibatasi oleh hal berikut:
- Penundaan upstream dalam pemrosesan pipeline. Pipeline mungkin memerlukan lebih banyak waktu untuk menyiapkan data sebelum data dapat diserap.
- Backoff, percobaan ulang, dan lapisan proxy pembentuk traffic.

Paket FHIR memiliki batasan berikut:

Kuota dan penagihan diterapkan ke setiap operasi dalam paket seolah-olah setiap operasi dijalankan secara independen. Misalnya, jika paket memiliki 10 operasi POST, 5 operasi GET, dan 1 operasi DELETE, kuota dan penagihan yang diterapkan pada paket sama seolah-olah operasi tersebut dijalankan secara independen.
Paket transaksi besar lebih cenderung memiliki konflik transaksi yang menyebabkan pertentangan kunci. Untuk informasi selengkapnya, lihat Mencegah error 429 Resource Exhausted operation_too_costly.
Paket batch dapat meningkatkan throughput data, tetapi tidak memiliki kemampuan konsistensi transaksional seperti integritas referensial.
Paket dengan batch besar dapat mengurangi throughput. Untuk informasi selengkapnya, lihat Menghindari paket besar.

Opsi penyimpanan data DICOM

Anda dapat menggunakan metode berikut untuk mencapai throughput data yang tinggi saat mengirim data dari Picture Archive and Communication System (PACS) ke Cloud Healthcare API:

Adaptor DICOM Cloud Healthcare API open source menggunakan protokol elemen layanan pesan DICOM (DIMSE)

Adaptor mengoptimalkan throughput data saat Anda menyinkronkan PACS dengan Cloud Healthcare API. Sebelum menyinkronkan, jalankan uji performa dan verifikasi bahwa adaptor dapat mempertahankan throughput data puncak.

Gunakan adaptor ini jika Anda tidak dapat mengupload file DICOM ke Cloud Storage menggunakan Storage Transfer Service atau opsi transfer lainnya. Misalnya, Anda mungkin tidak dapat memenuhi persyaratan Storage Transfer Service berikut:

Memasang sistem file ke setiap mesin yang menghosting agen di kumpulan agen Anda untuk mengambil data sumber.
Jika mentransfer data pada interval reguler, bukan pemuatan batch satu kali, Anda harus mengukur perubahan ukuran data dari waktu ke waktu untuk menentukan apa yang berubah.
Memaksimalkan performa transfer agen.
Membayar dan mengalokasikan penyimpanan Cloud Storage.
Memvalidasi transfer data ke Cloud Storage.
Menghapus resource Cloud Storage setelah Anda mengimpor data ke Cloud Healthcare API dan memperbaiki error impor apa pun.
Menjadwalkan interval penyerapan batch berdasarkan kapasitas penyimpanan dan jaringan sistem klinis.

Sebaiknya gunakan Storage Transfer Service untuk satu pemuatan batch guna mengisi penyimpanan DICOM. Penggunaan Storage Transfer Service secara rutin memerlukan pekerjaan tambahan, seperti pipeline impor sinkron. Untuk mengetahui informasi selengkapnya, lihat detail transfer sistem file Storage Transfer Service.

dicomStores.import

Gunakan metode ini untuk menyimpan data DICOM dalam jumlah besar.

Transaksi Toko DICOMweb

Gunakan metode ini untuk menyimpan data DICOM secara terprogram.

Mengelola kuota untuk mengoptimalkan throughput data

Bagian berikut menjelaskan cara mengelola dan merencanakan kuota untuk mengoptimalkan throughput data. Untuk praktik terbaik umum tentang pengelolaan kuota, lihat Praktik terbaik pengelolaan kuota.

Kuota rencana untuk traffic yang dapat diprediksi

Rencanakan persyaratan kuota Anda dengan menganalisis terlebih dahulu traffic harian standar aplikasi klien. Bahkan jika traffic dapat diprediksi, rencanakan kuota lebih banyak dari rata-rata yang Anda perlukan. Hal ini membantu Anda menghindari error dan memberikan margin keamanan terhadap lonjakan traffic atau peningkatan penggunaan sehari-hari yang sesekali.

Diagram berikut menunjukkan permintaan ke Cloud Healthcare API yang ukurannya konsisten dan dikirim dalam pola yang dapat diprediksi:

Perbandingan penggunaan kuota antara jam puncak dan standar. — **Gambar 1.** Beban API per jam gabungan di seluruh set data dan penyimpanan data di project Google Cloud.

Kuota rencana untuk permintaan volume besar

Hindari menjadwalkan tugas dengan batch besar selama jam sibuk. Untuk informasi selengkapnya, lihat Mendukung transaksi bervolume rendah secara konsisten.

Diagram berikut menunjukkan pola traffic yang dapat diprediksi. Namun, permintaan batch dalam jumlah besar selama periode traffic puncak melebihi kuota yang tersedia. Hal ini dapat menyebabkan error 429 Resource Exhausted untuk semua permintaan dalam project Anda.

Perbandingan penggunaan kuota antara jam puncak dan jam biasa dengan puncak yang lebih tinggi. — **Gambar 2.** Distribusi penggunaan resource yang tidak teratur yang disebabkan oleh tugas batch yang besar selama jam sibuk.

Jika sistem Anda memiliki kuota fleksibilitas tambahan, lonjakan traffic kecil tidak akan menyebabkan error atau menyebabkan pemuatan puncak yang dapat diprediksi untuk mengalami error. Lonjakan kecil harus didistribusikan di antara banyak penyimpanan data, aplikasi, dan klien lain yang menghasilkan beban dalam project Google Cloud.

Untuk mencegah satu tugas batch besar menyebabkan lonjakan traffic, lihat Menghindari paket besar.

Meminta kuota tambahan

Untuk mempertahankan throughput data yang tinggi dan menghindari error 429 Resource Exhausted, lihat praktik terbaik di halaman ini, khususnya Mengelola kuota untuk mengoptimalkan throughput data. Praktik terbaik ini memastikan bahwa aplikasi klien Anda andal dan dapat diskalakan dengan perubahan volume permintaan. Meminta kuota tambahan tanpa menerapkan praktik terbaik kemungkinan tidak akan mencegah error dalam jangka panjang.

Jika Anda menerapkan praktik terbaik dan masih memerlukan lebih banyak kuota, lihat Praktik terbaik untuk meminta kuota tambahan.

Resource throughput penyerapan data

Untuk mengetahui informasi lebih lanjut tentang throughput penyerapan data, lihat Mengelola traffic dan beban untuk beban kerja Anda di Google Cloud.