Distributed Database

 

ডিস্ট্রিবিউটেড ডাটাবেস (Distributed Database) হলো এমন একটি ডাটাবেস সিস্টেম যেখানে ডাটা এক জায়গায় না থেকে একাধিক ভিন্ন ভিন্ন লোকেশন বা সার্ভারে ছড়িয়ে থাকে, কিন্তু ব্যবহারকারী বা অ্যাপ্লিকেশনের কাছে এগুলোকে একটিই ডাটাবেস হিসেবে উপস্থাপন করা হয়।

অর্থাৎ, ডাটা ফিজিক্যালি বিভিন্ন সার্ভার বা ভৌগোলিক লোকেশনে থাকতে পারে, কিন্তু যখন কোয়েরি করা হয় তখন সেটি এমনভাবে কাজ করে যেন সব ডাটা এক জায়গাতেই আছে।

প্রধান বৈশিষ্ট্য:

1. ডাটা ডিস্ট্রিবিউশন – ডাটা বিভিন্ন লোকেশন/নোডে ছড়িয়ে থাকে।

2. ডাটা ট্রান্সপারেন্সি – ব্যবহারকারীরা বুঝতে পারে না কোন ডাটা কোন সার্ভারে আছে।

3. হরিজন্টাল ও ভার্টিকাল ফ্র্যাগমেন্টেশন – ডাটা ভাগ করে বিভিন্ন লোকেশনে রাখা যায়।

4. রিপ্লিকেশন – ডাটার কপি একাধিক নোডে রাখা যায় যাতে রিলায়েবিলিটি বাড়ে।

5. ফল্ট টলারেন্স – কোনো একটি সার্ভার ডাউন হলেও সিস্টেম পুরোপুরি বন্ধ হয়ে যায় না।

উদাহরণ:

1. গুগল স্প্যানার (Google Spanner)

2. অ্যামাজন ডায়নামোডিবি (Amazon DynamoDB)

3. কাসান্দ্রা (Apache Cassandra)

----------------------------------------------------------------------------------------------------------------------------

বিষয়	Centralized / Normal DB	Distributed DB
ডাটার অবস্থান	সব ডাটা একটি সার্ভার/লোকেশনে থাকে	ডাটা একাধিক লোকেশনে ছড়ানো থাকে
অ্যাক্সেস	সব ব্যবহারকারী এক জায়গার সার্ভারে কানেক্ট করে	ব্যবহারকারী যেকোনো লোকেশন থেকে কানেক্ট করতে পারে
পারফরম্যান্স	বেশি ব্যবহারকারী হলে সার্ভার লোড বেড়ে যায়	লোড বিভিন্ন সার্ভারে ভাগ হয়ে যায়, তাই পারফরম্যান্স ভালো
রিলায়েবিলিটি	সার্ভার ডাউন হলে পুরো সিস্টেম বন্ধ	কিছু সার্ভার ডাউন হলেও সিস্টেম কাজ চালাতে পারে
মেইনটেনেন্স	মেইনটেন করা তুলনামূলক সহজ	মেইনটেন করা জটিল কারণ অনেক নোড সমন্বয় করতে হয়
ডাটা কনসিসটেন্সি	কনসিসটেন্সি মেইনটেইন করা সহজ	রিপ্লিকেশন ও সিঙ্কের কারণে কনসিসটেন্সি রাখা কঠিন
সিকিউরিটি	এক জায়গায় সিকিউরিটি কন্ট্রোল করা হয়	অনেক জায়গায় সিকিউরিটি মেইনটেইন করতে হয়, তাই বেশি জটিল
কস্ট	হার্ডওয়্যার খরচ কম	একাধিক সার্ভার/লোকেশন লাগার কারণে খরচ বেশি

--------------------------------------------------------------------------------------------------------------------------

✅ সুবিধা (Advantages of Distributed Database)

