Databases — কোনটা কখন
- ●Database হলো সংগঠিতভাবে ডেটা জমা, খোঁজা ও ব্যবস্থাপনার একটা সিস্টেম — শুধু একটা ফাইলে লেখা নয়।
- ●একটাই 'সেরা' database নেই; relational, key-value, document, graph, wide-column, in-memory, time-series, spatial — প্রতিটার আলাদা শক্তি আছে।
- ●ডেটার গঠন আর access pattern দেখে database বাছতে হয়, ট্রেন্ড দেখে নয়।
সমস্যাটা কী?
ধরো তুমি একটা নতুন অ্যাপ বানাচ্ছ। ডেটা তো কোথাও রাখতে হবে — user-এর নাম, order, ছবি, লাইক। প্রথমে মনে হতে পারে, "একটা ফাইলে লিখে রাখলেই হয়।" কিন্তু লক্ষ user হলে? একসাথে হাজারজন একই ডেটা বদলালে? একটা নির্দিষ্ট order খুঁজতে পুরো ফাইল পড়তে হবে?
এখানেই database-এর দরকার। কিন্তু গুগল করলে দেখবে ডজনখানেক রকমের database আছে — SQL, NoSQL, Redis, MongoDB, Cassandra, Neo4j। নতুনদের মাথা ঘুরে যায়: "কোনটা বাছব?" সত্যি হলো — কোনো একটা "সেরা" database নেই। প্রতিটা একটা নির্দিষ্ট সমস্যার জন্য বানানো। চলো সেই ম্যাপটা বুঝি।
মূল ধারণা
Database হলো এমন একটা সিস্টেম যা ডেটাকে সংগঠিতভাবে জমা রাখে, যাতে দ্রুত খোঁজা, যোগ করা, বদলানো ও মোছা যায় — একইসাথে অনেক user নিরাপদে ব্যবহার করতে পারে।
মূল কথা হলো structure (ডেটা কীভাবে সাজানো) আর access pattern (তুমি কীভাবে ডেটা পড়বে-লিখবে)। এই দুটো ঠিক করে দেয় কোন ধরনের database তোমার জন্য ঠিক।
বড় ভাগ দুটো: SQL (relational) আর NoSQL (relational নয় এমন সব ধরন)। কিন্তু NoSQL নিজেই অনেক রকম, তাই চলো প্রতিটা আলাদা করে দেখি।
কীভাবে কাজ করে
প্রতিটা database একই মূল কাজ করে — store, index, query — কিন্তু ডেটাকে আলাদাভাবে সংগঠিত করে বলে আলাদা কাজে দক্ষ। নিচের তুলনার টেবিলটা পুরো ছবিটা এক নজরে দেখায়:
| ধরন | ডেটা যেভাবে রাখে | উদাহরণ | সবচেয়ে ভালো যেখানে |
|---|---|---|---|
| Relational / SQL | সারি-কলামের টেবিল | PostgreSQL, MySQL | লেনদেন, সম্পর্কিত ডেটা, join |
| Key-Value | চাবি → মান | Redis, DynamoDB | দ্রুত lookup, cache, session |
| Document | JSON-এর মতো ডকুমেন্ট | MongoDB, Couchbase | নমনীয় schema, content |
| Graph | node + edge (সম্পর্ক) | Neo4j, Neptune | নেটওয়ার্ক, সুপারিশ |
| Wide-Column | কলাম-family, বিশাল scale | Cassandra, HBase | বিপুল write, time-series লগ |
| In-Memory | RAM-এ সব | Redis, Memcached | super-fast cache, leaderboard |
| Time-Series | সময়-চিহ্নিত ডেটা | InfluxDB, TimescaleDB | metric, IoT sensor |
| Spatial | অবস্থান/জ্যামিতি | PostGIS | ম্যাপ, কাছের দোকান খোঁজা |
Schema: শক্ত নাকি নমনীয়?
Relational database-এ আগে থেকে কঠোর schema ঠিক করতে হয় (কোন কলাম, কী type)। Document/NoSQL-এ schema নমনীয় — পরে নতুন field যোগ করা সহজ। এই পার্থক্যটা বাছাইয়ে বড় ভূমিকা রাখে।
Database বাছাইটা যেন রান্নাঘরের পাত্র বাছাই। Relational = খোপ-কাটা টিফিন ক্যারিয়ার — সব গোছানো, নিয়ম মেনে। Key-Value = লকার নাম্বার দিয়ে জিনিস তোলা — চাবি জানলেই এক টানে পেয়ে যাও। Document = একটা শপিং ব্যাগ — যা খুশি একসাথে রাখো। Graph = বংশলতিকা/পারিবারিক গাছ — কে কার সাথে সম্পর্কিত তা দেখতে সেরা। ভাত রান্নায় কড়াই দিয়ে চলবে না; প্রতিটা কাজের আলাদা পাত্র আছে।
প্রকারভেদ
১. Relational / SQL
সারি ও কলামে ডেটা, টেবিলগুলো একে অপরের সাথে সম্পর্কিত। ACID transaction (নির্ভরযোগ্য লেনদেন) আর জটিল join-এ শক্তিশালী। ব্যবহার করো — ব্যাংকিং, e-commerce order, যেখানে সঠিকতা সবার আগে।
২. Key-Value
সবচেয়ে সরল মডেল: একটা চাবি (key) দাও, একটা মান (value) পাও। দ্রুততম। ব্যবহার করো — cache, user session, shopping cart, feature flag।
৩. Document
ডেটা JSON-এর মতো document-এ রাখা; প্রতিটা document নিজের ভেতরে সব তথ্য রাখে। নমনীয় schema। ব্যবহার করো — product catalog, ব্লগ/CMS, user profile।
৪. Graph
ডেটাকে node (জিনিস) আর edge (সম্পর্ক) হিসেবে রাখে। "friend-of-friend", "এই পণ্য যারা কিনেছে তারা আরও কী কিনেছে" — এমন সম্পর্কের query-তে অপরাজেয়। ব্যবহার করো — social network, recommendation, fraud detection।
৫. Wide-Column
টেবিলের মতো দেখালেও বিপুল scale-এর জন্য বানানো; প্রতি row-তে কোটি কলাম পর্যন্ত সম্ভব। বিশাল write-heavy কাজে দক্ষ। ব্যবহার করো — message log, event tracking, IoT।
৬. In-Memory
সব ডেটা RAM-এ, তাই microsecond-পর্যায়ের গতি (disk-এ গেলে অনেক ধীর)। ব্যবহার করো — cache, leaderboard, rate limiter, real-time counter।
৭. Time-Series
সময়-চিহ্নিত ডেটার (প্রতি সেকেন্ডে আসা metric) জন্য বিশেষভাবে অপ্টিমাইজড। ব্যবহার করো — server monitoring, স্টক price, sensor data।
৮. Spatial
অবস্থান ও জ্যামিতিক ডেটা সামলায়; "আমার ৫ কিমির মধ্যে কী আছে?" ধরনের query করে। ব্যবহার করো — ride-sharing, ম্যাপ, "কাছের রেস্টুরেন্ট"।
কখন ব্যবহার করবে / করবে না
শুরুতে সন্দেহ থাকলে একটা relational database (PostgreSQL) দিয়ে শুরু করাই বুদ্ধিমানের কাজ — এটা প্রায় সব কাজ মোটামুটি ভালো করে, এমনকি JSON ও spatial সমর্থনও দেয়। নির্দিষ্ট সমস্যা প্রকট হলে (যেমন cache দরকার → Redis, সম্পর্ক জটিল → Neo4j) তখন বিশেষায়িত database যোগ করো।
সবচেয়ে সাধারণ ভুল: hype দেখে database বাছা — "সবাই MongoDB ব্যবহার করছে, আমিও করব।" তোমার ডেটা যদি অত্যন্ত সম্পর্কযুক্ত আর transaction-নির্ভর হয়, document database-এ গিয়ে তুমি নিজেই হাতে join লিখতে গিয়ে কষ্ট পাবে। আগে নিজের ডেটা ও access pattern বোঝো, তারপর tool বাছো — উল্টোটা নয়।
বাস্তব উদাহরণ
Uber একটাই database-এ আটকে নেই — তারা polyglot persistence ব্যবহার করে। ড্রাইভার ও যাত্রীর অবস্থান-ভিত্তিক ম্যাচিং-এর জন্য spatial/geo index, real-time রাইড স্টেট ও দ্রুত lookup-এর জন্য Redis-এর মতো in-memory store, trip-এর নির্ভরযোগ্য রেকর্ডের জন্য relational/transactional database, আর বিপুল analytics ও লগের জন্য wide-column ও time-series সিস্টেম। প্রতিটা সমস্যার জন্য আলাদা, উপযুক্ত tool — এটাই বড় সিস্টেমের আসল প্যাটার্ন।
ইন্টারভিউতে database বাছার সময় শুধু নাম বলো না, কেন বলো: "এই ডেটা সম্পর্কযুক্ত আর consistency দরকার, তাই PostgreSQL; কিন্তু session-এর জন্য আলাদা Redis রাখব দ্রুততার জন্য।" Access pattern থেকে যুক্তি টানলে তুমি tool-জানা নয়, সমস্যা-বোঝা ইঞ্জিনিয়ার হিসেবে ধরা পড়বে।
মূল শব্দ (Key Terms)
মিনি কুইজ
1. একে অপরের সাথে গভীরভাবে সম্পর্কযুক্ত ডেটার (যেমন social network-এর friend connection) জন্য সবচেয়ে উপযুক্ত কোনটা?
2. অত্যন্ত দ্রুত cache বা session store-এর জন্য কোন ধরনের database আদর্শ?
3. Strong ACID transaction আর জটিল join দরকার হলে সাধারণত কোনটা বাছবে?