1 ارب سے زیادہ ChatGPT صارفین کے لیے آن لائن اسٹوریج کی تیز توسیع

OpenAI کا ہر پروڈکٹ ڈیٹا تک تیز اور قابل اعتماد رسائی پر منحصر ہے، خواہ کوئی لاگ ان کرے، Codex کی ترتیبات دیکھے یا ChatGPT میں نئی گفتگو شروع کرے. پروڈکٹ کے جواب دینے سے پہلے ان میں سے ہر عمل کے لیے الگ الگ کئی ڈیٹا تلاشیں درکار ہو سکتی ہیں. اگر یہ درخواستیں سست ہوں تو پروڈکٹ بھی سست محسوس ہوتا ہے. اگر یہ درخواستیں ناکام ہوں تو پروڈکٹ مکمل طور پر کام کرنا بند کر دیتا ہے.

Habitat وہ آن لائن اسٹوریج پلیٹ فارم ہے جو ہم نے بنایا تاکہ OpenAI کے پروڈکٹس مطلوبہ معلومات تک تیزی اور اعتماد سے رسائی حاصل کر سکیں. Habitat اب تقریباً 40 جغرافیائی خطوں میں ہر سیکنڈ 7 کروڑ سے زیادہ درخواستیں سنبھالتا ہے اور ہر ہفتے 1 ارب سے زیادہ افراد کے زیر استعمال پروڈکٹس کو سہارا دیتا ہے. Habitat پہلی بار DevDay 2023 میں GPTs کی معاونت کے لیے متعارف ہوا، ابتدا میں یہ ایک ڈیٹابیس سے منسلک سادہ Python کلائنٹ لائبریری تھا. آج یہ ایک پیچیدہ تقسیم شدہ نظام ہے جو 500 پیٹابائٹ سے زیادہ ڈیٹا فراہم کرتا ہے.

اس پیمانے کا بنیادی ڈھانچا بنانا اور چلانا آسان نہیں، مگر بذات خود غیر معمولی مشکل بھی نہیں. ہماری صورت حال کو منفرد بنانے والی چیز وہ بے مثال رفتار تھی جس سے ہمیں حیرت انگیز صارف نمو اور پروڈکٹ طلب سنبھالنے کے ساتھ ایک پختہ پلیٹ فارم بھی بنانا پڑا. نظام کے انجینئر عموماً 10 گنا پیمانے کے لیے بناتے ہیں اور اگلے 10 گنا کی تیاری کے دوران امید رکھتے ہیں کہ یہ چند سال چل جائے گا. ہمارے معاملے میں گزشتہ تین برس سے ہر سال نمو 10 گنا سے زیادہ رہی ہے. اسی لیے Habitat کی تعمیر اور کارروائی عملی فیصلوں اور درست ترتیب کا سلسلہ رہی: ہر جز کو بنیادی سطح تک سمجھ کر موجودہ نظام سے زیادہ سے زیادہ فائدہ لینا، اور بنیادی سرمایہ کاری کے لیے وقت حاصل کرنے کو اسٹوریج و کمپیوٹ صلاحیت کی قلت سے نمٹنا.

OpenAI کے ساتھ Habitat کو بھی بڑھنا پڑا: پہلے اہم پروڈکٹ ٹریفک کے لیے قابل اعتماد، پھر عالمی صارفین کے لیے تیز، اور آخر میں بہت بڑے پیمانے پر مؤثر طور پر قابل عمل بننا پڑا. یہ آن لائن اسٹوریج کی توسیع پر دو حصوں کی سیریز کی پہلی تحریر ہے. اس تحریر میں ہم بتائیں گے کہ Habitat کیسے بدلا، اسے لائبریری سے سروس کیوں بنایا، اور سروسنگ میں کم استعمال ہونے والی Python زبان میں لکھی سروس کو قابل اعتماد اسٹوریج پلیٹ فارم کی تہہ کیسے بنایا.

آئندہ تحریر میں ہم بڑے پیمانے پر کثیر کرایہ داری کو قابل اعتماد بنانے، مطالعہ کی کارکردگی بہتر کرنے کی تہہ دار حکمت عملی، اور بے مثال طلب کو قابل اعتماد طور پر سنبھالنے کے لیے Azure Cosmos DB کے ساتھ شراکت بڑھانے کی تفصیل دیں گے.

