Apa itu sistem informasi yang sarat muatan seperti hypermarket besar? Bagaimana jika 150 juta orang datang ke hypermarket secara bersamaan untuk berbelanja? Untuk apa Anda bisa menghukum kepala hypermarket, dan mengapa tidak? Mengapa waktu pemuatan dokumen pada malam hari jauh lebih sedikit daripada siang hari? Mengapa waktu pemuatan satu dokumen tidak berarti apa-apa?

Sistem informasi yang sarat muatan memiliki karakteristiknya sendiri, yang tidak jelas bagi banyak organisasi pemasok. Kami akan memberi tahu Anda bagaimana pemuatan massal dokumen (dan data lainnya) diatur dan mempertimbangkan secara terperinci pertanyaan yang sulit dipahami ini bagi banyak orang.

Sumber

Ketika mengembangkan sistem informasi besar (IS), tugas-tugas pemuatan data massal muncul. Tipe data tidak masalah dan tergantung pada area subjek Anda. Ini bisa berupa pembayaran, tagihan, pembacaan sensor, proyek pengadaan, dll. Pembuatan dan pengembangan GIS (sistem informasi negara) diatur oleh hukum dan dapat dengan mudah terjadi bahwa hukum akan mewajibkan organisasi untuk mengunggah jutaan dokumen ke sistem satu kali atau, bahkan lebih menarik, mengunggah jutaan dokumen secara berkala, misalnya, bulanan.

Dalam proyek kami (sedikit tentang pekerjaan LANIT dapat dibaca di sini dan di sini ), kami secara berkala menghadapi tugas-tugas tersebut dan telah mengembangkan semua solusi yang diperlukan. Namun, spesifikasi solusi memiliki beberapa fitur yang, ternyata, tidak jelas bagi banyak organisasi pemasok. Yang mengejutkan, kami menerima permintaan dan bahkan keluhan seperti itu:

• “Kami mengirim satu dokumen untuk diunduh, dan butuh waktu 10 detik. Karena itu, jika organisasi kami perlu mengunggah 100 ribu dokumen, maka kami akan membutuhkan 100.000 * 10/3600 = 277 jam untuk kami! "
• "Kami memuat, memuat dokumen, tetapi tidak ada yang dimuat ke dalam sistem."

Fakta bahwa memuat satu dokumen ke dalam sistem informasi dapat memakan waktu 10 detik tidak mengatakan apa-apa tentang sistem itu sendiri. Indikator ini tidak masuk akal sama sekali jika kita berbicara tentang sistem antrian. Selanjutnya, kami akan memberi tahu Anda bagaimana pemuatan massal dokumen (dan data lainnya) diatur dan mempertimbangkan secara rinci pertanyaan ini yang tidak jelas bagi banyak orang.

Sedangkan untuk memuat kesalahan, tidak semuanya jelas juga: ada banyak alasan mengapa data tidak dimuat ke dalam sistem. Masalah mungkin ada di sisi penyedia informasi dan mungkin di sisi IP. Di bawah ini kami akan menganalisis berbagai situasi dan melihat statistik.

Hypermarket Cina

Sebagai contoh, di provinsi Cina yang jauh, di mana sekitar 150 juta orang tinggal, hanya ada satu supermarket besar 24 jam di mana orang pergi membeli beras sebulan sekali. Warga bisa datang untuk beras setiap hari dalam sebulan. Ada banyak beras, ada banyak tempat di lantai perdagangan. Hambatan utama adalah pembayaran untuk pembelian di kasir, karena operasi ini wajib (Anda tidak dapat melewati pembeli tanpa pembayaran), itu membutuhkan waktu dan penggunaan peralatan khusus - checkout. Akan lebih baik bagi hypermarket bagi orang-orang entah bagaimana setuju di antara mereka sendiri dan datang berbelanja secara merata (siang dan malam), dalam hal penggunaan meja kas akan seefisien mungkin.

Namun, seperti keberuntungan, pembeli tidak pergi ke hypermarket. Pertama, mereka entah bagaimana tidak benar-benar ingin berbelanja di malam hari. Kedua, kadang-kadang mereka tidak terbatas: entah tidak ada siapa-siapa, lalu beberapa juta orang datang pada saat bersamaan.

