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

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

पुराने स्कूल की शक्ति

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

मुख्य अंतर्दृष्टि यह थी कि आधुनिक प्रोसेसर वास्तव में सरल, सीधे संचालन में बहुत तेज़ हैं। जटिल, बहु-परत प्रणालियों में इसे नज़रअंदाज करना आसान है जो I/O गति और नेटवर्क संचालन पर निर्भर हैं, और ऐसी प्रणालियाँ आज बहुत आम हैं। इसलिए हमने एक ऐसा डिज़ाइन विकसित किया जो परतों और अतिरिक्त मलबे को कम करता है। समानांतर में एकाधिक प्रोसेसर और सर्वर के साथ, खोज गति 1 टीबी प्रति सेकंड तक पहुंच जाती है।

इस लेख से मुख्य बातें:

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

(यह लेख मेमोरी में डेटा की खोज का वर्णन करता है। ज्यादातर मामलों में, जब कोई उपयोगकर्ता लॉग खोज करता है, तो स्केलियर सर्वर पहले ही इसे कैश कर चुके होते हैं। अगला लेख अनकैश्ड लॉग की खोज पर चर्चा करेगा। वही सिद्धांत लागू होते हैं: कुशल कोड, क्रूर बल बड़े कम्प्यूटेशनल संसाधनों के साथ)।

पाशविक बल विधि

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

मैंने Google में इस दृष्टिकोण का उपयोग किया और इसने अच्छा काम किया। लेकिन स्केलियर में हम लॉग को बाइट दर बाइट खोजते हैं।

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

सूचकांक बहुत अच्छे हैं, लेकिन उनकी सीमाएँ हैं। एक शब्द ढूंढना आसान है. लेकिन 'Googlebot' और '404' जैसे कई शब्दों वाले संदेशों को खोजना अधिक कठिन है। 'अनकॉट अपवाद' जैसे वाक्यांश की खोज के लिए एक अधिक बोझिल सूचकांक की आवश्यकता होती है जो न केवल उस शब्द के साथ सभी संदेशों को रिकॉर्ड करता है, बल्कि शब्द के विशिष्ट स्थान को भी रिकॉर्ड करता है।

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

एक अन्य समस्या विराम चिह्न है. क्या आप यहां से सभी अनुरोध ढूंढना चाहते हैं? 50.168.29.7? युक्त डिबगिंग लॉग के बारे में क्या? [error]? सदस्यताएँ आमतौर पर विराम चिह्न छोड़ देती हैं।

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

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

कीवर्ड इंडेक्स भी बहुत अधिक जगह लेते हैं, और लॉग प्रबंधन प्रणाली में भंडारण एक बड़ी लागत है।

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

यदि आपके पास पाशविक समस्या है (और बहुत अधिक बल) तो पाशविक बल काम करता है

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

हमारे खोज कोड में मूल रूप से काफी बड़ा आंतरिक लूप था। हम संदेशों को 4K पर पृष्ठों पर संग्रहीत करते हैं; प्रत्येक पृष्ठ में कुछ संदेश (UTF-8 में) और प्रत्येक संदेश के लिए मेटाडेटा होता है। मेटाडेटा एक संरचना है जो मान की लंबाई, आंतरिक संदेश आईडी और अन्य फ़ील्ड को एन्कोड करती है। खोज चक्र इस तरह दिखता था:

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

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

प्रारंभ में, ऐसा लगा कि ऐसा कोड क्रूर बल अनुकूलन के लिए बहुत उपयुक्त नहीं था। "असली काम" में String.indexOf() सीपीयू प्रोफ़ाइल पर भी हावी नहीं हुआ। अर्थात्, अकेले इस पद्धति का अनुकूलन कोई महत्वपूर्ण प्रभाव नहीं लाएगा।

ऐसा होता है कि हम प्रत्येक पृष्ठ की शुरुआत में मेटाडेटा संग्रहीत करते हैं, और UTF-8 में सभी संदेशों का पाठ दूसरे छोर पर पैक किया जाता है। इसका लाभ उठाते हुए, हमने पूरे पृष्ठ को एक साथ खोजने के लिए लूप को फिर से लिखा:

यह संस्करण सीधे दृश्य पर कार्य करता है raw byte[] और संपूर्ण 4K पृष्ठ पर सभी संदेशों को एक साथ खोजता है।

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

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

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

हम बल प्रयोग करते हैं

हमने चर्चा की है कि लॉग खोज को "मोटे तौर पर" लागू किया जा सकता है, लेकिन हमारे पास कितनी "शक्ति" है? काफी।

1 वर्ष: जब सही ढंग से उपयोग किया जाता है, तो आधुनिक प्रोसेसर का एक कोर अपने आप में काफी शक्तिशाली होता है।

