SQL vs NoSQL | PySD বাংলা

"MongoDB নাকি PostgreSQL?" নতুন project এর শুরুতে এই প্রশ্ন প্রায় সবসময় আসে, আর প্রায়ই ভুল কারণে উত্তর দেওয়া হয় ("NoSQL দ্রুত", "SQL পুরনো")। এই অধ্যায়ে দেখবো আসলে কোন ধরনের database কী সমস্যার জন্য বানানো, আর কীভাবে সিদ্ধান্ত নেবে।

#Relational (SQL) database

PostgreSQL, MySQL, SQL Server, Oracle, SQLite।

Data থাকে table এ, নির্দিষ্ট schema (column আর type) সহ
Table গুলোর মধ্যে সম্পর্ক (foreign key), JOIN দিয়ে মেলানো
ACID transaction: কয়েকটা বদল হয় একসাথে হবে, নয়তো একটাও না (Transaction অধ্যায়)
SQL: শক্তিশালী query ভাষা, যেকোনো প্রশ্ন পরে করা যায়

শক্তি: সঠিকতা, নমনীয় query, সম্পর্কিত data, পরিণত tool আর অভিজ্ঞ মানুষ। দুর্বলতা: অনেক machine এ ভাগ করা (horizontal write scaling) কঠিন; schema বদলানো পরিকল্পনা চায়।

#NoSQL: একটা না, কয়েক রকম

"NoSQL" মানে শুধু "SQL table না"। ভেতরে সম্পূর্ণ আলাদা কয়েকটা পরিবার:

প্রতিটা ধরন একটা নির্দিষ্ট ধরনের প্রশ্নের জন্য অত্যন্ত দক্ষ, বাকিগুলোয় দুর্বল।

ধরন	কীভাবে রাখে	কোন প্রশ্নে দারুণ	উদাহরণ ব্যবহার
Key-Value	key → value	"এই key এর value দাও", খুব দ্রুত	Cache, session, rate limit, counter
Document	JSON এর মতো document, নমনীয় গঠন	"এই id এর পুরো জিনিসটা দাও"	Product catalog (প্রতিটা category এর আলাদা field), CMS, mobile app এর backend
Wide-column	partition key দিয়ে ভাগ করা বিশাল table	"এই partition এর সর্বশেষ N টা", বিশাল write	Chat message, IoT sensor, activity log, time series
Graph	node আর edge	"বন্ধুর বন্ধু কারা", সম্পর্কের পথ	Social network, fraud detection, recommendation

আরও কয়েকটা বিশেষ ধরন: Search engine (Elasticsearch, OpenSearch: full-text search), Time-series (TimescaleDB, InfluxDB: metric), Vector database (pgvector, Qdrant: AI এর embedding, RAG অধ্যায়)।

#বড় পার্থক্যগুলো

	SQL	NoSQL (সাধারণভাবে)
Schema	আগে থেকে ঠিক করা	নমনীয় (কিন্তু app এর code এ schema থাকেই)
সম্পর্ক	JOIN, foreign key	সাধারণত নেই; data একসাথে রাখো (embed) বা app এ মেলাও
Query	যেকোনো প্রশ্ন, পরেও	আগে থেকে জানা প্রশ্নের জন্য design করতে হয়
Transaction	শক্তিশালী ACID	অনেকগুলোয় সীমিত (এখন অনেকে single-document বা সীমিত multi-document দেয়)
Scaling	Vertical সহজ, horizontal কঠিন	অনেকগুলো শুরু থেকেই horizontal এর জন্য বানানো
Consistency	Strong	প্রায়ই eventual (বদলানো যায়)

#"Query-first" design: NoSQL এর মূল চিন্তা

SQL এ আগে data সাজাও, পরে যেকোনো প্রশ্ন করো। Cassandra/DynamoDB এর মতো NoSQL এ উল্টো: আগে ঠিক করো কী কী প্রশ্ন করবে, তারপর প্রতিটা প্রশ্নের জন্য data সাজাও। একই data কয়েক রকমভাবে কয়েকবার রাখা স্বাভাবিক।

উদাহরণ chat app (Cassandra):

Text

প্রশ্ন: "এই chat এর সর্বশেষ ৫০টা message"
table messages_by_chat:  partition key = chat_id, sort = sent_at DESC

প্রশ্ন: "এই user এর সব chat, সর্বশেষটা আগে"
table chats_by_user:  partition key = user_id, sort = last_message_at DESC

পরে নতুন একটা প্রশ্ন ("এই শব্দ আছে এমন সব message") এলে নতুন table বা আলাদা search system লাগবে। SQL এ শুধু নতুন query লিখলেই হতো।

#"NoSQL দ্রুত" কথাটা কেন অর্ধসত্য

