- 1 अरब वेबपेज को 24 घंटे में क्रॉल करने के वास्तविक अनुभव और आधुनिक वेब क्रॉलिंग सिस्टम डिज़ाइन प्रक्रिया का साझा विवरण
- नवीनतम हार्डवेयर और क्लाउड इंफ्रास्ट्रक्चर के साथ कुछ सौ डॉलर के खर्च में बड़े पैमाने की क्रॉलिंग संभव हुई, और यह पुष्टि हुई कि मुख्य bottleneck parsing है
- JavaScript चलाए बिना सिर्फ HTML parsing किया गया, फिर भी काफी बड़ी संख्या में वेबपेज तक पहुँचना संभव था
- Redis आधारित node cluster आर्किटेक्चर डिज़ाइन, domain-आधारित sharding और process संरचना के optimization से अधिकतम दक्षता हासिल की गई
- network की तुलना में CPU·SSL·memory बड़े bottleneck के रूप में सामने आए, और बड़े domain frontier का प्रबंधन मुख्य मुद्दा था
समस्या की परिभाषा
- 24 घंटे के भीतर 1 अरब वेबपेज क्रॉल करने का लक्ष्य तय किया गया
- बजट कुछ सौ डॉलर (अंतिम रूप से लगभग 462 डॉलर) रखा गया, जो 2012 के उदाहरण के समान स्तर पर था
- केवल HTML एकत्र किया गया, JavaScript नहीं चलाया गया और सिर्फ
<a> links निकाले गए
- Politeness (शिष्ट क्रॉलिंग) को महत्व दिया गया: robots.txt का पालन, User Agent जानकारी शामिल करना, अनुरोध पर domain को बाहर करना, सिर्फ शीर्ष 10 लाख लोकप्रिय domain को लक्ष्य बनाना, एक ही domain पर 70 सेकंड का अंतर रखना आदि लागू किए गए
- fault tolerance सुनिश्चित किया गया: node failure होने पर restart और कुछ डेटा हानि को स्वीकार करते हुए sample-आधारित approach अपनाई गई
आर्किटेक्चर और डिज़ाइन
- पारंपरिक system design interview style (feature-wise distribution) के विपरीत, हर node सभी functions (crawl state, parsing, fetch, storage आदि) खुद संभाले ऐसी संरचना चुनी गई
- 12 nodes, और हर node पर
i7i.4xlarge (16 vCPU, 128GB RAM, 10Gbps, 3750GB storage) instance का उपयोग किया गया
- हर node में 1 Redis, 9 fetcher, 6 parser processes थे
- Redis में domain-wise frontier, fetch queue, visited URL, Bloom filter, robots.txt, parsing queue आदि रखे गए
- Fetcher: domain के अनुसार queue से URL निकालकर fetch करता है, asyncio के साथ 6000~7000 concurrent tasks, मुख्य bottleneck CPU
- Parser: 80 async workers, HTML parsing और link extraction, CPU-केंद्रित कार्य
- Storage: S3 के बजाय instance local storage चुना गया, ताकि बड़े पेजों के storage cost कम हों
- Sharding: domains को nodes में बाँटा गया (कोई cross-communication नहीं), और लोकप्रिय domains के imbalance को सुलझाने के लिए sharding node count समायोजित किया गया
प्रमुख विकल्प और प्रयोग
- SQLite, PostgreSQL जैसे कई storage विकल्पों का परीक्षण किया गया, और अंततः Redis का performance सबसे बेहतर रहा
- vertical scaling (एक बड़ा single instance) भी आज़माया गया, लेकिन software limitations के कारण bottleneck आया; अंततः horizontal scaling (कई nodes) संरचना चुनी गई
- nodes के बीच cross-communication हटाकर, single node के भीतर parallel processing की गई
क्रॉलिंग प्रक्रिया से मिले मुख्य सबक
Parsing सबसे बड़ा bottleneck है
- औसत page size पहले (2012 में 51KB) की तुलना में काफी बढ़ गई थी (औसत 242KB, median 138KB)
- lxml के बजाय selectolax (Lexbor आधारित) पर बदलने से parsing speed में बड़ा सुधार हुआ
- अधिकतम page size को 250KB तक truncate करके efficiency बेहतर की गई
- परिणामस्वरूप, एक single parser पर प्रति सेकंड 160 pages parsing हासिल हुई, और अंत में fetcher:parser अनुपात 9:6 करके लगभग 950 pages/second throughput प्राप्त हुआ
Fetching: क्या आसान हुआ और क्या कठिन
- network bandwidth bottleneck नहीं था (प्रति node 25Gbps में से लगभग 8Gbps ही उपयोग हुआ)
- DNS bottleneck भी नहीं बना, क्योंकि लक्ष्य सिर्फ लोकप्रिय domains थे
- इसके विपरीत, SSL handshake कुल CPU उपयोग का 25% लेकर सबसे बड़े bottleneck में से एक बन गया
- अधिकांश pages के HTTPS पर जाने से CPU cost बढ़ गई
वास्तविक क्रॉल रन और समस्याएँ
- शुरुआती प्रयोगों में single node (
i7i.2xlarge) पर कुछ घंटों तक परीक्षण करने के बाद, मुख्य क्रॉल को 12 nodes तक बढ़ाया गया
- memory समस्या सामने आई: लोकप्रिय domains के frontier (अभी तक न देखे गए URLs) कई दर्जन GB तक बढ़ गए, जिससे nodes बार-बार down होने लगे
- लोकप्रिय domains (जैसे yahoo.com, wikipedia.org) या असामान्य रूप से बहुत अधिक links वाले sites ने समस्या पैदा की
- समस्या वाले domains को manually exclude किया गया, और failure होने पर node restart तथा frontier truncation से recovery की गई
सिद्धांत और व्यवहार की तुलना
- पारंपरिक textbook estimate "5 machines से 5 दिनों में 10 अरब pages" की तुलना में, वास्तविक आँकड़े काफी हद तक करीब निकले
- हर node के वास्तविक network और CPU utilization को देखते हुए, optimization के आधार पर इससे भी अधिक throughput संभव है
आगे की चुनौतियाँ और विचार
- सिर्फ HTML parsing से भी काफी वेबपेज तक पहुँचना संभव है यह फिर से साबित हुआ, लेकिन बड़े platforms (जैसे GitHub) में अर्थपूर्ण content JS के भीतर होने से parsing संभव नहीं थी
- भविष्य की चुनौती के रूप में JS rendering-आधारित बड़े पैमाने की क्रॉलिंग की लागत और तरीकों की जाँच की ज़रूरत है
- डेटा विश्लेषण (वास्तव में एकत्र किए गए pages का metadata, active/inactive ratio आदि) को भी आगे के विषय के रूप में बताया गया
- हाल के समय में AI के साथ जुड़ी aggressive crawling बढ़ रही है, और Cloudflare का pay-per-crawl जैसे नए defense mechanisms उभर रहे हैं, जिससे वेब क्रॉलिंग का माहौल फिर बदल रहा है
3 टिप्पणियां
कमाल है..वाह वाह वाह...
दिलचस्प है। अच्छे से पढ़कर जा रहा हूँ, धन्यवाद
कमाल है.. क्या ये भाले और ढाल की लड़ाई है? हा हा