Fahim Shariar Shoumik

Backend Engineer | Golang Specialist | Distributed Systems Architect

Dhaka, Bangladesh
Fahim Shariar Shoumik

About

Tech entrepreneur and backend specialist with 10+ years of experience building scalable systems using Golang, gRPC, and Docker-based microservices. Proven leadership in startups and developer platforms. Passionate about API-first design, plugin-based extensibility, and headless CMS architectures. Currently building Apito.io, an API development platform. Past projects include FHIR-compliant EHR systems, DevOps consulting, and open-source tooling.

Back to Blog

NoSQL ডাটাবেস | পর্ব ১

NoSQLDatabaseMongoDBBengali

“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 বুঝি, তারপর বাছি—ট্রেন্ডের আগে।