Habitat ایک سادہ خیال سے شروع ہوا: پروڈکٹ انجینئرز کو ڈیٹابیس انتظام کے بارے میں سوچنے کی ضرورت نہیں ہونی چاہیے. Habitat پہلی بار DevDay 2023 میں GPTs کی معاونت کے لیے ایک چھوٹی Python لائبریری کے طور پر متعارف ہوا جو ChatGPT کے مرکزی سرور سے تعامل کرتی تھی. یہ چند کارروائیوں کی معاونت کرتا تھا جو پس منظر میں ڈیٹابیس ایپلیکیشن Azure Cosmos DB سے منسلک تھیں.

لائبریری کا کام پروڈکٹ ٹیموں کو بنیادی تفصیلات میں مہارت حاصل کیے بغیر ڈیٹا محفوظ اور حاصل کرنے کا آسان طریقہ دینا تھا. Habitat ضروری کام سنبھالتا تھا: ڈیٹا کی قسم، اس کا ماخذ یا منزل، درخواست کی اجازت اور دیگر امور کا تعین.

پروڈکٹ انجینئرز کو اسکیما تلاش، روٹنگ، اجازت، انکرپشن، سیریلائزیشن، درخواست کی تشکیل اور کنکشن پولنگ کی فکر نہیں کرنی پڑتی. انہیں یہ بھی سوچنے کی ضرورت نہیں تھی کہ ڈیٹا Azure Cosmos DB، کیش یا کسی اور اسٹوریج سے آتا ہے.

یہ Python لائبریری اچھی چلی اور خودکار Postgres و Azure Cosmos DB سے دور جانے کی کسی مرکزی مہم کے بغیر بھی OpenAI کے پروڈکٹ انجینئرز نے Habitat کو تیزی سے اپنایا.

پروڈکٹ ضروریات بدلنے پر ڈویلپرز کے لیے مشترکہ لائبریری میں کلائنٹ سائیڈ کیشنگ، کمپریشن یا انکرپشن جیسی خصوصیات کی معاونت شامل کرنا بھی آسان تھا.

2025 کے وسط تک Habitat بطور کلائنٹ سائیڈ نفاذ اپنی حدود کو پہنچ چکا تھا. Habitat کی تہہ پیچیدہ اور OpenAI کی سروسز کی تعداد بڑھنے کے ساتھ سابقہ نسخوں سے ہم آہنگ پروٹوکول تبدیلیاں ناقابل عمل ہو گئی تھیں.

ایک موقع پر ہم اپنے اہم ترین ڈیٹا سیٹس کو علاقائی طور پر تقسیم شدہ Azure Cosmos DB اکاؤنٹس میں منتقل کر کے کسی ایک خطے کی بندش کا اثر محدود کرنا چاہتے تھے. اس تبدیلی کے لیے کلائنٹ میں اضافی روٹنگ منطق شامل کرنا، اسے فیچر فلیگ کے پیچھے غیر فعال رکھنا، تمام کلائنٹس تک پہنچانا اور پھر فلیگ فعال کرنا ضروری تھا.

درجنوں سروسز میں تعیناتیوں کی ہم آہنگی اور ہر ٹیم کے ساتھ اجرا میں کئی دن لگے. اسے فعال کرنے سے پہلے ہمیں احساس ہوا کہ شارڈنگ منطق درست ہونے کی یقین دہانی کے لیے کچھ درخواست شیڈونگ بھی شامل کرنی چاہیے. اس کے اجرا میں مزید دو دن لگے. پھر معلوم ہونے والی خرابی کی اصلاح؟ مزید دو دن. آخرکار ہم فلیگ فعال کرنے کو تیار ہوئے، مگر ایک ٹیم نے غیر متعلقہ وجہ سے اپنی سروس کو پہلے کے ناقص کلائنٹ پر واپس کر دیا، جس سے وہی بندش ہوئی جس سے بچنے کے لیے ہم نے اتنی محنت کی تھی.

