ধাপ ৩ - ডিজাইনের গভীর বিশ্লেষণ (Design deep dive)

এ পর্যন্ত, আমরা উচ্চ-স্তরের ডিজাইন নিয়ে আলোচনা করেছি। এরপর, আমরা সবচেয়ে গুরুত্বপূর্ণ বিল্ডিং উপাদান এবং কৌশলগুলো গভীরভাবে আলোচনা করব:

• ডেপথ-ফার্স্ট সার্চ (DFS) বনাম ব্রেডথ-ফার্স্ট সার্চ (BFS)
• URL frontier
• HTML Downloader
• রোবাস্টনেস (Robustness)
• এক্সটেনসিবিলিটি (Extensibility)
• সমস্যাজনক কন্টেন্ট সনাক্ত করা এবং এড়ানো

DFS বনাম BFS

আপনি ওয়েবকে একটি ডিরেক্টেড গ্রাফ হিসাবে ভাবতে পারেন যেখানে ওয়েব পেজগুলো নোড হিসাবে এবং হাইপারলিংকগুলো (URL) এজ হিসাবে কাজ করে। ক্রল প্রক্রিয়াটিকে একটি ওয়েব পেজ থেকে অন্যদের কাছে একটি ডিরেক্টেড গ্রাফ অতিক্রম করা হিসাবে দেখা যেতে পারে। দুটি সাধারণ গ্রাফ ট্রাভার্সাল অ্যালগরিদম হলো DFS এবং BFS। তবে, DFS সাধারণত একটি ভালো পছন্দ নয় কারণ DFS-এর গভীরতা অনেক গভীর হতে পারে।

BFS সাধারণত ওয়েব ক্রলার দ্বারা ব্যবহৃত হয় এবং একটি first-in-first-out (FIFO) কিউ দ্বারা বাস্তবায়ন করা হয়। একটি FIFO কিউতে, URL গুলো তারা যে ক্রমে এনকিউ (enqueue) করা হয়েছিল সেই ক্রমে ডিকিউ (dequeue) করা হয়। তবে, এই বাস্তবায়নের দুটি সমস্যা রয়েছে:

• একই ওয়েব পেজ থেকে বেশিরভাগ লিংক একই হোস্টে ফিরে লিংক করা থাকে। চিত্র ৫-এ, wikipedia.com-এর সমস্ত লিংক হলো ইন্টারনাল লিংক, যা ক্রলারকে একই হোস্ট (wikipedia.com) থেকে URL প্রসেস করতে ব্যস্ত রাখে। যখন ক্রলার সমান্তরালভাবে (parallel) ওয়েব পেজ ডাউনলোড করার চেষ্টা করে, তখন Wikipedia সার্ভারগুলো রিকোয়েস্টে উপচে পড়বে। একে “অভদ্র” (impolite) হিসাবে বিবেচনা করা হয়।

[চিত্র ৫-এর বর্ণনা: ছবিটি একটি ওয়েবসাইটের মধ্যে ওয়েব পেজগুলোর সংগঠন চিত্রিত করে এমন একটি হায়ারার্কিক্যাল বা স্তরযুক্ত কাঠামো উপস্থাপন করে, সম্ভবত Wikipedia। রুট নোড হলো ‘wikipedia.com’, যা মূল ওয়েবসাইট ডোমেইন নির্দেশ করে। এই রুট থেকে, বেশ কয়েকটি শাখা বিভিন্ন মূল পেজ নির্দেশ করতে প্রসারিত হয়, যার লেবেল ‘wikipedia.com/page1’, ‘wikipedia.com/page2’, এবং ‘wikipedia.com/pageN’, যা মূল পেজগুলোর একটি পরিবর্তনশীল সংখ্যা নির্দেশ করে। এই প্রতিটি মূল পেজ আরও সাব-পেজে শাখা-প্রশাখাযুক্ত হয়, উদাহরণস্বরূপ ‘wikipedia.com/page1/1’, ‘wikipedia.com/page1/2’, ‘wikipedia.com/page2/1’, ‘wikipedia.com/page2/2’, ‘wikipedia.com/pageN/1’, ‘wikipedia.com/pageN/2’, এবং ‘wikipedia.com/pageN/N’। উপবৃত্তাকার চিহ্ন (…) নির্দেশ করে যে এই প্যাটার্নটি প্রতিটি মূল পেজের অধীনে একটি অনির্দিষ্ট সংখ্যক মূল পেজ এবং সাব-পেজের জন্য চলতে থাকে। তীর চিহ্নগুলো দিকনির্দেশক সম্পর্ক দেখায়, নির্দেশ করে যে ‘wikipedia.com’-এ অ্যাক্সেস করলে মূল পেজগুলোতে যাওয়া যায়, এবং একটি মূল পেজে অ্যাক্সেস করলে এর সংশ্লিষ্ট সাব-পেজগুলোতে যাওয়া যায়। কাঠামোটি দৃশ্যত একটি ডোমেইনের মধ্যে ওয়েব পেজগুলোর ট্রি-এর মতো সংগঠন প্রদর্শন করে, চিত্রিত করে কীভাবে একটি ওয়েবসাইট একাধিক স্তরের পেজ নিয়ে গঠিত হতে পারে।] চিত্র ৫

