Question 1

آپ کسی زندہ ڈیٹابیس کو بندش کے بغیر کیسے منتقل کرتے ہیں؟

Accepted Answer

تبدیلی کو ایک ہی سوئچ کے بجائے الٹنے کے قابل اور بتدریج بنا کر۔ معیاری طریقہ expand-and-contract ہے: پرانے کے ساتھ نیا کالم، میز یا ڈیٹابیس بنائیں، دونوں جگہ لکھیں، پرانی سطریں ایسے بیچوں میں بھریں جو میز کو مقفل نہ کریں، ڈیٹا کی تصدیق کے بعد پڑھنا منتقل کریں، اور پھر کسی بعد کی ریلیز میں پرانی ساخت ہٹا دیں۔ بالکل صفر بندش آپ کے stack اور پابندیوں پر منحصر ہے، اس لیے ہم صفر کا وعدہ کر کے رات دو بجے حقیقت دریافت کرنے کے بجائے ایک حقیقت پسند مختصر cutover وقفہ بتاتے ہیں۔

Question 2

کیا بہتری سے کچھ خراب ہو سکتا ہے؟

Accepted Answer

index اور کوئری کا کام عموماً کم خطرے کا ہوتا ہے بشرطیکہ تبدیلیوں کا جائزہ لیا جائے اور انہیں ایک ایک کر کے لگایا جائے، مگر حقیقی خطرات موجود ہیں: بڑی میز پر index بناتے ہوئے غلط طریقہ لکھنے کو مقفل کر سکتا ہے، اور NULL یا نقل شدہ اقدار کی موجودگی میں کوئری کی دوبارہ تحریر نتائج کو باریک انداز میں بدل سکتی ہے۔ ہم پروڈکشن جتنے ڈیٹا کی نقل پر آزماتے ہیں، جہاں انجن اجازت دے وہاں index کو concurrently بناتے ہیں، اور برابری فرض کرنے کے بجائے کوئری کے نتائج پہلے اور بعد میں ملاتے ہیں۔

Question 3

کیا آپ کو ہمارے پروڈکشن ڈیٹابیس تک رسائی درکار ہوگی؟

Accepted Answer

تشخیص کے لیے ہمیں عام اندازے سے کہیں کم درکار ہوتا ہے — execution plan، سست کوئریز کے لاگ، schema کی تعریفیں اور میز کے اعدادوشمار اکثر کافی ہوتے ہیں، اور ان میں سے کسی کے لیے گاہکوں کے ریکارڈ پڑھنا ضروری نہیں۔ جہاں براہِ راست رسائی واقعی ضروری ہو، وہاں ہم ایک نامزد صرف پڑھنے والے رول کے ذریعے کام کرتے ہیں، اور ذاتی ڈیٹا سے متعلق کسی بھی کام کے لیے ماسک شدہ یا محدود نقل کو ترجیح دیتے ہیں۔ پروڈکشن پر لکھنے کی اجازت مستقل نہیں بلکہ کسی مخصوص migration کے وقفے کے لیے دی جاتی ہے۔

Question 4

ہماری ٹریفک نہیں بڑھی مگر ہوسٹنگ بل بڑھتا جا رہا ہے، کیوں؟

Accepted Answer

منیجڈ Postgres پلیٹ فارموں پر ڈیٹا ٹرانسفر اور اسٹوریج کا بل اکثر compute سے الگ ہوتا ہے، اور ایسی ایپلیکیشن جو تین کالموں کی ضرورت پر پوری میز پڑھ لے، یا ہر درخواست پر وہی سطریں دوبارہ منگوائے، اپنی ٹریفک کے مقابلے میں کہیں زیادہ ٹرانسفر پیدا کرتی ہے۔ ہم اپنے ہی پلیٹ فارم پر بالکل یہی مسئلہ پکڑا اور اسے پوری میز پڑھنے کے بجائے محدود کالم منتخب کر کے، اندراج کو بیچ میں بدل کر، فی سطر آنے جانے کو مجموعی SQL میں لا کر اور سوچے سمجھے invalidation والی کیشنگ کی سطح لگا کر کم کیا۔

Question 5

serverless پر جانے کے بعد کنکشن کی حد کے ایرر کیوں آ رہے ہیں؟

Accepted Answer

serverless فنکشنز افقی طور پر پھیلتے ہیں اور ہر instance اپنے کنکشن رکھ سکتا ہے، اس لیے جو پلیٹ فارم ایک طویل مدتی ایپلیکیشن سرور کو آرام سے سنبھال لیتا تھا وہ اپنی کنکشن کی حد جلد ختم کر دیتا ہے۔ حل یہ ہے کہ درست جگہ پر connection pooler رکھا جائے، کلائنٹ اسی کے مطابق ترتیب دیا جائے، ٹرانزیکشن مختصر رکھی جائیں، اور جس کام کو زندہ کنکشن کی ضرورت نہیں اسے درخواست کے راستے سے باہر نکالا جائے۔ یہ گنجائش کا نہیں بلکہ ڈیزائن کا مسئلہ ہے، اور بڑا instance خریدنے سے شاذ ہی حل ہوتا ہے۔

Question 6

آپ normalisation اور denormalisation میں سے کس کا انتخاب کیسے کرتے ہیں؟

Accepted Answer

