Partitioning & Sharding (বিগ ডেটা স্কেলিং)

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

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

১৫.১ Partitioning কী? (এক ছাদের নিচে আলাদা ঘর)

Partitioning মানে হলো একটি বিশাল টেবিলকে লজিক্যালি এক রাখা, কিন্তু ফিজিক্যালি ছোট ছোট ফাইলে ভাগ করে ফেলা। MySQL নিজেই এটি ম্যানেজ করে, ডেভেলপারকে কুয়েরি চেঞ্জ করতে হয় না।

📌 উদাহরণ:

আপনার logs টেবিলে ২০ কোটি রো আছে। আপনি সাল (Year) অনুযায়ী ভাগ করলেন।

  • p2023: ২০২৩ সালের সব লগ
  • p2024: ২০২৪ সালের সব লগ

🎯 লাভ: যখন আপনি WHERE created_at = '2024-01-01' দেবেন, MySQL শুধু p2024 ফাইলে খুঁজবে। বাকি ফাইলে হাতও দেবে না। একে বলে Partition Pruning।

১৫.২ Partition Types (কোনটা কখন?)

MySQL ৪ ধরণের পার্টিশন সাপোর্ট করে:

📊 ১. RANGE Partition (সবচেয়ে জনপ্রিয়)

কোনো একটি রেঞ্জ বা সীমার ওপর ভিত্তি করে ভাগ করা। সাধারণত Date বা ID এর ওপর করা হয়।

CREATE TABLE orders (
  id INT,
  amount DECIMAL(10,2),
  created_at DATE
)
PARTITION BY RANGE (YEAR(created_at)) (
  PARTITION p2023 VALUES LESS THAN (2024),
  PARTITION p2024 VALUES LESS THAN (2025),
  PARTITION pFuture VALUES LESS THAN MAXVALUE
);

🌍 ২. LIST Partition

নির্দিষ্ট কিছু ভ্যালুর লিস্ট অনুযায়ী ভাগ করা। (যেমন: দেশ বা রিজিয়ন)

PARTITION BY LIST (country_code) (
  PARTITION pAsia VALUES IN (880, 91, 92), -- BD, India, PK
  PARTITION pUSA VALUES IN (1)
);

🔢 ৩. HASH Partition

যখন কোনো প্যাটার্ন (Date/Region) নেই, তখন ডেটাকে সমান ভাগে ভাগ করতে এটি ব্যবহার হয়।

-- user_id এর ওপর ভিত্তি করে ৪টি সমান ভাগে ভাগ হবে
PARTITION BY HASH(user_id) PARTITIONS 4;

🔑 ৪. KEY Partition

HASH এর মতোই, কিন্তু এখানে MySQL নিজস্ব অ্যালগরিদম ব্যবহার করে (Primary Key এর ওপর)

PARTITION BY KEY(id) PARTITIONS 4;

১৫.৩ Partition Pruning এবং Maintenance

✂️ Pruning (অটোমেটিক সিলেকশন):

SELECT * FROM orders WHERE created_at BETWEEN '2024-01-01' AND '2024-02-01';

MySQL বুঝবে এই ডেটা শুধু p2024 এ আছে। তাই সে অন্য পার্টিশন চেকই করবে না। এতে কুয়েরি ১০-২০ গুণ ফাস্ট হতে পারে।

⚡ দ্রুত ডিলিট করা (Drop Partition):

লগ টেবিল থেকে ৫ বছরের পুরোনো ডেটা DELETE কুয়েরি দিয়ে মুছতে গেলে সার্ভার হ্যাং করতে পারে।

কিন্তু পার্টিশন ড্রপ করলে ১ সেকেন্ডে সব ডিলিট!

ALTER TABLE orders DROP PARTITION p2018;

১৫.৪ Sharding কী? (আলাদা সার্ভার, আলাদা জগত)

📦 Partitioning

= এক সার্ভারে টেবিল ভাঙা

🌐 Sharding

= ডেটাকে ভেঙে একাধিক আলাদা সার্ভারে রাখা

ফেসবুকের সব ইউজারের ডেটা কি এক সার্ভারে ধরে? অসম্ভব! তারা Sharding ব্যবহার করে।

১৫.৫ Horizontal vs Vertical Sharding

↔️ Horizontal Sharding

একই টেবিলের রো (Row) গুলোকে ভাগ করে বিভিন্ন সার্ভারে রাখা।

  • Server A: User ID 1 - 1,000,000
  • Server B: User ID 1,000,001 - 2,000,000

↕️ Vertical Sharding

টেবিলের কলাম বা মডিউল অনুযায়ী সার্ভার আলাদা করা।

  • Server A: Users Database (Login, Profile)
  • Server B: Orders Database (Transaction, History)
  • Server C: Logs Database

