TL;DR: चार वर्षांपूर्वी मी नवीन सर्व्हर मॉनिटरिंग टूलची कल्पना घेऊन Google सोडले. सामान्यतः वेगळ्या फंक्शन्सना एका सेवेमध्ये एकत्र करण्याची कल्पना होती संकलन आणि लॉग विश्लेषण, मेट्रिक्स संग्रह, सूचना आणि डॅशबोर्ड. सेवा खऱ्या अर्थाने असली पाहिजे हे एक तत्व आहे जलद, एक सोपा, परस्परसंवादी, आनंददायक अनुभवासह devops प्रदान करते. यासाठी बजेटमध्ये राहून एका सेकंदाच्या अपूर्णांकांमध्ये मल्टी-गीगाबाइट डेटा सेटवर प्रक्रिया करणे आवश्यक आहे. विद्यमान लॉग मॅनेजमेंट टूल्स बर्‍याचदा धीमे आणि क्लिष्ट असतात, म्हणून आम्हाला एक चांगले आव्हान सामोरे जावे लागले: वापरकर्त्यांना नवीन अनुभव देण्यासाठी एक साधन हुशारीने डिझाइन करणे.

या लेखात वर्णन केले आहे की आम्ही स्कॅलर येथे जुन्या शालेय पद्धती, क्रूर शक्तीचा दृष्टिकोन, अनावश्यक स्तर काढून टाकून आणि जटिल डेटा संरचना टाळून ही समस्या कशी सोडवली. तुम्ही हे धडे तुमच्या स्वतःच्या अभियांत्रिकी समस्यांसाठी लागू करू शकता.

जुन्या शाळेची शक्ती

लॉग विश्लेषण सहसा शोधाने सुरू होते: विशिष्ट पॅटर्नशी जुळणारे सर्व संदेश शोधा. Scalyr मध्ये, हे अनेक सर्व्हरचे दहापट किंवा शेकडो गीगाबाइट्स लॉग आहेत. आधुनिक पध्दतींमध्ये, नियमानुसार, शोधासाठी ऑप्टिमाइझ केलेल्या काही जटिल डेटा स्ट्रक्चरचे बांधकाम समाविष्ट आहे. मी हे Google वर नक्कीच पाहिले आहे, जेथे ते या प्रकारात चांगले आहेत. पण आम्ही खूप क्रूर दृष्टिकोनावर स्थिरावलो: लॉगचे रेखीय स्कॅनिंग. आणि ते कार्य केले - आम्ही शोधण्यायोग्य इंटरफेस प्रदान करतो जो आमच्या प्रतिस्पर्ध्यांपेक्षा वेगवान ऑर्डर आहे (शेवटी अॅनिमेशन पहा).

मुख्य अंतर्दृष्टी अशी होती की आधुनिक प्रोसेसर खरोखरच साध्या, सरळ ऑपरेशनमध्ये खूप वेगवान आहेत. I/O स्पीड आणि नेटवर्क ऑपरेशन्सवर अवलंबून असलेल्या जटिल, बहु-स्तर प्रणालींमध्ये हे चुकणे सोपे आहे आणि अशा प्रणाली आज खूप सामान्य आहेत. म्हणून आम्ही एक डिझाइन विकसित केले जे थर आणि अतिरिक्त मलबा कमी करते. समांतर मध्ये एकाधिक प्रोसेसर आणि सर्व्हरसह, शोध गती प्रति सेकंद 1 TB पर्यंत पोहोचते.

या लेखातील महत्त्वाचे मुद्दे:

• ब्रूट-फोर्स शोध हा वास्तविक-जगातील, मोठ्या प्रमाणात समस्या सोडवण्यासाठी एक व्यवहार्य दृष्टीकोन आहे.
• ब्रूट फोर्स हे डिझाईन तंत्र आहे, काम-मुक्त समाधान नाही. कोणत्याही तंत्राप्रमाणे, हे इतरांपेक्षा काही समस्यांसाठी अधिक योग्य आहे आणि ते खराब किंवा चांगले लागू केले जाऊ शकते.
• ब्रूट फोर्स हे साध्य करण्यासाठी विशेषतः चांगले आहे स्थिर उत्पादकता
• ब्रूट फोर्सच्या प्रभावी वापरासाठी कोड ऑप्टिमाइझ करणे आणि योग्य वेळी पुरेशी संसाधने लागू करणे आवश्यक आहे. जर तुमचे सर्व्हर जास्त गैर-वापरकर्ता लोड अंतर्गत असतील आणि वापरकर्ता ऑपरेशन्सला प्राधान्य असेल तर ते योग्य आहे.
• कार्यप्रदर्शन संपूर्ण प्रणालीच्या डिझाइनवर अवलंबून असते, केवळ आतील लूप अल्गोरिदमवर अवलंबून नाही.