একটা key দিয়ে পড়া দুটোতেই দ্রুত। PostgreSQL এ primary key lookup ও ১ ms এর নিচে।
NoSQL এর আসল শক্তি বিশাল পরিমাণে horizontal scaling: প্রতি সেকেন্ডে লাখ লাখ write, শত শত TB data, অনেক machine এ ভাগ করা, একটা machine নষ্ট হলেও চলে।
বেশিরভাগ app সেই মাত্রায় কখনো পৌঁছায় না। একটা ভালো PostgreSQL machine প্রতি সেকেন্ডে কয়েক হাজার write আর কয়েক TB data আরামে সামলায়।

একটা পরিচিত গল্প

অনেক startup শুরুতে MongoDB নেয় কারণ "schema লাগে না, দ্রুত শুরু করা যায়"। এক বছর পর দেখে তাদের data আসলে খুব সম্পর্কিত (user, order, product, payment), আর তারা app এর code এ হাতে হাতে JOIN করছে, transaction এর অভাবে data অসঙ্গত হচ্ছে। শেষে PostgreSQL এ migrate করে। উল্টো গল্পও আছে: Discord এর মতো chat company বিশাল পরিমাণ message এর জন্য relational database থেকে Cassandra/ScyllaDB তে গেছে, কারণ তাদের প্রশ্ন সহজ কিন্তু data অসীম। দুই গল্পেরই শিক্ষা: data আর প্রশ্নের ধরন দেখে বাছাই করো, হুজুগে না।

#কীভাবে সিদ্ধান্ত নেবে

প্রশ্ন	যদি হ্যাঁ
Data এর মধ্যে অনেক সম্পর্ক, আর নানা রকম প্রশ্ন করতে হবে?	SQL
টাকা, stock, booking: একদম সঠিক হতে হবে, transaction লাগবে?	SQL
শুধু key দিয়ে দ্রুত পড়া-লেখা, অস্থায়ী data?	Key-value (Redis)
প্রতিটা জিনিসের গঠন খুব আলাদা আর পুরোটা একসাথে পড়া হয়?	Document
বিশাল write (লাখ/সেকেন্ড), সময় অনুযায়ী, সহজ প্রশ্ন?	Wide-column
সম্পর্কের পথ খোঁজা ("৩ ধাপ দূরের বন্ধু")?	Graph
লেখার ভেতরে শব্দ খোঁজা, typo সহ?	Search engine
নিশ্চিত না?	PostgreSQL দিয়ে শুরু করো

PostgreSQL কেন প্রায়ই ভালো শুরু: JSONB column দিয়ে document এর নমনীয়তা, pg_trgm আর full-text search দিয়ে মোটামুটি search, pgvector দিয়ে AI embedding, TimescaleDB দিয়ে time series। একটা database এ অনেক কাজ, চালানো সহজ। পরে কোনো একটা অংশ বড় হলে সেটা আলাদা বিশেষ database এ সরানো যায়।

#Polyglot persistence: একাধিক database একসাথে

বড় system এ সাধারণত একটা database না, কয়েকটা, প্রতিটা নিজের কাজে:

Source of truth থাকে PostgreSQL এ। বাকিগুলো সেখান থেকে নেওয়া copy, বিশেষ কাজের জন্য সাজানো।

সাবধানতা: প্রতিটা নতুন database মানে নতুন জিনিস শেখা, চালানো, backup, monitor করা। আর একাধিক database এ data মিলিয়ে রাখা (event, CDC দিয়ে) নিজেই একটা চ্যালেঞ্জ। তাই প্রয়োজন প্রমাণ হলে তবেই যোগ করো।

#অনুশীলন

#নিজেকে যাচাই করো

"NoSQL" কি একটা নির্দিষ্ট ধরনের database?

না। এটা কয়েকটা সম্পূর্ণ আলাদা পরিবারের সাধারণ নাম: key-value, document, wide-column, graph ইত্যাদি। প্রতিটা আলাদা সমস্যার জন্য।

Cassandra ধরনের database এ "query-first" design মানে কী?

আগে ঠিক করতে হয় কী কী প্রশ্ন করা হবে, তারপর প্রতিটা প্রশ্নের জন্য আলাদা করে data সাজাতে হয় (প্রায়ই একই data কয়েকবার)। পরে নতুন ধরনের প্রশ্ন করা কঠিন, যা SQL এ সহজ।

Bank এর balance এর জন্য কোন ধরনের database, কেন?

Relational (যেমন PostgreSQL), কারণ শক্তিশালী ACID transaction লাগে: টাকা এক জায়গা থেকে কাটা আর আরেক জায়গায় যোগ একসাথে হতে হবে, আর সবসময় সঠিক balance দেখাতে হবে।

নতুন project এ নিশ্চিত না হলে PostgreSQL দিয়ে শুরু করা কেন যুক্তিসঙ্গত?

এটা সম্পর্কিত data, transaction, নমনীয় query দেয়, আবার JSONB, full-text search, pgvector দিয়ে NoSQL এর অনেক কাজও করতে পারে। পরে কোনো অংশ খুব বড় হলে সেই অংশ বিশেষ database এ সরানো যায়।