کلائنٹ لائبریری کی تبدیلیوں کے لیے درجنوں سروسز میں پیچیدہ ہم آہنگی درکار تھی، اور یہ عمل مسلسل نازک، غیر مؤثر اور عملی ناکامیوں کا شکار ہوتا گیا. آئندہ تعیناتیوں میں اس عملی پھیلاؤ کو کم کرنے کے لیے ہم نے Habitat کو الگ سروس بنانے کا فیصلہ کیا.

اسٹوریج منطق کو خود مختار سروس میں الگ کر کے ہم نے تعیناتی، مشاہدہ پذیری اور پلیٹ فارم بہتری کے لیے واحد مرکزِ اختیار قائم کیا. بکھری ہوئی تازہ کاریوں کے بجائے ہم بہتریاں مرکزی طور پر نافذ کر کے ہر OpenAI پروڈکٹ کو فوری فائدہ دے سکتے تھے.

مرکزی سروس ہمیں ڈیٹا کی مضبوط ترین سلامتی اور رازداری کے بنیادی انتظامات نافذ کرنے کا واحد مقام بھی دیتی ہے. Habitat سروس وہ مقام ہے جہاں ہم رسائی کی پالیسیاں مرکزی طور پر نافذ، آڈٹ لاگنگ انجام اور Azure Cosmos DB جیسے بنیادی اسٹوریج وسائل تک رسائی محدود کر سکتے ہیں. Habitat صارف کا ڈیٹا محفوظ رکھنے اور بیرونی، اندرونی اور ایجنٹ فریقوں کی غیر مجاز رسائی روکنے میں اہم کردار ادا کرتا ہے.

ہم جانتے تھے کہ ہمیں ایک سروس درکار ہے، لیکن سروس کے طور پر Python کے اضافی بوجھ کے باوجود ہم ابھی اسے ترک نہیں کرنا چاہتے تھے. زیادہ تھروپٹ والی سروس کے لیے Python استعمال کرنے سے مقامی لائبریری کے مقابلے میں نیٹ ورک کی تاخیر اور CPU و میموری کی توسیع کے اخراجات نمایاں طور پر بڑھے. ہم یہ بھی سمجھتے تھے کہ Python کی ناکاریاں 100 گنا پیمانے پر قابل قبول نہیں ہوں گی، اس لیے بالآخر دوبارہ لکھنا تقریباً یقینی تھا.

تاہم، ہم نے اسے سوچ سمجھ کر لیا گیا تکنیکی قرض سمجھا. اس وقت ہمارا بنیادی مقصد لاگت یا وسائل کی بہتری نہیں، بلکہ پروڈکٹ ڈویلپرز کی رکاوٹیں دور کرنا اور پلیٹ فارم کو مستحکم بنانا تھا. مختصر مدت میں Python سروس کی کارکردگی سے متعلق سمجھوتے قبول کر کے ہم فوری مسائل کو ترجیح دے سکے، اپنی بنیادی APIs قائم کیں اور مضبوط بنیادی ڈھانچا بنایا.

ہم نے یہ سوچا سمجھا داؤ بھی لگایا کہ ہمارے اپنے کوڈنگ ماڈلز کی تیز ترقی مستقبل میں تکنیکی راستہ آسان بنا دے گی. ہمیں یقین تھا کہ Python سے مکمل منتقلی ضروری ہونے تک Codex اور GPT اسے ممکن بنا دیں گے. آخرکار یہ اندازہ درست ثابت ہوا.

Habitat کو Python سروس کے طور پر چلانا کارکردگی کے لحاظ سے غیر موزوں، مگر ضروری انتخاب تھا. Python ہمیں تیزی سے آگے بڑھنے دیتا ہے، مگر اس کا مطلب یہ نہیں کہ ہم احتیاط چھوڑ کر نمایاں طور پر زیادہ تاخیر قبول کر لیتے. جب صارف کی اوسط درخواست سینکڑوں ڈیٹابیس کالز کرتی ہو، تو صارف کو سب سے سست کال کی تاخیر محسوس ہوتی ہے. ہم نے پایا کہ اس پیمانے پر Python سروس چلانے کا بنیادی چیلنج انتہائی تاخیر کو قابو میں رکھنا ہے.