1. Reliability & Availability : একটি সার্ভার ডাউন হলেও অন্য নোড থেকে ডাটা পাওয়া যায় . সিস্টেম সম্পূর্ণভাবে বন্ধ হয় না।

2. Performance & Scalability : লোড বিভিন্ন নোডে ভাগ হয়ে যায়, তাই বড় সংখ্যক ব্যবহারকারী হ্যান্ডেল করা সহজ হয়।নতুন সার্ভার যোগ করে সহজেই স্কেল আপ করা যায়।

3. Data Locality : ইউজারের কাছে কাছাকাছি ডাটাবেস সার্ভার থেকে ডাটা ফেচ হয়, ফলে অ্যাক্সেস টাইম কমে।

4. Modularity : সিস্টেমকে ছোট ছোট ইউনিটে ভাগ করে রাখা যায়, তাই আলাদাভাবে আপগ্রেড/মেইনটেইন করা যায়।

5. Fault Tolerance : ডাটার রিপ্লিকেশন থাকলে এক সার্ভারের ডাটা নষ্ট হলেও অন্য সার্ভার থেকে পুনরুদ্ধার করা যায়।

❌ অসুবিধা (Disadvantages of Distributed Database)

1. Complexity  :  আর্কিটেকচার, ডাটা সিঙ্ক্রোনাইজেশন, কনসিসটেন্সি বজায় রাখা খুব জটিল।

2. Cost : একাধিক সার্ভার, নেটওয়ার্কিং, সিকিউরিটি ইত্যাদির জন্য খরচ অনেক বেশি।

3. Data Consistency Problem : রিপ্লিকেশন থাকলে এক নোডে ডাটা আপডেট করলে অন্য নোডে সাথে সাথে সিঙ্ক নাও হতে পারে।

4. Security Challenge : অনেক লোকেশনে ডাটা থাকায় হ্যাকিং বা অননুমোদিত অ্যাক্সেস ঠেকানো কঠিন।

5. Network Dependency : পুরো সিস্টেম নেটওয়ার্কের উপর নির্ভরশীল। নেটওয়ার্ক স্লো হলে বা ডাউন হলে সমস্যা হয়।

-----------------------------------------------------------------------------------------------------------------------------

Fragmentation

ডিস্ট্রিবিউটেড ডাটাবেসে Fragmentation মানে হলো একটি বড় টেবিলকে ছোট ছোট অংশে ভাগ করে বিভিন্ন লোকেশন/নোডে সংরক্ষণ করা।

এতে ডাটা ম্যানেজমেন্ট সহজ হয়, লোকাল ডাটা অ্যাক্সেস ফাস্ট হয় এবং লোড ব্যালেন্সিং ভালোভাবে করা যায়।

📌 Fragmentation এর ধরণ

1. Horizontal Fragmentation

   1. টেবিলকে row (record) এর ভিত্তিতে ভাগ করা হয়।

   2. প্রতিটি ফ্র্যাগমেন্টে টেবিলের নির্দিষ্ট কিছু রো থাকে, কিন্তু সব কলাম থাকে।

   🔹 উদাহরণ:
   ধরুন আমাদের কাছে একটি Customer টেবিল আছে:

   CustomerID | Name    | City
   -----------|---------|---------
   1          | Ali     | Dhaka
   2          | Rahim   | Chittagong
   3          | Karim   | Dhaka
   4          | Hasan   | Sylhet
   

   1. Dhaka এর কাস্টমারদের ডাটা ঢাকা সার্ভারে রাখা হলো।

   2. Chittagong এর কাস্টমারদের ডাটা চট্টগ্রাম সার্ভারে রাখা হলো।

   👉 এটিই হলো Horizontal Fragmentation।

Horizontal Fragmentation আবার দুই ধরণের হতে পারে –

1️⃣ Primary Horizontal Fragmentation

এটি হলো যখন একটি relation (table) কে সরাসরি তার own attribute (নিজস্ব কলাম) এর কোনো condition দিয়ে ভাগ করা হয়।

