एंटरप्राइज़ एप्लिकेशन की गति

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

एक आधुनिक अनुप्रयोग की एक विशिष्ट योजना पर विचार करें



आवेदन की समग्र गति दो श्रेणियों द्वारा निर्धारित की जाती है:
1) आवेदन में प्रत्येक लिंक की गति;
2) आवेदन के लिंक के बीच बातचीत की गति।

पहले बिंदु के अनुसार, केवल डेटाबेस ही कमजोर लिंक हो सकता है, क्योंकि हम हमेशा किसी अन्य सर्वर को पास रख सकते हैं और एप्लिकेशन सर्वर और वेब सर्वर को समानांतर कर सकते हैं।

दूसरे बिंदु का विश्लेषण करते हैं। ऑपरेटिंग सिस्टम की विभिन्न प्रक्रियाओं में एप्लिकेशन के विभिन्न भाग कम से कम काम करते हैं, इसलिए, आपस में दो लिंक की बातचीत के लिए, ऑपरेटिंग सिस्टम को कम से कम दो बार प्रक्रियाओं के बीच स्विच करने की आवश्यकता होती है। इसका मतलब यह है कि भले ही एप्लिकेशन सर्वर और डेटाबेस एक ही कंप्यूटर पर हों, लेकिन समय के अधिक होने के कारण, हम प्रति सेकंड 8,000 से अधिक SQL प्रश्नों पर भरोसा नहीं कर सकते हैं। नेटवर्किंग में क्रमशः और भी अधिक प्रक्रियाएं शामिल हैं, और अनुरोधों की संख्या लगभग 1000 तक कम हो जाती है। वेब सर्वर, वेब क्लाइंट और एप्लिकेशन सर्वर के बीच की बातचीत आमतौर पर एप्लिकेशन सर्वर और डेटाबेस के बीच की तुलना में बहुत कम तीव्र होती है। उपयोगकर्ता और वेब सर्वर के बीच एकमात्र संबंध अपेक्षाकृत लंबी प्रतिक्रिया समय की विशेषता है, विशेष रूप से उपग्रह चैनलों पर। तो यह भी ajax अनुरोधों के एक बादल की व्यवस्था करने के लायक नहीं है (जो कि अक्सर पहला ajax आवेदन पाप किया जाता है)। लेकिन डेटाबेस में वापस।

सामान्य ऑपरेशन में, प्रति सेकंड हजारों अनुरोध पर्याप्त हैं। समस्याएं किसी भी प्रकार के बड़े डेटा प्रोसेसिंग से शुरू होती हैं। लेकिन यह सीमा विशेष रूप से महत्वपूर्ण हो जाती है जब ऑब्जेक्ट ऐड-इन्स का उपयोग किया जाता है, जिसमें 1C सिस्टम जितना लोकप्रिय है। OOP का उपयोग करने की ख़ासियत यह है कि यह डेटाबेस में छोटी कॉल का एक समूह बनाता है। और अब इस स्थिति से दो तरीके हैं:
क) डेटाबेस के अंदर एप्लिकेशन लॉजिक रखें;
बी) एप्लिकेशन सर्वर के अंदर कैश डेटा।

विकल्प "ए" चुनना, आप परिमाण के दो आदेशों द्वारा गति बढ़ा सकते हैं: प्रति सेकंड 100,000 अनुरोधों तक। असुविधा यह है कि इस मामले में हम अंतर्निहित डेटाबेस भाषा में तर्क को लागू करने के लिए मजबूर हैं। सी # या जावा-प्रक्रियाओं के साथ संस्करण उपयुक्त नहीं है, क्योंकि ऐसी प्रक्रियाएं वर्चुअल मशीन में की जाती हैं, जो वास्तव में एक अलग प्रक्रिया है और व्यावहारिक रूप से बाहरी एप्लिकेशन सर्वर से बातचीत के समय में भिन्न नहीं होती है। और यद्यपि अंतर्निहित प्रोग्रामिंग भाषा एप्लिकेशन लॉजिक को लागू करने के लिए बहुत उपयुक्त नहीं है, कई बैंक इस दृष्टिकोण का उपयोग करते हैं। मूल रूप से, इस मामले में, ज़ाहिर है, ओरेकल का उपयोग इसके अंतर्निहित पीएल / एसक्यूएल के साथ किया जाता है।

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

