SQL vs NoSQL
- ●SQL (relational) database fixed schema-তে row/column-এ data রাখে, ACID আর শক্তিশালী join দেয়।
- ●NoSQL (non-relational) flexible schema-তে data রাখে, সহজে horizontal scale করে, প্রায়ই BASE/eventual consistency-ধর্মী।
- ●জটিল সম্পর্ক ও কঠোর সঠিকতায় SQL; বিপুল scale, নমনীয় বা পরিবর্তনশীল data-তে NoSQL।
সমস্যাটা কী?
তুমি নতুন একটা app বানাচ্ছ — ধরো একটা food delivery service। User, restaurant, menu, order, payment — সব data কোথাও রাখতে হবে। প্রথম বড় সিদ্ধান্ত: কোন ধরনের database?
বাজারে দুটো বড় ঘরানা:
- SQL / Relational database — যেমন MySQL, PostgreSQL। Data থাকে সাজানো table-এ (row ও column)।
- NoSQL / Non-relational database — যেমন MongoDB, Cassandra, Redis। Data রাখার ধরন অনেক নমনীয়।
ভুল বাছাই করলে পরে data সরানো খুব কষ্টের। তাই trade-off বোঝা জরুরি।
প্রথমটা: SQL (Relational Database)
Relational database data রাখে table-এ — ঠিক Excel-এর মতো row আর column। প্রতিটা table-এর একটা Schema থাকে — অর্থাৎ আগে থেকে নির্দিষ্ট গঠন: কোন কোন column থাকবে, প্রতিটার data type কী। প্রতিটা row সেই নিয়ম মানতে বাধ্য।
বিভিন্ন table পরস্পরের সাথে সম্পর্কযুক্ত (relation) — যেমন orders table-এ user_id দিয়ে users table-এর সাথে যোগ। একাধিক table থেকে একসাথে data টানতে ব্যবহার হয় JOIN।
SQL database-এর বড় শক্তি ACID — Atomicity, Consistency, Isolation, Durability। সহজ ভাষায়: একটা transaction হয় পুরোপুরি ঘটবে নয়তো একেবারেই ঘটবে না, আর data সবসময় সঠিক ও টেকসই থাকবে। টাকা লেনদেনে এটা অপরিহার্য।
সুবিধা:
- কঠোর গঠন → data পরিচ্ছন্ন ও সামঞ্জস্যপূর্ণ।
- শক্তিশালী JOIN → জটিল সম্পর্কযুক্ত query সহজ।
- ACID → transaction নির্ভরযোগ্য।
- পরিণত (mature), পরীক্ষিত, বিশাল community।
অসুবিধা:
- Schema পরিবর্তন করা ঝামেলার (বড় table-এ ধীর)।
- Horizontal scaling তুলনামূলক কঠিন — একাধিক server-এ ভাগ (sharding) জটিল।
দ্বিতীয়টা: NoSQL (Non-relational Database)
NoSQL মানে "Not Only SQL" — table-এর কঠোর গঠন বাধ্যতামূলক নয়। কোনো শক্ত fixed schema নেই; একই collection-এ এক document-এ যে field আছে আরেকটায় না-ও থাকতে পারে (flexible schema)।
বেশিরভাগ NoSQL শুরু থেকেই Sharding তথা horizontal scaling-এর জন্য তৈরি — data টুকরো করে অনেক server-এ ভাগ করে রাখা যায়, তাই বিপুল scale সামলানো সহজ। বিনিময়ে এরা প্রায়ই কঠোর ACID-এর বদলে BASE (Basically Available, Soft state, Eventual consistency) ধাঁচে চলে — অর্থাৎ data কিছুক্ষণ পুরোনো থাকতে পারে কিন্তু system দ্রুত ও সবসময় available।
NoSQL-এর কয়েকটা ধরন:
- Document (MongoDB) — JSON-এর মতো document রাখে; নমনীয় গঠন।
- Key-Value (Redis, DynamoDB) — সরল চাবি→মান; অত্যন্ত দ্রুত, cache/session-এ আদর্শ।
- Column-family (Cassandra) — বিপুল write ও বড় data-তে শক্তিশালী।
- Graph (Neo4j) — সম্পর্ক/network (যেমন "বন্ধুর বন্ধু") খোঁজায় চমৎকার।
সুবিধা: flexible schema, সহজ horizontal scaling, বিপুল data ও traffic-এ দ্রুত, দ্রুত development।
অসুবিধা: join দুর্বল বা নেই (অনেক সময় data নকল করে রাখতে হয়), কঠোর consistency কম, প্রতিটা ধরন নির্দিষ্ট কাজে ভালো — ভুল ধরন বাছলে কষ্ট।
SQL হলো একজন হিসাবরক্ষকের ছকে-বাঁধা লেজার খাতা — প্রতিটা পাতায় একই কলাম (তারিখ, খরচ, পরিমাণ), একটা ভুল হলে মেলানো যায়, সবকিছু পরস্পর সম্পর্কযুক্ত। কঠোর, কিন্তু নির্ভুল।
NoSQL হলো তোমার ব্যক্তিগত নোটবুক — এক পাতায় শুধু একটা ফোন নম্বর, পরের পাতায় একটা পুরো রেসিপি, আরেক পাতায় ছবি। যা খুশি, যেমন খুশি। দ্রুত, নমনীয় — কিন্তু সব পাতা মিলিয়ে নিখুঁত হিসাব বের করা কঠিন।
পাশাপাশি তুলনা
| বিষয় | SQL (Relational) | NoSQL (Non-relational) |
|---|---|---|
| Data মডেল | table (row/column) | document/key-value/column/graph |
| Schema | fixed, আগে থেকে নির্দিষ্ট | নমনীয়, পরিবর্তনযোগ্য |
| Consistency | ACID (কঠোর) | প্রায়ই BASE (eventual) |
| JOIN | শক্তিশালী | দুর্বল/নেই |
| Scaling | vertical-ঘেঁষা, sharding কঠিন | horizontal, sharding সহজ |
| উপযুক্ত | জটিল সম্পর্ক, transaction | বিপুল scale, নমনীয় data |
| উদাহরণ | MySQL, PostgreSQL | MongoDB, Cassandra, Redis |
কখন কোনটা বেছে নেবে
- SQL বেছে নাও যখন — data-র মধ্যে অনেক সম্পর্ক আছে, transaction-এ কঠোর সঠিকতা দরকার (টাকা, order, inventory), এবং গঠন মোটামুটি স্থির। সন্দেহ থাকলে SQL দিয়েই শুরু করা নিরাপদ।
- NoSQL বেছে নাও যখন — বিপুল scale (লাখো-কোটি record), data-র গঠন নমনীয়/বদলায়, খুব দ্রুত read/write দরকার, অথবা নির্দিষ্ট কাজ যেমন caching (key-value) বা network খোঁজা (graph)।
- বাস্তবে বড় system প্রায়ই দুটোই ব্যবহার করে (polyglot persistence) — order-এ SQL, session/cache-এ Redis, ইত্যাদি।
সবচেয়ে সাধারণ ভুল: "NoSQL মানেই দ্রুত ও আধুনিক, তাই সবকিছুতে NoSQL" — এই hype-এ গা ভাসানো। যদি তোমার data-তে অনেক সম্পর্ক ও transaction থাকে আর তুমি NoSQL নাও, পরে application-এর code-এ হাতে হাতে join ও consistency সামলাতে গিয়ে নাকানিচুবানি খাবে। ধরন দিয়ে নয়, তোমার data ও access pattern দিয়ে সিদ্ধান্ত নাও।
বাস্তব উদাহরণ
- ব্যাঙ্ক ও payment company core data-তে SQL (PostgreSQL/Oracle) ব্যবহার করে — ACID ছাড়া টাকার হিসাব রাখা অসম্ভব।
- Facebook শুরু করেছিল MySQL দিয়ে এবং এখনও বহু জায়গায় ব্যবহার করে, পাশাপাশি বিশাল scale-এর জন্য নানা NoSQL/cache স্তর যোগ করেছে।
- Netflix বিপুল, distributed data-র জন্য Cassandra (NoSQL) ব্যবহার করে — বহু region-এ অনেক write সামলাতে।
- প্রায় সব বড় site session ও caching-এ Redis (key-value NoSQL) ব্যবহার করে — অত্যন্ত দ্রুত বলে।
Interview-তে "SQL না NoSQL?" জিজ্ঞেস করলে কখনও সরাসরি একটা বোলো না। আগে পাল্টা প্রশ্ন করো: "Data-গুলোর মধ্যে কি জোরালো সম্পর্ক আছে? Transaction-এ কঠোর consistency কি লাগবে? কত বড় scale?" তারপর উত্তর দাও। এই access-pattern-ভিত্তিক চিন্তাটাই interviewer দেখতে চায়।
মূল শব্দ (Key Terms)
মিনি কুইজ
1. SQL database-এর schema সম্পর্কে কোনটি সত্য?
2. ACID-এর মূল উদ্দেশ্য কী?
3. বিপুল data সহজে অনেক server-এ ভাগ করে scale করার জন্য সাধারণত কোনটা সুবিধাজনক?