• স্ট্যান্ডার্ড BFS একটি URL-এর প্রায়োরিটি বা অগ্রাধিকার বিবেচনা করে না। ওয়েব বড় এবং প্রতিটি পেজের গুণমান এবং গুরুত্বের স্তর এক নয়। তাই, আমরা তাদের পেজ র‍্যাঙ্ক, ওয়েব ট্র্যাফিক, আপডেটের ফ্রিকোয়েন্সি ইত্যাদি অনুযায়ী URL গুলোকে অগ্রাধিকার দিতে চাইতে পারি।

URL frontier

URL frontier এই সমস্যাগুলো সমাধান করতে সাহায্য করে। একটি URL frontier হলো একটি ডেটা স্ট্রাকচার যা ডাউনলোড করার জন্য URL গুলো সংরক্ষণ করে। ভদ্রতা (politeness), URL অগ্রাধিকার (prioritization), এবং তাজাত্ব (freshness) নিশ্চিত করতে URL frontier একটি গুরুত্বপূর্ণ উপাদান। রেফারেন্স ম্যাটেরিয়ালে [5] [9] URL frontier-এর কিছু উল্লেখযোগ্য পেপারের কথা উল্লেখ করা হয়েছে। এই পেপারগুলো থেকে প্রাপ্ত ফলাফলগুলো নিম্নরূপ:

ভদ্রতা (Politeness)

সাধারণত, একটি ওয়েব ক্রলারের উচিত অল্প সময়ের মধ্যে একই হোস্টিং সার্ভারে খুব বেশি রিকোয়েস্ট পাঠানো এড়ানো। খুব বেশি রিকোয়েস্ট পাঠানোকে “অভদ্র” হিসাবে বিবেচনা করা হয় বা এমনকি ডিনায়াল-অফ-সার্ভিস (DOS) অ্যাটাক হিসাবেও গণ্য করা হয়। উদাহরণস্বরূপ, কোনো সীমাবদ্ধতা ছাড়াই, ক্রলার প্রতি সেকেন্ডে একই ওয়েবসাইটে হাজার হাজার রিকোয়েস্ট পাঠাতে পারে। এটি ওয়েব সার্ভারগুলোকে উপচে ফেলতে পারে।

ভদ্রতা কার্যকর করার সাধারণ ধারণা হলো একই হোস্ট থেকে একবারে একটি পেজ ডাউনলোড করা। দুটি ডাউনলোড টাস্কের মধ্যে একটি বিলম্ব (delay) যোগ করা যেতে পারে। ভদ্রতার সীমাবদ্ধতা ওয়েবসাইটের হোস্টনেম থেকে ডাউনলোড (ওয়ার্কার) থ্রেডগুলোর একটি ম্যাপিং বজায় রেখে বাস্তবায়ন করা হয়। প্রতিটি ডাউনলোডার থ্রেডের একটি পৃথক FIFO কিউ থাকে এবং এটি শুধুমাত্র সেই কিউ থেকে প্রাপ্ত URL গুলো ডাউনলোড করে। চিত্র ৬ ভদ্রতা পরিচালনা করে এমন ডিজাইনটি দেখায়।

