Performance Tradeoffs (পারফরম্যান্স ট্রেড-অফ)

সিস্টেম ডিজাইনে পারফরম্যান্স অপ্টিমাইজ করতে গেলে আমাদের প্রায়ই কিছু জিনিসের বিনিময়ে অন্য কিছু পেতে হয়। নিচে এমন তিনটি গুরুত্বপূর্ণ ট্রেড-অফ আলোচনা করা হলো।

1. Memory vs Latency (মেমোরি বনাম ল্যাটেন্সি)

আমরা মেমোরি (Space) খরচ করে ল্যাটেন্সি (Time) কমাতে পারি, অথবা ল্যাটেন্সি বাড়িয়ে মেমোরি বাঁচাতে পারি। একে Space-Time Tradeoff-ও বলা হয়।

ক. ল্যাটেন্সি কমানো (Use more Memory)

আমরা যদি বারবার ক্যালকুলেশন না করে রেজাল্ট সেভ করে রাখি (Caching), তবে রেসপন্স টাইম বা ল্যাটেন্সি অনেক কমে যায়। কিন্তু এর জন্য আমাদের অতিরিক্ত মেমোরি বা RAM খরচ করতে হয়।

• উদাহরণ: ডাটাবেস থেকে বারবার কুয়েরি না করে Redis বা Memcached-এ ডেটা রাখা।
• Tradeoff: Cost (RAM এর দাম বেশি) এবং ডেটা Stale হওয়ার ঝুঁকি।

খ. মেমোরি বাঁচানো (Accept more Latency)

আমরা যদি মেমোরি বাঁচাতে চাই, তবে ডেটা কম্প্রেস (Compression) করে রাখতে পারি।

• উদাহরণ: একটি ১জিবি ফাইলকে জিপ করে ১০০এমবি করা।
• Tradeoff: ফাইলটি পড়ার সময় আন-জিপ (Decompress) করতে হবে, যার জন্য CPU পাওয়ার লাগবে এবং সময় বেশি লাগবে (ল্যাটেন্সি বাড়বে)।

2. Throughput vs Latency (থ্রুপুট বনাম ল্যাটেন্সি)

Throughput: একক সময়ে সিস্টেম কতটা কাজ (Requests per second) করতে পারে। Latency: একটি নির্দিষ্ট কাজ শেষ করতে কতটা সময় লাগে।

মাঝে মাঝে থ্রুপুট বাড়ানোর জন্য ল্যাটেন্সিকে সেক্রিফাইস করতে হয়।

ব্যাচ প্রসেসিং (Batch Processing)

মনে করুন, আপনি একটি লগার সিস্টেম বানাচ্ছেন। প্রতিটি লগ আসার সাথে সাথে ডিস্কে রাইট করলে (Low Latency), ডিস্কের I/O অপারেশন অনেক বেড়ে যাবে এবং সিস্টেম স্লো হয়ে যাবে। এর বদলে, আপনি ১০০টি লগ আসা পর্যন্ত মেমোরিতে জমিয়ে রাখলেন, তারপর একসাথে একবার ডিস্কে রাইট করলেন।

• ফলাফল: সিস্টেমের থ্রুপুট অনেক বেড়ে গেল (কম I/O কল)।
• Tradeoff: ল্যাটেন্সি বাড়ল (প্রথম লগটিকে ১০০তম লগ আসা পর্যন্ত অপেক্ষা করতে হলো)।

প্যারালালিজম (Parallelism)

একই কাজ অনেকগুলো থ্রেডে ভাগ করে করলে থ্রুপুট বাড়ে, কিন্তু কনটেক্সট সুইচিং (Context Switching) বা নেটওয়ার্ক ওভারহেডের কারণে প্রতিটি রিকোয়েস্টের নিজস্ব ল্যাটেন্সি একটু বাড়তে পারে।

3. Accuracy vs Latency (নির্ভুলতা বনাম ল্যাটেন্সি)

কখনো কখনো আমাদের ১০০% নির্ভুল উত্তরের চেয়ে "দ্রুত উত্তর" বেশি জরুরি হয়।

Approximate Computing

বিগ ডেটা সিস্টেমে বিলিয়ন বিলিয়ন ডেটা কাউন্ট করা (যেমন: Unique Visitors Count) অনেক সময়সাপেক্ষ। আমরা যদি এক্সাক্ট কাউন্ট চাই, তবে পুরো ডেটাবেস স্ক্যান করতে হবে, যা অনেক ধীর। এর বদলে আমরা HyperLogLog বা Bloom Filters এর মতো অ্যালগরিদম ব্যবহার করতে পারি।

• সুবিধা: প্রায় ১ সেকেন্ডের মধ্যে উত্তর পাওয়া যায় (Low Latency)। মেমোরি খুব কম লাগে।
• Tradeoff: উত্তর ১০০% সঠিক নাও হতে পারে (১-২% এরর রেট থাকে)।

উদাহরণ: YouTube View Count

যখন একটি ভিডিও ভাইরাল হয়, ইউটিউব রিয়েল-টাইমে প্রতিটি ভিউ কাউন্ট আপডেট করে না। তারা একটি আনুমানিক সংখ্যা দেখায় এবং পরে ব্যাকগ্রাউন্ডে সঠিক সংখ্যা ক্যালকুলেট করে আপডেট করে ("301+ views" সমস্যা যা আগে দেখা যেত)।

• Takeaway: রিয়েল-টাইম এনালিটিক্সে অনেক সময় নির্ভুলতার চেয়ে স্পিড বেশি গুরুত্বপূর্ণ।