Sumber Pusat perbelanjaan terbesar di dunia, Pusat Global New Century di Chengdu di Cina. Ini memiliki 18 lantai dan luas 1.700.000 sq.m.

Apa yang harus dilakukan di supermarket? Partai Komunis Tiongkok telah menetapkan tugas untuk melayani semua orang Tionghoa, dan hanya itu. Setiap orang Tionghoa yang tidak terlayani adalah minus bagi karma manajer supermarket. Jika ada terlalu banyak orang Cina yang tidak puas, jangan hancurkan kepalanya untuknya! Pada saat yang sama, tentu saja, manajer tidak dapat memberikan 150 juta meja kas. Jika tiba-tiba dalam setahun pengendali licik akan membawa laporan bahwa box office digunakan sebesar 1%, maka sutradara yang malang akan menghadapi nasib yang tidak menyenangkan. Jika pembeli biasa menunggu terlalu lama (lebih dari satu menit), maka dia akan kehabisan hypermarket dan menulis pernyataan untuk kawan Mao sendiri, meneriakkan "lima ratus empat penipu Gatevanau tameaut Khan untuk kalian semua".

Setelah mengawasi bagaimana cara kerjanya, teman kami memperkenalkan sistem manajemen antrian yang canggih. Sekarang semuanya berfungsi seperti ini. Setelah mengambil sebungkus beras, pembeli pergi ke terminal untuk menerima nomor dalam antrian. Waktu tunggu dalam antrean tergantung pada jumlah meja kas. Secara eksperimental, direktur pendamping menemukan berapa banyak meja kas seharusnya sehingga pembeli, di satu sisi, tidak mengantre terlalu lama, dan di sisi lain, koefisien penggunaan meja kas tidak terlalu rendah.

Sumber

Semua orang senang. Sistem tiket sangat sederhana dan selalu cepat. Jumlah register kas dipilih sehingga:

• rasio pemanfaatan register kas memungkinkan rekan direktur untuk hidup bahagia selamanya;
• panjang antriannya kecil dan orang Cina menghabiskan sedikit waktu di dalamnya (95 persen dari waktu tunggu <nilai yang masuk akal, misalnya, 5 menit);
• bahkan jika sebagai akibat dari keadaan banyak pembeli akan datang ke toko pada waktu yang sama, waktu tunggu akan diperpanjang, tetapi mereka akan dilayani sampai pukul 23:00 malam sehingga mereka dapat kembali ke rumah dan menonton siaran berita sebelum tidur.

Tentang hal yang sama harus diatur IP dalam hal penerimaan massal dokumen. Misalnya, kita setiap bulan harus memastikan pemuatan total setidaknya 150 juta dokumen dari 100 ribu pemasok. Agar kualitas data yang diunduh menjadi tinggi, perlu untuk memeriksa semua data sebelum mengunduh. Data yang salah dibuang. Dan yang benar harus diletakkan dalam bentuk terstruktur dalam penyimpanan sistem sehingga mereka dapat dianalisis dan digunakan di masa depan.

Kebutuhan untuk memverifikasi data sebelum mengunduh mengarah pada fakta bahwa Anda perlu melakukan sejumlah "kontrol", mulai dari yang diformat dan diakhiri dengan yang kompleks (misalnya, terkadang kontrol bisnis diperlukan yang membuktikan bahwa organisasi memiliki dasar untuk mengunduh objek yang ditransfer).

Kami biasanya tidak dapat mengorbankan kualitas cek. Kami percaya bahwa pengembang telah mengoptimalkan semua algoritma dan optimasi lebih lanjut terlalu memakan waktu atau mempersulit pemeliharaan dan pengembangan sistem lebih lanjut. Pada proyek kami, waktu pemrosesan satu permintaan yang terdiri dari satu hingga lima ratus dokumen (pembayaran, faktur, kontrak, proyek pengadaan, dll.), Rata-rata, beberapa detik di backend (lihat contoh pada Gambar 1). Waktu ini tidak konstan, tetapi bervariasi dalam batas-batas tertentu, karena dalam sistem yang kompleks selalu ada banyak faktor berbeda yang dapat mempengaruhi pemrosesan suatu paket.

Gambar 1. Garis waktu tipikal untuk memproses paket dokumen. Waktu rata-rata di wilayah tiga detik.