(हा लेख मेमरीमध्ये डेटा शोधण्याचे वर्णन करतो. बहुतेक प्रकरणांमध्ये, जेव्हा वापरकर्ता लॉग शोध करतो, तेव्हा स्केलर सर्व्हरने ते आधीच कॅशे केले आहे. पुढील लेखात अनकॅशेड लॉग शोधण्याबद्दल चर्चा केली जाईल. समान तत्त्वे लागू होतात: कार्यक्षम कोड, ब्रूट फोर्स मोठ्या संगणकीय संसाधनांसह).

क्रूट फोर्स पद्धत

पारंपारिकपणे, कीवर्ड इंडेक्स वापरून मोठा डेटा सेट शोधला जातो. सर्व्हर लॉगवर लागू केल्यावर, याचा अर्थ लॉगमधील प्रत्येक अद्वितीय शब्द शोधणे. प्रत्येक शब्दासाठी, तुम्हाला सर्व समावेशांची सूची तयार करणे आवश्यक आहे. हे या शब्दासह सर्व संदेश शोधणे सोपे करते, उदाहरणार्थ 'एरर', 'फायरफॉक्स' किंवा "ट्रान्झेक्शन_16851951" - फक्त अनुक्रमणिका पहा.

मी Google वर हा दृष्टिकोन वापरला आणि ते चांगले काम केले. पण Scalyr मध्ये आपण लॉग बाइट बाय बाइट शोधतो.

का? अमूर्त अल्गोरिदमिक दृष्टिकोनातून, कीवर्ड इंडेक्स ब्रूट फोर्स शोधांपेक्षा अधिक कार्यक्षम आहेत. तथापि, आम्ही अल्गोरिदम विकत नाही, आम्ही कार्यप्रदर्शन विकतो. आणि कार्यप्रदर्शन केवळ अल्गोरिदम बद्दलच नाही तर सिस्टम अभियांत्रिकीबद्दल देखील आहे. आम्ही सर्वकाही विचारात घेतले पाहिजे: डेटाची मात्रा, शोध प्रकार, उपलब्ध हार्डवेअर आणि सॉफ्टवेअर संदर्भ. आम्ही ठरवले की आमच्या विशिष्ट समस्येसाठी, 'grep' सारखे काहीतरी निर्देशांकापेक्षा अधिक योग्य आहे.

निर्देशांक उत्तम आहेत, पण त्यांना मर्यादा आहेत. एक शब्द शोधणे सोपे आहे. परंतु 'googlebot' आणि '404' सारख्या अनेक शब्दांसह संदेश शोधणे अधिक कठीण आहे. 'न पकडलेला अपवाद' सारखा वाक्यांश शोधण्यासाठी अधिक अवजड निर्देशांक आवश्यक आहे जो केवळ त्या शब्दासह सर्व संदेशच नव्हे तर शब्दाचे विशिष्ट स्थान देखील रेकॉर्ड करतो.

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

दुसरी समस्या म्हणजे विरामचिन्हे. तुम्हाला कडून सर्व विनंत्या शोधायच्या आहेत 50.168.29.7? डीबगिंग लॉग बद्दल काय? [error]? सदस्यत्वे सहसा विरामचिन्हे वगळतात.

शेवटी, अभियंत्यांना शक्तिशाली साधने आवडतात आणि काहीवेळा समस्या केवळ नियमित अभिव्यक्तीने सोडविली जाऊ शकते. कीवर्ड इंडेक्स यासाठी फारसा योग्य नाही.

याव्यतिरिक्त, निर्देशांक जटिल. प्रत्येक संदेशाला अनेक कीवर्ड सूचीमध्ये जोडणे आवश्यक आहे. या याद्या नेहमी सहज शोधता येण्याजोग्या स्वरूपात ठेवल्या पाहिजेत. वाक्प्रचार, शब्दांचे तुकडे किंवा रेग्युलर एक्स्प्रेशन्ससह क्वेरी मल्टी-लिस्ट ऑपरेशन्समध्ये अनुवादित करणे आवश्यक आहे आणि परिणाम सेट तयार करण्यासाठी परिणाम स्कॅन आणि एकत्र केले जाणे आवश्यक आहे. मोठ्या प्रमाणात, बहु-भाडेकरू सेवेच्या संदर्भात, ही जटिलता कार्यप्रदर्शन समस्या निर्माण करते जे अल्गोरिदमचे विश्लेषण करताना दृश्यमान नसतात.

