Database & Storage (ডিপ ডাইভ)
সিস্টেম ডিজাইনে ডেটা কীভাবে স্টোর, রিট্রিভ এবং ম্যানেজ করা হয় তা অত্যন্ত গুরুত্বপূর্ণ। নিচে ডেটাবেসের কোর এবং অ্যাডভান্সড বিষয়গুলো নিয়ে আলোচনা করা হলো।
১. ACID ট্রানজ্যাকশন (ACID Transactions)
ডেটাবেসের প্রতিটি ট্রানজ্যাকশন ৪টি শর্ত পূরণ করতে হয়:
- Atomicity: ট্রানজ্যাকশনটি হয় পুরোপুরি সফল হবে অথবা কিছুই হবে না (All or Nothing)।
- Consistency: ট্রানজ্যাকশনের আগে ও পরে ডেটাবেস ভ্যালিড স্টেটে থাকবে।
- Isolation: একটি ট্রানজ্যাকশন অন্যটিকে প্রভাবিত করবে না।
- Durability: একবার ট্রানজ্যাকশন সফল হলে তা পাওয়ার কাট হলেও মুছবে না।
২. SQL বনাম NoSQL (SQL vs NoSQL)
| ফিচার | SQL (Relational) | NoSQL (Non-relational) |
|---|---|---|
| Schema | Fixed Schema | Flexible Schema |
| Scaling | Vertical | Horizontal |
| Joints | Complex JOINs supported | Joins are difficult (Denormalization preferred) |
| উদা: | PostgreSQL, MySQL | MongoDB, Cassandra |
৩. অ্যাডভান্সড ডেটা স্ট্রাকচারস এবং ফিল্টারস
ক. ব্লুম ফিল্টারস (Bloom Filters)
থিওরি: এটি একটি প্রবাবিলিস্টিক (Probabilistic) ডেটা স্ট্রাকচার যা দিয়ে দ্রুত চেক করা যায় কোনো এলিমেন্ট সেটে আছে কি না।
- এটি false positive দিতে পারে (বলতে পারে আছে কিন্তু নেই), কিন্তু false negative দেয় না (বললে নেই মানে ১০০% নেই)।
- ব্যবহর: ক্যাশ পেনিট্রেশন (Cache penetration) কমাতে এবং ডাটাবেস কুয়েরি অপ্টিমাইজ করতে।
খ. কুয়াড ট্রি (Quad Tree)
থিওরি: এটি জিও-লোকেশন (Location based) ডেটা ট্র্যাক করার জন্য ব্যবহৃত হয়। একটি এরিয়াকে ৪টি ভাগে ভাগ করে সার্চ করা হয়।
- ব্যবহর: Uber বা Google Maps এ কাছাকাছি রাইডার বা রেস্টুরেন্ট খুঁজতে।
গ. চেঞ্জ ডেটা ক্যাপচার (CDC)
থিওরি: ডাটাবেসে কোনো পরিবর্তন (Insert/Update/Delete) হলে তা সাথে সাথে অন্য সিস্টেমে (উদা: Search index বা Analytics DB) পাঠিয়ে দেওয়া।
৪. রেডিস (Redis) এবং এর ব্যবহার
রেডিস মূলত একটি ইন-মেমরি কি-ভ্যালু স্টোর।
- Caching: ডাটাবেসের লোড কমানোর জন্য।
- Rate Limiting: আইপি বা ইউজার ভিত্তিক রিকোয়েস্ট লিমিট করা।
- Leaderboard: গেমের রিয়েল-টাইম স্কোর ট্র্যাক করা।
- Pub/Sub: রিয়েল-টাইম নোটিফিকেশন সিস্টেম।
৫. PostgreSQL ইন্টারনাল আর্কিটেকচার
PostgreSQL একটি শক্তিশালী প্রসেস-বেসড (Process-based) ডাটাবেস।
- Shared Buffer: মেমরিতে ডেটা ক্যাশ করে রাখার জন্য।
- WAL (Write Ahead Log): যেকোনো পরিবর্তনের আগে এটি লগে লিখে রাখা হয় (Durability নিশ্চিত করতে)।
- MVCC (Multi-Version Concurrency Control): একই সময়ে রিড এবং রাইট লক ছাড়াই করার জন্য।
৬. কুয়েরি অপ্টিমাইজেশন (Query Optimization)
- Indexing: সঠিক কলামে ইনডেক্স ব্যবহার করা।
- Explain Plan: কুয়েরি কীভাবে রান হচ্ছে তা অ্যানালাইজ করা।
- Avoid SELECT *: শুধুমাত্র প্রয়োজনীয় কলাম সিলেক্ট করা।
- Denormalization: রিড পারফরম্যান্স বাড়াতে জয়েন কমিয়ে আলাদা টেবিল রাখা।
৭. সাধারণ ইন্টারভিউ প্রশ্নোত্তর (General Q&A)
প্রশ্ন ১: অবজেক্ট স্টোরেজ (Object Storage) এবং ব্লক স্টোরেজ (Block Storage) এর মধ্যে পার্থক্য কী?উত্তর: ব্লক স্টোরেজ (উদা: SSD/HDD) ডেটাকে ছোট ছোট ব্লকে ভাগ করে স্টোর করে, যা ডাটাবেসের জন্য ভালো। আর অবজেক্ট স্টোরেজ (উদা: AWS S3) ডেটাকে একটি অবজেক্ট হিসেবে মেটাডেটাসহ স্টোর করে, যা আনস্ট্রাকচারড ডেটা (ইমেজ, ভিডিও) স্টোর করার জন্য সেরা।
প্রশ্ন ২: ডাটাবেসে 'Page' বলতে কী বোঝায়?উত্তর: ডাটাবেস যখন ডিস্ক থেকে ডেটা রিড করে, তখন সে একটি নির্দিষ্ট সাইজের ডেটা ব্লক রিড করে যাকে 'Page' বলা হয় (সাধারণত 8KB বা 16KB)। ডাটাবেস মেমরিতে এই পেজগুলোই ম্যানেজ করা হয়।
প্রশ্ন ৩: ডাটাবেস কীভাবে 'Isolation' লেভেল বজায় রাখে?উত্তর: এটি মূলত Locking এবং MVCC (Multi-Version Concurrency Control) এর মাধ্যমে করা হয়। PostgreSQL এবং MySQL (InnoDB) মূলত MVCC ব্যবহার করে যা রাইটারদের রিডারদের ব্লক করতে দেয় না।
প্রশ্ন ৪: লিনিয়ারাইজেবিলিটি (Linearizability) কী?উত্তর: এটি ডিস্ট্রিবিউটেড সিস্টেমের একটি স্ট্রং কনসিস্টেন্সি মডেল। যদি কোনো ডেটা আপডেট হয়, তবে পরবর্তী সকল রিড রিকোয়েস্ট অবশ্যই আপডেট ভ্যালুটি ফেরত দেবে।
৮. উন্নত সিনারিও ভিত্তিক প্রশ্ন (Advanced Scenario Questions)
সিনারিও ১: "আপনি একটি ডিজিটাল ওয়ালেট বানাচ্ছেন। দুইজন ইউজার একই সাথে একই অ্যাকাউন্টে টাকা পাঠালে রেস কন্ডিশন কীভাবে আটকাবেন?"
সমাধান: ১. এটি হ্যান্ডেল করার জন্য ACID ট্রানজ্যাকশন এবং Pessimistic Locking (SELECT FOR UPDATE) ব্যবহার করব। ২. ট্রানজ্যাকশন শুরু করে অ্যাকাউন্টটি লক করব, ব্যালেন্স আপডেট করব এবং তারপর ট্রানজ্যাকশন কমিট (Commit) করে লক রিলিজ করব। এতে ডেটা ইনকনসিস্টেন্সি হবে না।
সিনারিও ২: "আপনার ডাটাবেসে রাইট রিকোয়েস্ট অনেক বেশি, কিন্তু রিড কম। এখানে আপনি LSM না কি B-Tree ব্যবহার করবেন?"
সমাধান: এখানে আমি LSM-Tree (Log-Structured Merge-tree) ব্যবহার করব। কারণ LSM-Tree রাইট রিকোয়েস্টগুলোকে মেমরিতে বাফারিং করে এবং পরে ক্রমে ডিস্কে রাইট করে, যা রাইট পারফরম্যান্স অনেক বাড়িয়ে দেয় (উদা: Cassandra)।
সিনারিও ৩: "একটি বড় ই-কমার্স সাইটে প্রোডাক্টের দাম আপডেট হলে তা সার্চ ইঞ্জিনে অ্যাপ্লাই করতে দেরি হচ্ছে। আপনি কীভাবে এটি রিয়েল-টাইম করবেন?"
সমাধান: এখানে CDC (Change Data Capture) ব্যবহার করা সেরা সমাধান। ডাটাবেসের ট্রানজ্যাকশন লগ ট্র্যাক করে প্রতিবার দাম পরিবর্তন হলে তা একটি মেসেজ কিউতে (Kafka) পাঠিয়ে দেব, যা সাথে সাথে সার্চ ইঞ্জিন (Elasticsearch) আপডেট করবে।
সিনারিও ৪: "ইমেজ বা ভিডিওর মতো বড় ফাইল কি ডাটাবেসের BLOB কলামে রাখা উচিত?"
সমাধান: না, এটি রিকমেন্ডেড নয়। এতে ডাটাবেসের সাইজ অনেক বেড়ে যায় এবং পারফরম্যান্স স্লো হয়। সেরা উপায় হলো ফাইলটি কোনো Object Storage (AWS S3) এ রাখা এবং ডাটাবেসে শুধুমাত্র তার URL বা ফাইল পাথ স্টোর করা।
TIP
ডিস্ট্রিবিউটেড ডাটাবেসের ক্ষেত্রে LSM (Log-Structured Merge-tree) এবং B-Tree এর পার্থক্য বোঝা খুবই জরুরি। LSM রাইট মেক্সিমাইজড সিস্টেমের (উদা: Cassandra) জন্য ভালো এবং B-Tree রিড ইন্টারসেভ সিস্টেমের (উদা: PostgreSQL) জন্য ভালো।