🔹 উদাহরণ:
ধরা যাক আমাদের কাছে Employee টেবিল আছে –

EmpID | Name   | Dept
------+--------+----------
1     | Ali    | HR
2     | Rahim  | IT
3     | Karim  | HR
4     | Hasan  | Finance

👉 যদি আমরা condition দিই:

1. Dept = "HR" → Dhaka সার্ভারে

2. Dept = "IT" → Chittagong সার্ভারে

তাহলে এই টেবিল তার নিজের attribute (Dept) এর ভিত্তিতে ভাগ হলো।
এটাই Primary Horizontal Fragmentation।

2️⃣ Derived Horizontal Fragmentation

এক্ষেত্রে একটি relation কে ভাগ করা হয় অন্য একটি relation-এর উপর ভিত্তি করে।

অর্থাৎ, condition টি মূল relation থেকে আসে না, বরং এটি অন্য relation এর সাথে join condition ব্যবহার করে ভাগ করা হয়।

🔹 উদাহরণ:
আমাদের কাছে দুইটা টেবিল আছে –

Employee Table

EmpID | Name   | DeptID
------+--------+-------
1     | Ali    | D1
2     | Rahim  | D2
3     | Karim  | D1
4     | Hasan  | D3

Department Table

DeptID | DeptName   | Location
-------+------------+----------
D1     | HR         | Dhaka
D2     | IT         | Chittagong
D3     | Finance    | Sylhet

👉 এখন যদি আমরা Employee টেবিলকে ভাগ করতে চাই Department এর Location এর উপর ভিত্তি করে (যেমন Dhaka এর এমপ্লয়ি আলাদা, Chittagong এর এমপ্লয়ি আলাদা)...
তাহলে এখানে Employee টেবিলকে তার নিজের attribute দিয়ে নয়, বরং Department টেবিলের attribute (Location) দিয়ে ভাগ করা হলো।

এটাই হলো Derived Horizontal Fragmentation।

1. Primary Horizontal Fragmentation = relation কে ভাগ করা হয় তার নিজের attribute দিয়ে।

2. Derived Horizontal Fragmentation = relation কে ভাগ করা হয় অন্য relation এর attribute ব্যবহার করে।

2. Vertical Fragmentation

   1. টেবিলকে column (attribute) এর ভিত্তিতে ভাগ করা হয়।

   2. প্রতিটি ফ্র্যাগমেন্টে টেবিলের নির্দিষ্ট কিছু কলাম থাকে।

   3. সাধারণত primary key প্রতিটি ফ্র্যাগমেন্টে রাখা হয়, যাতে আবার join করা যায়।

   🔹 উদাহরণ:
   একই Customer টেবিলকে ভাগ করলে:

   1. Fragment 1 (ঢাকা সার্ভারে): CustomerID, Name

   2. Fragment 2 (চট্টগ্রাম সার্ভারে): CustomerID, City

   👉 পরে join করে আসল টেবিল পুনর্গঠন করা যায়।

3. Hybrid (Mixed) Fragmentation

   1. প্রথমে টেবিলকে horizontal fragmentation করে, তারপর প্রতিটি অংশকে vertical fragmentation করা হয় (অথবা উল্টোটা)।

   2. মানে রো আর কলাম – দুইভাবে একসাথে ভাগ করা।

সহজভাবে মনে রাখার কৌশল:

1. Horizontal = রো ভাগ করা

2. Vertical = কলাম ভাগ করা

---

✅ Fragmentation-এর Correctness Rules

1️⃣ Completeness Rule (পূর্ণতা)

1. Fragmentation করার পরে প্রতিটি টুপল (row) অবশ্যই কোনো না কোনো ফ্র্যাগমেন্টে থাকবে।

2. কোনো ডাটা বাদ পড়া যাবে না।

🔹 উদাহরণ:
Employee টেবিলকে যদি Dept = "HR" এবং Dept = "IT" দিয়ে ভাগ করা হয়, তবে অন্য Dept-এর ডাটাও কোনো না কোনো ফ্র্যাগমেন্টে থাকতে হবে।

