एक अत्यधिक हाइपरमार्केट की तरह एक अत्यधिक भरी हुई सूचना प्रणाली क्या है? क्या होगा अगर खरीदारी के लिए एक ही समय में 150 मिलियन लोग हाइपरमार्केट में आते हैं? आप हाइपरमार्केट के प्रमुख को क्या दंडित कर सकते हैं, और क्यों नहीं? दिन के दौरान रात में दस्तावेज़ लोडिंग का समय बहुत कम क्यों है? किसी एकल दस्तावेज़ का लोडिंग समय वास्तव में कुछ भी क्यों नहीं है?

अत्यधिक भरी हुई सूचना प्रणाली की अपनी विशेषताएं हैं, जो कई आपूर्तिकर्ता संगठनों के लिए स्पष्ट नहीं हैं। हम आपको बताएंगे कि दस्तावेजों (और अन्य डेटा) के थोक लोडिंग की व्यवस्था कैसे की जाती है और कई लोगों के लिए इस समझ से बाहर के प्रश्न पर विस्तार से विचार करें।

स्रोत

बड़े और अत्यधिक लोड किए गए सूचना प्रणाली (आईएस) को विकसित करते समय, बड़े पैमाने पर डेटा लोडिंग के कार्य उत्पन्न होते हैं। डेटा प्रकार कोई फर्क नहीं पड़ता और आपके विषय क्षेत्र पर निर्भर करता है। यह भुगतान, बिल, सेंसर रीडिंग, खरीद परियोजनाएं आदि हो सकते हैं। जीआईएस (राज्य सूचना प्रणाली) के निर्माण और विकास को कानून द्वारा नियंत्रित किया जाता है और यह आसानी से हो सकता है कि कानून को संगठनों को एक बार में लाखों दस्तावेज़ों को सिस्टम में अपलोड करने की आवश्यकता होती है, या अधिक दिलचस्प बात यह है कि समय-समय पर लाखों दस्तावेज़ अपलोड करें, उदाहरण के लिए, मासिक।

हमारी परियोजनाओं में (LANIT के काम के बारे में थोड़ा यहां और यहां पढ़ा जा सकता है ), हम समय-समय पर ऐसे कार्यों का सामना करते हैं और सभी आवश्यक समाधान विकसित किए हैं। हालांकि, समाधान की बारीकियों में कुछ विशेषताएं हैं, जैसा कि यह निकला, कई आपूर्तिकर्ता संगठनों के लिए स्पष्ट नहीं हैं। हमारे आश्चर्य के लिए, हमें इस तरह के अनुरोध और यहां तक ​​कि शिकायतें भी मिलीं:

• “हमने एक दस्तावेज़ डाउनलोड करने के लिए भेजा, और इसमें 10 सेकंड का समय लगा। इसलिए, यदि हमारे संगठन को 100 हजार दस्तावेज अपलोड करने की आवश्यकता है, तो हमारे लिए 100 000 * 10/3600 = 277 घंटे लगेंगे! ”
• "हम दस्तावेज़ लोड करते हैं, लेकिन सिस्टम में कुछ भी लोड नहीं किया जाता है।"

तथ्य यह है कि एक दस्तावेज़ को सूचना प्रणाली में लोड करने में 10 सेकंड लग सकते हैं, सिस्टम द्वारा अपने बारे में कुछ भी नहीं कहता है। यदि हम कतार प्रणाली के बारे में बात कर रहे हैं तो यह संकेतक बहुत अधिक मायने नहीं रखता है। आगे, हम आपको बताएंगे कि दस्तावेज़ों (और अन्य डेटा) के थोक लोडिंग की व्यवस्था कैसे की जाती है और इस प्रश्न पर विस्तार से विचार करें जो कि बहुतों के लिए स्पष्ट नहीं है।