১৫.৬ Sharding Key Selection (জীবন-মরণ সিদ্ধান্ত)

শার্ডিং করার সময় আপনাকে ঠিক করতে হবে কোন কলামের ওপর ভিত্তি করে ডেটা ভাগ করবেন। এই কলামকে Sharding Key বলে।

✅ ভালো Key

  • user_id
  • company_id
  • region_id

❌ খারাপ Key

  • timestamp (কারণ সব নতুন ডেটা এক সার্ভারে হিট করবে, একে Hotspot বলে)

📌 উদাহরণ (User ID % 4):

User 1 -> 1 % 4 = 1 -> Server 1
User 2 -> 2 % 4 = 2 -> Server 2
User 4 -> 4 % 4 = 0 -> Server 0

১৫.৭ Sharding এর চ্যালেঞ্জ (কেন সবাই করে না?)

💡 ইন্টারভিউতে যদি জিজ্ঞেস করে, "কখন শার্ডিং করবেন না?" উত্তর হবে: "যতদিন পারা যায় এড়াতে হবে।"

  • ⚠️JOIN সমস্যা: Server A তে ইউজার, Server B তে অর্ডার। এখন JOIN করবেন কীভাবে? (অ্যাপ লেভেলে করতে হয়, যা কঠিন)
  • ⚠️Transaction (ACID) সমস্যা: দুই সার্ভারে একসাথে ট্রানজেকশন মেইনটেইন করা খুব কঠিন (Two-Phase Commit লাগে)
  • ⚠️Global Query: "মোট কত ইউজার আছে?"—এই প্রশ্নের উত্তরের জন্য সব সার্ভারে কুয়েরি করে যোগ করতে হয়
  • ⚠️Rebalancing: একটি সার্ভার ভরে গেলে সেখান থেকে ডেটা অন্য সার্ভারে সরানো অনেক ঝামেলার

১৫.৮ Real-World Scaling Path (Senior Architect Guide)

আপনার স্টার্টআপ বড় হচ্ছে। কখন কোন স্টেপ নেবেন?

Level 1: Optimization — কুয়েরি অপটিমাইজেশন, ইনডেক্সিং ঠিক করা

Level 2: Caching — Redis বা Memcached ব্যবহার করা

Level 3: Read Replica — একটি Master (Write) এবং একাধিক Slave (Read) সার্ভার

Level 4: Partitioning — বড় টেবিলগুলোকে (যেমন লগ) ইয়ারলি পার্টিশন করা

Level 5: Sharding — যখন উপরের সব ফেইল করবে এবং ডেটা টেরাবাইটে পৌঁছাবে—শুধুমাত্র তখনই

১৫.৯ When to use Partitioning vs Sharding?

বৈশিষ্ট্যPartitioningSharding
কোথায় থাকে?একই সার্ভারে, একই ডিস্কেসম্পূর্ণ আলাদা ফিজিক্যাল সার্ভারে
উদ্দেশ্যকুয়েরি ফাস্ট করা, ম্যানেজমেন্ট সহজ করাস্টোরেজ এবং রাইট লোড ডিস্ট্রিবিউট করা
জটিলতাকম (MySQL নিজেই করে)অনেক বেশি (অ্যাপ লেভেলে লজিক লাগে)
JOINইজি (স্বাভাবিকভাবেই কাজ করে)কঠিন (ক্রস সার্ভার জয়েন সম্ভব না)

🎯 অধ্যায় ১৫ এর সারাংশ (Summary)

এই অধ্যায়ে আমরা শিখলাম:

  • ✓Partitioning: বিশাল টেবিলকে RANGE বা HASH দিয়ে ভাগ করে কুয়েরি ফাস্ট করা (Pruning)
  • ✓Drop Partition: সেকেন্ডের মধ্যে কোটি কোটি পুরোনো ডেটা ডিলিট করার টেকনিক
  • ✓Sharding: ডেটাকে একাধিক সার্ভারে ছড়িয়ে দিয়ে অসীম স্কেলিং করার উপায়
  • ✓Sharding Key: সঠিক কি বাছাই করা (user_id ভালো, timestamp খারাপ)
  • ✓Scaling Path: Optimization → Caching → Replica → Partitioning → Sharding

✨ আপনি এখন বিগ ডেটা হ্যান্ডেল করার জন্য মানসিকভাবে প্রস্তুত। পরবর্তী অধ্যায়ে আমরা শিখব Replication—যেখানে আমরা শিখব কীভাবে ডেটা কপি করে হাই অ্যাভেলেবিলিটি নিশ্চিত করা যায় (Master-Slave, Master-Master)।

প্রস্তুত তো? 🚀

🔒 কপিরাইট সুরক্ষিত কন্টেন্ট 🔒

কপি, স্ক্রিনশট, প্রিন্ট করা সম্পূর্ণ নিষিদ্ধ।