SQL বনাম NoSQL: database নির্বাচনের trade-off
SQL vs. NoSQL
এই পাঠের সূচিপত্র
এই পাঠে যা শিখবেন
- Data model ও access pattern থেকে store নির্বাচন
- Transactions, indexing ও operational trade-off
- Polyglot persistence-এর ownership
সমস্যা দিয়ে শুরু
Catalog-এর flexible attributes দেখে team পুরো order database document store-এ নিতে চায়। অন্য team relational database ছাড়া কিছু মানতে চায় না। Store category একা decision দেয় না। Payment invariant, product query, scale, transaction boundary ও team-এর operational অভিজ্ঞতা আলাদা workload-এ আলাদা requirement তৈরি করে।
সহজ করে বুঝি
SQL database সাধারণত relational model, declarative joins ও mature transactions দেয়। NoSQL একটি একক model নয়: key-value, document, wide-column ও graph-এর behavior ভিন্ন। অনেক non-relational store transactions দেয়, অনেক relational store JSON support করে। তাই “SQL scale করে না” বা “NoSQL schema নেই” misleading। Schema explicit DDL-তে নাকি application contract-এ, invariant এক key/document-এর নাকি বহু entity-এর, query pattern কতটা known—এসব প্রশ্ন করুন।
পরিচিত একটি উপমা
একটি দোকানে financial ledger, product attribute card এবং delivery route map আলাদা কাজ করে। সবকিছু একটি খাতায় রাখা সম্ভব হলেও কাজ সহজ নাও হতে পারে। আবার প্রতিটি ছোট তথ্যের জন্য আলাদা খাতা রাখলে মিলিয়ে দেখার খরচ বাড়ে। Tool নির্বাচন কাজের requirement দিয়ে করুন।
নকশাটি দেখুন
Diagram লোড হচ্ছে…
Diagram-এর text flow দেখুন
flowchart TD A[Laravel domain actions] --> O[(SQL orders and ledger)] A --> C[(Flexible product attributes)] O --> E[Committed catalog or order events] E --> S[(Search projection)] S --> R[Search API]
Order ও ledger authoritative transactional boundary-তে আছে। Flexible attributes SQL JSON-এও রাখা যায়; diagram আলাদা product হওয়া বাধ্যতামূলক বলে না। Search projection source থেকে update হয়, direct dual-write atomic ধরে নেওয়া যাবে না। Search result থেকে checkout গেলে current authoritative price/stock আবার যাচাই করতে হয়।
PHP ও Laravel-এ প্রয়োগ
Migration up fragment PostgreSQL/MySQL-এর relational table-এ bounded flexible attributes রাখে। Product attribute shape Form Request-এ allowlist/validate করুন; JSON field unrestricted user input dump নয়। Price integer minor units এবং currency rule আলাদা দরকার। JSON query/index support engine-specific।
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;
Schema::create('products', function (Blueprint $table) {
$table->id();
$table->string('sku')->unique();
$table->string('name');
$table->unsignedBigInteger('price_minor');
$table->char('currency', 3);
$table->json('attributes')->nullable();
$table->timestamps();
});সুবিধা, সীমাবদ্ধতা ও trade-off
এক relational store দিয়ে শুরু করলে backup, transaction ও operational workflow সহজ থাকে। Specialized store measured search/graph/write workload সমাধান করতে পারে। Polyglot persistence নতুন feature-এর পাশাপাশি data synchronization, credentials, backups ও incident surface বাড়ায়। Store add করার আগে access pattern relational index বা schema change দিয়ে মেটে কি না দেখুন। “Web scale” slogan concrete capacity estimate-এর বিকল্প নয়।
সাধারণ ভুল
- NoSQL মানেই কোনো schema/transaction নেই বলা।
- সব query later ভাবব বলে key design না করা।
- দুই database-এ পরপর write করে atomic commit দাবি করা।
আরও একটু গভীরে
Partition key workload distribution নির্ধারণ করে; relational sharding এবং NoSQL partitioning দুটোতেই skew হতে পারে। Consistency setting database product ও operation অনুযায়ী পড়ুন, category label থেকে নয়। Global secondary index update lag বা cross-partition query cost API latency বদলায়। Migration decision-এ export/import, cutover validation ও rollback plan রাখুন; শুধু নতুন SDK call লিখে storage move শেষ হয় না।
মনে রাখুন
Store category নয়, invariant ও access pattern decision চালাবে। একটি simple authoritative source থেকে শুরু করা যুক্তিসংগত। Specialized projections-এর lag ও recovery policy স্পষ্ট রাখুন।
নিজে চেষ্টা করুন
Orders, product catalog, session cache ও recommendation graph-এর জন্য query ও invariant তালিকা করুন। প্রতিটির store choice-এর বিরুদ্ধে সবচেয়ে শক্ত alternative লিখুন। Two-store write failure timeline দিয়ে reconciliation plan তৈরি করুন।
নিজের বোঝা যাচাই করুন
1. SQL-এ flexible data সম্ভব?
হ্যাঁ। অনেক engine JSON support করে। তবে shape validation, indexing ও query semantics engine অনুযায়ী বিচার করতে হবে।
2. NoSQL কি একটি database type?
এটি একাধিক non-relational model-এর umbrella term। Document ও graph store-এর query/consistency behavior এক নয়।
3. Transactions শুধু SQL-এ?
না। অনেক non-relational product transaction support করে, নির্দিষ্ট scope ও limit-সহ। Product documentation দিয়ে guarantee বিচার করুন।
4. Polyglot persistence কখন?
এক authoritative store-এর সীমা measured requirement মেটাতে না পারলে specialized store সাহায্য করতে পারে। Operational costও decision-এর অংশ।
5. Search projection authoritative?
সাধারণত source-এর derived view। Lag বা missed update থাকতে পারে; checkout correctness source database-এ যাচাই করুন।
আরও পড়ুন
এই পাঠের কুইজ
এই পাঠ থেকে ২টি প্রশ্ন। উত্তর দিয়ে ব্যাখ্যা দেখুন; অধ্যায়ের কুইজ আলাদাভাবে দিতে হবে।
এই পাঠের ২টি প্রশ্নের উত্তর দিন। পাস করতে দুটিই সঠিক হতে হবে।
জমা দেওয়ার পর সঠিক উত্তর ও ব্যাখ্যা দেখবেন। ফলাফল এই ব্রাউজারে সংরক্ষিত থাকবে। অনুশীলনের ফল অধ্যায় সম্পন্নের হিসাবে যোগ হয় না।
অগ্রগতি এই ব্রাউজারে সংরক্ষিত থাকে। শুধু পাঠ খুললে সম্পন্ন হয় না।