लोडिंग त्रुटियों के लिए, सब कुछ या तो स्पष्ट नहीं है: सिस्टम में डेटा लोड नहीं होने के कई कारण हैं। समस्या सूचना प्रदाताओं के पक्ष में हो सकती है और आईपी के पक्ष में हो सकती है। नीचे हम विभिन्न स्थितियों का विश्लेषण करेंगे और आंकड़े देखेंगे।

चीनी हाइपरमार्केट

उदाहरण के लिए, एक दूर के चीनी प्रांत में, जहाँ लगभग 150 मिलियन लोग रहते हैं, वहाँ केवल एक बड़ा, 24 घंटे का सुपरमार्केट है जहाँ लोग महीने में एक बार चावल खरीदने जाते हैं। निवासी महीने के किसी भी दिन चावल के लिए आ सकते हैं। बहुत सारा चावल है, ट्रेडिंग फ्लोर में बहुत जगह है। मुख्य अड़चन चेकआउट पर खरीद के लिए भुगतान है, क्योंकि यह ऑपरेशन अनिवार्य है (आप भुगतान के बिना खरीदारों को छोड़ नहीं सकते हैं), इसमें समय लगता है और विशेष उपकरण - कैश डेस्क का उपयोग होता है। लोगों के लिए हाइपरमार्केट के लिए बेहतर होगा कि वे किसी तरह से सहमत हों और समान रूप से (रात और दिन) खरीदारी करें, इस मामले में नकद डेस्क का उपयोग जितना संभव हो उतना प्रभावी होगा।

हालांकि, जैसा कि भाग्य के पास होगा, खरीदार हाइपरमार्केट की ओर नहीं जाते हैं। सबसे पहले, वे वास्तव में रात में खरीदारी करने के लिए नहीं जाना चाहते हैं। दूसरे, कभी-कभी वे असीमित होते हैं: या तो कोई भी नहीं होता है, तो कई मिलियन लोग एक ही समय पर आते हैं।

स्रोत । दुनिया में सबसे बड़ा शॉपिंग सेंटर, चीन में चेंगदू में न्यू सेंचुरी ग्लोबल सेंटर। इसकी 18 मंज़िलें हैं और 1,700,000 sq.m का क्षेत्रफल है।

सुपरमार्केट में क्या करना है? चीनी कम्युनिस्ट पार्टी ने सभी चीनियों की सेवा का कार्य निर्धारित किया है, और यह बात है। प्रत्येक असुरक्षित चीनी सुपरमार्केट प्रबंधक के कर्म का एक ऋण है। यदि बहुत अधिक असंतुष्ट चीनी हैं, तो उसके लिए अपना सिर मत ढहाओ! उसी समय, निश्चित रूप से, प्रबंधक 150 मिलियन नकद डेस्क नहीं दे सकता है। यदि एक वर्ष में अचानक चालाक नियंत्रक एक रिपोर्ट लाएगा कि बॉक्स ऑफिस का उपयोग 1% पर किया जाता है, तो दुर्भाग्यपूर्ण निर्देशक का सामना करना पड़ेगा। यदि एक साधारण खरीदार बहुत लंबा इंतजार करता है (एक मिनट से अधिक), तो वह हाइपरमार्केट से बाहर चला जाएगा और कॉमरेड माओ को एक बयान लिखेगा, जो "पांच सौ और चार चीटर गेटवनाउ तमोगे खान आप सभी को चिल्लाएगा"।

महासागर के ऊपर देखने के बाद कि यह कैसे काम करता है, हमारे मित्र ने एक उन्नत कतार प्रबंधन प्रणाली शुरू की। अब यह सब इस तरह काम करता है। चावल का एक पैकेट लेने के बाद, खरीदार कतार में एक नंबर प्राप्त करने के लिए टर्मिनल पर जाता है। लाइन में प्रतीक्षा समय कैश डेस्क की संख्या पर निर्भर करता है। प्रयोगात्मक रूप से, साथी निदेशक ने पाया कि कितने कैश डेस्क होने चाहिए ताकि खरीदार एक तरफ, बहुत लंबे समय तक लाइन में न खड़े हों, और दूसरी तरफ, कैश डेस्क के उपयोग का गुणांक भी कम नहीं है।