कीवर्ड इंडेक्स देखील खूप जागा घेतात आणि लॉग मॅनेजमेंट सिस्टममध्ये स्टोरेज ही एक मोठी किंमत आहे.

दुसरीकडे, प्रत्येक शोध खूप संगणकीय शक्ती वापरू शकतो. आमचे वापरकर्ते अद्वितीय क्वेरीसाठी उच्च-गती शोधांचे कौतुक करतात, परंतु अशा क्वेरी तुलनेने क्वचितच केल्या जातात. ठराविक शोध क्वेरींसाठी, उदाहरणार्थ, डॅशबोर्डसाठी, आम्ही विशेष तंत्र वापरतो (आम्ही पुढील लेखात त्यांचे वर्णन करू). इतर विनंत्या इतक्या क्वचित असतात की तुम्हाला क्वचितच एका वेळी एकापेक्षा जास्त प्रक्रिया करावी लागते. परंतु याचा अर्थ असा नाही की आमचे सर्व्हर व्यस्त नाहीत: ते नवीन संदेश प्राप्त करणे, विश्लेषित करणे आणि संकुचित करणे, सूचनांचे मूल्यांकन करणे, जुना डेटा संकुचित करणे इत्यादी कामात व्यस्त आहेत. अशा प्रकारे, आमच्याकडे प्रोसेसरचा बऱ्यापैकी महत्त्वाचा पुरवठा आहे ज्याचा उपयोग क्वेरी कार्यान्वित करण्यासाठी केला जाऊ शकतो.

तुम्हाला क्रूर समस्या असल्यास (आणि भरपूर शक्ती) ब्रूट फोर्स कार्य करते

लहान अंतर्गत लूपसह साध्या समस्यांवर ब्रूट फोर्स सर्वोत्तम कार्य करते. बर्‍याचदा तुम्ही खूप जास्त वेगाने चालण्यासाठी अंतर्गत लूप ऑप्टिमाइझ करू शकता. कोड क्लिष्ट असल्यास, तो ऑप्टिमाइझ करणे अधिक कठीण आहे.

आमच्या शोध कोडमध्ये मूलतः बऱ्यापैकी मोठा आतील लूप होता. आम्ही 4K वर पृष्ठांवर संदेश संग्रहित करतो; प्रत्येक पृष्ठावर काही संदेश (UTF-8 मध्ये) आणि प्रत्येक संदेशासाठी मेटाडेटा असतो. मेटाडेटा ही एक रचना आहे जी मूल्याची लांबी, अंतर्गत संदेश आयडी आणि इतर फील्ड एन्कोड करते. शोध चक्र असे दिसले:

ही वास्तविक कोडची सरलीकृत आवृत्ती आहे. परंतु येथेही, एकाधिक ऑब्जेक्ट प्लेसमेंट, डेटा कॉपी आणि फंक्शन कॉल दृश्यमान आहेत. JVM फंक्शन कॉल्स ऑप्टिमाइझ करण्यात आणि तात्कालिक वस्तूंचे वाटप करण्यात खूप चांगले आहे, म्हणून हा कोड आमच्या पात्रतेपेक्षा चांगले काम करतो. चाचणी दरम्यान, ग्राहकांनी ते यशस्वीरित्या वापरले. पण अखेरीस आम्ही ते पुढच्या पातळीवर नेले.

(आपण विचारू शकता की आम्ही थेट लॉगसह कार्य करण्याऐवजी 4K पृष्ठे, मजकूर आणि मेटाडेटासह या स्वरूपात संदेश का संग्रहित करतो. अशी अनेक कारणे आहेत, जी या वस्तुस्थितीकडे वळतात की आंतरिकरित्या स्केलर इंजिन हे वितरीत डेटाबेसपेक्षा अधिक आहे. फाइल सिस्टम. लॉग पार्सिंग केल्यानंतर मजकूर शोध सहसा मार्जिनमध्ये डीबीएमएस-शैलीतील फिल्टरसह एकत्र केला जातो. आम्ही एकाच वेळी अनेक हजारो लॉग शोधू शकतो आणि साध्या मजकूर फाइल्स आमच्या व्यवहार, प्रतिकृती, वितरित डेटा व्यवस्थापनासाठी योग्य नाहीत).

सुरुवातीला, असे दिसते की असा कोड ब्रूट फोर्स ऑप्टिमायझेशनसाठी फारसा योग्य नाही. "वास्तविक कार्य" मध्ये String.indexOf() CPU प्रोफाइलवरही वर्चस्व गाजवले नाही. म्हणजेच, ही पद्धत केवळ अनुकूल केल्याने लक्षणीय परिणाम होणार नाही.