Asyncio، Python کو I/O پر منحصر کام بیک وقت انجام دینے میں مدد دیتا ہے، مگر Python GIL سے بچنے یا CPU کی متوازی پراسیسنگ فراہم کرنے میں نہیں. I/O پر منحصر درخواست پراکسی کے علاوہ Habitat کئی CPU پر منحصر ذمہ داریاں اور پس منظر کے کام سنبھالتا ہے: روٹنگ، کمپریشن، انکرپشن، چیک سم، زیریں نظام کی صحت کی جانچ، درخواست کی شیڈو نقل اور ہیجنگ.

ہماری سروس میں CPU پر منحصر اتنے کاموں کے باعث asyncio شیڈیولنگ کی تاخیر آسانی سے درخواست کی انتہائی تاخیر پر غالب آ سکتی ہے. ابتدائی اجرا سے پہلے موافقت کے دوران، p99 یا زیادہ تاخیر والی درخواستوں کے ٹریس میں ہم نے دیکھا کہ زیریں اسٹوریج کے فوری جواب کے باوجود درخواستیں اکثر اس وقت رک جاتیں جب جواب پڑھنے والی کوروٹین دوبارہ شیڈیول ہونے کی منتظر ہوتی.

OpenAI میں Python سروسز کے لیے میموری، CPU، نیٹ ورک اور ڈسک کے استعمال کی معمول کی پیمائش کے ساتھ asyncio لوپ اور اس کی مصروفیت کی نگرانی اور اسی کے مطابق موافقت بھی نہایت اہم ہے.

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

اسی لیے ہم ہر پراسیس سے بیک وقت صرف چند درخواستیں نمٹواتے اور اس کے بجائے Python ورکر پراسیسز کی تعداد بہت زیادہ بڑھاتے ہیں.

ابتدائی اجرا میں براہ راست CPU پروفائلنگ سے ہمیں زیادہ asyncio تاخیر اور اس کے نتیجے میں انتہائی تاخیر کی ایک بنیادی وجہ ملی: Statsig کے ذریعے ہماری فیچر فلیگ کنفیگریشنز کی وقفے وقفے سے JSON پارسنگ. Statsig فیچر فلیگز سنبھالتا اور A/B ٹیسٹ وغیرہ چلاتا ہے.

Statsig بطور ڈیفالٹ بغیر کسی بے قاعدگی کے ہر منٹ تازہ کنفیگریشن حاصل کرتا تھا، اور اس میں تمام سروسز کے ہر پروڈکشن اصول شامل تھے. دوسری جانب، CPU کا استعمال بڑھانے اور تاخیر گھٹانے کے لیے فی پوڈ 8 تک Python پراسیس چلانے کا تعمیراتی فیصلہ کیا گیا تھا. نتیجتاً ہر منٹ ہر پوڈ میں ایک لمحہ ایسا آتا جب تمام ورکر زیرِ عمل درخواستیں روک کر اپنے CPU چکر ایک بہت بڑی کنفیگریشن فائل پارس کرنے میں صرف کرتے.

CPU پروفائلنگ سے بنیادی وجہ معلوم ہونے کے بعد حل آسان تھا: چھوٹی اور مخصوص کنفیگریشن تعینات کریں، تازہ کاری کا وقفہ بڑھائیں اور ایسے پس منظر کے کاموں میں کچھ بے قاعدگی شامل کریں.

asyncio کی تاخیر کم رکھنے کے لیے سرور پراسیسز میں درخواستوں کا اچھا توازن بھی ضروری ہے؛ موافقت نہ ہو تو کنکشن پولنگ اس مقصد کے خلاف جا سکتی ہے.

کلائنٹ سائیڈ کنکشن پولنگ میں کئی بیک وقت درخواستیں کرنے والا ایک کلائنٹ پراسیس صرف چند سرور کنکشن بنا سکتا ہے، اور یوں اپنا پورا بوجھ چند ہی پراسیسز کو بھیجتا ہے. لوڈ بیلنسنگ میں تبدیلی سے پہلے ہماری سروس کے استعمال میں بہت فرق تھا؛ بعض انتہائی پراسیس اوسط سے 5 سے 10 گنا زیادہ بیک وقت درخواستیں سنبھالتے تھے.