स्रोत

सभी लोग खुश हैं। टिकटिंग प्रणाली बहुत सरल और हमेशा तेज है। नकदी रजिस्टर की संख्या का चयन किया जाता है ताकि:

• नकदी रजिस्टर के उपयोग अनुपात ने साथी निदेशक को कभी भी खुशी से जीने की अनुमति दी;
• कतार की लंबाई छोटी थी और चीनियों ने इसमें बहुत कम समय (प्रतीक्षा समय का 95 प्रतिशत भाग <एक उचित मूल्य, उदाहरण के लिए, 5 मिनट);
• यहां तक ​​कि अगर परिस्थितियों के परिणामस्वरूप कई दुकानदार एक ही समय में स्टोर पर आएंगे, तो प्रतीक्षा समय बढ़ाया जाएगा, लेकिन उन्हें शाम को 23:00 बजे तक परोसा जाएगा ताकि वे घर लौट सकें और सोने से पहले समाचार रिलीज देख सकें।

उसी के बारे में दस्तावेजों के सामूहिक स्वागत के संदर्भ में आईपी की व्यवस्था की जानी चाहिए। उदाहरण के लिए, हमें प्रत्येक माह 100 हजार आपूर्तिकर्ताओं से कम से कम 150 मिलियन दस्तावेजों का लोड सुनिश्चित करना चाहिए। डाउनलोड किए गए डेटा की गुणवत्ता उच्च होने के लिए, डाउनलोड करने से पहले सभी डेटा की जांच करना आवश्यक है। गलत डेटा को छोड़ दिया जाता है। और सही लोगों को सिस्टम स्टोरेज में एक संरचित रूप में रखा जाना चाहिए ताकि भविष्य में उनका विश्लेषण और उपयोग किया जा सके।

डाउनलोड करने से पहले डेटा को सत्यापित करने की आवश्यकता इस तथ्य की ओर ले जाती है कि आपको कई "नियंत्रण" करने की आवश्यकता है, स्वरूपित से लेकर और जटिल लोगों के साथ समाप्त होने के लिए (उदाहरण के लिए, कभी-कभी व्यावसायिक नियंत्रण की आवश्यकता होती है जो यह साबित करता है कि संगठन के पास स्थानांतरित वस्तुओं को डाउनलोड करने का एक आधार है)।

हम आमतौर पर चेक की गुणवत्ता का त्याग नहीं कर सकते। हम मानते हैं कि डेवलपर्स पहले से ही सभी एल्गोरिदम को अनुकूलित कर चुके हैं और आगे का अनुकूलन बहुत समय लेने वाला है या सिस्टम के आगे रखरखाव और विकास को जटिल बनाता है। हमारी परियोजनाओं पर, एक अनुरोध पर एक से पांच सौ दस्तावेजों (भुगतान, चालान, अनुबंध, खरीद परियोजना, आदि) के लिए प्रसंस्करण समय, औसतन, बैकएंड पर कुछ सेकंड है (चित्र 1 में उदाहरण देखें)। यह समय स्थिर नहीं है, लेकिन कुछ सीमाओं के भीतर भिन्न होता है, क्योंकि एक जटिल प्रणाली में हमेशा बहुत सारे कारक होते हैं जो पैकेज के प्रसंस्करण को प्रभावित कर सकते हैं।

चित्रा 1. प्रसंस्करण पैकेज पैकेज के लिए एक विशिष्ट समयरेखा। तीन सेकंड के क्षेत्र में औसत समय।

