Quorum ও R+W Greater Than N
- ●N কপি রাখলে প্রতিবার সবগুলোতে read/write না করে quorum (সংখ্যাগরিষ্ঠ) ছুঁলেই কাজ চলে।
- ●R + W এর চেয়ে বড় N হলে read এবং write quorum overlap করে, তাই নতুন write কখনো মিস হয় না।
- ●R ও W ঘুরিয়ে তুমি consistency, latency আর availability-র মধ্যে tunable trade-off বানাতে পারো।
সমস্যাটা কী?
ডেটা একটামাত্র সার্ভারে রাখলে সেই সার্ভার মরে গেলে সব শেষ। তাই আমরা ডেটার একাধিক কপি বা replica রাখি — ধরো N সমান ৩। এখন প্রশ্ন: write করার সময় কি তিনটাতেই লিখব? read করার সময় কি তিনটাই পড়ব?
যদি প্রতিবার সব replica-তে লিখতে হয়, তাহলে একটা replica ডাউন থাকলেই write আটকে যাবে — availability নষ্ট। আবার যদি শুধু একটাতে লিখি আর অন্য একটা থেকে পড়ি, তাহলে পুরোনো (stale) ডেটা পাওয়ার সম্ভাবনা।
মাঝামাঝি একটা চতুর সমাধান দরকার — যেটা কিছু নোড ডাউন থাকলেও কাজ করে, আবার stale ডেটাও এড়ায়। এটাই quorum-এর গল্প।
মূল ধারণা
Quorum: কোনো অপারেশন সফল ঘোষণা করার জন্য প্রয়োজনীয় সর্বনিম্ন সংখ্যক নোডের সম্মতি। সব নোড না, শুধু একটা নির্দিষ্ট সংখ্যাগরিষ্ঠ ছুঁলেই হলো।
তিনটা সংখ্যা মনে রাখো:
- N — মোট কতগুলো replica আছে।
- W — write quorum; একটা write সফল বলতে কতগুলো নোডে confirm হতে হবে।
- R — read quorum; একটা read করার সময় কতগুলো নোড থেকে value সংগ্রহ করতে হবে।
জাদুর শর্ত হলো: R + W এর চেয়ে বড় N। মানে R আর W যোগ করলে যা হয়, সেটা N-এর চেয়ে বড় হতে হবে। এই শর্ত মানা থাকলে read আর write quorum অন্তত একটা নোডে অবশ্যই overlap করবে — আর সেই overlap-করা নোডে সর্বশেষ write থাকবেই। ফলে read কখনো নতুন write মিস করবে না।
কীভাবে কাজ করে
Overlap-এর জাদু
ধরো N সমান ৫। তুমি একটা value লিখলে W সমান ৩ নোডে। পরে কেউ R সমান ৩ নোড থেকে পড়ছে। মোট নোড ৫, কিন্তু লেখা হয়েছে ৩টায় আর পড়া হচ্ছে ৩টা থেকে — পায়ার-জোড়ার নিয়মে অন্তত একটা নোড দুই দলেই থাকবে। সেই নোডে নতুন value আছে, তাই read সেটা ধরে ফেলবে।
প্রতিটা value-র সাথে একটা version number বা timestamp থাকে; read করার সময় কয়েকটা value পেলে সবচেয়ে নতুনটা বেছে নেওয়া হয়।
R ও W এর বিভিন্ন সমন্বয় (N সমান ৩)
| R | W | R+W vs N | বৈশিষ্ট্য |
|---|---|---|---|
| 1 | 3 | 4, বড় | write ধীর/কম available, read দ্রুত |
| 3 | 1 | 4, বড় | write দ্রুত, read ধীর; fast write workload |
| 2 | 2 | 4, বড় | ভারসাম্যপূর্ণ, একটি নোড ডাউন সহনীয় |
| 1 | 1 | 2, ছোট | খুব দ্রুত কিন্তু stale read সম্ভব |
Sloppy quorum ও hinted handoff
যখন আসল নোডগুলো partition-এ আটকে থাকে, Dynamo-style সিস্টেম "sloppy quorum" ব্যবহার করে — সাময়িকভাবে অন্য নোডে লিখে রাখে আর hint দিয়ে রাখে, আসল নোড ফিরলে ডেটা সঁপে দেয় (hinted handoff)। এতে availability বাড়ে, কিন্তু overlap-এর কঠোর নিশ্চয়তা কিছুটা শিথিল হয়।
কৌশল
ভাবো একটা সমিতির গুরুত্বপূর্ণ সিদ্ধান্ত নিতে ৫ জন সদস্যের কমিটি (N সমান ৫)। নিয়ম করা হলো — কোনো সিদ্ধান্ত পাস করতে অন্তত ৩ জনের সই লাগবে (W সমান ৩), আর কোনো পুরোনো সিদ্ধান্ত যাচাই করতে অন্তত ৩ জনকে জিজ্ঞেস করতে হবে (R সমান ৩)। যেহেতু ৩ যোগ ৩ সমান ৬ যা ৫ এর চেয়ে বড়, যাচাইকারী যে ৩ জনকে জিজ্ঞেস করবে, তাদের অন্তত একজন আগের সিদ্ধান্তে সই করেছিলেন — তাই সঠিক তথ্য পাবেই। দু'একজন সদস্য অসুস্থ থাকলেও কমিটি অচল হয় না।
কখন ব্যবহার করবে / করবে না
ব্যবহার করবে যখন তোমার high availability দরকার আর কিছু নোড ডাউন থাকলেও সিস্টেম চালু রাখতে হবে — leaderless replication (Dynamo, Cassandra, Riak)।
ব্যবহার করবে না যখন তোমার strict linearizability দরকার এবং একটা leader-based system (যেমন Raft/Postgres) ইতিমধ্যে সহজে সেটা দিচ্ছে। quorum নিজে strong consistency-র সম্পূর্ণ গ্যারান্টি নয় — concurrent write আর timing edge case-এ এখনো সাবধানতা লাগে।
R + W এর চেয়ে বড় N শর্ত শুধু "নতুন write মিস হবে না" নিশ্চিত করে — এটা সম্পূর্ণ linearizability দেয় না। দুটো concurrent write একই সময়ে এলে কোনটা জিতবে তা version/timestamp ঠিক না করলে ডেটা হারাতে পারে (last-write-wins-এর ফাঁদ)। আর W সমান ১ রাখলে দ্রুততার লোভে তুমি stale read-এর ঝুঁকি বিশাল করে ফেলবে।
বাস্তব উদাহরণ
- Apache Cassandra: প্রতি query-তে consistency level বেছে নেওয়া যায় — ONE, QUORUM, ALL। QUORUM মানেই R+W overlap নিশ্চিত করা।
- Amazon DynamoDB / Dynamo paper: এই tunable N, R, W ধারণার জন্মদাতা।
- Riak: ডিফল্ট N সমান ৩ এবং QUORUM read/write দিয়ে আসে।
- MongoDB: writeConcern "majority" আর readConcern "majority" আসলে quorum overlap-এর ধারণাই প্রয়োগ করে।
ইন্টারভিউতে "কীভাবে stale read এড়াবে" জিজ্ঞেস করলে সরাসরি বলো — "R + W এর চেয়ে বড় N রাখব, তাতে read ও write quorum overlap করবে।" তারপর যোগ করো কীভাবে R আর W ঘুরিয়ে read-heavy বা write-heavy workload-এর জন্য tune করা যায়। এই tunable trade-off বোঝাটাই মূল পয়েন্ট।
মূল শব্দ (Key Terms)
মিনি কুইজ
1. N সমান ৫ হলে, R + W এর চেয়ে বড় N নিশ্চিত করতে R সমান ৩ হলে W কমপক্ষে কত হতে হবে?
2. R + W এর চেয়ে বড় N শর্ত কেন গুরুত্বপূর্ণ?
3. W সমান ১ রাখলে কী হয়?