Partitioning ও Sharding: ডেটা ভাগ করার নকশা
Partitioning, Sharding, and Shard Keys
এই পাঠের সূচিপত্র
এই পাঠে যা শিখবেন
- Partitioning বনাম application sharding
- Shard key, routing ও skew
- Tenant directory এবং migration boundary
সমস্যা দিয়ে শুরু
Orders table বড় হওয়ায় team “shard করি” বলছে। কিন্তু slow query-এর index নেই। Sharding maintenance ও cross-shard query কঠিন করে; প্রথমে query, retention ও partition pruning দিয়ে requirement মেটে কি না দেখা উচিত। সত্যিই single write/storage boundary অতিক্রম করলে shard design দরকার হতে পারে।
সহজ করে বুঝি
Partitioning একটি logical table-এর data ভাগ করে; database engine একই cluster-এ partitions manage করতে পারে। Sharding data বহু independently managed database/node-এ ভাগ করে। Shard key query routing ও data distribution নির্ধারণ করে। tenant_id locality দেয় কিন্তু বড় tenant hotspot হতে পারে। Time range retention সহজ করে, current partition hot হতে পারে। Hash distribution balanced হতে পারে, range query fan-out বাড়ে। Cross-shard join/transaction সাধারণ local operation-এর চেয়ে জটিল।
পরিচিত একটি উপমা
এক গুদামের numbered shelf partition, ভিন্ন শহরের warehouse shard। একটি দোকানের সব পণ্য এক warehouse-এ রাখলে lookup সহজ, কিন্তু সেই দোকান বড় হলে একটি warehouse overloaded হতে পারে। Transfer-এর সময় কোন warehouse authoritative তা খাতায় লিখতে হয়।
নকশাটি দেখুন
Diagram লোড হচ্ছে…
Diagram-এর text flow দেখুন
flowchart TD R[Authenticated tenant request] --> D[(Tenant shard directory)] D --> A[Allowlisted connection A] D --> B[Allowlisted connection B] A --> S1[(Shard 1 tenant subset)] B --> S2[(Shard 2 tenant subset)]
Request-এর tenant identity verified membership থেকে আসে। Directory current shard ownership জানায়। Connection নাম fixed allowlist-এ যাচাই হয়, user arbitrary database host দিতে পারে না। Tenant migration-এ directory switch-এর আগে data catch-up ও write routing plan দরকার। একসঙ্গে দুই shard-এ write authority ছড়ালে duplicates বা divergence হতে পারে।
PHP ও Laravel-এ প্রয়োগ
Service fragment; authenticated tenant resolver membership verify করেছে এবং trusted directory connectionName দিয়েছে। Laravel config/database.php-এ shard_a/shard_b configure করা আছে। একই schema প্রতিটি shard-এ আছে ধরে নেওয়া হয়েছে। Query tenant filterও রাখে যাতে shared shard-এর অন্য tenant leak না হয়।
use Illuminate\Support\Facades\DB;
$allowed = ['shard_a', 'shard_b'];
abort_unless(in_array($connectionName, $allowed, true), 503);
$orders = DB::connection($connectionName)->table('orders')
->where('tenant_id', $tenant->id)
->orderByDesc('id')
->limit(20)
->get(['id', 'status', 'created_at']);
return response()->json(['data' => $orders]);সুবিধা, সীমাবদ্ধতা ও trade-off
Sharding write/storage capacity ভাগ করতে পারে এবং failure blast radius কিছুটা সীমিত করে। Routing, rebalancing, schema migration, backup ও global uniqueness জটিল হয়। Cross-tenant reporting আলাদা analytics pipeline-এ নেওয়া লাগতে পারে। Simple modulo shard count change অনেক key remap করে; directory বা stable assignment migration control সহজ করতে পারে। Shared infrastructure-এর failure isolation বাস্তব deployment অনুযায়ী বিচার করুন।
সাধারণ ভুল
- Shard key ছাড়া API design করে পরে সব query fan-out করা।
- Raw user input দিয়ে connection নাম/host নির্বাচন।
- Local numeric ID-কে global unique ধরে নেওয়া।
আরও একটু গভীরে
Global ID UUID/ULID বা composed identity হতে পারে; sortable ID থাকলেও authorization দরকার। Tenant move-এ backfill, change capture, validation, cutover ও rollback phases plan করুন। Dual-write gap atomic transaction নয়। One hot tenant নিজেই shard capacity ছাড়ালে sub-sharding লাগতে পারে, যা locality assumption বদলায়। Directory availability ও cache invalidation routing correctness-এর critical dependency।
মনে রাখুন
Sharding distribution-এর পাশাপাশি ownership problem। Query locality ও skew আগে বোঝুন। Directory, migration এবং global operation-এর খরচ ছাড়া shard decision অসম্পূর্ণ।
নিজে চেষ্টা করুন
Three tenant-এর data size ১, ২ ও ১০০ units ধরে দুই shard assignment করুন। Hash ও explicit directory-এর trade-off তুলনা করুন। বড় tenant move করার সময় active write কীভাবে consistent রাখবেন high-level timeline লিখুন।
নিজের বোঝা যাচাই করুন
1. Partition আর shard একই?
সম্পর্কিত data division হলেও operational boundary আলাদা হতে পারে। Engine-managed table partition আর independent databases routing এক complexity নয়।
2. Tenant key সেরা?
Locality ভালো, কিন্তু unequal tenant size hotspot তৈরি করতে পারে। Data ও traffic distribution দিয়ে বিচার করুন।
3. Cross-shard transaction সহজ?
এক local transaction-এর মতো নয়। Distributed transaction বা business workflow/Saga লাগতে পারে, product support অনুযায়ী।
4. Directory কেন?
Current ownership explicit রাখে এবং controlled tenant move করতে সাহায্য করে। তবে directory availability ও stale routing নতুন concern।
5. ID থাকলেই query safe?
না। Shard routing-এর পরেও tenant/user authorization filter লাগবে। Numeric ID অন্য shard-এ duplicate হতে পারে।
আরও পড়ুন
এই পাঠের কুইজ
এই পাঠ থেকে ২টি প্রশ্ন। উত্তর দিয়ে ব্যাখ্যা দেখুন; অধ্যায়ের কুইজ আলাদাভাবে দিতে হবে।
এই পাঠের ২টি প্রশ্নের উত্তর দিন। পাস করতে দুটিই সঠিক হতে হবে।
জমা দেওয়ার পর সঠিক উত্তর ও ব্যাখ্যা দেখবেন। ফলাফল এই ব্রাউজারে সংরক্ষিত থাকবে। অনুশীলনের ফল অধ্যায় সম্পন্নের হিসাবে যোগ হয় না।
অগ্রগতি এই ব্রাউজারে সংরক্ষিত থাকে। শুধু পাঠ খুললে সম্পন্ন হয় না।