[চিত্র ৬-এর বর্ণনা: ছবিটি টাস্ক বিতরণের জন্য একটি সিস্টেম আর্কিটেকচার ডায়াগ্রাম উপস্থাপন করে। একটি ‘Queue router’ উপাদান উপরে বসে থাকে, বিভিন্ন টাস্কের ধরন বা অগ্রাধিকার নির্দেশ করে একাধিক কিউতে টাস্ক বিতরণ করে যার লেবেল ‘b1’, ‘b2’, এবং ‘bn’। এই কিউগুলো উল্লম্ব আয়তক্ষেত্র হিসাবে চিত্রিত করা হয়েছে। ‘Queue router’ একটি ‘Mapping Table’-তেও (একটি ডাটাবেস আইকন হিসাবে উপস্থাপিত) তথ্য পাঠায়, যা একটি লুকআপ বা ম্যাপিং ফাংশন নির্দেশ করে। প্রতিটি কিউ (‘b1’, ‘b2’, ‘bn’) একটি ‘Queue selector’-এ ফিড করে, যা তারপর একাধিক ‘Worker thread’-এ (লেবেলযুক্ত ‘Worker thread 1’, ‘Worker thread 2’, এবং ‘Worker thread N’) টাস্ক বিতরণ করে, যা ভেতরে সবুজ বার সহ আয়তক্ষেত্র হিসাবে উপস্থাপিত, যা সমান্তরাল প্রসেসিং নির্দেশ করে। উপবৃত্তাকার চিহ্ন (…) নির্দেশ করে যে স্পষ্টভাবে দেখানোর বাইরেও একাধিক কিউ এবং ওয়ার্কার থ্রেড রয়েছে। তীর চিহ্নগুলো উপাদানগুলোর মধ্যে টাস্ক বা তথ্যের প্রবাহ চিত্রিত করে।] চিত্র ৬

• Queue router: এটি নিশ্চিত করে যে প্রতিটি কিউ (b1, b2, … bn) শুধুমাত্র একই হোস্টের URL গুলো ধারণ করে।
• Mapping table: এটি প্রতিটি হোস্টকে একটি কিউতে ম্যাপ করে।

টেবিল ১

• FIFO কিউ b1, b2 থেকে bn: প্রতিটি কিউ একই হোস্টের URL গুলো ধারণ করে।
• Queue selector: প্রতিটি ওয়ার্কার থ্রেড একটি FIFO কিউতে ম্যাপ করা থাকে, এবং এটি শুধুমাত্র সেই কিউ থেকে URL গুলো ডাউনলোড করে। কিউ নির্বাচনের যুক্তি Queue selector দ্বারা সম্পন্ন করা হয়।
• Worker thread 1 থেকে N: একটি ওয়ার্কার থ্রেড একই হোস্ট থেকে একে একে ওয়েব পেজ ডাউনলোড করে। দুটি ডাউনলোড টাস্কের মধ্যে একটি বিলম্ব যোগ করা যেতে পারে।

অগ্রাধিকার (Priority)

অ্যাপল পণ্য সম্পর্কে একটি ডিসকাশন ফোরাম থেকে একটি র‍্যান্ডম পোস্ট অ্যাপলের হোম পেজের পোস্টগুলোর চেয়ে খুব আলাদা গুরুত্ব বহন করে। যদিও তাদের উভয়ের মধ্যে “Apple” কীওয়ার্ড রয়েছে, তবুও একটি ক্রলারের জন্য প্রথমে অ্যাপলের হোম পেজ ক্রল করাটা যুক্তিযুক্ত।

আমরা উপযোগিতার ওপর ভিত্তি করে URL গুলোকে অগ্রাধিকার দিই, যা PageRank [10], ওয়েবসাইট ট্র্যাফিক, আপডেটের ফ্রিকোয়েন্সি ইত্যাদি দ্বারা পরিমাপ করা যেতে পারে। “Prioritizer” হলো সেই উপাদান যা URL অগ্রাধিকার পরিচালনা করে। এই ধারণা সম্পর্কে গভীর তথ্যের জন্য রেফারেন্স ম্যাটেরিয়াল [5] [10] দেখুন।

চিত্র ৭ URL অগ্রাধিকার পরিচালনা করে এমন ডিজাইনটি দেখায়।

