Connections, Migrations, နှင့် Backups

နားလည်ထားရမယ့် အချက်

Database connection အသစ်တစ်ခု ဖွင့်တာက အလကား မဟုတ်ပါဘူး — တစ်ခုစီက memory နဲ့ setup time ကုန်ကျစေပြီး busy ဖြစ်နေတဲ့ application တစ်ခုက database တစ်ခုတည်း တစ်ပြိုင်နက် ကိုင်နိုင်တာထက် ပိုများတဲ့ connection ကို ဖွင့်ဖို့ ကြိုးစားနိုင်ပါတယ်။

Connection pooling က request များစွာအတွက် ကန့်သတ်ထားသော၊ ပြန်လည်အသုံးချနိုင်တဲ့ connection set တစ်ခုကို မျှဝေပေးပါတယ်။ Serverless architecture တွေအတွက် ဒါက ပိုအရေးကြီးပါတယ်၊ ဒါမဟုတ်ရင် ရေတိုသက်တမ်း function instance များစွာက ကိုယ်ပိုင် connection ကို တစ်ပြိုင်နက် ဖွင့်ဖို့ ကြိုးစားနိုင်လို့ပါ။

Replication က availability, read scaling, disaster recovery ကို support ပေးပေမယ့် backup ရဲ့ အစားထိုးတစ်ခု မဟုတ်ပါဘူး — mistake တစ်ခုကလည်း replicate ဖြစ်သွားနိုင်ပါတယ်။ Scaling ကို ကျယ်ပြန့်စွာ ကြည့်ရင် vertical scaling, read replica, caching, partitioning/sharding တို့ ပါဝင်ပါတယ်။

CONNECTION POOL AND MIGRATION FLOW
----------------------------------
MANY REQUESTS          CONNECTION POOL         DATABASE
   req 1  ---\
   req 2  ----\      +-----------------+
   req 3  -----+----> | limited, reused |------> [ DB ]
   req 4  ----/       | connections     |
   req 5  ---/        +-----------------+
   (some requests wait briefly for a free connection)

MIGRATION FLOW
--------------
  Create -> Review -> Backup -> Apply -> Verify
  (never hand-edit schema directly against production)

လက်တွေ့ scenario နဲ့ ချိတ်ကြည့်မယ်

Connection pooling ကို application နဲ့ database ကြားမှာ ရှိတဲ့ pooler library (သို့) managed proxy တစ်ခုက ကိုင်တွယ်လေ့ရှိပါတယ်၊ ကိုယ်တိုင် တည်ဆောက်ရတာ မဟုတ်ပါဘူး။ Discipline ကတော့ pool size ကို ကျိုးကြောင်းဆီလျော်စွာ သတ်မှတ်ဖို့ပါ။

Migration သေးငယ်ပုံပေါက်လို့ review (သို့) backup အဆင့်ကို ဘယ်တော့မှ မကျော်သင့်ပါဘူး — migration သေးငယ်တာတွေကပဲ သတိထားမှုနည်းသွားစေတတ်ပါတယ်။ Seed data ကလည်း user record အစစ်နဲ့ ခွဲထားတဲ့ label တပ် script ထဲမှာ ရှိသင့်ပါတယ်။

• Migration နှင့် pooling configuration လက်တွေ့အတွက်: PostgreSQL ရဲ့ safe-schema-migrations နှင့် connections-pooling-and-security lesson များ။
• Replication နှင့် high availability လက်တွေ့အတွက်: Redis ရဲ့ replication နှင့် sentinel-high-availability lesson များ။

• Connection pooling က ကန့်သတ်ထားတဲ့ ပြန်သုံးနိုင်သော connection set ကို request များစွာအတွက် မျှဝေပေးပြီး database ကို ရေလွှမ်းစေခြင်းမှ ကာကွယ်ပေးပါတယ်။
• Migration တွေကို ဖန်တီး၊ review, backup, apply, verify အစီအစဉ်အတိုင်း လုပ်သင့်ပြီး production ပေါ်တိုက်ရိုက် လက်နဲ့ ပြင်ဆင်ခြင်း လုံးဝ မလုပ်သင့်ပါ။
• Restore ကို တကယ်စမ်းမမှသာ backup က hypothesis တစ်ခုမက ဖြစ်လာပါတယ်၊ replication က availability ကို support ပေးပေမယ့် backup ကို အစားမထိုးနိုင်ပါ။

အတူတူ စမ်းရေးကြည့်မယ်

// Simplified simulation of a connection pool: only `poolSize` requests can
// hold a connection at once. Everyone else has to wait for one to free up.
function simulateConnectionPool(poolSize, requestCount) {
  const immediate = Math.min(poolSize, requestCount);
  const waiting = Math.max(0, requestCount - poolSize);
  return { poolSize, requestCount, immediate, waiting };
}

console.log(simulateConnectionPool(10, 8));
console.log(simulateConnectionPool(10, 45));

Pool size 10 နဲ့ request 8 ခု ဝင်လာရင် 8 ခုလုံး ချက်ချင်း connection ရပြီး 0 ခု စောင့်ရပါတယ်။ Pool size 10 အတူတူနဲ့ request 45 ခု ဝင်လာရင် 10 ခုသာ ချက်ချင်း connection ရပြီး 35 ခု စောင့်ရပါတယ် — traffic က pool size ထက် ကျော်လွန်သွားတဲ့အခါ request တစ်ခုချင်းစီအတွက် ကန့်သတ်ချက်မရှိဘဲ connection ဖွင့်တဲ့ application တစ်ခုက database ကို ဘာကြောင့် လျင်မြန်စွာ လွှမ်းမိုးနိုင်တာလဲဆိုတာ အတိအကျ ပြသထားပါတယ်။

Wikipedia: Connection pool — How Databases Work