Bahkan jika untuk IS Anda, tanggal pengunduhan diatur oleh hukum, maka untuk penyedia dokumen, sebagai suatu peraturan, tidak ada jadwal pengunduhan yang jelas. Ada template tertentu untuk berbagai jenis dokumen, misalnya, faktur dapat diterbitkan pada awal bulan, puncak dalam memuat data lain dapat ditentukan oleh ketentuan dokumen normatif atau dapat dikaitkan dengan akhir tahun, dll.

Oleh karena itu, dalam praktiknya, pada saat tertentu, intensitas pemuatan dokumen bisa sangat berbeda - hampir tidak mungkin untuk secara akurat memperkirakannya. Mungkin saja 150 juta dokumen pemasok yang baik memutuskan untuk mengunggah ke sistem pada saat yang bersamaan. Dan ini bukan hal yang sama sekali, seolah-olah mereka mengunduhnya dengan ketat sesuai jadwal 5 juta per hari.

Gambar 2. Contoh distribusi jumlah dokumen yang diunduh per hari selama enam bulan terakhir.

Gambar 2 menunjukkan bahwa jumlah dokumen yang dimuat per hari sangat bervariasi. Jelas bahwa rata-rata sekitar 4-5 juta dokumen diunduh per hari. Pada saat yang sama, beberapa hari lebih dari 10 juta dokumen dikirim ke sistem. Jumlah maksimum dokumen yang diunggah per hari adalah lebih dari 17 juta.

Jika kita melihat dinamika pemuatan dokumen per jam, kita akan melihat fluktuasi lalu lintas yang lebih besar. Pada beberapa jam, 50 ribu dokumen dimuat ke dalam IS, dan pada beberapa jam jumlah dokumen yang dimuat melebihi 1 juta. Semakin pendek interval yang kita ambil, semakin besar spread dalam beban yang kita lihat.

Jelas, dua, tiga, dan sepuluh juta dokumen dapat secara bersamaan memasuki sistem. Oleh karena itu, ketika merancang mekanisme pemuatan massal, kami menggunakan buffering query menggunakan antrian. Setiap permintaan dari pengguna pertama kali disimpan dalam antrian. Dengan demikian, kami dapat menerima permintaan untuk menerima dokumen dengan intensitas sangat tinggi ke dalam sistem, karena operasi penerimaan permintaan sangat sederhana. Tetapi validasi dan pemuatan dokumen sudah dilakukan oleh "prosesor" khusus, yang jumlahnya disesuaikan tergantung pada kapasitas yang tersedia. Semakin banyak zat besi, semakin banyak "prosesor", semakin banyak permintaan yang dapat diproses sistem pada saat bersamaan.

Kekuatan kompleks perangkat keras-IP perangkat lunak ditentukan oleh bandwidth dan biaya perangkat keras yang diperlukan. Kita perlu menemukan keseimbangan agar kita (pelanggan) puas dengan pemanfaatan besi selama periode beban rendah, dan pada saat yang sama, selama periode puncak, antrian data untuk memuat tidak tumbuh terlalu banyak. Mengingat bahwa pada malam hari paling sering kita mengalami penurunan beban secara alami, kita dapat menggunakan pedoman - semua data harus diunduh baik pada hari yang sama atau semalam. Jika semakin sering terjadi bahwa data tidak memiliki waktu untuk memuat semalaman, maka ini adalah sinyal untuk meningkatkan throughput dengan menambahkan zat besi.

Gambar 3. Contoh jadwal untuk mengubah panjang antrian untuk memuat paket data.

Gambar 3 menunjukkan statistik pada panjang antrian untuk mengunduh paket data. Perlu diperhatikan bahwa pada siang hari kita memiliki punuk karakteristik, dan pada malam hari antrian diatur ulang.

Karena waktu buka paket data adalah jumlah waktu tunggu dalam antrian dan waktu pemrosesan paket data di backend, waktu muat di malam hari jauh lebih sedikit daripada siang hari (lihat Gambar 4).

Gambar 4. Waktu pengunduhan untuk paket data. Rata-rata untuk periode tersebut adalah 11,92 menit. Waktu boot termasuk waktu antrian dan waktu pemrosesan backend.

