Data Partitioning Strategies
- ●Partitioning হলো বড় data-কে ছোট ছোট manageable অংশে ভাগ করা, যাতে query দ্রুত ও scalable হয়।
- ●Horizontal partitioning row ভাগ করে, vertical partitioning column ভাগ করে।
- ●Partition key ভুল হলে hotspot তৈরি হয়—কিছু partition ভিড়, বাকিগুলো খালি।
সমস্যাটা কী?
তোমার একটা table আছে যেখানে ১০০ কোটি row—যেমন একটা social app-এর সব post। একটা single server-এ এত data রাখলে নানা সমস্যা: query ধীর হয়ে যায় (পুরো বিশাল table স্ক্যান করতে হয়), একটা machine-এর disk/RAM-এর সীমা ছাড়িয়ে যায়, আর backup/maintenance দুঃস্বপ্ন হয়।
সমাধান সহজ ধারণা থেকে আসে—এক জায়গায় সব না রেখে data-কে ছোট ছোট টুকরোয় ভাগ করে ফেলো। প্রতিটা টুকরো ছোট, দ্রুত, আর আলাদা আলাদা সামলানো যায়। এটাই partitioning। কিন্তু কীভাবে ভাগ করবে—সেই কৌশলই পুরো performance ঠিক করে দেয়।
মূল ধারণা
Partitioning হলো একটা বড় dataset বা table-কে ছোট, স্বাধীন অংশে (partition) ভাগ করার প্রক্রিয়া, যাতে প্রতিটা partition আলাদাভাবে দ্রুত query, store ও manage করা যায়।
দুটো মূল ধরন:
- Horizontal partitioning: row ভাগ করা। একই column structure, কিন্তু ভিন্ন row ভিন্ন partition-এ। যেমন—২০২৪ সালের order এক partition-এ, ২০২৫-এর অন্যটায়।
- Vertical partitioning: column ভাগ করা। একটা wide table-এর কিছু column এক জায়গায়, কম-ব্যবহৃত বড় column (যেমন profile picture blob) আলাদা জায়গায়।
বেশিরভাগ scaling আলোচনায় "partitioning" বলতে horizontal বোঝানো হয়।
কীভাবে কাজ করে
Horizontal partitioning-এ সিদ্ধান্ত নিতে হয়—কোন row কোন partition-এ যাবে, তা partition key অনুযায়ী। তিনটি প্রধান কৌশল:
Range Partitioning
Key-এর মান অনুযায়ী range-এ ভাগ। যেমন তারিখ দিয়ে:
Partition A: 2024-01 থেকে 2024-06
Partition B: 2024-07 থেকে 2024-12
range query (যেমন "জুলাই মাসের সব order") খুব দ্রুত, কারণ একটা partition-এই সব আছে। কিন্তু সর্বশেষ মাসে নতুন data বেশি ঢুকলে সেই partition-এ hotspot হয়।
Hash Partitioning
Key-কে একটা hash function-এ দিয়ে ফলাফল অনুযায়ী partition বাছা হয়:
partition = hash(user_id) % number_of_partitions
data সমানভাবে ছড়িয়ে পড়ে—hotspot কম। কিন্তু range query কঠিন, কারণ কাছাকাছি key ভিন্ন partition-এ চলে যায়।
List Partitioning
নির্দিষ্ট মানের তালিকা অনুযায়ী ভাগ। যেমন region দিয়ে:
Partition Dhaka: city IN (Dhaka, Gazipur)
Partition Chattogram: city IN (Chattogram, Cox's Bazar)
যখন data-র স্পষ্ট category আছে তখন কার্যকর।
তুলনামূলক টেবিল
| কৌশল | বিতরণ | Range query | Hotspot ঝুঁকি |
|---|---|---|---|
| Range | অসমান হতে পারে | দ্রুত | বেশি |
| Hash | সমান | ধীর | কম |
| List | category-ভিত্তিক | মাঝারি | category-নির্ভর |
চিত্রকল্প
ভাবো একটা বিশাল লাইব্রেরিতে লক্ষ লক্ষ বই এক ঘরে গাদাগাদি—খুঁজে পাওয়া অসম্ভব। তাই বইগুলো ভাগ করতে হবে।
Range partitioning: লেখকের নামের প্রথম অক্ষর দিয়ে—A-F এক কক্ষে, G-M আরেক কক্ষে। "R" দিয়ে শুরু সব বই খুঁজতে এক কক্ষেই যাও (দ্রুত), কিন্তু জনপ্রিয় অক্ষরের কক্ষ উপচে পড়ে।
Hash partitioning: প্রতিটা বইয়ের ISBN-কে একটা সূত্রে ফেলে কক্ষ ঠিক করা—সব কক্ষে সমান বই (balanced), কিন্তু "R দিয়ে শুরু" সব বই খুঁজতে গেলে সব কক্ষে দৌড়াতে হবে।
কৌশল: partition key বাছাই
সবচেয়ে গুরুত্বপূর্ণ সিদ্ধান্ত হলো partition key বাছা। ভালো key-এর গুণ:
- High cardinality: অনেক ভিন্ন মান থাকা (যেমন
user_id), যাতে সমানভাবে ভাগ হয়। - সমান বিতরণ: কোনো একটা মানে সব data না জমে।
- Query pattern-এর সাথে মিল: যে column দিয়ে বেশি filter করো, সেটাই key হলে query এক partition-এ সীমিত থাকে।
খারাপ উদাহরণ—country দিয়ে partition করলে যদি ৮০% ইউজার বাংলাদেশের হয়, তাহলে একটা partition বিশাল আর বাকিগুলো খালি (hotspot)।
Sharding-এর সাথে সম্পর্ক
Partitioning আর sharding ঘনিষ্ঠ। Partitioning সাধারণত একটা single database-এর ভিতরে (logical) ভাগ। Sharding হলো সেই partition-গুলোকে একাধিক আলাদা server/node জুড়ে ছড়ানো—অর্থাৎ distributed horizontal partitioning। Sharding শুধু query speed না, পুরো load ও storage একাধিক machine-এ ভাগ করে দেয়।
কখন ব্যবহার করবে / করবে না
- ব্যবহার করো: table বিশাল (কোটি কোটি row), single server-এ আঁটছে না, query ধীর, বা data-র লজিক্যাল ভাগ আছে (যেমন সময় বা region)।
- করবে না: data ছোট হলে partitioning শুধু জটিলতা বাড়ায়। আগে index ও query optimization চেষ্টা করো।
ভুল partition key বেছে hotspot তৈরি করা সবচেয়ে সাধারণ ভুল। যেমন timestamp দিয়ে partition করলে সব নতুন write সর্বশেষ partition-এ পড়ে—একটা partition গরম, বাকিগুলো ঠান্ডা। ফলে scale করেও লাভ নেই, কারণ একটা node-ই সব চাপ নিচ্ছে। key বাছার আগে data distribution আর query pattern ভালো করে দেখো।
বাস্তব উদাহরণ
একটা messaging অ্যাপ তাদের বিশাল messages table chat_id দিয়ে hash partition করল একাধিক shard-এ। কারণ chat_id-র cardinality বিশাল ও write সমানভাবে ছড়ায়, ফলে কোনো একটা shard hotspot হয় না। আবার একই chat-এর সব message একই shard-এ থাকে বলে chat history query দ্রুত হয়। অন্যদিকে তাদের analytics_events table range partition করল তারিখ দিয়ে—পুরোনো partition সহজে আর্কাইভ/মুছে ফেলা যায়।
ইন্টারভিউতে partition key জিজ্ঞেস করলে দুটো জিনিস বলো: "key-টা high-cardinality আর সমান বিতরণযোগ্য হতে হবে যাতে hotspot না হয়, এবং আমার মূল query pattern-এর সাথে মিলতে হবে যাতে query এক partition-এ সীমিত থাকে।" এই দুই শর্ত মেলালে partitioning সফল।
মূল শব্দ (Key Terms)
মিনি কুইজ
1. Horizontal partitioning কী ভাগ করে?
2. Hash partitioning-এর প্রধান সুবিধা কী?
3. Sharding আর partitioning-এর সম্পর্ক কী?