यहां तक ​​कि अगर आपके आईएस के लिए डाउनलोड की तारीखें कानून द्वारा विनियमित हैं, तो दस्तावेज़ प्रदाताओं के लिए, एक नियम के रूप में, कोई स्पष्ट डाउनलोड शेड्यूल नहीं है। विभिन्न प्रकार के दस्तावेजों के लिए कुछ टेम्पलेट हैं, उदाहरण के लिए, महीने की शुरुआत में चालान जारी किए जा सकते हैं, अन्य डेटा लोड करने में चोटियों को मानक दस्तावेजों की शर्तों द्वारा निर्धारित किया जा सकता है या वर्ष के अंत के साथ जुड़ा हो सकता है, आदि।

इसलिए, व्यवहार में, किसी भी समय, दस्तावेजों को लोड करने की तीव्रता बहुत अलग हो सकती है - इसे सटीक रूप से ठीक करना लगभग असंभव है। ऐसा हो सकता है कि अच्छे आपूर्तिकर्ताओं के सभी 150 मिलियन दस्तावेज एक ही समय में सिस्टम पर अपलोड करने का निर्णय लेते हैं। और यह बिल्कुल भी वैसी बात नहीं है, जैसे कि उन्हें प्रतिदिन 5 मिलियन के शेड्यूल के अनुसार कड़ाई से डाउनलोड किया गया हो।

चित्रा 2. पिछले छह महीनों के लिए दिन में डाउनलोड किए गए दस्तावेजों की संख्या के वितरण का एक उदाहरण।

चित्रा 2 से पता चलता है कि प्रति दिन लोड किए गए दस्तावेजों की संख्या व्यापक रूप से भिन्न होती है। यह स्पष्ट है कि प्रति दिन औसतन 4-5 मिलियन दस्तावेज़ डाउनलोड किए जाते हैं। इसी समय, कुछ दिनों में 10 मिलियन से अधिक दस्तावेज सिस्टम को भेजे गए थे। प्रति दिन अपलोड किए गए दस्तावेजों की अधिकतम संख्या 17 मिलियन से अधिक है।

यदि हम दस्तावेज़ लोडिंग की प्रति घंटा की गति को देखते हैं, तो हम ट्रैफ़िक में और भी अधिक उतार-चढ़ाव देखेंगे। कुछ घंटों में, आईएस में 50 हजार दस्तावेज़ लोड किए जाते हैं, और कुछ घंटों में लोड किए गए दस्तावेज़ों की संख्या 1 मिलियन से अधिक हो जाती है। जितना कम अंतराल हम ले जाते हैं, उतने अधिक प्रसार जो हम देखते हैं।

जाहिर है, दो, तीन और दस लाख दस्तावेज एक साथ सिस्टम में प्रवेश कर सकते हैं। इसलिए, बल्क लोड मैकेनिज्म डिजाइन करते समय, हम क्वीन्स का उपयोग करके क्वेरी बफरिंग का उपयोग करते हैं। उपयोगकर्ता से कोई भी अनुरोध पहले कतार में संग्रहीत किया जाता है। इस प्रकार, हम सिस्टम में बहुत अधिक तीव्रता के साथ दस्तावेज़ प्राप्त करने के लिए अनुरोध प्राप्त कर सकते हैं, क्योंकि अनुरोध प्राप्त करने का संचालन बहुत सरल है। लेकिन दस्तावेज़ का सत्यापन और लोडिंग पहले से ही विशेष "प्रोसेसर" द्वारा किया जाता है, जिसकी मात्रा उपलब्ध क्षमताओं के आधार पर समायोजित की जाती है। जितना अधिक लोहा, उतना ही "प्रोसेसर", सिस्टम एक ही समय में अधिक अनुरोध कर सकता है।

आईपी ​​हार्डवेयर-सॉफ्टवेयर कॉम्प्लेक्स की शक्ति आवश्यक बैंडविड्थ और हार्डवेयर लागतों द्वारा निर्धारित की जाती है। हमें एक संतुलन खोजने की आवश्यकता है ताकि हम (ग्राहक) कम लोड की अवधि के दौरान लोहे के उपयोग से संतुष्ट हों, और साथ ही, पीक अवधि के दौरान, लोडिंग के लिए डेटा कतार बहुत अधिक न बढ़े। यह देखते हुए कि रात में सबसे अधिक बार हमें लोड में स्वाभाविक कमी आती है, हम एक दिशानिर्देश का उपयोग कर सकते हैं - सभी डेटा को उसी दिन या रात में डाउनलोड किया जाना चाहिए। यदि अधिक से अधिक बार ऐसा होता है कि डेटा को रात भर लोड करने का समय नहीं है, तो यह लोहे को जोड़कर थ्रूपुट को बढ़ाने का संकेत है।