असे घडते की आम्ही प्रत्येक पृष्ठाच्या सुरुवातीला मेटाडेटा संचयित करतो आणि UTF-8 मधील सर्व संदेशांचा मजकूर दुसर्‍या टोकाला भरलेला असतो. याचा फायदा घेऊन, आम्ही एकाच वेळी संपूर्ण पृष्ठ शोधण्यासाठी लूप पुन्हा लिहिला:

ही आवृत्ती थेट दृश्यावर कार्य करते raw byte[] आणि संपूर्ण 4K पृष्ठावर एकाच वेळी सर्व संदेश शोधते.

ब्रूट फोर्स पद्धतीसाठी हे ऑप्टिमाइझ करणे खूप सोपे आहे. प्रत्येक पोस्टवर स्वतंत्रपणे न करता संपूर्ण 4K पृष्ठासाठी अंतर्गत शोध लूप एकाच वेळी कॉल केला जातो. डेटाची कॉपी नाही, वस्तूंचे वाटप नाही. आणि अधिक जटिल मेटाडेटा ऑपरेशन्स केवळ तेव्हाच कॉल केल्या जातात जेव्हा परिणाम सकारात्मक असतो, आणि प्रत्येक संदेशावर नाही. अशा प्रकारे आम्ही एक टन ओव्हरहेड काढून टाकले आहे, आणि उर्वरित भार एका लहान अंतर्गत शोध लूपमध्ये केंद्रित आहे, जो पुढील ऑप्टिमायझेशनसाठी योग्य आहे.

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

आमच्या अंमलबजावणीसाठी प्रत्येक शोधासाठी 64K लुकअप टेबल तयार करणे आवश्यक आहे, परंतु आम्ही शोधत असलेल्या गीगाबाइट डेटाच्या तुलनेत ते काहीच नाही. आतील लूप एका कोरवर प्रति सेकंद अनेक गीगाबाइट्स प्रक्रिया करते. सराव मध्ये, प्रत्येक कोरवर स्थिर कामगिरी सुमारे 1,25 GB प्रति सेकंद आहे आणि सुधारणेसाठी जागा आहे. आतील लूपच्या बाहेरील काही ओव्हरहेड काढून टाकणे शक्य आहे आणि आम्ही Java ऐवजी C मध्ये इनर लूप वापरण्याची योजना आखत आहोत.

आम्ही शक्ती वापरतो

आम्ही चर्चा केली आहे की लॉग शोध "अंदाजे" लागू केले जाऊ शकते, परंतु आमच्याकडे किती "शक्ती" आहे? खूपच जास्त.

1 कोर: योग्यरितीने वापरल्यास, आधुनिक प्रोसेसरचा एकच कोर स्वतःच खूप शक्तिशाली असतो.

8 कोर: आम्ही सध्या Amazon hi1.4xlarge आणि i2.4xlarge SSD सर्व्हरवर चालत आहोत, प्रत्येक 8 कोर (16 थ्रेड्स) सह. वर नमूद केल्याप्रमाणे, हे कोर सहसा पार्श्वभूमी ऑपरेशनमध्ये व्यस्त असतात. जेव्हा वापरकर्ता शोध घेतो, तेव्हा पार्श्वभूमी ऑपरेशन्स निलंबित केले जातात, सर्व 8 कोर शोधासाठी मोकळे करतात. शोध सामान्यत: एका स्प्लिट सेकंदात पूर्ण होतो, त्यानंतर पार्श्वभूमीचे काम पुन्हा सुरू होते (थ्रॉटलिंग प्रोग्राम हे सुनिश्चित करतो की शोध क्वेरींचा बॅरेज महत्त्वाच्या पार्श्वभूमीच्या कामात व्यत्यय आणत नाही).

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

अनेक कोर: नजीकच्या भविष्यात, आम्ही सर्व सर्व्हरवर डेटा अशा प्रकारे वितरित करू की ते सर्व प्रत्येक क्षुल्लक विनंतीवर प्रक्रिया करण्यात सहभागी होतील. प्रत्येक कोर काम करेल. [टीप: आम्ही योजना लागू केली आणि शोध गती 1 TB/s पर्यंत वाढवली, लेखाच्या शेवटी टीप पहा].

साधेपणा विश्वासार्हता सुनिश्चित करते

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