ہمیں یہ ایک اتفاقی واقعے میں معلوم ہوا، جب سروس کے ایک حصے پر زیادہ بوجھ ڈالنے والا کلائنٹ بند کرنے کے باوجود کچھ پراسیس اچانک ٹریفک گزرنے کے بہت بعد تک خراب رہے. درحقیقت ان پراسیسز کی کارکردگی بے قابو ہو کر گرتی رہی اور انہیں دوبارہ شروع کرنے تک زیادہ سے زیادہ درخواستیں ملتی رہیں. پوڈ پر ضرورت سے زیادہ بوجھ پڑنے کے بعد کوئی رویہ مزید ٹریفک اسی پوڈ سے جوڑ رہا تھا. یہ ناکامی کی ایسی قسم تھی جس سے ہمارے بعض ساتھی گزشتہ کام کی وجہ سے بخوبی واقف تھے: نیم مستحکم ناکامی⁠(نئی ونڈو میں کھلتا ہے).

ہمیں کنکشن پول پر شک تھا. زیادہ سے زیادہ کنکشن استعمال کی مدت محدود کرنے پر خرابی واقعی محدود ہو گئی اور ہماری تحقیق کی سمت درست ثابت ہوئی. مزید تحقیق سے پتا چلا کہ Python کا aiohttp TCPConnector بطور ڈیفالٹ LIFO کنکشن دوبارہ استعمال کرتا ہے: اگلی درخواست کے لیے حال ہی میں واپس آنے والا کنکشن چنا جاتا ہے. یہ عموماً مناسب ڈیفالٹ ہے: حالیہ کنکشن دوبارہ استعمال کرنے سے اچانک ٹریفک کے لیے بنے اضافی کنکشن غیر فعالیت کی مدت کے بعد بند ہو جاتے اور ان کی دیکھ بھال کا بوجھ گھٹتا ہے. اس صورت میں اس نے ہمارے لیے نیم مستحکم ناکامی پیدا کر دی. درخواستوں کے اچانک اضافے میں سست اور بوجھ زدہ سرورز کی درخواستوں نے کنکشن بعد میں پول کو واپس کیے، اس لیے بعد کی درخواستوں نے انہیں زیادہ چنا اور ٹریفک پہلے سے مشکل میں پوڈز پر مرتکز ہوتی گئی. کنکشن پول میں FIFO دوبارہ استعمال نافذ کرنے سے یہ بازخوردی چکر ٹوٹ گیا اور مستحکم حالت میں درخواستوں کا فرق بھی کم ہوا.

آج ہم OpenAI کے پورے بنیادی ڈھانچے میں کنکشن پولنگ اور سرور کے بوجھ سے باخبر بہتر توازن کے لیے زیادہ تر Istio اور Envoy پر منحصر ہیں، جس سے یہ مسئلہ مکمل طور پر ٹل جاتا ہے.

asyncio کی کم تاخیر کے لیے موافقت اور بہت سے Python پراسیسز کا ایک ضمنی اثر یہ ہے کہ کنکشنز کی بہت بڑی تعداد، جسے ”تھنڈرنگ ہرڈ“ کہتے ہیں، زیریں انحصارات پر آسانی سے ناقابل برداشت بوجھ ڈال سکتی ہے.

روزانہ کی معمول کی تعیناتی بھی، اگر آہستہ چلنے کے لیے موزوں نہ بنائی جائے، کنکشنز کے بار بار بدلنے سے CPU میں نمایاں اتار چڑھاؤ پیدا کر سکتی ہے. یا کنکشن رساؤ NAT گیٹ وے کو بھر کر نیٹ ورک گرا سکتا ہے. یہ دوسری سروسز میں بھی غیر معمولی مسائل نہیں، مگر دس گنا زیادہ پراسیسز کے باعث ان کے پیدا ہونے کی حد بہت کم ہو جاتی ہے اور اکثر نیٹ ورک وسائل بھر جاتے ہیں جنہیں کلائنٹس محض تھروپٹ کی بنیاد پر مستحکم حالت میں سنبھالنے کی توقع نہیں رکھتے.

