“NoSQL মানে SQL নেই”—ভুল ধারণা। বরং বলা হয় Not only SQL: স্কিমা কম rigid, স্কেল আর কিছু অ্যাক্সেস প্যাটার্নে RDBMS-এর চেয়ে প্রাকৃতিক।
কেন হঠাৎ গুরুত্ব পেল?
Facebook, Google, Amazon ধরণের সিস্টেমে দরকার ছিল: বিশ্বজুড়ে ডাটা, স্কেল আউট, পারফরম্যান্স—কোটি কোটি ইউজারের নিচে মন্থরতা নয়। RDBMS সব জায়গায় খারাপ নয়; কিন্তু কিছু workload-এ NoSQL কম ঝামেলায় ফিট করে।
কী? (ডকুমেন্ট মডেল)
অনেক NoSQL সিস্টেম ডাটাকে ডকুমেন্ট হিসেবে রাখে—JSON/XML-সদৃশ, টেবিল-কলামে ভাঙার চাপ কম। আধুনিক API বেশি JSON—একটা রেসপন্স যেমন আছে, সেভাবেই স্টোর করলে অ্যাপ আর DB-র মধ্যে ম্যাপিং সহজ।
নিচে সাধারণ একটা JSON:
{
"firstName": "Frank",
"lastName": "Weigel",
"age": 25,
"address": {
"streetAddress": "21 2nd Street",
"city": "MV",
"state": "CA",
"postalCode": "94040"
},
"phoneNumber": [
{
"type": "home",
"number": "212 555-1234"
},
{
"type": "fax",
"number": "646 555-4567"
}
]
}
এটা RDBMS-এ নরমালাইজ করতে একাধিক টেবিল, ফরেন কি, অনেক সময় pivot—অনেক JOIN। NoSQL ডকুমেন্ট স্টোরে এক ডকুমেন্টেই পুরো বস্তুটা রাখা যায়; প্রয়োজনে পুরোটা read, নির্দিষ্ট ফিল্ড আপডেট—প্রোডাক্ট অনুযায়ী ভিন্ন।

ট্র্যাডিশনাল RDBMS ডিজাইনে একই ডাটা ছড়িয়ে থাকে।
জটিল রিয়েল-ওয়ার্ল্ড ডাটা
নিচেরটা FHIR-স্টাইল রোগী রেকর্ডের অংশ (স্ট্রাকচার ফিক্সড, কিন্তু নেস্টিং গভীর):
{
"resourceType": "Patient",
"gender": "male",
"birthDate": "1942-01-14",
"id": "3abaceca-6fdd-4735-bff3-6b4830c0dab4",
"identifier": [
{
"type": {
"coding": [
{
"system": "http://hl7.org/fhir/identifier-type",
"code": "SB"
}
]
},
"system": "http://hl7.org/fhir/sid/us-ssn",
"value": "999383955"
},
{
"type": {
"coding": [
{
"system": "http://hl7.org/fhir/v2/0203",
"code": "DL"
}
]
},
"system": "urn:oid:2.16.840.1.113883.4.3.25",
"value": "S99944313"
},
{
"type": {
"coding": [
{
"system": "http://hl7.org/fhir/v2/0203",
"code": "MR"
}
]
},
"system": "http://hospital.smarthealthit.org",
"value": "89e67b18-d167-4eec-bcc4-f2249ee21c95"
}
],
"name": [
{
"use": "official",
"family": "Bauch453",
"given": ["Stanley527"],
"prefix": ["Mr."]
}
],
"telecom": [
{
"system": "phone",
"value": "(168) 007-5982",
"use": "home"
}
],
"address": [
{
"extension": [
{
"extension": [
{
"url": "latitude",
"valueDecimal": 42.59437957318591
},
{
"url": "longitude",
"valueDecimal": -72.09361425668885
}
],
"url": "http://hl7.org/fhir/StructureDefinition/geolocation"
}
],
"line": ["75918 Mann Landing", "Suite 587"],
"city": "Templeton",
"state": "MA",
"postalCode": "01468",
"country": "US"
}
],
"maritalStatus": {
"coding": [
{
"system": "http://hl7.org/fhir/v3/MaritalStatus",
"code": "M"
}
],
"text": "M"
},
"multipleBirthBoolean": false,
"communication": [
{
"language": {
"coding": [
{
"system": "http://hl7.org/fhir/ValueSet/languages",
"code": "en-US",
"display": "English (United States)"
}
]
}
}
],
"generalPractitioner": [
{
"reference": "urn:uuid:dbf5b6ef-6951-449b-be3a-0f0abccad36c"
}
]
}
এটাকে টেবিলে ভেঙে নিতে গেলে টেবিলের সংখ্যা দ্রুত বাড়ে; প্রোডাক্ট যদি ডকুমেন্ট হিসেবেই read/write করে থাকে, NoSQL প্রায়ই কম boilerplate।
কখন NoSQL, কখন RDBMS?
ডাটাই বলে দেয় বেশি।
- স্প্রেডশিট-মতো সারি-কলাম, ট্রানজাকশন একাধিক টেবিল জুড়ে tight—RDBMS এখনও শক্তিশালী ডিফল্ট।
- ডাটা গভীর নেস্টেড, স্কিমা পরিবর্তনশীল, আর workload-এর বেশিরভাগ read—ফ্রন্টে দেখাতে বারবার মাল্টি-টেবিল JOIN লাগে—সেখানে ডকুমেন্ট আকারে স্টোর ভাবা যায়।
আরেকটা সংকেত: read অনুপাত বেশি, একই লজিক্যাল অবজেক্ট বার বার জOIN করে আনতে হচ্ছে—সেখানে JSON-ish স্টোর কখনও কখনও সরল।
শেষ কথা
NoSQL = RDBMS-কে replace করতে আসে না; সঠিক আকারে সঠিক টুল। ট্রানজাকশন, রিপোর্টিং, কমপ্লায়েন্স—এখানে Postgres/MySQL এখনও অনেক দলের spine। আমি নিজে নতুন ফিচারে আগে access pattern বুঝি, তারপর বাছি—ট্রেন্ডের আগে।