2️⃣ Reconstruction Rule (পুনর্গঠন)

1. Fragmentation করার পর সব ফ্র্যাগমেন্টকে আবার union / join করে আসল relation পাওয়া যেতে হবে।

2. অর্থাৎ fragmentation হওয়া টেবিল যেন reconstruct করা যায়।

🔹 উদাহরণ:
Horizontal Fragmentation → Union দিয়ে reconstruct করা হয়।
Vertical Fragmentation → Join (with primary key) দিয়ে reconstruct করা হয়।

3️⃣ Disjointness Rule (অসংলগ্নতা)

1. Horizontal Fragmentation-এর ক্ষেত্রে কোনো টুপল যেন একাধিক ফ্র্যাগমেন্টে না থাকে (overlap না হয়)।

2. তবে replication থাকলে overlap ইচ্ছাকৃতভাবে হতে পারে।

🔹 উদাহরণ:

যদি Customer টেবিলকে City = Dhaka এবং City = Chittagong দিয়ে ভাগ করি → কোনো row দুই জায়গায় যাবে না।

 সংক্ষেপে:

1. Completeness → সব ডাটা কাভার করতে হবে।

2. Reconstruction → fragment থেকে আবার আসল relation তৈরি করা যাবে।

3. Disjointness → কোনো ডাটা overlap করবে না (except replication case)।

-----------------------------------------------------------------------------------------------------------------------------

📌 Concurrency Control কী?

Concurrency Control হলো ডাটাবেসে একসাথে একাধিক ট্রান্স্যাকশন চলার সময় ডাটার সঠিকতা (Correctness) ও সামঞ্জস্যতা (Consistency) বজায় রাখার প্রক্রিয়া।

অর্থাৎ, একাধিক ইউজার বা প্রসেস যদি একই ডাটা একসাথে অ্যাক্সেস বা আপডেট করতে চায়, তবে সেটিকে এমনভাবে ম্যানেজ করতে হবে যেন –

1. ডাটা loss না হয়,

2. ডাটা inconsistency না হয়,

3. প্রতিটি ট্রান্স্যাকশন isolation পায়।

✅ কেন Concurrency Control দরকার?

1. একাধিক transaction parallelly কাজ করলে সমস্যা হতে পারে (যেমন এক ট্রান্স্যাকশন আপডেট করলো, আরেকজন সেটি ওভাররাইট করে দিলো)।

2. সঠিকভাবে কন্ট্রোল না করলে Dirty Read, Lost Update, Inconsistent Retrieval ইত্যাদি সমস্যা দেখা দেয়।

📌 Concurrency Problems (যা এড়াতে হয়)

1. Lost Update → এক ট্রান্স্যাকশনের আপডেট অন্য ট্রান্স্যাকশন মুছে দেয়।

2. Dirty Read → একটি ট্রান্স্যাকশন এমন ডাটা পড়ে যা এখনো কমিট হয়নি।

3. Unrepeatable Read → একই query বারবার চালালে ভিন্ন ভিন্ন রেজাল্ট আসে।

4. Phantom Read → একটি query চালানোর পর দ্বিতীয়বার চালালে নতুন record দেখা দেয়।

📌 Concurrency Control Techniques

1. Lock-based Protocols

   1. Shared Lock (read), Exclusive Lock (write)

   2. Two-Phase Locking (2PL)

2. Timestamp-based Protocols

   1. প্রতিটি transaction কে একটি টাইমস্ট্যাম্প দেওয়া হয় এবং সেই অনুযায়ী ordering করা হয়।

3. Optimistic Concurrency Control (OCC)

   1. ধরে নেওয়া হয় conflict হবে না, পরে validation phase-এ চেক করা হয়।

4. Multiversion Concurrency Control (MVCC)

   1. ডাটার একাধিক version রাখা হয়, তাই readers ও writers একসাথে কাজ করতে পারে।

   2. PostgreSQL, Oracle, MySQL (InnoDB) এগুলো MVCC ব্যবহার করে।

 সংক্ষেপে:
Concurrency Control = অনেকগুলো transaction কে parallelly safe & consistent ভাবে চালানো।

-----------------------------------------------------------------------------------------------------------------------------

📌 Transaction এবং ACID Properties

একটি Transaction হলো ডাটাবেসে একগুচ্ছ অপারেশন যা একসাথে execute হয়।
এটি অবশ্যই ACID properties মেনে চলবে –

1. Atomicity → সব কাজ হবে অথবা কিছুই হবে না।

2. Consistency → ডাটাবেস সঠিক অবস্থায় থাকবে।

3. Isolation → এক ট্রান্স্যাকশনের কাজ অন্যটির সাথে interfere করবে না।

4. Durability → একবার কমিট হলে ডাটা হারাবে না (সিস্টেম ক্র্যাশ হলেও)।

এগুলো Centralized DBMS এবং Distributed DBMS – উভয়ের জন্যই বাধ্যতামূলক।

📌 Transaction-এর ধরন (Distributed Database-এ)

ডিস্ট্রিবিউটেড ডাটাবেসে ট্রান্স্যাকশন দুই ধরণের হতে পারে:

1️⃣ Local Transaction

1. ডাটা অ্যাক্সেস করা হয় একটি লোকাল ডাটাবেসে।

2. মানে শুধুমাত্র এক লোকেশনের সার্ভারে read/write/update করা হয়।

3. এখানে Transaction ম্যানেজ করা তুলনামূলক সহজ।

🔹 উদাহরণ:
ঢাকার সার্ভারে থাকা কাস্টমারের balance update করলাম –

UPDATE Account SET balance = balance - 500 WHERE AccNo = 101;

👉 এটি শুধু ঢাকার ডাটাবেসেই চলছে, তাই এটি Local Transaction।

---

2️⃣ Global Transaction

1. ডাটা অ্যাক্সেস করা হয় একাধিক লোকাল ডাটাবেসে।

2. একাধিক সার্ভার/লোকেশনের মধ্যে coordination করতে হয়।

3. এখানে distributed concurrency control ও commit protocols (যেমন Two-Phase Commit) দরকার হয়।

🔹 উদাহরণ:
একজন কাস্টমার ঢাকার শাখা থেকে টাকা তুললো, আর সেই একই কাস্টমারের ডাটা চট্টগ্রাম শাখার সার্ভারেও আছে। তখন –

1. ঢাকার ডাটাবেস থেকে balance কমাতে হবে।

2. চট্টগ্রামের ডাটাবেসে ট্রান্স্যাকশনের রেকর্ড আপডেট করতে হবে।
   👉 এটি হলো Global Transaction।

 সংক্ষেপে:

1. Local Transaction = এক লোকাল ডাটাবেসে কাজ করে।

2. Global Transaction = একাধিক লোকাল ডাটাবেসে একসাথে কাজ করে (ডিস্ট্রিবিউটেড কন্ট্রোল দরকার)।

----------------------------------------------------------------------------------------------------------------------------

📌 Distributed Transaction System এর Components

1️⃣ Transaction Manager (TM)

1. প্রতিটি সাইটে (local database site) একটি Transaction Manager থাকে।

2. এর কাজ:

   1. লোকাল ডাটাবেসে চলা ট্রান্স্যাকশনগুলো ACID properties মেনে চলছে কিনা সেটা নিশ্চিত করা।

   2. Concurrency control (যেমন locks, timestamps) ব্যবহার করে ডাটা কনসিস্টেন্সি বজায় রাখা।

   3. লোকাল লগ (log) রাখা, যাতে rollback বা recovery করা যায়।

2️⃣ Transaction Coordinator (TC)

1. প্রতিটি সাইটেই একটি Transaction Coordinator থাকে।