Kami dapat menyimpulkan: jika pemasok mengirim paket data pada malam hari, waktu pengunduhan akan minimal. Di sisi lain, jika kapasitas IC dipilih sedemikian rupa untuk memproses jumlah data yang diharapkan pada hari yang sama atau maksimum per malam, maka pemasok tidak masuk akal untuk menjaga pemuatan data - Anda hanya perlu mengirim seluruh jumlah dokumen, dan akan diproses secepat mungkin.

Bagaimana memberi makan seluruh desa

Mari kita kembali ke klaim kita. “Kami mengirim satu dokumen untuk diunduh, dan butuh waktu 10 detik. Karena itu, jika organisasi kami perlu mengunggah 100 ribu dokumen, kami akan membutuhkan 100.000 * 10/3600 = 277 jam untuk kami! ”

Setiap pelanggan yang tiba di hypermarket pada waktu yang berbeda dapat dilayani pada waktu yang berbeda. Itu akan tergantung pada berapa banyak pelanggan yang datang ke toko. Pada malam hari, meja kas cenderung kosong dan pembeli akan segera dilayani. Dan pada jam sibuk Anda dapat mengantri selama beberapa jam.

Sumber

Apa yang harus dilakukan jika Anda perlu membeli beras di desa berpenduduk 100 ribu? Tidak masuk akal untuk mengirim setiap penduduk desa satu per satu ke hypermarket (yang berikutnya keluar hanya setelah yang sebelumnya kembali). Jelas, dalam hal ini, pembelian beras untuk seluruh desa akan berlangsung berjam-jam atau sehari, karena Anda harus mengantri 100 ribu kali berturut-turut. Di sisi lain, jika semua penduduk desa datang ke hypermarket sekaligus, antri bersama-sama, maka mereka akan mengantre pada saat yang bersamaan. Bahkan, mereka hanya mengantri sekali. Waktu tunggu mereka dalam antrean juga akan sangat tergantung pada jumlah meja kas.

Dengan kata lain, waktu pemuatan sejumlah besar data dipengaruhi oleh beban saat ini pada sistem (jumlah paket dalam antrian) dan throughput sistem (intensitas pemrosesan paket-paket ini). Indikator seperti waktu pemuatan paket individu itu sendiri tidak cukup dan mengarah pada kesimpulan yang salah.

Untuk memuat sejumlah besar data ke IS, Anda tidak perlu mengirim permintaan secara berurutan, menunggu yang sebelumnya diproses. Penting untuk mengirim semua permintaan ke IS sekaligus, mereka akan antri dan diproses oleh "prosesor" khusus dengan intensitas tergantung pada kapasitas dan kemampuan yang tersedia. Jelas, biasanya bandwidth IP secara signifikan melebihi kebutuhan masing-masing penyedia data tertentu.

Akibatnya, metode sinkron tidak cocok untuk memuat massal - ini adalah antipattern.

Untuk apa Anda bisa menghukum sesama direktur?

Apa yang paling mengkhawatirkan tentang seorang rekan sutradara dalam cerita ini? Untuk apa mereka menghukumnya?

Pelanggan mungkin ditolak layanan - ini selalu tidak menyenangkan. Tetapi ada banyak alasan mengapa ini bisa terjadi, dan mereka memiliki sifat yang berbeda. Mari daftar.

1. Jika sistem antrian tidak berfungsi, ini sangat buruk. Sangat buruk sehingga hari berikutnya situasi seperti ini beres di kantor Kamerad Mao.

2. Jika garis di hypermarket meningkat dan pelanggan mulai bertahan di sana untuk waktu yang lama, maka ini mencurigakan, tetapi tidak serta merta buruk. Ini harus dipantau, tetapi ada dua situasi:

• antrian bertambah karena kenyataan bahwa terlalu banyak orang Cina datang pada waktu yang sama, misalnya, karena rumor tentang kenaikan harga;
• antrian bertambah karena fakta bahwa untuk beberapa alasan banyak box office telah rusak. Situasi ini sudah buruk, akan dipahami pada pertemuan perencanaan dan dapat menyebabkan teguran.

3. Jika orang Cina tertentu tidak dapat membeli beras, maka ini dapat juga karena berbagai alasan:

• jika orang Cina lupa mengambil uang itu, maka ini bukan kesalahan rekan direktur;
• jika di kasir terjadi sesuatu atau kasir memarahi orang Cina, maka ini sudah menjadi masalah hypermarket. Jika proporsi insiden tersebut meningkat ke tingkat tertentu, maka ini akan menjadi masalah besar.

