Node.js या Java: प्रदर्शन, संसाधन, प्रवाह नियंत्रण, लोकप्रियता और व्यक्तिगत अनुभव

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

जावा का उपयोग करने वाली कंपनियां:



नोड.जेएस का उपयोग करने वाली कंपनियां:



यह भी कम दिलचस्प नहीं है कि जावा डेवलपर (30272 रिक्तियों) और नोड.जेएस डेवलपर (7401 रिक्तियों) के अनुरोध पर वास्तव में.कॉम (06/28/2019) पर एक खोज के अनुसार, इन प्रौद्योगिकियों के विशेषज्ञ काफी मांग में हैं।



लेकिन लोकप्रियता के संबंध में यह सब सामान्य जानकारी है। वह जानकारी जिसने मुझे विषय में गहराई से उतरने और तकनीकी विशेषताओं के विषय पर अनुमान लगाने के लिए प्रेरित किया, जिसके कारण इस लेख को लिखा गया।

वे तुलना करने लायक क्यों हैं?

जावा एक भाषा है, नोड.जेएस को जेएस के आधार पर बनाया गया एक पारिस्थितिकी तंत्र कहा जा सकता है, और, सबसे पहले, वी 8 पर आधारित - Google से एक इंजन।

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

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

V8 और JVM

जब JS कोड v8 में जाता है, तो बस समय-समय पर बाइट कोड में संकलित किया जाता है जिसे वर्चुअल मशीन में उपयोग किया जाता है, JS कोड तेजी से और तेजी से चलता है।
बाइट कोड एक उच्च-स्तरीय मध्यवर्ती भाषा है, इसलिए एक जावा वर्चुअल मशीन में वे न केवल जावा में लिखते हैं, बल्कि स्काला और कोटलिन में भी लिखते हैं।

पूर्वापेक्षाएँ हैं कि निकट भविष्य में V8 के लिए न केवल JS बल्कि टाइपस्क्रिप्ट या अन्य का उपयोग करना संभव होगा। फिलहाल, जेएस में इन भाषाओं का एक परिवर्तन है। भविष्य में, उन्हें संभवतः बॉक्स से बाहर का समर्थन किया जाएगा, और सब कुछ बहुत तेजी से काम करेगा।

अब V8 का निरंतर विकास हो रहा है, और बड़े और नोड के नए संस्करणों की उपस्थिति, V8 इंजन के नए संस्करण के आगमन के साथ जुड़ी हुई है। वे सीधे परस्पर जुड़े हुए हैं।

Node.js: फायदे और नुकसान

Node.js को 2009 में रयान डाहल ने बनाया था।

Node.js में ही कई मुख्य घटक शामिल हैं:

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

चलो इसके पेशेवरों और विपक्षों पर चलते हैं।

पेशेवरों:

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

विपक्ष:

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

जावा के फायदे और नुकसान

इसके विपरीत, तुरंत जावा की मुख्य विशेषताओं पर विचार करें।

पेशेवरों:

• काम की गति
• व्यापकता (कई देशों के विश्वविद्यालयों में वे जावा का अध्ययन करते हैं, जावा में ओओपी का अध्ययन करना भी सुविधाजनक है),
• पुस्तकालयों का विशाल समूह।

विपक्ष:

• भारीपन,
• कुछ जावा प्रतिमान लंबे समय के लिए बनाए गए हैं और पहले से ही पुराने हैं,
• JDK मालिकाना है, इसलिए जावा धीरे-धीरे विकसित हो रहा है।

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

ओरेकल और गूगल संघर्ष

जावा सूर्य द्वारा बनाया गया था, जिसे बाद में ओरेकल द्वारा अधिग्रहण कर लिया गया था और अभी भी इसके स्वामित्व में है। इस कारण से, जावा का उपयोग करने वाली कई कंपनियों के लिए कुछ समस्याएं पैदा होती हैं।

