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

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

पुरानो विद्यालय शक्ति

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

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

यस लेखबाट मुख्य टेकवेहरू:

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

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

क्रूट बल विधि

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

मैले गुगलमा यो दृष्टिकोण प्रयोग गरें र यसले राम्रोसँग काम गर्‍यो। तर Scalyr मा हामी लग बाइट बाइट द्वारा खोजी गर्छौं।

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

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

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

अर्को समस्या विराम चिह्न हो। तपाईं बाट सबै अनुरोधहरू फेला पार्न चाहनुहुन्छ 50.168.29.7? डिबगिङ लगहरू समावेश गर्ने बारे के [error]? सदस्यताहरू सामान्यतया विराम चिह्न छोड्छन्।

अन्तमा, ईन्जिनियरहरू शक्तिशाली उपकरणहरू मन पराउँछन्, र कहिलेकाहीँ समस्या नियमित अभिव्यक्तिको साथ मात्र समाधान गर्न सकिन्छ। कीवर्ड सूचकांक यसको लागि धेरै उपयुक्त छैन।

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

कीवर्ड अनुक्रमणिकाहरूले पनि धेरै ठाउँ लिन्छन्, र लग व्यवस्थापन प्रणालीमा भण्डारण ठूलो लागत हो।

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

यदि तपाईलाई ब्रूट समस्या (र धेरै बल) छ भने ब्रूट फोर्सले काम गर्दछ

ब्रुट फोर्सले साना आन्तरिक लूपहरूसँग साधारण समस्याहरूमा राम्रो काम गर्दछ। प्रायः तपाईले आन्तरिक लूपलाई धेरै उच्च गतिमा चलाउन अनुकूलन गर्न सक्नुहुन्छ। यदि कोड जटिल छ भने, यसलाई अनुकूलन गर्न धेरै गाह्रो छ।

हाम्रो खोज कोड मूलतः एकदम ठूलो भित्री लूप थियो। हामी 4K मा पृष्ठहरूमा सन्देशहरू भण्डारण गर्छौं; प्रत्येक पृष्ठमा केही सन्देशहरू छन् (UTF-8 मा) र प्रत्येक सन्देशको लागि मेटाडेटा। मेटाडेटा एउटा संरचना हो जसले मानको लम्बाइ, आन्तरिक सन्देश ID, र अन्य क्षेत्रहरू सङ्केत गर्छ। खोज चक्र यस्तो देखिन्थ्यो:

यो वास्तविक कोडको सरलीकृत संस्करण हो। तर यहाँ पनि, बहु वस्तु प्लेसमेन्टहरू, डाटा प्रतिलिपिहरू, र प्रकार्य कलहरू देखिने छन्। JVM प्रकार्य कलहरू अनुकूलन गर्न र अल्पकालिक वस्तुहरू आवंटित गर्नमा धेरै राम्रो छ, त्यसैले यो कोडले हामीले योग्य भन्दा राम्रो काम गर्‍यो। परीक्षणको क्रममा, ग्राहकहरूले यसलाई सफलतापूर्वक प्रयोग गरे। तर अन्ततः हामीले यसलाई अर्को स्तरमा ल्यायौं।

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

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

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

यो संस्करण सीधा दृश्य मा काम गर्दछ raw byte[] र सम्पूर्ण 4K पृष्ठमा एकैचोटि सबै सन्देशहरू खोज्छ।

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

हाम्रो वास्तविक खोज एल्गोरिथ्म मा आधारित छ लियोनिद Volnitsky को महान विचार। यो Boyer-Moore एल्गोरिथ्म जस्तै छ, प्रत्येक चरणमा खोज स्ट्रिङको लगभग लम्बाइ छोड्दै। मुख्य भिन्नता यो हो कि यसले झूटा मिलानहरू कम गर्न एक पटकमा दुई बाइटहरू जाँच गर्दछ।

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

हामी बल प्रयोग गर्छौं

हामीले लग खोजी "मोटामोटी" रूपमा लागू गर्न सकिन्छ भनेर छलफल गरेका छौं, तर हामीसँग कति "शक्ति" छ? एकदम धेरै।

१ कोर: सही रूपमा प्रयोग गर्दा, आधुनिक प्रोसेसरको एकल कोर आफ्नै अधिकारमा धेरै शक्तिशाली हुन्छ।

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

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

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

सरलताले विश्वसनीयता सुनिश्चित गर्दछ

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

कुञ्जी शब्द अनुक्रमणिकाले कहिलेकाहीं अविश्वसनीय रूपमा छिटो परिणामहरू उत्पादन गर्दछ, र अन्य पटक यो गर्दैन। मानौं तपाईंसँग 50 GB लगहरू छन् जसमा 'ग्राहक_5987235982' शब्द ठ्याक्कै तीन पटक देखिन्छ। यस शब्दको खोजीले अनुक्रमणिकाबाट सिधै तीन स्थानहरू गणना गर्दछ र तुरुन्तै पूरा हुनेछ। तर जटिल वाइल्डकार्ड खोजहरूले हजारौं किवर्डहरू स्क्यान गर्न र लामो समय लिन सक्छ।

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

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

सेवाको प्रयोगमा सहजताका लागि स्थिर, भरपर्दो कार्यसम्पादन महत्त्वपूर्ण छ। यदि यो आवधिक रूपमा ढिलो हुन्छ भने, प्रयोगकर्ताहरूले यसलाई अविश्वसनीय रूपमा बुझ्नेछन् र यसलाई प्रयोग गर्न अनिच्छुक हुनेछन्।

कार्यमा लग खोज

यहाँ एउटा छोटो एनिमेसन छ जसले Scalyr खोजलाई कार्यमा देखाउँछ। हामीसँग डेमो खाता छ जहाँ हामी प्रत्येक सार्वजनिक Github भण्डारमा प्रत्येक घटना आयात गर्छौं। यस डेमोमा, म एक हप्ताको डेटाको मूल्यको जाँच गर्छु: लगभग 600 MB कच्चा लगहरू।

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

निष्कर्षमा

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

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

ब्रूट फोर्स विधि प्रयोग गरेर, हामीले लगहरूको सेटमा छिटो, भरपर्दो, लचिलो खोज लागू गर्यौं। हामी आशा गर्दछौं कि यी विचारहरू तपाईंको परियोजनाहरूको लागि उपयोगी छन्।

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

स्रोत: www.habr.com