चित्रा 3. डेटा पैकेट लोड करने के लिए एक कतार की लंबाई बदलने के लिए अनुसूची का एक उदाहरण।

चित्र 3 डेटा पैकेट डाउनलोड करने के लिए कतार की लंबाई पर आंकड़े दिखाता है। यह ध्यान देना आवश्यक है कि दिन में हमारे पास एक विशिष्ट कूबड़ है, और रात में कतार रीसेट हो जाती है।

चूंकि डेटा पैकेट का लोड समय कतार में प्रतीक्षा समय और बैकएंड पर डेटा पैकेट के प्रसंस्करण समय का योग है, रात में लोड समय दिन की तुलना में बहुत कम है (चित्र 4 देखें)।

चित्रा 4. डेटा पैकेट के लिए डाउनलोड समय। अवधि के लिए औसत 11.92 मिनट था। बूट समय में कतार समय और बैकएंड प्रसंस्करण समय शामिल है।

हम यह निष्कर्ष निकाल सकते हैं: यदि आपूर्तिकर्ता रात में डेटा पैकेट भेजता है, तो डाउनलोड समय न्यूनतम होगा। दूसरी ओर, यदि आईसी की क्षमताओं को इस तरह से चुना जाता है कि एक ही दिन या अधिकतम प्रति रात डेटा की अपेक्षित मात्रा को संसाधित करने के लिए, तो आपूर्तिकर्ता को डेटा लोड करने के लिए समझ में नहीं आता है - आपको बस दस्तावेजों की पूरी मात्रा भेजने की आवश्यकता है, और इसे जितनी जल्दी हो सके संसाधित किया जाएगा।

पूरे गाँव को कैसे खिलाया जाए

आइए अपने दावों पर वापस आते हैं। “हमने एक दस्तावेज़ डाउनलोड करने के लिए भेजा, और इसमें 10 सेकंड का समय लगा। इसलिए, यदि हमारे संगठन को 100 हजार दस्तावेज अपलोड करने की आवश्यकता है, तो हमारे लिए 100,000 * 10/3600 = 277 घंटे लगेंगे! ”

हाइपरमार्केट में आने वाले प्रत्येक ग्राहक को अलग-अलग समय पर परोसा जा सकता है। यह इस बात पर निर्भर करेगा कि स्टोर में कितने ग्राहक आए। रात में, नकदी डेस्क खाली होने की संभावना है और खरीदार को तुरंत सेवा दी जाएगी। और भीड़ के घंटे में आप कई घंटों तक लाइन में लग सकते हैं।

स्रोत

यदि आपको 100 हजार निवासियों के गांव में चावल खरीदने की आवश्यकता है तो क्या करें? प्रत्येक ग्रामीण को हाइपरमार्केट एक के बाद एक भेजने का कोई मतलब नहीं है (अगले एक पिछले एक रिटर्न के बाद ही बाहर आता है)। जाहिर है, इस मामले में, पूरे गांव के लिए चावल की खरीद कई घंटों या एक दिन तक चलेगी, क्योंकि आपको उत्तराधिकार में 100 हजार बार लाइन में खड़ा होना होगा। दूसरी ओर, यदि सभी ग्रामीण एक साथ हाइपरमार्केट में आते हैं, तो सभी एक साथ कतार में आते हैं, तो वे एक ही समय में लाइन में खड़े होंगे। वास्तव में, वे केवल एक बार लाइन में खड़े होते हैं। लाइन में उनका प्रतीक्षा समय भी कैश डेस्क की संख्या पर काफी निर्भर करेगा।