کنکشنز کو زیادہ سے زیادہ یکجا کرنے کے لیے ہم Envoy پر بھی انحصار کرتے ہیں. ہم اسے Python کے HTTP/1 کنکشنز کو HTTP/2 میں اپ گریڈ کر کے ملٹی پلیکسنگ سے فائدہ اٹھانے، پھر انہیں پول کرنے اور ان کی عمر بڑھانے کے لیے استعمال کرتے ہیں. Envoy ہمیں شرح کی حدود اور سرکٹ بریکرز نافذ کرنے کا مرکزی مقام بھی دیتا ہے، جو ہر الگ Python پراسیس میں کم مؤثر ہوتے.

Python کو اس حد تک وسعت دینے کی ایک وجہ Habitat کی محدود API تھی، جو ہر درخواست کی لاگت کو قابل پیش گوئی رکھتی ہے. کلائنٹس کو من مانی SQL کوئریز بنانے دینے کے بجائے، جو بڑے ٹیبل اسکین یا متعدد ٹیبلز کے جوائن کا سبب بن سکتی ہیں، Habitat ایک سادہ NoSQL API فراہم کرتا ہے. طاقتور API نہ ہونا Habitat کے ڈیزائن میں ایک واضح سمجھوتا ہے.

ہمارا مقصد سادہ، قابل پیش گوئی اور یکساں کام والی درخواستوں کو بہتر بنانا ہے. ہمارے تجربے میں ایسے نظاموں کو وسعت دینا کہیں آسان اور غلط استعمال کرنا مشکل ہے. غیر متوقع پھیلاؤ والی درخواستیں عملی طور پر خطرناک ہیں: وہ علیحدگی اور لوڈ بیلنسنگ کو پیچیدہ بناتی اور تاخیر کی ایسی اچانک حدیں پیدا کرتی ہیں جن کے مطابق سروس اور کلائنٹس دونوں کو وسعت دینا مشکل ہوتا ہے.

Habitat اور Azure Cosmos DB پر منتقل ہونے سے پہلے OpenAI کا بیشتر آن لائن ڈیٹا Postgres میں محفوظ تھا. اس وقت تمام کوئری اور اسکیما تبدیلیوں کا جائزہ لینا آسان تھا تاکہ پروڈکشن میں بھیجنے سے پہلے یقینی بنایا جا سکے کہ وہ درست رویہ رکھتی اور انڈیکس شدہ ڈیٹا پر چلتی ہیں. ٹیم اور پروڈکٹس بڑھنے کے ساتھ یہ جلد ناقابل انتظام ہو گیا اور بندشوں کی عام وجہ بنا، جہاں کسی مصروف راستے پر ایک نئی مہنگی کوئری پورا ڈیٹابیس گرا دیتی تھی.

مسئلہ لاگت کے عدم توازن کا ہے: ایسی SQL کوئریز لکھنا سستا اور آسان ہے جنہیں چلانا مہنگا اور مشکل ہو. Habitat میں ہم اس سے بچتے اور مہنگی کوئریز کو کلائنٹ کی جانب بالکل واضح بنا دیتے ہیں. Habitat پر ضرورت سے زیادہ بوجھ ڈالنے والی لامحدود کوئریز نہیں ہیں، جبکہ پیچیدہ جوائن اور گراف ٹریورسل کے لیے پروڈکٹ ٹیموں کو کچھ بھاری کام کرنا پڑتا ہے، جس سے مجموعی ڈیزائن زیادہ مؤثر بنتا ہے.

Habitat، کلائنٹ کی متعین کردہ آبجیکٹ اور ایج اقسام پر مبنی NoSQL API فراہم کرتا ہے، جو TAO⁠(نئی ونڈو میں کھلتا ہے) سے متاثر ہے. کلائنٹس آبجیکٹس، ایجز اور ان کے باہمی تعلقات پہلے سے متعین کرتے ہیں، مگر ہر قسم کا مواد نہیں. حاصل شدہ تعلقات گراف جیسے ہوتے ہیں، مگر Habitat کسی مخصوص آبجیکٹ کے براہ راست ایجز کی کوئری کے سوا عام گراف ٹریورسل کوئریز کی معاونت نہیں کرتا.