[চিত্র ৭-এর বর্ণনা: ছবিটি URL প্রসেসিংয়ের জন্য একটি সিস্টেম উপস্থাপন করে। input URLs-এর একটি স্ট্রিম একটি Prioritizer উপাদানে প্রবেশ করে, যা তারপর এই URL গুলোকে f1, f2, …, fn লেবেলযুক্ত একাধিক কিউতে বিতরণ করে। এই কিউগুলো উল্লম্বভাবে স্তূপকৃত আয়তক্ষেত্র হিসাবে উপস্থাপিত, যা বোঝায় যে তারা একাধিক URL ধারণ করে। Prioritizer কিছু অগ্রাধিকার যুক্তির ওপর ভিত্তি করে (ডায়াগ্রামে নির্দিষ্ট করা হয়নি) প্রতিটি আগত URL কোন কিউতে অ্যাসাইন করা উচিত তা নির্ধারণ করে। তাদের সংশ্লিষ্ট কিউতে প্রসেস হওয়ার পরে, সমস্ত কিউ থেকে URL গুলো একটি Queue selector উপাদানে ফিড করা হয়। এই উপাদানটি বিভিন্ন কিউ থেকে URL নির্বাচন করে, সম্ভবত কিছু নির্বাচনের মানদণ্ডের ওপর ভিত্তি করে (আবারও, বিস্তারিত বলা হয়নি), এবং output URLs-এর একটি স্ট্রিম আউটপুট করে। উপবৃত্তাকার চিহ্ন (…) নির্দেশ করে যে স্পষ্টভাবে দেখানোর চেয়ে f2 এবং fn-এর মধ্যে আরও কিউ রয়েছে। সামগ্রিক প্রবাহটি উপর থেকে নিচে, URL গুলো উপরে প্রবেশ করছে এবং নিচে বের হচ্ছে।] চিত্র ৭

• Prioritizer: এটি URL গুলোকে ইনপুট হিসাবে নেয় এবং অগ্রাধিকারগুলো গণনা করে।
• Queue f1 থেকে fn: প্রতিটি কিউতে একটি নির্ধারিত অগ্রাধিকার রয়েছে। উচ্চ অগ্রাধিকারযুক্ত কিউগুলো উচ্চ সম্ভাবনায় নির্বাচিত হয়।
• Queue selector: উচ্চ অগ্রাধিকারযুক্ত কিউগুলোর প্রতি পক্ষপাত (bias) সহ একটি কিউ র‍্যান্ডমভাবে বেছে নেয়।

চিত্র ৮ URL frontier ডিজাইন উপস্থাপন করে, এবং এটি দুটি মডিউল ধারণ করে:

• Front queues: অগ্রাধিকার পরিচালনা করে
• Back queues: ভদ্রতা পরিচালনা করে

[চিত্র ৮-এর বর্ণনা: ছবিটি URL প্রসেসিংয়ের জন্য একটি সিস্টেম আর্কিটেকচার ডায়াগ্রাম উপস্থাপন করে। ইনপুট URL গুলো সিস্টেমে প্রবেশ করে এবং একটি Prioritizer দ্বারা প্রসেস করা হয়, যা সেগুলোকে একাধিক Front queues (f1, f2, …, fn)-এ বিতরণ করে, যা উল্লম্ব আয়তক্ষেত্র হিসাবে উপস্থাপিত। এই কিউগুলো একটি Front queue selector-এ ফিড করে, যা URL গুলো আউটপুট করে। output URLs গুলো তারপর একটি Back queue router দ্বারা একাধিক Back queues (b1, b2, …, bn)-এ রুট করা হয়, যাও আয়তক্ষেত্র হিসাবে উপস্থাপিত। Back queue router একটি Mapping Table-তেও তথ্য পাঠায়, যা একটি ডাটাবেস আইকন হিসাবে চিত্রিত। পরিশেষে, একটি Back queue selector ব্যাক কিউ থেকে URL গুলো একাধিক Worker threads (1, 2, 3, …)-এ বিতরণ করে, যা সবুজ আয়তক্ষেত্র হিসাবে দেখানো হয়েছে, চূড়ান্ত প্রসেসিংয়ের জন্য। তীর চিহ্নগুলো উপাদানগুলোর মধ্যে ডেটা প্রবাহ নির্দেশ করে। উপবৃত্তাকার চিহ্ন (…) নির্দেশ করে যে স্পষ্টভাবে দেখানোর চেয়ে আরও কিউ এবং ওয়ার্কার থ্রেড রয়েছে।] চিত্র ৮

