ہمارے صارفین تھکاوٹ کو جانے بغیر ایک دوسرے کو پیغامات لکھتے ہیں۔
یہ بہت زیادہ ہے۔ اگر آپ تمام صارفین کے تمام پیغامات پڑھنے کے لیے نکلے تو اس میں 150 ہزار سال سے زیادہ کا وقت لگے گا۔ بشرطیکہ آپ کافی ترقی یافتہ قاری ہوں اور ہر پیغام پر ایک سیکنڈ سے زیادہ خرچ نہ کریں۔
اعداد و شمار کے اتنے حجم کے ساتھ، یہ ضروری ہے کہ اسے ذخیرہ کرنے اور اس تک رسائی حاصل کرنے کی منطق بہترین طریقے سے بنائی جائے۔ دوسری صورت میں، ایک غیر معمولی لمحے میں، یہ واضح ہوسکتا ہے کہ سب کچھ جلد ہی غلط ہو جائے گا.
ہمارے لیے یہ لمحہ ڈیڑھ سال پہلے آیا تھا۔ ہم اس تک کیسے پہنچے اور آخر میں کیا ہوا - ہم آپ کو ترتیب سے بتاتے ہیں۔
پس منظر
پہلے ہی نفاذ میں، VKontakte پیغامات نے PHP بیک اینڈ اور MySQL کے امتزاج پر کام کیا۔ یہ ایک چھوٹے طالب علم کی ویب سائٹ کے لئے ایک مکمل طور پر عام حل ہے. تاہم، یہ سائٹ بے قابو ہو گئی اور اپنے لیے ڈیٹا ڈھانچے کی اصلاح کا مطالبہ کرنے لگی۔
2009 کے آخر میں، پہلا ٹیکسٹ انجن کا ذخیرہ لکھا گیا، اور 2010 میں اس میں پیغامات منتقل کیے گئے۔
ٹیکسٹ انجن میں پیغامات کو فہرستوں میں محفوظ کیا جاتا تھا - ایک قسم کے "میل باکس"۔ ایسی ہر فہرست کا تعین uid کے ذریعے کیا جاتا ہے - وہ صارف جو ان تمام پیغامات کا مالک ہے۔ ایک پیغام میں صفات کا ایک مجموعہ ہوتا ہے: انٹرلوکیوٹر شناخت کنندہ، متن، منسلکات وغیرہ۔ "باکس" کے اندر پیغام کا شناخت کنندہ local_id ہے، یہ کبھی تبدیل نہیں ہوتا اور نئے پیغامات کے لیے ترتیب وار تفویض کیا جاتا ہے۔ "خانے" آزاد ہیں اور انجن کے اندر ایک دوسرے کے ساتھ ہم آہنگ نہیں ہوتے ہیں؛ ان کے درمیان بات چیت پی ایچ پی کی سطح پر ہوتی ہے۔ آپ ڈیٹا سٹرکچر اور ٹیکسٹ انجن کی صلاحیتوں کو اندر سے دیکھ سکتے ہیں۔ .
یہ دو صارفین کے درمیان خط و کتابت کے لیے کافی تھا۔ اندازہ لگائیں کہ آگے کیا ہوا؟
مئی 2011 میں، VKontakte نے متعدد شرکاء کے ساتھ گفتگو کو متعارف کرایا۔ ان کے ساتھ کام کرنے کے لیے، ہم نے دو نئے کلسٹرز بنائے ہیں - ممبر چیٹس اور چیٹ ممبرز۔ پہلا صارفین کی چیٹس کے بارے میں ڈیٹا اسٹور کرتا ہے، دوسرا چیٹس کے ذریعے صارفین کے بارے میں ڈیٹا اسٹور کرتا ہے۔ خود فہرستوں کے علاوہ، اس میں شامل ہے، مثال کے طور پر، مدعو کرنے والا صارف اور وہ وقت جب وہ چیٹ میں شامل کیے گئے تھے۔
"پی ایچ پی، آئیے چیٹ پر ایک پیغام بھیجیں،" صارف کا کہنا ہے۔
"چلو، {username}،" پی ایچ پی کہتے ہیں۔
اس اسکیم کے نقصانات ہیں۔ مطابقت پذیری اب بھی پی ایچ پی کی ذمہ داری ہے۔ بڑی چیٹس اور صارفین جو بیک وقت انہیں پیغامات بھیجتے ہیں ایک خطرناک کہانی ہے۔ چونکہ ٹیکسٹ انجن کی مثال uid پر منحصر ہے، اس لیے چیٹ کے شرکاء کو مختلف اوقات میں ایک ہی پیغام موصول ہو سکتا ہے۔ کوئی اس کے ساتھ رہ سکتا ہے اگر ترقی ابھی تک کھڑی رہی۔ لیکن ایسا نہیں ہوگا۔
2015 کے آخر میں، ہم نے کمیونٹی پیغامات کا آغاز کیا، اور 2016 کے آغاز میں، ہم نے ان کے لیے ایک API شروع کیا۔ کمیونٹیز میں بڑے چیٹ بوٹس کی آمد کے ساتھ، لوڈ کی تقسیم کو بھی بھول جانا ممکن تھا۔
ایک اچھا بوٹ روزانہ کئی ملین پیغامات تیار کرتا ہے - یہاں تک کہ سب سے زیادہ بات کرنے والے صارفین بھی اس پر فخر نہیں کرسکتے ہیں۔ اس کا مطلب یہ ہے کہ ٹیکسٹ انجن کی کچھ مثالیں، جن پر ایسے بوٹس رہتے تھے، مکمل طور پر متاثر ہونے لگے۔
2016 میں میسج انجن چیٹ ممبرز اور ممبر چیٹس کی 100 مثالیں اور 8000 ٹیکسٹ انجن ہیں۔ ان کی میزبانی ایک ہزار سرورز پر کی گئی، ہر ایک 64 جی بی میموری کے ساتھ۔ پہلے ہنگامی اقدام کے طور پر، ہم نے میموری میں مزید 32 GB کا اضافہ کیا۔ ہم نے پیشن گوئی کا اندازہ لگایا۔ سخت تبدیلیوں کے بغیر، یہ تقریباً ایک سال کے لیے کافی ہوگا۔ آپ کو یا تو ہارڈ ویئر کو پکڑنا ہوگا یا خود ڈیٹا بیس کو بہتر بنانا ہوگا۔
فن تعمیر کی نوعیت کی وجہ سے، ہارڈ ویئر کو ضربوں میں بڑھانا ہی سمجھ میں آتا ہے۔ یعنی کم از کم کاروں کی تعداد کو دوگنا کرنا - ظاہر ہے کہ یہ کافی مہنگا راستہ ہے۔ ہم اصلاح کریں گے۔
نیا تصور
نئے نقطہ نظر کا مرکزی جوہر بات چیت ہے۔ چیٹ میں پیغامات کی فہرست ہوتی ہے جو اس سے متعلق ہوتے ہیں۔ صارف کے پاس چیٹس کی فہرست ہے۔
مطلوبہ کم از کم دو نئے ڈیٹا بیس ہیں:
- چیٹ انجن یہ چیٹ ویکٹرز کا ذخیرہ ہے۔ ہر چیٹ میں پیغامات کا ایک ویکٹر ہوتا ہے جو اس سے متعلق ہوتے ہیں۔ ہر پیغام میں ایک متن اور چیٹ کے اندر ایک منفرد پیغام شناخت کنندہ ہوتا ہے - chat_local_id۔
- صارف کا انجن یہ صارفین کے ویکٹرز کا ذخیرہ ہے - صارفین کے لنکس۔ ہر صارف کے پاس peer_id کا ایک ویکٹر ہوتا ہے (انٹرلوکیٹرز - دوسرے صارفین، ملٹی چیٹ یا کمیونٹیز) اور پیغامات کا ایک ویکٹر۔ ہر peer_id میں پیغامات کا ایک ویکٹر ہوتا ہے جو اس سے متعلق ہوتا ہے۔ ہر پیغام میں ایک chat_local_id اور اس صارف کے لیے ایک منفرد پیغام ID ہے - user_local_id۔
نئے کلسٹرز TCP کا استعمال کرتے ہوئے ایک دوسرے کے ساتھ بات چیت کرتے ہیں - یہ یقینی بناتا ہے کہ درخواستوں کی ترتیب تبدیل نہیں ہوتی ہے۔ خود درخواستیں اور ان کے لیے تصدیقیں ہارڈ ڈرائیو پر ریکارڈ کی جاتی ہیں - اس لیے ہم انجن کی ناکامی یا دوبارہ شروع ہونے کے بعد کسی بھی وقت قطار کی حالت کو بحال کر سکتے ہیں۔ چونکہ یوزر انجن اور چیٹ انجن 4 ہزار شارڈز ہیں، اس لیے کلسٹرز کے درمیان درخواست کی قطار یکساں طور پر تقسیم کی جائے گی (لیکن حقیقت میں کوئی بھی نہیں ہے - اور یہ بہت تیزی سے کام کرتا ہے)۔
زیادہ تر معاملات میں ہمارے ڈیٹا بیس میں ڈسک کے ساتھ کام کرنا تبدیلیوں کے بائنری لاگ (بن لاگ)، جامد اسنیپ شاٹس اور میموری میں ایک جزوی تصویر کے امتزاج پر مبنی ہے۔ دن کے دوران ہونے والی تبدیلیاں بِن لاگ پر لکھی جاتی ہیں، اور وقتاً فوقتاً موجودہ حالت کا اسنیپ شاٹ بنایا جاتا ہے۔ اسنیپ شاٹ ڈیٹا ڈھانچے کا ایک مجموعہ ہے جو ہمارے مقاصد کے لیے موزوں ہے۔ یہ ایک ہیڈر (تصویر کا میٹینڈیکس) اور میٹا فائلز کا ایک سیٹ پر مشتمل ہے۔ ہیڈر مستقل طور پر RAM میں محفوظ ہوتا ہے اور یہ بتاتا ہے کہ سنیپ شاٹ سے ڈیٹا کہاں تلاش کرنا ہے۔ ہر میٹا فائل میں وہ ڈیٹا شامل ہوتا ہے جس کی ضرورت وقت کے قریبی مقامات پر ہو سکتی ہے — مثال کے طور پر، ایک صارف سے متعلق۔ جب آپ اسنیپ شاٹ ہیڈر کا استعمال کرتے ہوئے ڈیٹا بیس سے استفسار کرتے ہیں، تو مطلوبہ میٹا فائل پڑھی جاتی ہے، اور پھر اسنیپ شاٹ بنانے کے بعد ہونے والی بین لاگ میں ہونے والی تبدیلیوں کو مدنظر رکھا جاتا ہے۔ آپ اس نقطہ نظر کے فوائد کے بارے میں مزید پڑھ سکتے ہیں۔ .
ایک ہی وقت میں، ہارڈ ڈرائیو پر ڈیٹا خود دن میں صرف ایک بار تبدیل ہوتا ہے - ماسکو میں رات گئے، جب بوجھ کم سے کم ہوتا ہے۔ اس کی بدولت (یہ جانتے ہوئے کہ ڈسک پر ڈھانچہ دن بھر مستقل رہتا ہے)، ہم ویکٹر کو ایک مقررہ سائز کی صفوں سے بدلنے کے متحمل ہو سکتے ہیں - اور اس کی وجہ سے، میموری میں اضافہ ہوتا ہے۔
نئی اسکیم میں پیغام بھیجنا اس طرح لگتا ہے:
- پی ایچ پی بیک اینڈ صارف کے انجن سے پیغام بھیجنے کی درخواست کے ساتھ رابطہ کرتا ہے۔
- صارف-انجن مطلوبہ چیٹ-انجن مثال کے لیے درخواست کو پراکسی کرتا ہے، جو صارف-انجن chat_local_id پر واپس آتا ہے - اس چیٹ کے اندر ایک نئے پیغام کا منفرد شناخت کنندہ۔ چیٹ_انجین پھر چیٹ میں موجود تمام وصول کنندگان کو پیغام نشر کرتا ہے۔
- user-engine chat-engine سے chat_local_id وصول کرتا ہے اور user_local_id کو PHP پر واپس کرتا ہے - اس صارف کے لیے ایک منفرد پیغام شناخت کنندہ۔ اس شناخت کنندہ کو پھر استعمال کیا جاتا ہے، مثال کے طور پر، API کے ذریعے پیغامات کے ساتھ کام کرنے کے لیے۔
لیکن اصل میں پیغامات بھیجنے کے علاوہ، آپ کو کچھ اور اہم چیزوں کو نافذ کرنے کی ضرورت ہے:
- ذیلی فہرستیں، مثال کے طور پر، سب سے حالیہ پیغامات ہیں جو آپ گفتگو کی فہرست کو کھولتے وقت دیکھتے ہیں۔ بغیر پڑھے ہوئے پیغامات، ٹیگز والے پیغامات ("اہم"، "سپیم"، وغیرہ)۔
- چیٹ انجن میں پیغامات کو کمپریس کرنا
- صارف کے انجن میں پیغامات کو کیش کرنا
- تلاش کریں (تمام ڈائیلاگ کے ذریعے اور ایک مخصوص کے اندر)۔
- ریئل ٹائم اپ ڈیٹ (لانگ پولنگ)۔
- موبائل کلائنٹس پر کیشنگ کو لاگو کرنے کے لیے تاریخ کو محفوظ کرنا۔
تمام ذیلی فہرستیں تیزی سے ڈھانچے کو تبدیل کر رہی ہیں۔ ان کے ساتھ کام کرنے کے لیے ہم استعمال کرتے ہیں۔ . اس انتخاب کی وضاحت اس حقیقت سے کی گئی ہے کہ درخت کے اوپری حصے میں ہم بعض اوقات اسنیپ شاٹ سے پیغامات کا ایک پورا حصہ ذخیرہ کرتے ہیں - مثال کے طور پر، رات کو دوبارہ ترتیب دینے کے بعد، درخت ایک ٹاپ پر مشتمل ہوتا ہے، جس میں سب لسٹ کے تمام پیغامات ہوتے ہیں۔ اسپلے ٹری توازن کے بارے میں سوچے بغیر اس طرح کی چوٹی کے وسط میں داخل کرنا آسان بناتا ہے۔ اس کے علاوہ، Splay غیر ضروری ڈیٹا کو ذخیرہ نہیں کرتا، جو ہماری یادداشت کو بچاتا ہے۔
پیغامات میں معلومات کی ایک بڑی مقدار شامل ہوتی ہے، زیادہ تر متن، جو کمپریس کرنے کے لیے مفید ہے۔ یہ ضروری ہے کہ ہم ایک انفرادی پیغام کو بھی درست طریقے سے غیر محفوظ کر سکیں۔ پیغامات کو کمپریس کرنے کے لیے استعمال کیا جاتا ہے۔ اپنی ہیورسٹکس کے ساتھ - مثال کے طور پر، ہم جانتے ہیں کہ پیغامات میں الفاظ "غیر الفاظ" کے ساتھ متبادل ہوتے ہیں - خالی جگہیں، اوقاف کے نشانات - اور ہمیں روسی زبان کے لیے علامتوں کے استعمال کی کچھ خصوصیات بھی یاد ہیں۔
چونکہ چیٹس کے مقابلے میں بہت کم صارفین ہیں، اس لیے چیٹ انجن میں بے ترتیب رسائی ڈسک کی درخواستوں کو محفوظ کرنے کے لیے، ہم صارف کے انجن میں پیغامات کیش کرتے ہیں۔
پیغام کی تلاش کو صارف-انجن سے لے کر ان تمام چیٹ-انجن مثالوں پر ایک ترچھی استفسار کے طور پر لاگو کیا جاتا ہے جن میں اس صارف کی چیٹس ہوتی ہیں۔ نتائج صارف کے انجن میں ہی مل جاتے ہیں۔
ٹھیک ہے، تمام تفصیلات کو مدنظر رکھا گیا ہے، جو کچھ باقی ہے وہ ایک نئی اسکیم پر جانا ہے - اور ترجیحی طور پر صارفین کے اس پر توجہ کیے بغیر۔
ڈیٹا کی منتقلی
لہذا، ہمارے پاس ایک ٹیکسٹ انجن ہے جو صارف کے ذریعے پیغامات کو ذخیرہ کرتا ہے، اور دو کلسٹرز چیٹ ممبرز اور ممبر چیٹس جو ملٹی چیٹ رومز اور ان میں موجود صارفین کے بارے میں ڈیٹا اسٹور کرتے ہیں۔ اس سے نئے صارف انجن اور چیٹ انجن میں کیسے جائیں؟
پرانی اسکیم میں ممبر چیٹس کو بنیادی طور پر اصلاح کے لیے استعمال کیا جاتا تھا۔ ہم نے فوری طور پر اس سے ضروری ڈیٹا چیٹ ممبرز کو منتقل کر دیا، اور پھر اس نے منتقلی کے عمل میں مزید حصہ نہیں لیا۔
چیٹ ممبرز کے لیے قطار۔ اس میں 100 مثالیں شامل ہیں، جبکہ چیٹ انجن میں 4 ہزار ہیں۔ ڈیٹا کی منتقلی کے لیے، آپ کو اسے تعمیل میں لانے کی ضرورت ہے - اس کے لیے، چیٹ ممبرز کو انہی 4 ہزار کاپیوں میں تقسیم کیا گیا تھا، اور پھر چیٹ کے انجن میں چیٹ ممبرز بن لاگ کو پڑھنے کو فعال کیا گیا تھا۔
اب چیٹ انجن چیٹ ممبرز سے ملٹی چیٹ کے بارے میں جانتا ہے، لیکن اسے ابھی تک دو بات چیت کرنے والوں کے ساتھ مکالمے کے بارے میں کچھ نہیں معلوم۔ اس طرح کے مکالمے ٹیکسٹ انجن میں صارفین کے حوالے سے ہوتے ہیں۔ یہاں ہم نے ڈیٹا "ہیڈ آن" لیا: ہر چیٹ انجن مثال نے ٹیکسٹ انجن کے تمام واقعات سے پوچھا کہ کیا ان کے پاس ڈائیلاگ کی ضرورت ہے۔
زبردست - چیٹ انجن جانتا ہے کہ وہاں کیا ملٹی چیٹ چیٹس ہیں اور وہ جانتا ہے کہ وہاں کیا مکالمے ہیں۔
آپ کو ملٹی چیٹ چیٹس میں پیغامات کو یکجا کرنے کی ضرورت ہے تاکہ آپ ہر چیٹ میں پیغامات کی فہرست کے ساتھ ختم ہوں۔ سب سے پہلے، چیٹ انجن ٹیکسٹ انجن سے اس چیٹ کے تمام صارف کے پیغامات کو بازیافت کرتا ہے۔ کچھ معاملات میں ان میں سے بہت زیادہ ہیں (سیکڑوں ملین تک)، لیکن بہت ہی غیر معمولی استثناء کے ساتھ چیٹ مکمل طور پر RAM میں فٹ بیٹھتی ہے۔ ہمارے پاس غیر ترتیب شدہ پیغامات ہیں، جن میں سے ہر ایک کی متعدد کاپیاں ہیں - آخر کار، وہ سبھی صارفین کے مطابق مختلف ٹیکسٹ انجن مثالوں سے کھینچے گئے ہیں۔ مقصد پیغامات کو ترتیب دینا اور غیر ضروری جگہ لینے والی کاپیوں سے چھٹکارا حاصل کرنا ہے۔
ہر پیغام میں ایک ٹائم اسٹیمپ ہوتا ہے جس میں اسے بھیجنے کا وقت اور متن ہوتا ہے۔ ہم چھانٹنے کے لیے وقت استعمال کرتے ہیں - ہم ملٹی چیٹ شرکاء کے قدیم ترین پیغامات کی طرف اشارہ کرتے ہیں اور ٹائم اسٹیمپ کو بڑھانے کی طرف بڑھتے ہوئے مطلوبہ کاپیوں کے متن سے ہیشز کا موازنہ کرتے ہیں۔ یہ منطقی ہے کہ کاپیوں میں ایک ہی ہیش اور ٹائم اسٹیمپ ہوں گے، لیکن عملی طور پر ہمیشہ ایسا نہیں ہوتا ہے۔ جیسا کہ آپ کو یاد ہے، پرانی اسکیم میں مطابقت پذیری PHP کے ذریعے کی گئی تھی - اور غیر معمولی معاملات میں، ایک ہی پیغام بھیجنے کا وقت مختلف صارفین کے درمیان مختلف ہوتا ہے۔ ان صورتوں میں، ہم نے خود کو ٹائم اسٹیمپ میں ترمیم کرنے کی اجازت دی - عام طور پر ایک سیکنڈ کے اندر۔ دوسرا مسئلہ مختلف وصول کنندگان کے لیے پیغامات کی مختلف ترتیب ہے۔ اس طرح کے معاملات میں، ہم نے مختلف صارفین کے لیے مختلف ترتیب کے اختیارات کے ساتھ ایک اضافی کاپی بنانے کی اجازت دی۔
اس کے بعد ملٹی چیٹ میں میسجز کا ڈیٹا صارف کے انجن کو بھیجا جاتا ہے۔ اور یہاں درآمد شدہ پیغامات کی ایک ناخوشگوار خصوصیت آتی ہے۔ عام آپریشن میں، انجن پر آنے والے پیغامات کو user_local_id کے ذریعے صعودی ترتیب میں سختی سے آرڈر کیا جاتا ہے۔ پرانے انجن سے صارف کے انجن میں درآمد کیے گئے پیغامات نے اس مفید خاصیت کو کھو دیا۔ ایک ہی وقت میں، جانچ کی سہولت کے لیے، آپ کو ان تک تیزی سے رسائی حاصل کرنے، ان میں کچھ تلاش کرنے اور نئی چیزیں شامل کرنے کے قابل ہونے کی ضرورت ہے۔
ہم درآمد شدہ پیغامات کو ذخیرہ کرنے کے لیے ڈیٹا کا ایک خاص ڈھانچہ استعمال کرتے ہیں۔
یہ سائز کے ویکٹر کی نمائندگی کرتا ہے۔ سب کہاں ہیں - عناصر کی ایک خاص ترتیب کے ساتھ مختلف اور نزولی ترتیب میں ترتیب دیے گئے ہیں۔ انڈیکس کے ساتھ ہر سیگمنٹ میں عناصر کو ترتیب دیا گیا ہے۔ ایسی ساخت میں کسی عنصر کی تلاش میں وقت لگتا ہے۔ کے ذریعے بائنری تلاش ایک عنصر کے اضافے کو ختم کردیا جاتا ہے۔ .
لہذا، ہم نے یہ معلوم کیا کہ ڈیٹا کو پرانے انجنوں سے نئے انجنوں میں کیسے منتقل کیا جائے۔ لیکن اس عمل میں کئی دن لگتے ہیں - اور اس بات کا امکان نہیں ہے کہ ان دنوں میں ہمارے صارفین ایک دوسرے کو لکھنے کی عادت ترک کر دیں۔ اس وقت کے دوران پیغامات ضائع نہ ہونے کے لیے، ہم ایک کام کی اسکیم پر سوئچ کرتے ہیں جو پرانے اور نئے دونوں کلسٹرز کا استعمال کرتی ہے۔
ڈیٹا چیٹ ممبرز اور صارف انجن کو لکھا جاتا ہے (اور ٹیکسٹ انجن کو نہیں، جیسا کہ پرانی اسکیم کے مطابق عام آپریشن میں ہوتا ہے)۔ صارف-انجن چیٹ-انجن کی درخواست کو پراکسی کرتا ہے - اور یہاں سلوک اس بات پر منحصر ہے کہ آیا یہ چیٹ پہلے ہی ضم ہو چکی ہے یا نہیں۔ اگر چیٹ کو ابھی تک ضم نہیں کیا گیا ہے، تو چیٹ انجن خود پیغام نہیں لکھتا، اور اس کی پروسیسنگ صرف ٹیکسٹ انجن میں ہوتی ہے۔ اگر چیٹ کو پہلے ہی چیٹ انجن میں ضم کر دیا گیا ہے، تو یہ chat_local_id صارف کے انجن کو لوٹاتا ہے اور تمام وصول کنندگان کو پیغام بھیجتا ہے۔ صارف کا انجن تمام ڈیٹا کو ٹیکسٹ انجن میں پراکسی کرتا ہے - تاکہ اگر کچھ ہوتا ہے، تو ہم ہمیشہ پرانے انجن میں موجود تمام موجودہ ڈیٹا کو واپس لے سکتے ہیں۔ ٹیکسٹ انجن user_local_id لوٹاتا ہے، جسے صارف-انجن اسٹور کرتا ہے اور بیک اینڈ پر واپس آتا ہے۔
نتیجے کے طور پر، منتقلی کا عمل اس طرح نظر آتا ہے: ہم خالی صارف-انجن اور چیٹ-انجن کلسٹرز کو جوڑتے ہیں۔ چیٹ انجن پورے چیٹ ممبرز بن لاگ کو پڑھتا ہے، پھر اوپر بیان کردہ اسکیم کے مطابق پراکسینگ شروع ہوتی ہے۔ ہم پرانے ڈیٹا کو منتقل کرتے ہیں اور دو مطابقت پذیر کلسٹر (پرانے اور نئے) حاصل کرتے ہیں۔ باقی صرف یہ ہے کہ پڑھنے کو ٹیکسٹ انجن سے صارف کے انجن میں تبدیل کیا جائے اور پراکسینگ کو غیر فعال کیا جائے۔
نتائج
نئے طریقہ کار کی بدولت، انجنوں کی کارکردگی کے تمام میٹرکس کو بہتر بنایا گیا ہے اور ڈیٹا کی مستقل مزاجی کے مسائل کو حل کر دیا گیا ہے۔ اب ہم پیغامات میں نئی خصوصیات کو تیزی سے نافذ کر سکتے ہیں (اور یہ پہلے ہی شروع کر چکے ہیں - ہم نے چیٹ کے شرکاء کی زیادہ سے زیادہ تعداد میں اضافہ کیا، فارورڈ کیے گئے پیغامات کی تلاش کو لاگو کیا، پن کیے ہوئے پیغامات شروع کیے اور فی صارف پیغامات کی کل تعداد کی حد کو بڑھا دیا) .
منطق میں تبدیلیاں واقعی بہت بڑی ہیں۔ اور میں یہ نوٹ کرنا چاہوں گا کہ اس کا مطلب ہمیشہ یہ نہیں ہوتا کہ ایک بہت بڑی ٹیم اور کوڈ کی لائنوں کے ہزاروں سال کی ترقی۔ چیٹ انجن اور صارف کے انجن کے ساتھ تمام اضافی کہانیاں جیسے میسج کمپریشن کے لیے ہف مین، اسپلے ٹریز اور امپورٹڈ پیغامات کے لیے ڈھانچہ 20 ہزار لائنوں سے کم کوڈ ہے۔ اور وہ صرف 3 مہینوں میں 10 ڈویلپرز نے لکھے تھے (تاہم، یہ ذہن میں رکھنے کے قابل ہے کہ - عالمی چیمپئنز ).
مزید برآں، سرورز کی تعداد کو دوگنا کرنے کے بجائے، ہم نے ان کی تعداد کو نصف تک کم کر دیا - اب یوزر-انجن اور چیٹ-انجن 500 فزیکل مشینوں پر رہتے ہیں، جبکہ نئی سکیم میں لوڈ کے لیے ایک بڑا ہیڈ روم ہے۔ ہم نے سامان پر بہت پیسہ بچایا - تقریبا$ 5 ملین + $750 ہزار ہر سال آپریٹنگ اخراجات میں۔
ہم انتہائی پیچیدہ اور بڑے پیمانے پر مسائل کے لیے بہترین حل تلاش کرنے کی کوشش کرتے ہیں۔ ہمارے پاس ان میں سے کافی تعداد ہے - اور اسی وجہ سے ہم ڈیٹا بیس ڈیپارٹمنٹ میں باصلاحیت ڈویلپرز کی تلاش کر رہے ہیں۔ اگر آپ محبت کرتے ہیں اور جانتے ہیں کہ اس طرح کے مسائل کو کیسے حل کیا جائے، الگورتھم اور ڈیٹا سٹرکچر کا بہترین علم ہے، تو ہم آپ کو ٹیم میں شامل ہونے کی دعوت دیتے ہیں۔ ہمارے سے رابطہ کریں۔ تفصیلات کے لیے
یہاں تک کہ اگر یہ کہانی آپ کے بارے میں نہیں ہے، تو براہ کرم نوٹ کریں کہ ہم سفارشات کو اہمیت دیتے ہیں۔ کسی دوست کے بارے میں بتائیں ، اور اگر وہ کامیابی سے پروبیشنری مدت مکمل کرتا ہے، تو آپ کو 100 ہزار روبل کا بونس ملے گا۔
ماخذ: www.habr.com