जब Android में जावा का उपयोग करने के लिए ओरेकल ने उनके साथ मुकदमा शुरू किया तो Google को समस्या हो रही थी। इस वजह से, Google ने बहुत सक्रिय रूप से कोटलिन को अपनाया, जो स्वतंत्र रूप से दिखाई दिया। जावा मालिकाना है। लेकिन एक ओरेकल वर्चुअल मशीन है, साथ ही एक ओपन जावा वर्चुअल मशीन (ओपन जेवीएम) है, जिसका उपयोग लिनक्स में किया जाता है और ओपन सोर्स में लिखा जाता है। कभी-कभी कुछ असंगतताएं होती हैं, लेकिन हाल ही में वे कम और कम हैं।

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

जावा बनाम नोड.जेएस: प्रदर्शन और संसाधन खपत

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


Node.js और Java प्रदर्शन

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

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

Node.js अपनी घटना संचालित वास्तुकला के कारण हल्का है। यह एक वेब सर्वर के रूप में काम करने के लिए बनाया गया है और हल्के कार्यों की सर्विसिंग का बहुत अच्छा काम करता है। उदाहरण के लिए, एक साधारण क्वेरी जैसे किसी चीज़ की गणना करना या किसी डेटाबेस में लिखना, बहुत जल्दी होता है। और अगर बहुत सारे अनुरोध हैं और हम नोड में सिस्टम को स्केल करना चाहते हैं, तो आप Nginx या Apache वेब सर्वर का उपयोग कर सकते हैं। आपके पास कई समान नोड उदाहरण हो सकते हैं। फिर सब कुछ राउंड-रॉबिन लोड संतुलन के माध्यम से वितरित किया जाएगा। यदि हम क्रमशः 16 कोर पर 8 नोड इंस्टेंस चलाते हैं, तो ओएस खुद ही कर्नेल के बीच के उदाहरणों को वितरित करेगा। नोड इस पर नियंत्रण नहीं करता है, इसमें एक धागा होगा।

जावा और नोड.जेएस में प्रवाह नियंत्रण

जावा में, हम एक एप्लिकेशन बना सकते हैं और उसमें 8 थ्रेड चला सकते हैं। इस तथ्य के कारण कि ओएस के साथ घनिष्ठ संपर्क है, आप लोड वितरित कर सकते हैं।

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


जावा धागा प्रबंधन

नोड पर, आप कोड की कुछ पंक्तियाँ लिख सकते हैं और सबसे सरल वेब सर्वर प्राप्त कर सकते हैं। स्वाभाविक रूप से, एक व्यापक कार्यक्षमता के लिए, जहां सूचनाएं, प्राधिकरण, लॉगिंग आदि होंगे। इसे लागू करना अधिक कठिन है, लेकिन ऐसे ढांचे हैं जो आपको ऐसे मुद्दों को हल करने की अनुमति देते हैं।


नोड.जेएस में प्रवाह नियंत्रण

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

वेब, REST API नोड का तत्व है, और कभी-कभी वे इसका उपयोग करते हैं। लेकिन अगर हम जटिल गणनाओं से निपट रहे हैं, तो जावा का उपयोग करना अभी भी बेहतर है।

मेरा जावा प्रोजेक्ट

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

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

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

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

नोड.जेएस पर अनुभव से

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

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

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

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

सारांश और संभावनाएं: नोड.जेएस जावा से आगे निकलने में सक्षम होंगे?

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

जावा मूल रूप से C ++ की जगह एक हल्के समाधान के रूप में बनाया गया था, और अब हेवीवेट बन गया है। यह विकासवाद जैसा है। शायद किसी दिन कुछ ऐसा होगा जो नोड को बदल देगा।


मॉड्यूल - जावा विकास बनाम नोड। जेएस

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

समस्या यह है कि जावा विकास हाल ही में धीमी गति से हुआ है, और नोड.जेएस इतनी गति से विकसित हो रहा है कि निकट भविष्य में इसे बदलना संभव नहीं है।