Brief #06 · Backend
Scaling PostgreSQL to 10M Users
Hard⏱ 20-30 ঘণ্টা
একটা Postgres কে ১০ লাখ থেকে ১ কোটি user পর্যন্ত নিয়ে যাও, ধাপে ধাপে: index, pooling, replica, partition, তারপর shard, প্রতিটা ধাপে benchmark সহ।
Outline free · tracking সহ বানাতে Pro লাগবে
SBriefTeam এর পক্ষ থেকে
আমাদের social app একটা মাত্র Postgres server এ চলে। ১০ লাখ user এ সব ঠিক ছিল; marketing কথা দিয়েছে আগামী বছর ১ কোটি হবে, আর রাত ৯টায় feed আসতে এখনই ৩ সেকেন্ড লাগে। কেউ 'আরো server দাও' বলার আগে সংখ্যা দিয়ে দেখাও, কোন পরিবর্তনে কতটা লাভ, আর sharding এর ঝামেলা আসলে কখন সার্থক।
যা বানাবে
- 1একটা script দিয়ে ১০ লাখ user, follow আর post বানাও, আর feed এর মতো একটা k6 বা pgbench workload লেখো (৯০% read, ১০% write)। Baseline হিসেবে p95 আর throughput লিখে রাখো।
- 2
pg_stat_statementsআরEXPLAIN ANALYZEদিয়ে ধীর query খোঁজো; ঠিক index দিয়ে (composite, partial, covering) সারাও, আর আগে-পরের plan দেখাও। - 3সামনে transaction mode এ PgBouncer বসাও, আর ২,০০০ client এ connection আর latency এর কী হয় দেখাও।
- 4দুইটা streaming read replica যোগ করো; read গুলো সেখানে পাঠাও, আর replication lag সামলাও যাতে user নিজের নতুন post সবসময় দেখে (read-your-writes)।
- 5Posts table কে মাস অনুযায়ী partition করো, তারপর ১ কোটি user এ গিয়ে user_id দিয়ে চারটা Postgres node এ shard করো একটা routing layer সহ, আর downtime ছাড়াই একটা shard এর data সরাও।
ধাপে ধাপে walkthrough
শেষ হবে যখন
- একটা ফলাফলের table: একই workload আর hardware এ প্রতিটা ধাপের পরে p95 আর throughput।
- গুরুত্বপূর্ণ পথের কোনো query বড় table এ sequential scan করে না।
- Primary বন্ধ করে একটা replica কে promote করলে কোনো commit হওয়া write হারায় না, আর কত সময় লাগলো মেপেছো।
- Shard সরানোর পুরো সময় app উত্তর দিতে থাকে, আর পরে একটা check নিশ্চিত করে row এর সংখ্যা মেলে।
আরো এগোতে চাইলে
- একই workload এ নিজের বানানো sharding এর সাথে Citus এর তুলনা করো।
- একটা hot shard খুঁজে বের করো (একজন celebrity user), আর সারাও।