2. এর কাজ:

   1. সেই সাইটে যেসব transaction initiate হয়, সেগুলো coordinate করা।

   2. Local transaction হলে → লোকাল TM এর সাথে কাজ করে।

   3. Global transaction হলে → অন্যান্য সাইটের TM এর সাথে যোগাযোগ করে।

   4. Commit Protocols (যেমন Two-Phase Commit - 2PC) ব্যবহার করে একাধিক সাইটে ডাটা সঠিকভাবে update হচ্ছে কিনা তা coordinate করা।

✅ একসাথে কাজ করার প্রক্রিয়া (Simple Flow):

1. কোনো transaction শুরু হলো Dhaka সাইটে → Dhaka এর Transaction Coordinator সেটাকে initiate করবে।

2. যদি transaction টি শুধু Dhaka ডাটাবেসে কাজ করে → Dhaka এর Transaction Manager সেটি handle করবে।

3. যদি transaction টি Dhaka + Chittagong দুই সাইটে কাজ করে → Dhaka এর Transaction Coordinator → চট্টগ্রামের Transaction Coordinator এর সাথে যোগাযোগ করবে → তারপর উভয় সাইটের Transaction Manager মিলে কাজ সম্পন্ন করবে।

-----------------------------------------------------------------------------------------------------------------------------

📌 বিভিন্ন Transaction Models

1️⃣ General Transaction

1. এখানে read এবং write অপারেশনের উপর কোনো নির্দিষ্ট order নেই।

2. Transaction ইচ্ছেমতো read করবে, ইচ্ছেমতো write করবে।

3. সবচেয়ে flexible কিন্তু consistency বজায় রাখা কঠিন।

👉 উদাহরণ:

R(A), W(B), R(C), W(A), R(D)

2️⃣ Two-step Transaction

1. এখানে সব read operations আগে হবে, তারপর সব write operations।

2. মানে: transaction → প্রথমে পড়বে (read), পরে লিখবে (write)।

👉 উদাহরণ:

R(A), R(B), R(C), W(A), W(B)

3️⃣ Restricted (Read-Before-Write) Transaction

1. এখানে rule হলো: কোনো ডাটা item update (write) করার আগে সেটি অবশ্যই read করতে হবে।

2. Write without read → অনুমোদিত নয়।

👉 উদাহরণ:

R(A), W(A), R(B), W(B)

4️⃣ Restricted Two-step Transaction

1. এটি হলো Two-step + Restricted এর কম্বিনেশন।

2. মানে:

   1. সব read আগে, সব write পরে,

   2. এবং write করার আগে অবশ্যই read করতে হবে।

👉 উদাহরণ:

R(A), R(B), W(A), W(B)

5️⃣ Action Model

1. এটি হলো Restricted Model-এর স্পেশাল কেস।

2. এখানে প্রতিটি read এর সাথে সাথে তার corresponding write একসাথে (pair) execute হয়।

3. প্রতিটি read-write জুটি একসাথে একটি action হিসেবে ধরা হয়।

👉 উদাহরণ:

R(A), W(A), R(B), W(B)

---------------------------------------------------------------------------------------------------------------------------

Transaction Type : 

🔹 Flat Transaction

1. একটি সিঙ্গেল ট্রানজ্যাকশন থাকে।

2. সেটি সরাসরি বিভিন্ন সার্ভার/সাইটে গিয়ে ডেটা রিড বা রাইট করে।

3. ট্রানজ্যাকশনটি Atomic → মানে সব অপারেশন সফল হবে, না হলে সব Rollback হবে।

4. সাব-ট্রানজ্যাকশন বলে কিছু থাকে না, সবকিছু একক ইউনিট হিসেবে কাজ করে।

✅ উদাহরণ:
ধরি, একজন ইউজার ব্যাংকের অ্যাপে টাকা ট্রান্সফার করছে:

1. তার অ্যাকাউন্ট থেকে টাকা কমলো (ঢাকা সার্ভার)।