ہم گراف کو اس طرح تقسیم کرتے ہیں کہ ہر آبجیکٹ اور متعلقہ ایجز اسٹوریج کی سطح پر ایک ہی پارٹیشن میں ہوں، مگر آبجیکٹس اور ان دور دراز آبجیکٹس کو ڈیٹابیس کی سطح پر ایک جگہ رکھنے کی منظم کوشش نہیں کرتے جن کی طرف ایجز اشارہ کرتے ہیں. نتیجتاً ماڈل افقی توسیع کے لیے آسانی سے تقسیم ہو جاتا ہے، مگر گراف ٹریورسل غیر مؤثر رہتے ہیں کیونکہ آبجیکٹس کے درمیان کسی بھی مرحلے میں مختلف خطوں کے دو الگ Azure Cosmos DB اکاؤنٹس سے ڈیٹا لانا پڑ سکتا ہے.

زیادہ پیچیدہ کوئریز درکار ہونے پر ہم Rockset کے ذریعے Habitat کا آف لائن ثانوی منظر بھی فراہم کرتے ہیں. ہم تبدیلیوں کا ڈیٹا حاصل کرنے کی تکنیک (CDC) سے آن لائن اسٹوریج کی تبدیلیاں تقریباً حقیقی وقت میں الگ Rockset انسٹینسز تک پہنچاتے ہیں. ہر کلائنٹ ٹیم اپنی پیچیدہ کوئری ضروریات کے لیے اپنے Rockset انسٹینس کی توسیع کی ذمہ دار ہے.

Rockset کی یہ فراہمی کلائنٹس کے لیے اضافی دشواری پیدا کرتی ہے، مگر فی الحال یہ درست سمجھوتا ہے: سادہ کوئریز کو ڈیفالٹ رکھنا اور پیچیدہ کوئریز کے ضرورت مندوں کو متبادل راستہ دینا. یہ ڈیزائن ہمارے آن لائن اسٹوریج کو مطالعہ پر منحصر تجزیاتی اور تلاش کے کاموں سے الگ رکھتا ہے.

Python میں دوبارہ لکھنے کو ایک سال مؤخر کر کے ہم انتہائی تیز نمو کے دوران زیادہ فوری اور مؤثر مسائل پر توجہ دے سکے. پلیٹ فارم پختہ ہونے اور نمو مزید تیز ہونے کے ساتھ، اور OpenAI میں کورز کی تعداد کے لحاظ سے دوسری بڑی سروس اور Envoy استعمال میں چوتھی ہونے کے باعث، بالآخر Python سے آگے بڑھنے کا وقت آ گیا. اپنے عروج پر Python نے ہمیں ہر سیکنڈ 2 کروڑ سے زیادہ درخواستیں نمٹانے میں مدد دی.

2026 کی دوسری سہ ماہی میں صرف 2 انجینئرز، Codex اور GPT‑5.5 کی مدد سے ہم پوری سروس Rust میں دوبارہ لکھ سکے. نئی Rust سروس اب ہماری 95% پروڈکشن درخواستیں سنبھال رہی ہے، اور آنے والے ہفتوں میں Python مکمل طور پر ختم کر دیا جائے گا. ہمارے ڈیٹا کے مطابق Rust سروس، Python نسخے کے مقابلے میں CPU کے لحاظ سے 6 گنا اور میموری کے لحاظ سے 15 گنا زیادہ مؤثر ہے، جبکہ اوسط اور انتہائی تاخیر بھی نمایاں طور پر کم ہے. ہم آئندہ بلاگ میں مزید سیکھے گئے اسباق بیان کریں گے.

Python، اور اب Rust، سروس Habitat کا صرف ایک پہلو ہے. 1 ارب سے زیادہ ChatGPT صارفین کے لیے آن لائن اسٹوریج کی تیز توسیع کی اس سیریز کے دوسرے حصے میں ہم اسٹوریج تہہ اور Habitat کے ذریعے 500 پیٹابائٹ سے زیادہ ڈیٹا اور فی سیکنڈ 7 کروڑ سے زیادہ درخواستیں سنبھالنے پر بات کریں گے.

اگر آپ جدید ترین پیمانے کے OLTP نظاموں پر کام کرنا چاہتے اور ایسی انجینئرنگ میں دلچسپی رکھتے ہیں، تو ہماری ٹیم میں یہ دستیاب عہدہ دیکھیں⁠.