दूसरे शब्दों में, सिस्टम पर वर्तमान लोड (कतार में पैकेटों की संख्या) और सिस्टम के थ्रूपुट (जिस तीव्रता से ये पैकेट संसाधित होते हैं) पर डेटा की एक बड़ी मात्रा का लोडिंग समय प्रभावित होता है। एक व्यक्तिगत पैकेज के लोडिंग समय के रूप में इस तरह के एक संकेतक अपने आप में अपर्याप्त है और गलत निष्कर्ष की ओर जाता है।

आईएस में बड़ी मात्रा में डेटा लोड करने के लिए, पिछले एक के प्रसंस्करण की प्रतीक्षा करते हुए, क्रमिक रूप से अनुरोध भेजना आवश्यक नहीं है। आईएस को सभी अनुरोधों को एक साथ भेजना आवश्यक है, वे उपलब्ध क्षमता और क्षमताओं के आधार पर एक तीव्रता के साथ विशेष "प्रोसेसर" द्वारा पंक्तिबद्ध और संसाधित किए जाएंगे। जाहिर है, आमतौर पर आईपी की बैंडविड्थ प्रत्येक विशेष डेटा प्रदाता की जरूरतों से काफी अधिक होती है।

नतीजतन, सिंक्रोनस तरीके बल्क लोडिंग के लिए उपयुक्त नहीं हैं - यह एक एंटीपैटर्न है।

आप एक साथी निर्देशक को किस बात की सजा दे सकते हैं?

इस कहानी में एक साथी निर्देशक के लिए सबसे ज्यादा चिंता की बात क्या है? वे उसे किस बात की सजा दे सकते हैं?

ग्राहक को सेवा से वंचित किया जा सकता है - यह हमेशा अप्रिय होता है। लेकिन कई कारण हैं कि ऐसा क्यों हो सकता है, और उनकी एक अलग प्रकृति है। आइए सूची बनाते हैं।

1. यदि कतार जारी करने वाला सिस्टम काम नहीं करता है, तो यह बहुत बुरा है। यह सिर्फ इतना बुरा है कि अगले दिन ऐसी स्थितियों को कॉमरेड माओ के कार्यालय में ठीक किया गया है।

2. यदि हाइपरमार्केट में लाइन बढ़ जाती है और ग्राहक लंबे समय तक वहां लटकना शुरू कर देते हैं, तो यह संदेहास्पद है, लेकिन जरूरी नहीं कि तुरंत खराब हो। इस पर नजर रखी जानी चाहिए, लेकिन दो स्थितियां हैं:

• इस तथ्य के कारण कतार बढ़ रही है कि बहुत सारे चीनी एक ही समय में आए हैं, उदाहरण के लिए, कीमत बढ़ने के बारे में अफवाह के कारण;
• कतार इस तथ्य के कारण बढ़ रही है कि किसी कारण से कई बॉक्स ऑफिस टूट गए हैं। यह स्थिति पहले से ही खराब है, इसे एक योजना बैठक पर समझा जाएगा और इससे फटकार लग सकती है।

3. यदि कोई विशेष चीनी चावल नहीं खरीद सकता है, तो यह विभिन्न कारणों से भी हो सकता है:

• यदि चीनी पैसा लेना भूल गया, तो यह साथी निदेशक की गलती नहीं है;
• यदि चेकआउट में कुछ टूट गया या कैशियर ने चीनी को डांटा, तो यह पहले से ही हाइपरमार्केट समस्या है। अगर ऐसी घटनाओं का अनुपात एक निश्चित स्तर तक बढ़ जाता है, तो यह एक बड़ी समस्या बन जाएगी।

