Praktik terbaik throughput penyerapan data

Halaman ini menjelaskan praktik terbaik untuk mengoptimalkan throughput data saat menyerap data ke Cloud Healthcare API. Rekomendasi ini ditujukan untuk praktisi teknis yang berpengalaman 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 throughput data mungkin dibatasi:

• Anda tidak merencanakan permintaan dalam volume 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 impor dan ekspor kecil.
• Terlalu banyak operasi yang berjalan lama (LRO) yang berjalan secara serentak dan bandwidth terbatas.
• Terlalu banyak LRO yang dijadwalkan secara bersamaan sehingga menyebabkan kegagalan.

Mencoba lagi permintaan yang gagal

Jika klien mencoba ulang permintaan dengan cepat dan berulang kali setelah gagal, klien dapat melebihi kuota Cloud Healthcare API. Bagian berikut menjelaskan cara mencoba ulang 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 ulang permintaan yang gagal dengan penundaan yang meningkat secara eksponensial di antara percobaan ulang dan penundaan acak kecil.

Pastikan penerapan backoff eksponensial Anda bersifat idempotent untuk setiap percobaan ulang, terutama jika Anda menggunakan logika kustom untuk mengabaikan kondisi kegagalan. Lihat 9.2.2 Idempotent Methods dalam spesifikasi HTTP untuk mengetahui informasi selengkapnya.

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 ulang permintaan ini:

• Operasi yang mengubah resource FHIR atau paket resource FHIR.

• Permintaan LRO sinkron. Coba lagi jika ada 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 dalam operasi impor atau pembuatan.
  • Gunakan permintaan sinkron untuk data yang gagal diproses.

Contoh algoritma backoff eksponensial

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

1. Kirim permintaan ke Cloud Healthcare API.

2. Jika permintaan gagal, tunggu 1 + random-fraction detik, lalu coba lagi permintaan tersebut.

3. Jika permintaan gagal, tunggu 2 + random-fraction detik, lalu coba lagi permintaan tersebut.

4. Jika permintaan gagal, tunggu 4 + random-fraction detik, lalu coba lagi permintaan tersebut.

5. Lanjutkan pola ini, menunggu 2ⁿ + random-fraction detik setelah setiap percobaan ulang, hingga maximum-backoff kali.

6. Setelah deadline detik, berhenti mencoba lagi permintaan tersebut.

Gunakan nilai berikut saat Anda mengimplementasikan algoritme:

• Sebelum setiap percobaan ulang, waktu tunggu adalah min((2n + 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 mencegah klien menjadi 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 ulang tanpa batas waktu.

Menerapkan pembatasan kapasitas sisi klien dengan pembentukan traffic

Pembatasan kapasitas melindungi sistem berskala besar dengan mencegahnya dibanjiri permintaan yang berlebihan. Jika pembatasan kapasitas sisi klien tidak memadai, sistem kuota Cloud Healthcare API dapat membatasi throughput data. Untuk informasi selengkapnya, lihat Praktik terbaik untuk pengelolaan kuota.

Jika Anda memiliki persyaratan tambahan, seperti pengiriman terjamin di seluruh percobaan ulang, strategi di Mencoba ulang permintaan yang gagal mungkin tidak memadai. Traffic shaping adalah teknik pembatasan kapasitas yang menjaga kapasitas permintaan sisi klien dalam batasan bandwidth. Hal ini akan menyebarkan lonjakan beban selama berjam-jam atau berminggu-minggu, sehingga meningkatkan throughput. Jika kuota dibatasi, pembentukan traffic dapat mencapai throughput yang lebih tinggi daripada menggunakan percobaan ulang saja karena menghindari pushback dan melacak unit pekerja.

Anda dapat menerapkan pembentukan traffic untuk operasi pembuatan, penghapusan, pembaruan, dan penghapusan (CRUD) sinkron, termasuk fhir.executeBundle.

Persyaratan pembentukan traffic

Untuk menerapkan traffic shaping, sistem Anda harus menerapkan hal berikut:

• Antrean pemrosesan yang didukung penyimpanan dengan redundansi untuk menghindari kegagalan disk.
• Pekerja terkoordinasi untuk mengambil dari antrean pemrosesan.
• Deteksi penggunaan secara keseluruhan untuk menyesuaikan jumlah pekerja dan kecepatan pemrosesannya berdasarkan batas kuota.
• Pemulihan dari bencana untuk antrean pemrosesan yang didukung penyimpanan. Jika terjadi bencana, sistem Anda harus dapat menghapus atau memulihkan antrean.
• Mengurangi LRO selama jam sibuk. Untuk informasi selengkapnya, lihat Merencanakan dan menggunakan kuota secara efisien dan Menyiapkan 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 pekerjaan, seperti kueri per detik (QPS) atau byte yang diserap per detik.

Menerapkan pembatasan kapasitas di area lain sistem Anda

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

• Throttle sisi klien di Apache Beam. Lihat Penskalaan otomatis horizontal untuk mengetahui informasi tentang cara mengontrol throttling menggunakan flag 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 ditampilkan di Menangani error di beberapa lapisan, juga dapat mengontrol throttling di seluruh layanan yang menggunakan Cloud Healthcare API. Bergantung pada jenis traffic shaping yang diperlukan, gunakan salah satu opsi berikut:

Asinkron

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

Sinkron

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

Lapisan proxy dapat menyesuaikan pembatasan kapasitasnya 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 membaca file secara rutin atau melakukan panggilan prosedur jarak jauh (RPC) dengan batas kapasitas yang dienkode.

Pemrosesan sinkron terkadang memiliki kelemahan berikut:

• Resource di lapisan klien dan proxy tidak tersedia saat klien memblokir dan menunggu respons. Hal ini dapat menyebabkan error, waktu tunggu habis, dan throughput data menurun, sehingga mempersulit penskalaan.

• Jika klien dan lapisan proxy terputus, lebih banyak pekerjaan yang diperlukan untuk memastikan data diubah seperti yang diminta.

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 konkurensi permintaan maksimum menggunakan objek RateLimits
• Batas percobaan ulang menggunakan objek RetryConfig

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

Saat menggunakan Cloud Tasks, pertimbangkan hal berikut:

• Cloud Tasks tidak menjamin pengiriman tepat satu kali. Dalam pengiriman tepat sekali, setiap permintaan yang berisi data duplikat akan dikenali sebagai duplikat dan diabaikan oleh server. Untuk mengetahui informasi selengkapnya, lihat Setelah Lambda: pemrosesan tepat satu kali di Dataflow, Bagian 1.
• Ukuran tugas maksimum mungkin jauh lebih kecil dari ukuran paket FHIR maksimum di Cloud Healthcare API. Untuk mengetahui informasi selengkapnya, lihat Kuota dan batas Cloud Tasks dan Kuota dan batas Cloud Healthcare API.
• Cloud Tasks memiliki masalah dan batasan.

Menggabungkan paket FHIR dengan pembatas kapasitas

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

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

Cegah antrean pembatas kapasitas agar tidak penuh dengan memantau resource berikut:

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

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

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

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

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

Connection: keep-alive

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

Library requests Python menggunakan keep-alive HTTP secara default. Jika Anda menggunakan Node.js, tetapkan keepAlive ke true saat 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:

• Bersiaplah untuk lonjakan traffic yang tiba-tiba di 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 alur traffic, atau uji apakah lapisan proxy menangani pushback.
• Buat rencana pemulihan dari bencana. Hal ini biasanya memerlukan reset traffic masuk atau menggunakan 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 mengetahui rekomendasi.
• Buat kebijakan pemberitahuan menggunakan Google Cloud Observability. Kebijakan pemberitahuan memberi tahu Anda tentang masalah seperti jika sistem Anda mengalami tekanan atau memerlukan intervensi manusia.
• Buat playbook operasional agar administrator sistem tahu apa yang harus dilakukan jika kebijakan pemberitahuan mengirimkan notifikasi.

• Gunakan playbook operasional di lingkungan staging untuk merespons skenario berikut:

  • Keterlambatan yang disebabkan oleh pembatasan kapasitas
  • Penolakan yang disebabkan oleh batas kuota yang terlampaui
  • Lonjakan traffic masuk

Mencegah error 429 Resource Exhausted operation_too_costly

Membuat ribuan update paralel setiap hari ke resource FHIR dapat menyebabkan konflik kunci, latensi, dan mencegah transaksi selesai. 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, "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 data database. Hal ini dapat terjadi karena banyak operasi dalam paket FHIR atau kombinasi operasi CRUD.

Pertimbangkan skenario berikut:

1. Paket transaksi FHIR yang memperbarui resource Pasien dan resource FHIR lainnya akan mengunci resource Pasien hingga transaksi selesai.

2. Beberapa paket FHIR mencoba memperbarui resource Pasien secara paralel, dan terjadi pertentangan kunci. Respons error mencakup kolom diagnostics dengan teks Resource type: PATIENT.

   Anda dapat mencoba memperbarui resource Pasien lagi dengan backoff eksponensial, tetapi periode pertentangan kunci yang lama dapat menyebabkan waktu tunggu habis, throughput berkurang, dan penggunaan resource meningkat.

3. Server FHIR Cloud Healthcare API pada akhirnya mendeteksi backlog transaksi dan pengurangan beban dengan menampilkan error operation_too_costly. Tindakan ini membatasi traffic dan mencegah error lebih lanjut.

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

Memecahkan masalah error 429 Too Many Requests

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, buka link FHIR transactional bundle aborted due to cumulative heavy load di kolom diagnostics.

Hindari paket besar

Error 429 Too Many Requests lebih mungkin terjadi dengan paket transaksi besar. Paket dengan ukuran berapa pun dapat menyebabkan bottleneck throughput. Uji berbagai paket untuk menemukan ukuran yang optimal.

Paket besar dengan percobaan ulang dapat memiliki pengembalian performa yang menurun 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 berukuran besar atau memiliki QPS tinggi.

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

• Gunakan paket transaksi yang lebih kecil yang mendukung konsistensi data. Jika resource FHIR tidak bergantung satu sama lain, perbarui secara terpisah. Misalnya, resource FHIR mungkin tidak bergantung pada versi tertentu dari 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 berukuran serupa memiliki lebih sedikit pertentangan karena tidak menahan kunci di seluruh update resource FHIR.

Paket transaksi kecil menghindari pertentangan karena hanya menyimpan beberapa kunci sekaligus dan selesai dengan cepat. Hal ini membantu mencegah backlog 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 jumlah 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 impor dengan latensi tinggi atau besar secara serentak, atau throughput data mungkin terbatas.

• Impor FHIR memiliki kompleksitas yang lebih rendah daripada menggunakan paket FHIR. Misalnya, Anda tidak harus melakukan hal berikut:

  • Mempartisi paket besar menjadi paket yang lebih kecil
  • Mengelola jadwal
  • Mencoba ulang error sementara di tingkat resource atau paket

• Impor FHIR tidak menerapkan integritas referensial. Untuk informasi selengkapnya, lihat Integritas referensi FHIR.

• Jangan gunakan impor FHIR jika keaktualan data merupakan prioritas tinggi. Impor dapat cepat, tetapi dapat tertunda selama berjam-jam atau berhari-hari.

• Impor FHIR 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 sebagian resource.

Menggunakan paket FHIR

Gunakan paket FHIR, bukan impor FHIR, dalam kasus berikut:

• Biaya penagihan atau bandwidth jaringan terlalu mahal untuk membuat pipeline guna menyimpan data di Cloud Storage dan mengimpornya.

• Integritas referensial harus diterapkan.

• Validasi profil FHIR harus diterapkan.

• Anda perlu mengirim notifikasi Pub/Sub saat resource FHIR disimpan. Impor FHIR tidak mendukung notifikasi Pub/Sub.

• Keaktualan data adalah 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 memproses pipeline. Pipeline mungkin memerlukan lebih banyak waktu untuk menyiapkan data sebelum data dapat diserap.
  • Backoff, percobaan ulang, dan lapisan proxy pembentukan 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 ke paket sama seperti jika operasi tersebut dijalankan secara independen.

• Paket transaksi yang 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 referensi.

• Paket 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 Archiving and Communication System (PACS) ke Cloud Healthcare API:

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

Adaptor mengoptimalkan throughput data saat Anda menyinkronkan PACS dengan Cloud Healthcare API. Sebelum menyinkronkan, jalankan pengujian performa dan pastikan 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 Layanan Transfer Penyimpanan ini:

• Memasang sistem file ke setiap mesin yang menghosting agen di kumpulan agen untuk mengambil data sumber.
• Jika Anda mentransfer data pada interval reguler, bukan pemuatan batch satu kali, Anda harus mengukur perubahan pada 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.
• Menjadwalkan interval penyerapan batch berdasarkan kapasitas penyimpanan dan jaringan sistem klinis.

Sebaiknya gunakan Storage Transfer Service untuk satu pemuatan batch guna mengisi penyimpanan DICOM. Menggunakan 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 volume besar.

Transaksi Penyimpanan 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.

Merencanakan kuota untuk traffic yang dapat diprediksi

Rencanakan persyaratan kuota dengan menganalisis traffic harian biasa aplikasi klien Anda terlebih dahulu. Meskipun traffic dapat diprediksi, rencanakan kuota yang lebih besar dari rata-rata yang Anda butuhkan. Hal ini membantu Anda menghindari error dan memberikan margin keamanan terhadap lonjakan traffic atau peningkatan sesekali dalam penggunaan harian.

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

Gambar 1. Total beban API per jam di seluruh set data dan penyimpanan data dalam project Google Cloud.

Merencanakan kuota untuk permintaan bervolume besar

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

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

Gambar 2. Distribusi penggunaan resource yang tidak teratur disebabkan oleh tugas batch besar selama jam sibuk.

Jika sistem Anda memiliki kuota fleksibilitas tambahan, lonjakan traffic kecil tidak akan menyebabkan error atau menyebabkan beban puncak yang dapat diprediksi 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, terutama 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.

Referensi throughput penyerapan data

Untuk mengetahui informasi selengkapnya tentang throughput penyerapan data, lihat Mengelola traffic dan beban untuk workload Anda di Google Cloud.