2. অন্যজনের অ্যাকাউন্টে টাকা যোগ হলো (চট্টগ্রাম সার্ভার)।

👉 এগুলো একসাথে একটি Flat Transaction।

🔹 Nested Transaction

1. একটি বড় ট্রানজ্যাকশনের ভেতরে Sub-transactions থাকে।

2. প্রতিটি সাব-ট্রানজ্যাকশন আবার ছোট ছোট সাব-ট্রানজ্যাকশনেও ভাগ হতে পারে।

3. কাজগুলো hierarchical বা গাছের মতো স্ট্রাকচার এ সাজানো থাকে।

4. সাব-ট্রানজ্যাকশনগুলো কখনও আলাদাভাবে কমিট বা রোলব্যাক হতে পারে (কনফিগারেশনের উপর নির্ভর করে)।

✅ উদাহরণ:

ধরি, একজন ছাত্র অনলাইনে বিশ্ববিদ্যালয়ে ভর্তি হলো। পুরো ভর্তি প্রক্রিয়াটা একটা বড় ট্রানজ্যাকশন (T), কিন্তু এর মধ্যে আবার ছোট ছোট সাব-ট্রানজ্যাকশন আছে।

1. T1: Payment Process

   1. T11: ব্যাংক সার্ভার থেকে টাকা কাটা

   2. T12: বিশ্ববিদ্যালয়ের ফি অ্যাকাউন্টে টাকা জমা

2. T2: Academic Registration

   1. T21: ছাত্রের তথ্য ডাটাবেসে সেভ করা

   2. T22: কোর্স সিলেকশন রেজিস্ট্রেশন

3. T3: ID Generation

   1. T31: ছাত্রের ID কার্ড নম্বর জেনারেট

   2. T32: ইমেইল অ্যাকাউন্ট তৈরি

👉 এখানে পুরো ভর্তি প্রক্রিয়াটা একটি বড় Nested Transaction (T)।

1. যদি Payment (T1) ফেল করে → ভর্তি প্রক্রিয়া থেমে যাবে।

2. কিন্তু যদি কোর্স সিলেকশনে (T22) সমস্যা হয়, সেটা ঠিক করা যাবে আলাদা করে, অন্য সাব-ট্রানজ্যাকশন বাতিল হবে না।

সহজ ভাষায়:
Nested Transaction মানে হলো — বড় কাজটাকে ধাপে ধাপে ছোট ছোট সাব-কাজে ভাগ করে করা।

-----------------------------------------------------------------------------------------------------------------------------

🔹 Serializability কী?

1. Serializability হলো একটি DBMS concept, যা বলে দেয়—যখন অনেকগুলো ট্রানজ্যাকশন একসাথে (concurrent) চলছে, তখন তাদের execution order এমনভাবে সাজাতে হবে যেন ফলাফলটা একই থাকে যেভাবে তারা একটার পর একটা (serially) চললে হতো।

2. মানে, concurrent execution হলেও, final result database এর consistency নষ্ট করবে না।

🔹 কেন দরকার?

1. সব ট্রানজ্যাকশনকে একে একে (serial) চালালে consistency ঠিক থাকে, কিন্তু efficiency কমে যায়।

2. তাই আমরা parallel/concurrent execution চাই।

3. কিন্তু সব parallel schedule ঠিক না → কিছু inconsistency তৈরি করে।

4. তাই serializability ব্যবহার করে যাচাই করা হয় → কোন concurrent schedule নিরাপদ।

🔹 DDBMS এ Serializability

ডিস্ট্রিবিউটেড ডাটাবেজে (DDBMS) serializability আরও জটিল হয়ে যায়, কারণ এখানে data একাধিক সাইটে ছড়ানো থাকে।

🟣 Case 1: Data Replication নেই

1. এখানে serializability চেক করা সহজ।

2. Global schedule = সব লোকাল schedule এর union।

3. যদি global schedule serializable হয় → সব ঠিক আছে।

🟣 Case 2: Data Replication আছে

1. এখানে জটিলতা বেশি।