यह स्पष्ट है कि किसी भी आईपी के लिए बड़े पैमाने पर लोडिंग तंत्र की एक महत्वपूर्ण विशेषता सेवा से इनकार का प्रतिशत है। आईएस के संचालन से संबंधित तकनीकी कारणों (उपकरण विफलता, सिस्टम त्रुटि, आदि) के लिए सेवा से इनकार करना और आपूर्तिकर्ता के पक्ष में समस्याओं से संबंधित कारणों के लिए असफलता (गलत डेटा पैकेट प्रारूप, व्यापार के दृष्टिकोण से गलत डेटा) के बीच अंतर करना आवश्यक है नियंत्रण, आदि)।

स्थिति अलग हो सकती है। लेकिन अगर आईपी को उपरोक्त सिद्धांतों को ध्यान में रखते हुए विकसित किया गया था और तकनीकी त्रुटियों की निरंतर निगरानी और उन्मूलन की प्रक्रिया है, तो जल्द ही या बाद में स्थिति स्थिर हो जाएगी। एक अच्छी तरह से कार्य प्रणाली पर, पैकेज डाउनलोड के आंकड़े तालिका 1 की तरह कुछ दिखते हैं।

	डाउनलोड अनुरोधों की संख्या, पीसी	शेयर,%
पूरी तरह से सफलतापूर्वक अपलोड किए गए पैकेज	125 977 459	79.94%
वे पैकेज जो आपूर्तिकर्ता के पक्ष (FLC, व्यवसाय नियंत्रण) पर समस्याओं के कारण पूरी तरह या आंशिक रूप से लोड नहीं किए गए थे	29 936 543	19%
जिन पैकेजों को IP साइड में समस्या के कारण डाउनलोड नहीं किया गया था	38 805	0.02%
डुप्लिकेट पैकेज	1638886	1.04%
केवल	156 812 782	100%

तालिका 1. जुलाई 2018 के लिए आंकड़े डाउनलोड करें

तालिका से पता चलता है कि अधिकांश पैकेज सफलतापूर्वक लोड होते हैं। इसके अलावा, सूचना प्रदाता के पक्ष में त्रुटियों का एक उच्च अनुपात। यह बड़ी संख्या में आपूर्तिकर्ताओं और सूचना विनिमय के लिए तत्परता की उनकी बदलती डिग्री के कारण हो सकता है। आपूर्तिकर्ताओं में कम-गुणवत्ता वाले डेटा हो सकते हैं, उन्हें सूचना प्रणालियों के साथ समस्या हो सकती है। कुछ डेटा इलेक्ट्रॉनिक संरचित रूप में उपलब्ध नहीं हो सकते हैं, और इसे प्राप्त करने में समय लगता है।

दुर्भाग्य से, आईपी त्रुटियां हो सकती हैं, खासकर अगर इसका तेजी से विकास चल रहा है। यह महत्वपूर्ण है कि औद्योगिक वातावरण में त्रुटियों की निगरानी की प्रक्रिया और उनकी घटना के कारणों का विश्लेषण शुरू किया जाए। हम LANIT में अपनी परियोजनाओं पर एकीकरण तंत्र के लिए एक विकसित निगरानी प्रणाली का उपयोग करते हैं, और यदि हम देखते हैं कि त्रुटियों की संख्या बढ़ने लगती है, तो हम उनके स्रोत का निर्धारण करते हैं और जल्दी से सुधारात्मक कार्रवाई करने का प्रयास करते हैं।

निष्कर्ष

अंत में, मैं मुख्य बिंदुओं को फिर से दोहराना चाहूंगा।

1. राज्य या कॉर्पोरेट आईपी के विकास और विकास में, बड़े पैमाने पर डेटा लोडिंग के कार्य उत्पन्न होते हैं। आईएस के लिए डाउनलोड अनुरोधों का प्रवाह, एक नियम के रूप में, यादृच्छिक है। इसका मतलब है कि हम वितरण को लगभग जानते हैं, लेकिन किसी भी समय बहुत कम और कई अनुरोध आ सकते हैं।
2. . - . , , - , 99% .
3. . – . () , . - . – , . .
4. , .
5. , . ( , ).