वेब क्रॉलर डिज़ाइन करें: फ्रंटियर, शिष्टाचार, फ़ेच, डेडुप और स्केल

टीएल;डीआर

समस्या: बड़े पैमाने की वास्तुकला (आर्किटेक्चर) तैयार करने के लिए उपलब्धता, थ्रूपुट और परिचालन जटिलता के बीच संतुलन बनाना आवश्यक है।

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

परिणाम: उत्पादन वातावरण में विफलता से निपटने और प्रदर्शन लक्ष्यों को हासिल करने की सटीक रूपरेखा।

कल्पना कीजिए एक लाइब्रेरियन जो पृथ्वी के हर सार्वजनिक किताब का कार्ड बनाना चाहता है, बस अंतर इतना है कि "किताबें" वेब पेज हैं और हर सेकंड नई आती रहती हैं। या एक वैक्यूम रोबोट सोचिए जिसे शहर जितनी बड़ी इमारत के हर कमरे में जाना है: उसे साफ करने वाले कमरों की सूची चाहिए, उसे एक ही दरवाज़े पर सौ बार नहीं पीटना चाहिए, और उसे याद रखना चाहिए कि कौन से कमरे पहले साफ हो चुके हैं ताकि वह हमेशा के लिए घूमता न रहे।

वेब क्रॉलर वही लाइब्रेरियन और वही रोबोट है, सॉफ्टवेयर के रूप में। सर्च इंजन, आर्काइव, प्राइस मॉनिटर और रिसर्च टूल सब किसी न किसी रूप में यही इस्तेमाल करते हैं। गूगल का क्रॉलर मशहूर है, पर विचार किसी भी आकार में एक जैसा है: कहीं से शुरू करो, पेज डाउनलोड करो, लिंक ढूँढो, उन्हें आगे विज़िट करो, जो मिला उसे स्टोर करो, और वही काम दोबारा न करो।

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

हम कौन सी समस्या हल कर रहे हैं?

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

इसलिए क्रॉलर को करना होता है:

१. ज्ञात अच्छे पतों की छोटी सूची से शुरू करना। २. अभी बाकी पेजों की to-do सूची रखना। ३. हर पेज सावधानी से डाउनलोड करना ताकि कोई साइट कुचल न जाए। ४. एचटीएमएल पढ़ना, उपयोगी टेक्स्ट और लिंक निकालना। ५. पेज को टिकाऊ जगह पर रखना। ६. डुप्लिकेट पहचानना ताकि स्टोरेज और समय बर्बाद न हों। ७. बजट या कतार खत्म होने तक दोहराना।

अगर सिर्फ लूप याद रहे: खोजो → डाउनलोड करो → समझो → बचाओ → और खोजो।

पात्रों का समूह (साधारण शब्दों में)

नाम	वास्तविक जीवन में मतलब
सीड यूआरएल	वे पहले दरवाज़े जो आप जानबूझकर खोलते हैं
फ्रंटियर (कतार)	"अगला विज़िट" पतों की स्टिकी-नोट सूची
शिष्टाचार (politeness)	एक साइट पर लगातार प्रहार मत करो; हर होस्ट की बारी का इंतज़ार
फ़ेच	एचटीटीपी से पेज सच में डाउनलोड करना
पार्स	एचटीएमएल पढ़ना, लिंक और कंटेंट ढूँढना
स्टोर	पेज बॉडी और मेटाडेटा डिस्क या ऑब्जेक्ट स्टोरेज पर रखना
डेडुप	वे पते और बॉडी छोड़ना जो पहले संभाले जा चुके

इंटरव्यू में लोग "यूआरएल frontier," "fetcher," "content store," और "यूआरएल seen" कहते हैं। यही पात्र हैं, सिर्फ पेशेवर नामों में।

सीड यूआरएल: क्रॉल कहाँ से शुरू होता है

सीड वह यूआरएल है जिसे आप डिस्कवरी शुरू होने से पहले सिस्टम में खुद (या भरोसेमंद सूची से) डालते हैं। क्रॉलर हवा से पहला पेज नहीं बना सकता। सीड प्रवेश द्वार हैं।