2. কারণ একটা ডেটার একাধিক copy (replica) থাকতে পারে বিভিন্ন সাইটে।

3. সব replica-র মান একই থাকা বাধ্যতামূলক। এটাকে বলে Mutual Consistency।

4. যদি কোনো schedule এর কারণে এক সাইটের copy আপডেট হয় কিন্তু অন্য সাইটেরটা না হয় → তখন inconsistency তৈরি হবে।

🔹 উদাহরণ (Replication এর কারণে সমস্যা)

ধরি, ডাটাবেজে একটা data item X আছে, যার দুটি copy আছে:

1. ঢাকা সার্ভারে → X = 100

2. চট্টগ্রাম সার্ভারে → X = 100

এখন দুটি ট্রানজ্যাকশন একসাথে চলছে:

1. T1: X = X + 50 (ঢাকা সার্ভারে update) → X = 150

2. T2: X = X * 2 (চট্টগ্রাম সার্ভারে update) → X = 200

👉 এখন problem হলো—

1. ঢাকা সার্ভারে X = 150

2. চট্টগ্রাম সার্ভারে X = 200

মানে, mutual consistency ভেঙে গেছে, যদিও লোকালি দুইটা schedule serializable ছিল।

মূলকথা

1. Serializability নিশ্চিত করে যে concurrent ট্রানজ্যাকশন গুলো database কে consistent রাখবে।

2. DDBMS এ serializability → শুধু লোকাল নয়, global serializability নিশ্চিত করতে হবে।

3. আর যদি replication থাকে, তবে mutual consistency বজায় রাখা সবচেয়ে কঠিন কাজ।

🔹 Global Serializability কী?

1. Serializability মানে হলো, একাধিক concurrent ট্রানজ্যাকশন চললেও, তাদের ফলাফল এমন হতে হবে যেন তারা একটার পর একটা (serially) চলেছে।

2. কিন্তু Distributed Database Management System (DDBMS) এ, অনেকগুলো local database থাকে।

3. প্রতিটি সাইটে নিজস্ব local schedule চলে।

4. এই সব local schedule একত্র করলে যেটা পাওয়া যায় তাকে বলে Global Schedule।

👉 Global Serializability মানে হলো:

1. সব local schedule আলাদাভাবে serializable হতে হবে।

2. এবং তাদের মিলিত form (global schedule) ও serializable হতে হবে।

🔹 কেন দরকার?

যদি শুধু local serializability থাকে, কিন্তু global level এ inconsistency হয়, তাহলে database এ ভুল ফলাফল আসবে।

🔹 উদাহরণ (Global Serializability problem)

ধরি, দুটি data item আছে:

1. X ঢাকা সার্ভারে

2. Y চট্টগ্রাম সার্ভারে

এখন দুটি ট্রানজ্যাকশন চলছে:

1. T1: Read(X), Write(Y)

2. T2: Read(Y), Write(X)

3. ঢাকা সার্ভারের local schedule: T1 → T2

4. চট্টগ্রাম সার্ভারের local schedule: T2 → T1

👉 লোকালি দুইটিই serializable।
কিন্তু globally, একটা সাইটে T1 আগে চলছে, আরেকটায় T2 আগে চলছে।
ফলাফল → cycle তৈরি হয় (conflict graph এ) → global serializability ভেঙে যায়।

🔹 Replication এর ক্ষেত্রে সমস্যা

যদি data এর একাধিক copy থাকে:

1. তখন সব copy তে update একইভাবে propagate হতে হবে।

2. যদি এক সার্ভারে X = 100 থেকে 150 হয়, আর অন্য সার্ভারে সেটা update না হয় → global serializability maintain হবে না।

মূলকথা

1. Local Serializability ≠ Global Serializability সবসময়।

2. Global serializability মানে হলো সব সাইটের schedule মিলে globally consistent order তৈরি করতে হবে।

3. Replication থাকলে কাজটা আরও কঠিন হয়।