তাজাত্ব (Freshness)

ওয়েব পেজগুলো ক্রমাগত যুক্ত, মুছে ফেলা এবং সম্পাদিত হচ্ছে। আমাদের ডেটা সেট তাজা রাখতে একটি ওয়েব ক্রলারকে অবশ্যই পর্যায়ক্রমে ডাউনলোড করা পেজগুলো পুনরায় ক্রল করতে হবে। সমস্ত URL পুনরায় ক্রল করা সময়সাপেক্ষ এবং রিসোর্স-নিবিড়। তাজাত্ব অপ্টিমাইজ করার জন্য কয়েকটি কৌশল নিচে তালিকাভুক্ত করা হলো:

• ওয়েব পেজগুলোর আপডেটের ইতিহাসের ওপর ভিত্তি করে পুনরায় ক্রল করা।
• URL গুলোকে অগ্রাধিকার দেওয়া এবং গুরুত্বপূর্ণ পেজগুলো প্রথমে এবং আরও ঘন ঘন পুনরায় ক্রল করা।

URL Frontier-এর জন্য স্টোরেজ

সার্চ ইঞ্জিনের জন্য বাস্তব বিশ্বের ক্রলে, frontier-এ URL গুলোর সংখ্যা শত শত মিলিয়ন হতে পারে [4]। সবকিছু মেমরিতে রাখা টেকসইও নয় এবং স্কেলেবলও নয়। সবকিছু ডিস্কে রাখাও বাঞ্ছনীয় নয় কারণ ডিস্ক ধীরগতির; এবং এটি সহজেই ক্রলের জন্য একটি বটলনেক হয়ে উঠতে পারে।

আমরা একটি হাইব্রিড পদ্ধতি গ্রহণ করেছি। বেশিরভাগ URL ডিস্কে সংরক্ষণ করা হয়, তাই স্টোরেজ স্পেস কোনো সমস্যা নয়। ডিস্ক থেকে পড়া এবং ডিস্কে লেখার খরচ কমাতে, আমরা enqueue/dequeue অপারেশনের জন্য মেমরিতে বাফার বজায় রাখি। বাফারে থাকা ডেটা পর্যায়ক্রমে ডিস্কে লেখা হয়।

HTML Downloader

HTML Downloader HTTP প্রোটোকল ব্যবহার করে ইন্টারনেট থেকে ওয়েব পেজগুলো ডাউনলোড করে। HTML Downloader নিয়ে আলোচনা করার আগে, আমরা প্রথমে Robots Exclusion Protocol-এর দিকে তাকাই।

Robots.txt

Robots.txt, যাকে Robots Exclusion Protocol বলা হয়, হলো একটি স্ট্যান্ডার্ড যা ওয়েবসাইটগুলো ক্রলারদের সাথে যোগাযোগ করতে ব্যবহার করে। এটি নির্দিষ্ট করে যে ক্রলারগুলো কোন পেজগুলো ডাউনলোড করতে অনুমোদিত। একটি ওয়েব সাইট ক্রল করার চেষ্টা করার আগে, একটি ক্রলারের উচিত প্রথমে তার সংশ্লিষ্ট robots.txt চেক করা এবং এর নিয়মগুলো মেনে চলা।

robots.txt ফাইলের পুনরাবৃত্তি ডাউনলোড এড়াতে, আমরা ফাইলের ফলাফলগুলো ক্যাশ করি। ফাইলটি পর্যায়ক্রমে ডাউনলোড এবং ক্যাশে সংরক্ষণ করা হয়। এখানে https://www.amazon.com/robots.txt  থেকে নেওয়া robots.txt ফাইলের একটি অংশ দেওয়া হলো। creatorhub-এর মতো কিছু ডিরেক্টরি Google bot-এর জন্য নিষিদ্ধ (disallowed)।