अच्छे सीड ऐसे लगते हैं:

जानी-मानी होमपेज (न्यूज़ साइट, सरकारी पोर्टल, विश्वविद्यालय की जड़ें)।
विषय हब, अगर आपको सिर्फ शॉपिंग, खेल या डॉक्स चाहिए।
साइटमैप या "पिछले महीने के क्रॉल के टॉप होस्ट," जब आप फिर से शुरू कर रहे हों।

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

सीड पहले फ्रंटियर में जाते हैं। उसके बाद लगभग हर नया यूआरएल उन पेजों के लिंक से आता है जो आप पहले डाउनलोड कर चुके।

फ्रंटियर: इंटरनेट की to-do सूची

यूआरएल फ्रंटियर उन पेजों की कतार है जो अभी फ़ेच होने का इंतज़ार कर रहे हैं। इसे रोबोट की "अभी गंदे कमरे" की सूची समझें, या लाइब्रेरियन के "अभी जाँच बाकी किताबों" के ढेर की तरह।

उस सूची की ज़रूरी आदतें:

१. पहले आया, पहले गया, सरल कहानी है। ब्रेड्थ-फर्स्ट सर्च (बीएफएस) का मतलब: सीड के पास पहले जाओ, फिर बाहर फैलो। यह "इस मंज़िल के सब कमरे साफ करो, फिर एक अंतहीन बेसमेंट में मत कूदो" जैसा है। २. डेप्थ-फर्स्ट डिफ़ॉल्ट खराब है। एक लिंक श्रृंखला को हमेशा फॉलो करने से कैलेंडर, सेशन आईडी, या अनंत पाथ ट्रैप में फँस सकते हो। ३. प्राथमिकता मदद करती है। बड़े अखबार की होमपेज अक्सर किसी रैंडम कमेंट थ्रेड से पहले ध्यान की हक़दार होती है। प्रोडक्शन सिस्टम कई फ्रंट कतारें रखते हैं (ऊँची, मध्यम, नीची प्राथमिकता) और महत्वपूर्ण काम की ओर झुकाव रखते हुए भी बाकी को पूरी तरह भूखा नहीं छोड़ते। ४. सूची बहुत बड़ी है। करोड़ों पेंडिंग यूआरएल एक लैपटॉप की रैम में आराम से नहीं बैठते। असली फ्रंटियर डिस्क-बैक्ड कतारों पर रहते हैं, अक्सर होस्ट नाम से मशीनों पर बाँटे जाते हैं।

एक और संरचना ट्रिक: कई डिज़ाइन front queues प्राथमिकता के लिए और back queues हर वेबसाइट होस्ट के लिए रखते हैं। प्राथमिकता तय करती है किस तरह का काम तैयार है; होस्ट वाली कतार तय करती है कब उस होस्ट से फिर संपर्क हो सकता है। इसी विभाजन से शिष्टाचार और उपयोगी क्रम एक ही सिस्टम में रहते हैं।

नया यूआरएल → प्राथमिकता स्कोर → front queues → होस्ट से रूट → हर होस्ट की back queue → वर्कर

शिष्टाचार: एक साइट पर प्रहार मत करो

अगर आपका रोबोट example.com पर ५०० लिंक पाता है और एक साथ ५०० कनेक्शन खोलता है, तो आप क्रॉल नहीं कर रहे। आप हमला कर रहे हैं। साइटें धीमी हो जाती हैं, एरर देती हैं, या आपका आईपी बैन कर देती हैं। अच्छा क्रॉलर हर होस्ट को साझा लाइब्रेरी डेस्क की तरह मानता है: एक सावधानी भरा अनुरोध एक बार में (या छोटा, दस्तावेज़ीकृत लिमिट), फिर थोड़ा इंतज़ार।

शिष्टाचार आमतौर पर मतलब:

हर होस्ट पर ज़्यादा से ज़्यादा एक सक्रिय डाउनलोड (कभी-कभी प्रति आईपी, क्योंकि कई साइटें एक मशीन बाँटती हैं)।
उसी होस्ट की दो विज़िट के बीच देरी (उदाहरण: एक-दो सेकंड, या साइट जो माँगे)।
पहले robots.txt पढ़ना। यह छोटी फ़ाइल साइट मालिक https://host/robots.txt पर प्रकाशित करते हैं: "यहाँ क्रॉल कर सकते हो" और "/admin में मत आओ।"
साफ़ User-Agent स्ट्रिंग, संपर्क पेज के साथ, ताकि इंसान जानें आप कौन हो।
जब साइट 429 (बहुत अनुरोध) या 503 (अनुपलब्ध) दे तो और ज़ोर से पीछे हटना।

अगर इस पोस्ट से सिर्फ एक प्रोडक्शन नियम याद रहे: समानांतर क्रॉल को कभी एक होस्ट के खिलाफ denial-of-service मत बनने दो। पूरे वेब पर थ्रूपुट मायने रखता है। हर होस्ट पर शिष्टाचार गैर-मोलभाव वाला है।

फ़ेच: पेज डाउनलोड करना

फ़ेच वह पल है जब वर्कर सच में नेटवर्क पर कहता है "यह यूआरएल दो।"

सावधान फ़ेच पथ कुछ ऐसा दिखता है:

१. फ्रंटियर से अगला अनुमति-प्राप्त यूआरएल लो (होस्ट देरी का सम्मान करते हुए)। २. नॉर्मलाइज़ करो (होस्ट लोअरकेस, बेकार #section जैसे फ्रैगमेंट हटाओ; रिलेटिव रूप पार्स में ठीक होंगे)। ३. उस होस्ट के robots नियम जाँचो (कैश से, अगर पहले लाए थे)। ४. डीएनएस रिज़ॉल्व करो (लोकल कैश से, ताकि हर बार नाम लुकअप का इंतज़ार न हो)। ५. छोटे टाइमआउट, अधिकतम बॉडी साइज़, और सीमित रीडायरेक्ट बजट के साथ एचटीटीपी GET। ६. रिस्पॉन्स बॉडी पार्सर को दो, या फेलियर रिकॉर्ड करके आगे बढ़ो।

व्यावहारिक बातें जो शुरुआती को भी सुननी चाहिए:

चिंता	साधारण नियम
टाइमआउट	सेकंड में फेल हो, मिनटों में नहीं
विशाल फ़ाइलें	साइज़ कैप रखो ताकि एक विशाल डाउनलोड वर्कर न रोक दे
रीडायरेक्ट	हॉप सीमित; नए होस्ट पर कूदने पर उसी होस्ट का शिष्टाचार लागू
कम्प्रेशन	gzip स्वीकारो; बैंडविड्थ बचाओ
रीक्रॉल	जब कॉपी पहले हो तो `If-None-Match` / `If-Modified-Since` इस्तेमाल करो

स्केल पर आप कई मशीनों पर कई फ़ेचर चलाते हो, आमतौर पर होस्ट से शार्ड करते हो ताकि example.com का शिष्टाचार लॉक उन्हीं वर्कर्स के पास रहे जो example.com से बात करते हैं।

पार्स: एचटीएमएल पढ़ना और अगले दरवाज़े ढूँढना

पार्स मतलब: डाउनलोड किए बाइट्स के अंदर देखना और इतना समझना कि कंटेंट स्टोर हो और लिंक निकल सकें।

एचटीएमएल के लिए आमतौर पर:

१. पुष्टि करो कि यह मोटे तौर पर एचटीएमएल है (कोई अवांछित बाइनरी नहीं)। २. मुख्य टेक्स्ट और उपयोगी मेटाडेटा निकालो (टाइटल, भाषा संकेत, कैनोनिकल यूआरएल अगर हो)। ३. हर a href="..." लिंक ढूँढो। ४. रिलेटिव लिंक (/about) को एब्सोल्यूट (https://example.com/about) बनाओ, रीडायरेक्ट के बाद के अंतिम यूआरएल से। ५. यूआरएल साफ करो: #fragment हटाओ, प्रोडक्ट अनुमति दे तो ट्रैकिंग जंक भी।

फिर यूआरएल फ़िल्टर वह काम फेंकता है जिसे आप करने से इनकार करते हो:

mailto:, javascript:, data: स्कीम।
अवांछित फ़ाइल प्रकार (.zip, .mp4) जब तक प्रोडक्ट न कहे।
बेहद लंबे यूआरएल जो स्पाइडर ट्रैप लगते हों।
ब्लैकलिस्टेड होस्ट।

जो बचता है यूआरएल डेडुप (नीचे) से गुज़रता है और अगर नया हो तो फ्रंटियर में वापस जाता है।

छोटे स्केल पर पार्स और फ़ेच एक मशीन पर रह सकते हैं। बड़े स्केल पर डाउनलोड वर्कर और पार्स वर्कर अलग स्टेज होते हैं, ताकि धीमा पार्सर नेटवर्क न रोके।

स्टोर: जो डाउनलोड का खर्चा चुकाया, उसे रखना

स्टोर क्रॉल की टिकाऊ याद है: पेज बॉडी, और इतना मेटाडेटा कि बाद में काम आ सके (इंडेक्स, आर्काइव, अगले हफ्ते तुलना)।

आमतौर पर विभाजन:

ब्लॉब / ऑब्जेक्ट स्टोरेज एचटीएमएल (या कम्प्रेस्ड एचटीएमएल) के लिए। बड़ा, राइट-हैवी, समय के साथ सस्ते टियर।
मेटाडेटा डेटाबेस छोटे तथ्यों के लिए: यूआरएल, फ़ेच समय, स्टेटस कोड, कंटेंट टाइप, कंटेंट हैश, साइज़।

मेटाडेटा इसलिए रखते हो कि हर ब्लॉब दोबारा न पढ़ना पड़े: "आखिरी बार कब फ़ेच किया?" "क्या ४०४ था?" "यह हैश पहले से जाना है?"

रीक्रॉल नीति पास ही रहती है। महत्वपूर्ण पेज अक्सर बदलते हैं; लंबे टेल वाले ज़्यादा इंतज़ार कर सकते हैं। पूरे वेब का अंधा पूरा रीक्रॉल महंगा है, इसलिए सिस्टम बदलाव दर सीखते हैं और बजट वहीं खर्च करते हैं जहाँ ताज़गी ज़रूरी हो।

डेडुप: पहले किया काम छोड़ो

वेब कॉपी पसंद करता है। वही लेख www और बिना-www डोमेन पर आ सकता है। मिरर नए यूआरएल के नीचे वही बॉडी छापते हैं। डेडुप्लिकेशन के बिना आप डिस्क और सीपीयू पर déjà vu जलाते हो।

दो परतें हैं, और शुरुआती दोनों याद रखें:

परत	सवाल	रोज़मर्रा की उपमा
यूआरएल seen	क्या हमने यह पता पहले शेड्यूल या फ़ेच किया?	क्या सफाई सूची पर यह कमरा नंबर पहले लिखा?
Content seen	क्या हमने यह पेज बॉडी (या सटीक जुड़वाँ) पहले स्टोर की?	क्या यही किताब टेक्स्ट दूसरी कॉल नंबर के नीचे पहले फाइल हुई?

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

कंटेंट डेडुप बॉडी का हैश बनाता है (सटीक कॉपी)। अगर हैश पहले है, तो पूरा नया ब्लॉब न लिखो, या पहली कॉपी का पॉइंटर रखो। लगभग-डुप्लिकेट (अलग विज्ञापन वाला वही लेख) बाद का, भारी सिस्टम है। इंटरव्यू का डिफ़ॉल्ट सटीक हैश है।

दोनों परतें अलग-अलग बग के लिए ज़रूरी:

दो यूआरएल, एक बॉडी → कंटेंट डेडुप स्टोरेज बचाता है।
अनंत अद्वितीय यूआरएल जंक क्वेरी के साथ → यूआरएल फ़िल्टर, पाथ सीमा, और प्रति-होस्ट बजट फ्रंटियर बचाते हैं।

उच्च-स्तरीय चित्र

सीड यूआरएल
    │
    ▼
┌─────────────┐     ┌──────────────┐     ┌────────────────┐
│ URL Frontier│────►│ Fetcher      │────►│ Parser         │
│ (प्राथमिकता│     │ DNS, robots, │     │ लिंक + बॉडी    │
│  + शिष्टाचार)│    │ HTTP GET     │     └────────┬───────┘
└──────▲──────┘     └──────────────┘              │
       │                                          ▼
       │                                 कंटेंट हैश नया?
       │                                    │         │
       │                                   हाँ        नहीं → छोड़ो या सिर्फ लिंक
       │                                    ▼
       │                                 content store
       │                                    ▼
       │                                 लिंक निकालो
       │                                    ▼
       │                                 फ़िल्टर + URL seen?
       │                                    │
       └────────────── सिर्फ नए यूआरएल ──────┘

एक पेज की पाइपलाइन यात्रा

एक अकेले पेज का पीछा करें ताकि हिस्से अमूर्त न लगें।

सेटअप। सीड में https://news.example/ है। फ्रंटियर खाली है सिवाय उस सीड के। शिष्टाचार कहता है: हर होस्ट पर एक समय में एक फ़ेच, छोटी देरी के साथ।

१. सीड लोड। https://news.example/ फ्रंटियर में ऊँची प्राथमिकता से आता है क्योंकि यह होमपेज है।

२. शिष्टाचार के साथ dequeue। एक वर्कर वह यूआरएल निकालता है। news.example पर कोई और फ़ेच नहीं चल रहा। Robots नियम https://news.example/robots.txt से लोड और कैश होते हैं। पाथ / अनुमत है।

३. फ़ेच। डीएनएस news.example रिज़ॉल्व करता है। वर्कर साफ़ User-Agent और १० सेकंड टाइमआउट के साथ एचटीटीपी GET भेजता है। स्टेटस २००। बॉडी लगभग ८० KB एचटीएमएल।

४. पार्स। पार्सर टाइटल "Example News," मुख्य लेख टेक्स्ट पढ़ता है, और लिंक ढूँढता है:

https://news.example/politics/bill-42
https://news.example/sports/final
https://other-site.org/op-ed
mailto:tips@news.example (फ़िल्टर)
/local/weather (https://news.example/local/weather बनता है)

५. कंटेंट डेडुप। एचटीएमएल का हैश नया है। बॉडी ऑब्जेक्ट स्टोरेज में लिखो। मेटाडेटा लिखो: यूआरएल, समय, २००, हैश, साइज़।

६. यूआरएल फ़िल्टर और यूआरएल seen।

mailto: हटा।
तीन http(s) लिंक नॉर्मलाइज़।
कोई यूआरएल-seen सेट में नहीं था, इसलिए तीनों marked seen और enqueue।
other-site.org news.example से अलग back queue में जाता है।

७. अगले चक्र।

वर्कर को अगले news.example यूआरएल से पहले शिष्टाचार देरी का इंतज़ार चाहिए।
दूसरा वर्कर https://other-site.org/op-ed तुरंत फ़ेच कर सकता है अगर वह होस्ट खाली हो।
जब बाद में politics/bill-42 फ़ेच हो, उसकी बॉडी अनोखी हो सकती है, या पहले स्टोर मिरर से मिल सकती है (कंटेंट डेडुप)।
वहाँ मिले लिंक फिर फ्रंटियर भरते हैं।

८. फेलियर पथ (वही पेज विचार)। अगर फ़ेच टाइमआउट हो, सिस्टम फेलियर रिकॉर्ड करता है, शायद backoff से रीट्राई, और यह दिखावा नहीं करता कि पेज स्टोर हो गया। अगर robots /admin मना करता है, वह यूआरएल "robots जाँच" स्टेप से आगे नहीं जाता।

एक पेज के बाद आपने हर बड़ा विचार अभ्यास कर लिया: सीड, फ्रंटियर, शिष्टाचार, फ़ेच, पार्स, स्टोर, दोहरी डेडुप, और मल्टी-होस्ट शेड्यूलिंग।

कुछ स्केल नोट (फिर भी साधारण भाषा)

जब लोग कहते हैं "एक अरब पेज प्रति माह का क्रॉलर डिज़ाइन करो," आकार वही रहता है। फर्नीचर बड़ा हो जाता है।

मोटा रेट: १ अरब पेज / ३० दिन / ८६,४०० सेकंड ≈ औसत ४०० पेज प्रति सेकंड। पीक ऊँचा हो सकता है।
स्टोरेज: अगर औसत एचटीएमएल सैकड़ों किलोबाइट है, मासिक कच्चा डेटा सैकड़ों टेराबाइट है। कम्प्रेशन और बहु-वर्ष रिटेंशन इसे असली स्टोरेज डिज़ाइन बनाते हैं, साइड फ़ोल्डर नहीं।
होस्ट से शार्ड: फ्रंटियर स्लाइस, शिष्टाचार स्टेट, और अक्सर फ़ेच वर्कर होस्ट हैश से समूहित रखो ताकि एक मशीन वेबसाइटों का सेट होल्ड करे।
स्पाइडर ट्रैप: अनंत कैलेंडर, सेशन आईडी, रिकर्सिव पाथ रोबोट को एक गलियारे में हमेशा के लिए फँसाना चाहते हैं। यूआरएल लंबाई, पाथ गहराई, और प्रति-होस्ट प्रति-दिन पेज कैप रखो। मानव किल स्विच रखो।
JS-भारी साइटें: कुछ लिंक तभी दिखते हैं जब ब्राउज़र जावास्क्रिप्ट चलाए। पूरा रेंडर महंगा है। उच्च-मूल्य होस्ट पर इस्तेमाल करो, पहले दिन हर रैंडम पेज पर नहीं।

इंटरव्यू में गूगल का क्रॉलर बनाने की ज़रूरत नहीं। लूप, शिष्टाचार, और दो तरह की डेडुप समझना दिखाना ज़रूरी है।

दोस्त के लिए संक्षेप

वेब क्रॉलर वह सॉफ्टवेयर है जो सार्वजनिक वेब को कैटलॉग करता है जैसे लाइब्रेरियन किताबें कैटलॉग करता है और वैक्यूम रोबोट कमरे विज़िट करता है।

आप कुछ सीड यूआरएल से शुरू करते हो, वे दरवाज़े जो जानबूझकर चुनते हो। वे फ्रंटियर में जाते हैं, अभी-विज़िट-बाकी पेजों की बड़ी to-do कतार। वर्कर उस कतार से निकालते हैं, पर शिष्ट रहते हैं: हर वेबसाइट पर एक समय में एक सावधान अनुरोध, देरी के साथ, और robots.txt का सम्मान ताकि मालिक कह सकें "इस गलियारे में मत आओ।"

फ़ेच पेज डाउनलोड करता है। पार्स एचटीएमएल पढ़ता है, उपयोगी टेक्स्ट बचाता है, नए लिंक ढूँढता है। स्टोर पेज और मेटाडेटा रखता है। डेडुप दो बार काम करता है: एक बार ताकि वही यूआरएल हमेशा enqueue न हो, और एक बार ताकि वही लेख बॉडी दस पतों के नीचे न स्टोर हो।

फिर नए लिंक फ्रंटियर में लौटते हैं, और रोबोट चलता रहता है। पूरा डिज़ाइन वही लूप है, उन साइटों के लिए सुरक्षित जिन्हें आप विज़िट करते हो, और इंटरनेट स्केल पर चलाने लायक सस्ता।

समापन

अगर इंटरव्यू में सिर्फ एक डायग्राम खींचो, तो लूप खींचो: फ्रंटियर → शिष्ट फ़ेच → पार्स → कंटेंट स्टोर → लिंक निकालना → यूआरएल फ़िल्टर और seen → वापस फ्रंटियर। प्रवेश पर सीड लेबल करो। ज़ोर से कहो कि प्राथमिकता और शिष्टाचार फ्रंटियर में रहते हैं, बाद में जोड़ी गई चीज़ नहीं।

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