اس بنیاد پر کہ ڈیٹا کو کیا ضمانت دینی ہے اور اسے پڑھا کیسے جاتا ہے۔ normalisation متضاد ڈیٹا کو روکتی ہے اور ہر لین دین والے نظام کے لیے درست ڈیفالٹ ہے؛ denormalisation کارکردگی کا ایک سوچا سمجھا فیصلہ ہے جس کی قیمت آپ اپ ڈیٹ کی پیچیدگی اور ڈیٹا کے بہک جانے کے خطرے کی صورت میں ادا کرتے ہیں۔ ہم وہیں denormalise کرتے ہیں جہاں کسی مصروف راستے پر join کا مہنگا ہونا ثابت ہو، اخذ شدہ ڈیٹا کو ڈیٹابیس یا کسی ایک ہی کوڈ راستے سے برقرار رکھتے ہیں، اور وجہ لکھ دیتے ہیں تاکہ کوئی غلطی سے اسے واپس نہ کر دے۔

Question 7

آپ غائب index کیسے تلاش کرتے ہیں؟

Accepted Answer

اندازے کے بجائے اصل بوجھ دیکھ کر: سست کوئریز کے لاگ، بڑی میزوں پر sequential scan دکھاتے execution plan، اور index کے استعمال کے اعدادوشمار جو غیر استعمال شدہ index اور بغیر index والی مصروف میزیں دونوں سامنے لے آتے ہیں۔ composite index میں کالموں کی ترتیب اتنی ہی اہم ہے جتنا یہ کہ کون سے کالم شامل ہیں، اور filter والی کوئریز کے لیے partial index اکثر وسیع index سے بہتر کارکردگی دیتے ہیں۔ ہم لکھنے کی طرف بھی دیکھتے ہیں، کیونکہ ہر index اندراج اور اپ ڈیٹ کو مہنگا کرتا ہے۔

Question 8

اگر ہم آپ کے ساتھ کام بند کر دیں تو ہمارے ڈیٹا کا کیا بنے گا؟

Accepted Answer

وہ وہیں رہتا ہے جہاں ہمیشہ تھا — آپ کے ڈیٹابیس میں، آپ کے اکاؤنٹ کے تحت۔ ہم کلائنٹ کا پروڈکشن ڈیٹا اپنی ملکیت کے انفراسٹرکچر پر نہیں رکھتے جب تک آپ خود ایسا نہ کہیں، اور معاہدہ ختم ہونے کے بعد طے شدہ حوالگی کے لیے درکار حد سے زیادہ کوئی نقل اپنے پاس نہیں رکھتے۔ آپ کو schema کی دستاویز، migration کی تاریخ، index کے پیچھے کی دلیل اور بحالی کا طریقہ کار ملتا ہے، اور ہم آپ کے اگلے فراہم کنندہ کو بریفنگ بھی دے سکتے ہیں۔

Question 9

کیا آپ ہمارے موجودہ ہوسٹنگ اور ڈیٹابیس فراہم کنندہ کے ساتھ کام کر سکتے ہیں؟

Accepted Answer

جی ہاں۔ ہم Neon جیسے منیجڈ PostgreSQL اور اس جیسے دیگر فراہم کنندگان کے ساتھ، روایتی ہوسٹنگ پر MySQL کے ساتھ، اور VPS پر خود سنبھالے گئے instances کے ساتھ باقاعدگی سے کام کرتے ہیں، اور آغاز کے لیے پلیٹ فارم بدلنے کی شرط نہیں رکھتے۔ اگر موجودہ پلیٹ فارم واقعی رکاوٹ ہو — نہ point-in-time recovery، نہ read replica کا اختیار، یا ایسا ورژن جس کی سپورٹ ختم ہو چکی ہو — تو ہم محض دعویٰ کرنے کے بجائے وجہ لکھ کر بتائیں گے اور متبادل کی قیمت بھی دیں گے۔

Question 10

بیک اپ اور point-in-time recovery کیسے سنبھالے جاتے ہیں؟

Accepted Answer

ہم پہلے یہ طے کرتے ہیں کہ ڈیٹا کے ضیاع کی کتنی مدت اور بحالی کا کتنا وقت قابلِ قبول ہے، کیونکہ باقی سب کچھ انہی دو اعداد سے طے ہوتا ہے، پھر بیک اپ اور مدتِ حفاظت اسی کے مطابق ترتیب دے کر ایک الگ ماحول میں اصل ریسٹور سے ان کی تصدیق کرتے ہیں۔ ہم یہ بھی لکھ کر رکھتے ہیں کہ بحالی کون شروع کر سکتا ہے اور آپ کے ڈیٹا کے حجم پر مکمل ریسٹور میں عملاً کتنا وقت لگتا ہے، کیونکہ یہ پیمائش اگر پہلی بار کسی حادثے کے دوران لی جائے تو بے کار ہے۔

Question 11

کیا آپ کثیر کرایہ دار ڈیٹا کی علیحدگی سنبھالتے ہیں؟

Accepted Answer

جی ہاں، اور ہم اسے کوڈنگ کے نظم و ضبط کے بجائے schema کا معاملہ سمجھتے ہیں۔ ہر کرایہ دار سے متعلق میز میں tenant کی کلید ہوتی ہے، رسائی ایسی کوئریز سے گزرتی ہے جو اسے چھوڑ ہی نہیں سکتیں، اور row-level security یہ حد ہر ڈویلپر کے WHERE یاد رکھنے پر نہیں بلکہ ڈیٹابیس کی سطح پر نافذ کرتی ہے۔ ہم نے یہی طریقہ ikas اسٹورز کے لیے بنائے گئے ایک کثیر کرایہ دار AI سپورٹ پلیٹ فارم میں شامل کیا، جس میں فی کرایہ دار استعمال اور لاگت کی نگرانی بھی شامل تھی۔

ہم کیسے مدد کر سکتے ہیں؟

ڈیٹابیس خدمات
عمومی سوالات

مددگار
معلومات

شروع کرنا

ٹائم لائن

قیمتیں

سپورٹ

ابھی بھی سوالات ہیں؟

ڈیٹابیس خدماتعمومی سوالات

مددگارمعلومات