User-agent: Googlebot
Disallow: /creatorhub/*
Disallow: /rss/people/*/reviews
Disallow: /gp/pdp/rss/*/reviews
Disallow: /gp/cdp/member-reviews/
Disallow: /gp/aw/cr/

robots.txt ছাড়াও, পারফরম্যান্স অপ্টিমাইজেশন হলো আরেকটি গুরুত্বপূর্ণ ধারণা যা আমরা HTML ডাউনলোডারের জন্য কভার করব।

পারফরম্যান্স অপ্টিমাইজেশন

নিচে HTML ডাউনলোডারের জন্য পারফরম্যান্স অপ্টিমাইজেশনের একটি তালিকা দেওয়া হলো।

১. ডিস্ট্রিবিউটেড ক্রল (Distributed crawl)

উচ্চ পারফরম্যান্স অর্জন করতে, ক্রল জবগুলো একাধিক সার্ভারে বিতরণ করা হয়, এবং প্রতিটি সার্ভার একাধিক থ্রেড চালায়। URL স্পেসকে ছোট ছোট টুকরোতে ভাগ করা হয়; তাই, প্রতিটি ডাউনলোডার URL গুলোর একটি সাবসেটের জন্য দায়ী থাকে। চিত্র ৯ একটি ডিস্ট্রিবিউটেড ক্রলের একটি উদাহরণ দেখায়।

[চিত্র ৯-এর বর্ণনা: ছবিটি একটি সিস্টেম আর্কিটেকচার ডায়াগ্রাম উপস্থাপন করে যা একটি কেন্দ্রীয় উপাদান দেখায় যার লেবেল ‘URL Frontier’ একাধিক ‘HTML Downloaders’-এ URL বিতরণ করছে। URL Frontier একটি ডিসপ্যাচার হিসাবে কাজ করে, ‘distribute URLs’ লেবেলযুক্ত নির্দেশিত তীর চিহ্নের মাধ্যমে তিনটি চিত্রিত HTML Downloader-এ (একটি উপবৃত্তাকার চিহ্ন ’…’ নির্দেশ করে যে আরও এমন ডাউনলোডার রয়েছে) URL পাঠায়। প্রতিটি তীর চিহ্ন URL Frontier থেকে একটি পৃথক HTML Downloader-এ URL গুলোর প্রবাহ নির্দেশ করে, যা একটি সমান্তরাল প্রসেসিং বা লোড-ব্যালেন্সিং কৌশল নির্দেশ করে। ডায়াগ্রামটি একটি এক-থেকে-অনেক সম্পর্ক চিত্রিত করে যেখানে একটি একক উৎস টাস্ক (URL) গুলো একাধিক ওয়ার্কার নোডে (HTML Downloaders) প্রসেসিংয়ের জন্য বিতরণ করে। ছবির নিচে একটি নোট রয়েছে যা নির্দেশ করে যে ভিউয়ার সম্পূর্ণ SVG 1.1 সমর্থন করে না।] চিত্র ৯

২. ক্যাশ DNS Resolver (Cache DNS Resolver)

DNS Resolver ক্রলারগুলোর জন্য একটি বটলনেক কারণ অনেক DNS ইন্টারফেসের সিঙ্ক্রোনাস প্রকৃতির কারণে DNS রিকোয়েস্টগুলো সময় নিতে পারে। DNS রেসপন্স টাইম 10ms থেকে 200ms পর্যন্ত হয়ে থাকে। একবার একটি ক্রলার থ্রেড দ্বারা DNS-এ একটি রিকোয়েস্ট সম্পাদিত হলে, প্রথম রিকোয়েস্টটি সম্পূর্ণ না হওয়া পর্যন্ত অন্যান্য থ্রেডগুলো ব্লক হয়ে যায়। ঘন ঘন DNS কল করা এড়াতে আমাদের DNS ক্যাশ বজায় রাখা গতি অপ্টিমাইজেশনের জন্য একটি কার্যকর কৌশল। আমাদের DNS ক্যাশ ডোমেইন নেম থেকে IP অ্যাড্রেস ম্যাপিং রাখে এবং cron jobs দ্বারা পর্যায়ক্রমে আপডেট করা হয়।

৩. লোকালিটি (Locality)

ক্রল সার্ভারগুলো ভৌগলিকভাবে বিতরণ করুন। যখন ক্রল সার্ভারগুলো ওয়েবসাইট হোস্টগুলোর কাছে থাকে, তখন ক্রলারগুলো দ্রুত ডাউনলোড টাইম অনুভব করে। ডিজাইন লোকালিটি বেশিরভাগ সিস্টেম উপাদানের ক্ষেত্রে প্রযোজ্য: ক্রল সার্ভার, ক্যাশ, কিউ, স্টোরেজ ইত্যাদি।

৪. শর্ট টাইমআউট (Short timeout)

কিছু ওয়েব সার্ভার ধীরগতিতে রেসপন্স করে বা একদমই রেসপন্স নাও করতে পারে। দীর্ঘ অপেক্ষার সময় এড়াতে, একটি সর্বোচ্চ অপেক্ষার সময় নির্দিষ্ট করা হয়। যদি একটি হোস্ট পূর্বনির্ধারিত সময়ের মধ্যে রেসপন্স না করে, তবে ক্রলারটি জব বন্ধ করবে এবং অন্য কিছু পেজ ক্রল করবে।

রোবাস্টনেস (Robustness)

পারফরম্যান্স অপ্টিমাইজেশনের পাশাপাশি, রোবাস্টনেসও একটি গুরুত্বপূর্ণ বিবেচ্য বিষয়। আমরা সিস্টেমের রোবাস্টনেস উন্নত করার জন্য কয়েকটি পদ্ধতি উপস্থাপন করি:

• কনসিস্টেন্ট হ্যাশিং (Consistent hashing): এটি ডাউনলোডারগুলোর মধ্যে লোড বিতরণ করতে সাহায্য করে। কনসিস্টেন্ট হ্যাশিং ব্যবহার করে একটি নতুন ডাউনলোডার সার্ভার যোগ বা সরানো যেতে পারে। আরও বিস্তারিত জানতে “Design consistent hashing” অধ্যায়টি দেখুন।
• ক্রল স্টেট এবং ডেটা সংরক্ষণ করা: ব্যর্থতা থেকে রক্ষা পেতে, ক্রল স্টেট এবং ডেটা একটি স্টোরেজ সিস্টেমে লেখা হয়। সংরক্ষিত স্টেট এবং ডেটা লোড করে একটি বিঘ্নিত ক্রল সহজেই পুনরায় শুরু করা যেতে পারে।
• এক্সেপশন হ্যান্ডলিং (Exception handling): বড় স্কেলের সিস্টেমে এরর অনিবার্য এবং সাধারণ। ক্রলারকে অবশ্যই সিস্টেম ক্র্যাশ না করে মার্জিতভাবে (gracefully) এক্সেপশন হ্যান্ডেল করতে হবে।
• ডেটা ভ্যালিডেশন (Data validation): সিস্টেম এরর প্রতিরোধ করার জন্য এটি একটি গুরুত্বপূর্ণ ব্যবস্থা।

এক্সটেনসিবিলিটি (Extensibility)

প্রায় প্রতিটি সিস্টেমের বিবর্তনের সাথে সাথে, একটি ডিজাইনের লক্ষ্য হলো সিস্টেমটিকে নতুন কন্টেন্ট টাইপ সমর্থন করার জন্য যথেষ্ট নমনীয় করা। নতুন মডিউল প্লাগ-ইন করে ক্রলারটি প্রসারিত করা যেতে পারে। চিত্র ১০ দেখায় কীভাবে নতুন মডিউল যোগ করতে হয়।

[চিত্র ১০-এর বর্ণনা: ছবিটি একটি ওয়েব ক্রলার সিস্টেম আর্কিটেকচার উপস্থাপন করে। প্রক্রিয়াটি ‘seed URLs’ দিয়ে শুরু হয়, যা একটি ‘URL Frontier’-এ ফিড করা হয়। ‘URL Frontier’ URL গুলো একটি ‘HTML Downloader’-এ পাঠায়, যা তারপর HTML কন্টেন্ট ডাউনলোড করার আগে IP অ্যাড্রেস পেতে একটি ‘DNS Resolver’ ব্যবহার করে। ডাউনলোড করা HTML তারপর একটি ‘Content Parser’ দ্বারা প্রসেস করা হয়, যা পার্স করা ডেটা ‘Content St..’ (সম্ভবত একটি কন্টেন্ট স্টোরেজ ডাটাবেস) এর বিরুদ্ধে চেক করার জন্য একটি ‘Content Seen?’ মডিউলে পাঠায়। যদি কন্টেন্টটি নতুন হয়, তবে এটি একটি ‘Extension Module’-এ পাঠানো হয়, যাতে ‘PNG…’ (বিভিন্ন ফাইল টাইপ নির্দেশ করে), একটি ‘Link Extractor’ (নতুন URL খুঁজে বের করার জন্য), এবং একটি ‘Web Monitor’ (ওয়েবসাইটের পরিবর্তন মনিটর করার জন্য) এর মতো উপাদান রয়েছে। ‘Link Extractor’-এর আউটপুট একটি ‘URL Filter’ দ্বারা ফিল্টার করা হয় এবং একটি ‘URL Seen?’ মডিউলের বিরুদ্ধে চেক করা হয়, যা URL টি আগে প্রসেস করা হয়েছে কিনা তা নির্ধারণ করতে একটি ‘URL Storag..’ (সম্ভবত একটি URL স্টোরেজ ডাটাবেস) এর সাথে পরামর্শ করে। পুরো সিস্টেমটি একটি বদ্ধ লুপ গঠন করে, ‘Link Extractor’ দ্বারা চিহ্নিত নতুন URL গুলো আরও প্রসেসিংয়ের জন্য ‘URL Frontier’-এ ফিরে ফিড করা হয়।] চিত্র ১০

• PNG ফাইল ডাউনলোড করতে PNG Downloader মডিউল প্লাগ-ইন করা হয়েছে।
• ওয়েব মনিটর করতে এবং কপিরাইট এবং ট্রেডমার্ক লঙ্ঘন প্রতিরোধ করতে Web Monitor মডিউল যোগ করা হয়েছে।

সমস্যাজনক কন্টেন্ট সনাক্ত করা এবং এড়ানো

এই বিভাগটি অপ্রয়োজনীয়, অর্থহীন বা ক্ষতিকারক কন্টেন্ট সনাক্তকরণ এবং প্রতিরোধ নিয়ে আলোচনা করে।

১. অপ্রয়োজনীয় কন্টেন্ট (Redundant content)

আগে আলোচনা করা হয়েছে, প্রায় ৩০% ওয়েব পেজ হলো ডুপ্লিকেট। হ্যাশ (Hashes) বা চেকসাম (checksums) ডুপ্লিকেশন সনাক্ত করতে সাহায্য করে [11]।

২. স্পাইডার ট্র্যাপ (Spider traps)

একটি স্পাইডার ট্র্যাপ হলো একটি ওয়েব পেজ যা একটি ক্রলারকে ইনফিনিট লুপে ফেলে। উদাহরণস্বরূপ, একটি অসীম গভীর ডিরেক্টরি স্ট্রাকচার নিচে তালিকাভুক্ত করা হলো: http://www.spidertrapexample.com/foo/bar/foo/bar/foo/bar/...

URL গুলোর জন্য একটি সর্বোচ্চ দৈর্ঘ্য নির্ধারণ করে এমন স্পাইডার ট্র্যাপ এড়ানো যেতে পারে। তবে, স্পাইডার ট্র্যাপ সনাক্ত করার জন্য কোনো সর্বজনীন সমাধান নেই। স্পাইডার ট্র্যাপ ধারণকারী ওয়েবসাইটগুলো সনাক্ত করা সহজ কারণ এমন ওয়েবসাইটগুলোতে অস্বাভাবিকভাবে অনেক বেশি ওয়েব পেজ আবিষ্কৃত হয়। স্পাইডার ট্র্যাপ এড়াতে স্বয়ংক্রিয় অ্যালগরিদম তৈরি করা কঠিন; তবে, একজন ব্যবহারকারী ম্যানুয়ালি একটি স্পাইডার ট্র্যাপ যাচাই এবং সনাক্ত করতে পারেন, এবং হয় ক্রলার থেকে সেই ওয়েবসাইটগুলো বাদ দিতে পারেন অথবা কিছু কাস্টমাইজড URL ফিল্টার প্রয়োগ করতে পারেন।

৩. ডেটা নয়েজ (Data noise)

কিছু কন্টেন্টের খুব কম বা কোনো মূল্য নেই, যেমন বিজ্ঞাপন, কোড স্নিপেট, স্প্যাম URL ইত্যাদি। সেই কন্টেন্টগুলো ক্রলারগুলোর জন্য উপযোগী নয় এবং সম্ভব হলে সেগুলো বাদ দেওয়া উচিত।