प्रति सेकंड 100,000 लाइनों की सीमा कहां से आई, जिसे हम डेटाबेस का उपयोग करके किसी भी तरह से दूर नहीं कर सकते। इसका उत्तर सरल है - यह डेटाबेस में इंडेक्स बनाने की अनुमानित औसत गति है। हां, भले ही एक आधुनिक प्रोसेसर आधे सेकंड में 100 मिलियन पंक्तियों को सॉर्ट कर सकता है, Oracle 20 सेकंड में 1 मिलियन तत्वों के सूचकांक का निर्माण करता है। आवेदन को विकसित करते समय यह ध्यान में रखा जाना चाहिए। और यहां तक ​​कि प्रति सेकंड इन 100 हजार लाइनों को केवल एक अंतर्निहित भाषा में या एक फ़ाइल से बड़े पैमाने पर डेटा लोड करके प्रक्रियाओं के माध्यम से प्राप्त किया जा सकता है। SQL कमांड का उपयोग करके, हम प्रति सेकंड अधिकतम 10,000 क्वेरी प्राप्त करते हैं। आप क्लस्टरिंग करके समग्र गति बढ़ा सकते हैं, लेकिन प्रतिक्रिया समय बहुत है, वृद्धि करना बहुत मुश्किल है।

मैं आपको याद दिला दूं कि हम मास डेटा प्रोसेसिंग के बारे में बात कर रहे हैं, उदाहरण के लिए, एक महीने को बंद करना या एक वर्ष को बंद करना। हर रोज़ मोड में, सामान्य गति पर्याप्त है।

अब बात करते हैं संभावनाओं की। अब, कंप्यूटर प्रौद्योगिकी में एक वास्तविक क्रांति चुपचाप और चुपचाप हो रही है - 64-बिट के लिए संक्रमण। और यह सिर्फ 4 गीगाबाइट से अधिक मेमोरी स्थापित करने का अवसर नहीं है - ऐसा अवसर अभी भी पेंटियम II पर कुछ अन्य प्रोसेसर मोड का उपयोग करके था। 64 बिट्स, यह प्रोसेसर के एड्रेस स्पेस में किसी भी डेटा को शामिल करने की क्षमता है। साथ में सॉलिड-स्टेट ड्राइव के विकास के साथ, जो कि क्लासिक हार्ड ड्राइव की तुलना में रैम की तरह अधिक है, यह नाटकीय रूप से भविष्य के प्रसंस्करण सिस्टम के रूप को बदल देता है। जाहिर है, निकट भविष्य में हम एप्लिकेशन सर्वर और डेटाबेस के मिलन को देखेंगे। पहला कदम: ओरेकल ने जावा तकनीक खरीदी, और माइक्रोसॉफ्ट पहले से ही सी # में एसक्यूएल प्रश्नों को एम्बेड कर रहा है। यानी वे अपने DBMS के अंदर तर्क रखने की कोशिश करते हैं। इस दृष्टिकोण का नुकसान यह है कि OOP के सिद्धांतों पर आधारित तर्क संबंधपरक डेटा मॉडल पर बहुत अच्छी तरह से फिट नहीं होता है - जबकि डेटाबेस के लिए प्रश्नों की संख्या परिमाण के एक क्रम से बढ़ जाती है। हालांकि, बड़े बैंक जो इस दृष्टिकोण का उपयोग करेंगे, वे नई विकास तकनीकों पर बिल्कुल भी स्विच नहीं कर सकते। तो, Sberbank का आईटी विभाग कर्मियों की कुल संख्या के बराबर है। विनिर्माण क्षेत्र की कंपनियों में, प्रोग्रामर यहां बहुत छोटे हैं और नई तकनीकें, अजीब तरह से पर्याप्त हैं, मांग में अधिक हैं।

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

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

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