8 कोर: वर्तमान में हम Amazon hi1.4xlarge और i2.4xlarge SSD सर्वर पर चल रहे हैं, प्रत्येक में 8 कोर (16 थ्रेड) हैं। जैसा कि ऊपर उल्लेख किया गया है, ये कोर आमतौर पर पृष्ठभूमि संचालन में व्यस्त रहते हैं। जब उपयोगकर्ता कोई खोज करता है, तो पृष्ठभूमि संचालन निलंबित कर दिया जाता है, जिससे खोज के लिए सभी 8 कोर मुक्त हो जाते हैं। खोज आम तौर पर एक सेकंड में पूरी हो जाती है, जिसके बाद पृष्ठभूमि का काम फिर से शुरू हो जाता है (थ्रॉटलिंग प्रोग्राम यह सुनिश्चित करता है कि खोज क्वेरी की बाढ़ महत्वपूर्ण पृष्ठभूमि के काम में हस्तक्षेप नहीं करती है)।

16 कोर: विश्वसनीयता के लिए, हम सर्वर को मास्टर/स्लेव समूहों में व्यवस्थित करते हैं। प्रत्येक मास्टर के पास उसके आदेश के तहत एक SSD और एक EBS सर्वर होता है। यदि मुख्य सर्वर क्रैश हो जाता है, तो SSD सर्वर तुरंत उसकी जगह ले लेता है। लगभग हर समय, मास्टर और स्लेव ठीक काम करते हैं, ताकि प्रत्येक डेटा ब्लॉक दो अलग-अलग सर्वरों पर खोजा जा सके (ईबीएस स्लेव सर्वर में एक कमजोर प्रोसेसर है, इसलिए हम इस पर विचार नहीं करते हैं)। हम कार्य को उनके बीच विभाजित करते हैं, ताकि हमारे पास कुल 16 कोर उपलब्ध हों।

अनेक कोर: निकट भविष्य में, हम सर्वरों में डेटा इस तरह वितरित करेंगे कि वे सभी हर गैर-तुच्छ अनुरोध को संसाधित करने में भाग लें। हर कोर काम करेगा. [टिप्पणी: हमने योजना लागू की और खोज गति को 1 टीबी/सेकेंड तक बढ़ा दिया, लेख के अंत में नोट देखें].

सरलता विश्वसनीयता सुनिश्चित करती है

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

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

दूसरी ओर, ब्रूट फोर्स खोजें किसी भी प्रश्न के लिए कमोबेश समान गति से प्रदर्शन करती हैं। लंबे शब्दों को खोजना बेहतर है, लेकिन किसी एक अक्षर को खोजना भी काफी तेज़ है।

पाशविक बल विधि की सरलता का अर्थ है कि इसका प्रदर्शन इसके सैद्धांतिक अधिकतम के करीब है। अप्रत्याशित डिस्क ओवरलोड, लॉक विवाद, पॉइंटर चेज़िंग और विफलता के हजारों अन्य कारणों के लिए कम विकल्प हैं। मैंने पिछले सप्ताह हमारे सबसे व्यस्त सर्वर पर स्केलियर उपयोगकर्ताओं द्वारा किए गए अनुरोधों को देखा। 14 अनुरोध थे. ठीक उनमें से आठ ने एक सेकंड से अधिक समय लिया; 000 मिलीसेकंड के भीतर 99% पूरा हो गया (यदि आपने लॉग विश्लेषण टूल का उपयोग नहीं किया है, तो मुझ पर विश्वास करें: ये तेज़ है).

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

कार्रवाई में खोज लॉग करें

यहां एक संक्षिप्त एनीमेशन है जो स्केलियर खोज को क्रियान्वित करता हुआ दिखाता है। हमारे पास एक डेमो खाता है जहां हम प्रत्येक सार्वजनिक जीथब रिपॉजिटरी में प्रत्येक घटना को आयात करते हैं। इस डेमो में, मैं एक सप्ताह के डेटा की जांच करता हूं: लगभग 600 एमबी कच्चे लॉग।

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

अंत में

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

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

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

संपादन करना: पिछले कुछ वर्षों में प्रदर्शन में वृद्धि को प्रतिबिंबित करने के लिए शीर्षक और पाठ को "20 जीबी प्रति सेकंड पर खोजें" से "1 टीबी प्रति सेकंड पर खोजें" में बदल दिया गया है। गति में यह वृद्धि मुख्य रूप से हमारे बढ़े हुए ग्राहक आधार की सेवा के लिए आज हम जो EC2 सर्वर लगा रहे हैं उनके प्रकार और संख्या में बदलाव के कारण है। जल्द ही ऐसे बदलाव आने वाले हैं जो परिचालन दक्षता में एक और नाटकीय वृद्धि प्रदान करेंगे, और हम उन्हें साझा करने के लिए इंतजार नहीं कर सकते।

स्रोत: www.habr.com