Jelas bahwa untuk setiap IP karakteristik penting dari mekanisme pemuatan massa adalah persentase penolakan layanan. Penting untuk membedakan antara penolakan layanan karena alasan teknis terkait operasi IS (kegagalan peralatan, kesalahan sistem, dll.) Dan kegagalan karena alasan yang terkait dengan masalah di sisi pemasok (format paket data yang salah, data yang salah dari sudut pandang bisnis) kontrol, dll.).

Situasi mungkin berbeda. Tetapi jika IP dikembangkan dengan mempertimbangkan prinsip-prinsip di atas dan ada proses pemantauan berkelanjutan dan penghapusan kesalahan teknis, maka cepat atau lambat situasinya akan stabil. Pada sistem yang berfungsi dengan baik, statistik pada unduhan paket terlihat seperti tabel 1.

	Jumlah permintaan unduhan, pcs	Bagikan%
Paket yang Diunggah Sepenuhnya Berhasil	125 977 459	79,94%
Paket yang tidak dimuat penuh atau sebagian karena masalah di sisi pemasok (FLC, kontrol bisnis)	29 936 543	19%
Paket yang tidak diunduh karena masalah di sisi IP	38 805	0,02%
Paket Gandakan	1.638.886	1,04%
Total	156 812 782	100%

Tabel 1. Unduh statistik untuk Juli 2018

Tabel ini menunjukkan bahwa sebagian besar paket berhasil dimuat. Apalagi proporsi kesalahan yang tinggi di sisi penyedia informasi. Ini mungkin disebabkan oleh banyaknya pemasok dan tingkat kesiapan mereka yang berbeda untuk pertukaran informasi. Pemasok mungkin memiliki data berkualitas rendah, mereka mungkin memiliki masalah dengan sistem informasi. Beberapa data mungkin tidak tersedia dalam bentuk terstruktur elektronik, dan butuh waktu untuk menerimanya.

Sayangnya, kesalahan IP dapat terjadi, terutama jika perkembangannya yang cepat sedang berlangsung. Adalah penting bahwa proses pemantauan kesalahan di lingkungan industri dan analisis penyebab terjadinya mereka diluncurkan. Kami menggunakan sistem pemantauan yang dikembangkan untuk mekanisme integrasi pada proyek kami di LANIT, dan jika kami melihat bahwa jumlah kesalahan mulai tumbuh, kami menentukan sumbernya dan mencoba mengambil tindakan korektif dengan cepat.

Kesimpulan

Sebagai kesimpulan, saya ingin mengulangi poin utama lagi.

1. Dalam pengembangan dan pengembangan IP negara atau perusahaan, tugas pemuatan data massal muncul. Aliran permintaan unduhan ke IS, sebagai suatu peraturan, adalah acak. Ini berarti bahwa kita kira-kira mengetahui distribusi, tetapi pada saat tertentu sangat sedikit dan banyak permintaan mungkin datang.
2. Mekanisme untuk menerima data untuk pemuatan massal harus dibangun menggunakan antrian. Intinya tidak mungkin dengan cara lain. Kalau tidak, kita harus membiarkan kehilangan data jika sejumlah besar data datang untuk diunduh, atau kita perlu menggunakan sangat, sangat banyak zat besi, yang akan menganggur 99% dari waktu.
3. Waktu pemuatan data terdiri dari waktu tunggu dalam antrian dan waktu pemrosesan data. Waktu pemrosesan paket data pada backend dengan desain dan proses pengembangan yang memadai adalah detik atau milidetik. Waktu tunggu antrian (menit) tergantung pada jumlah penangan yang digunakan oleh sistem. Jumlah prosesor ditentukan oleh kekuatan kompleks perangkat keras-perangkat lunak. Lebih banyak besi - lebih banyak penangan, lebih cepat antrian. Begitu juga sebaliknya.
4. Layanan sinkron tidak berlaku untuk unduhan massal, sehingga tidak disarankan.
5. Jika Anda pemasok dan Anda perlu mengunggah banyak data, segera kirim semuanya ke IP. Dalam hal apa pun Anda tidak boleh mengirim data secara berurutan (paket berikutnya tidak dikirim sampai yang sebelumnya diunduh).