कीवर्ड इंडेक्स कधीकधी आश्चर्यकारकपणे जलद परिणाम देते आणि इतर वेळी तसे होत नाही. समजा तुमच्याकडे 50 GB लॉग आहेत ज्यामध्ये 'ग्राहक_5987235982' हा शब्द अगदी तीन वेळा दिसतो. या शब्दाचा शोध अनुक्रमणिकेतून थेट तीन स्थानांची गणना करतो आणि त्वरित पूर्ण होईल. परंतु जटिल वाइल्डकार्ड शोध हजारो कीवर्ड स्कॅन करू शकतात आणि बराच वेळ घेऊ शकतात.

दुसरीकडे, कोणत्याही क्वेरीसाठी ब्रूट फोर्स शोध कमी-अधिक प्रमाणात समान गतीने करतात. लांब शब्द शोधणे चांगले आहे, परंतु एकच वर्ण शोधणे देखील जलद आहे.

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

सेवेचा वापर सुलभतेसाठी स्थिर, विश्वासार्ह कार्यप्रदर्शन महत्त्वाचे आहे. ते वेळोवेळी मागे पडल्यास, वापरकर्त्यांना ते अविश्वसनीय समजतील आणि ते वापरण्यास नाखूष होतील.

कृतीमध्ये लॉग शोध

येथे एक लहान अॅनिमेशन आहे जे स्केलर शोध कृतीत दर्शवते. आमच्याकडे डेमो खाते आहे जिथे आम्ही प्रत्येक सार्वजनिक गिथब रेपॉजिटरीमधील प्रत्येक कार्यक्रम आयात करतो. या डेमोमध्ये, मी एका आठवड्यातील डेटाचे परीक्षण करतो: अंदाजे 600 MB कच्चे लॉग.

व्हिडिओ माझ्या डेस्कटॉपवर (सर्व्हरपासून सुमारे 5000 किलोमीटर अंतरावर) विशेष तयारीशिवाय थेट रेकॉर्ड केला गेला. तुम्‍हाला दिसणार्‍या कामगिरीमुळे आहे वेब क्लायंट ऑप्टिमायझेशन, तसेच जलद आणि विश्वासार्ह बॅकएंड. जेव्हा जेव्हा 'लोडिंग' इंडिकेटरशिवाय विराम मिळतो, तेव्हा मी विराम देतो जेणेकरून मी काय दाबणार आहे ते तुम्ही वाचू शकता.

शेवटी

मोठ्या प्रमाणात डेटावर प्रक्रिया करताना, एक चांगला अल्गोरिदम निवडणे महत्वाचे आहे, परंतु "चांगले" चा अर्थ "फॅन्सी" नाही. तुमचा कोड सरावात कसा काम करेल याचा विचार करा. अल्गोरिदमचे सैद्धांतिक विश्लेषण असे काही घटक सोडते जे वास्तविक जगात खूप महत्त्वाचे असू शकतात. साधे अल्गोरिदम ऑप्टिमाइझ करणे सोपे आणि किनारी परिस्थितींमध्ये अधिक स्थिर असतात.

कोड कोणत्या संदर्भात अंमलात आणला जाईल याचा देखील विचार करा. आमच्या बाबतीत, पार्श्वभूमी कार्ये व्यवस्थापित करण्यासाठी आम्हाला पुरेसे शक्तिशाली सर्व्हर आवश्यक आहेत. वापरकर्ते तुलनेने क्वचितच शोध सुरू करतात, म्हणून आम्ही प्रत्येक शोध पूर्ण करण्यासाठी आवश्यक असलेल्या अल्प कालावधीसाठी सर्व्हरचा संपूर्ण गट घेऊ शकतो.

ब्रूट फोर्स पद्धत वापरून, आम्ही लॉगच्या संचामध्ये एक जलद, विश्वासार्ह, लवचिक शोध लागू केला. आम्हाला आशा आहे की या कल्पना तुमच्या प्रकल्पांसाठी उपयुक्त ठरतील.

सुधारणे: शीर्षक आणि मजकूर "20 GB प्रति सेकंदाने शोधा" वरून "1 TB प्रति सेकंदाने शोधा" मध्ये बदलून गेल्या काही वर्षांतील कामगिरीत वाढ झाली आहे. वेगात झालेली ही वाढ मुख्यत्वेकरून EC2 सर्व्हरच्या प्रकारात आणि संख्येत झालेल्या बदलांमुळे आम्ही आज आमच्या वाढलेल्या ग्राहकांना सेवा देण्यासाठी करत आहोत. ऑपरेशनल कार्यक्षमतेत आणखी एक नाट्यमय वाढ देणारे बदल लवकरच येत आहेत आणि आम्ही ते सामायिक करण्यासाठी प्रतीक्षा करू शकत नाही.

स्त्रोत: www.habr.com