ارے حبر! میرا نام Maxim Vasiliev ہے، میں FINCH میں تجزیہ کار اور پروجیکٹ مینیجر کے طور پر کام کرتا ہوں۔ آج میں آپ کو بتانا چاہوں گا کہ کس طرح، ElasticSearch کا استعمال کرتے ہوئے، ہم 15 منٹ میں 6 ملین درخواستوں پر کارروائی کرنے اور اپنے ایک کلائنٹ کی سائٹ پر روزانہ بوجھ کو بہتر بنانے میں کامیاب ہوئے۔ بدقسمتی سے، ہمیں ناموں کے بغیر کرنا پڑے گا، چونکہ ہمارے پاس این ڈی اے ہے، ہم امید کرتے ہیں کہ مضمون کے مواد کو اس سے کوئی نقصان نہیں پہنچے گا۔ چلو.
پروجیکٹ کیسے کام کرتا ہے۔
اپنے بیک اینڈ پر، ہم ایسی خدمات بناتے ہیں جو ہمارے کلائنٹ کی ویب سائٹس اور موبائل ایپلیکیشن کی کارکردگی کو یقینی بناتی ہیں۔ عام ڈھانچہ آریھ میں دیکھا جا سکتا ہے:
کام کے عمل میں، ہم بڑی تعداد میں لین دین پر کارروائی کرتے ہیں: خریداری، ادائیگیاں، صارف کے بیلنس کے ساتھ آپریشن، جس کے لیے ہم بہت سارے لاگز کو اسٹور کرتے ہیں، ساتھ ہی اس ڈیٹا کو بیرونی سسٹمز میں درآمد اور برآمد کرتے ہیں۔
جب ہم کلائنٹ سے ڈیٹا وصول کرتے ہیں اور اسے صارف کو منتقل کرتے ہیں تو الٹا عمل بھی ہوتے ہیں۔ اس کے علاوہ، ادائیگیوں اور بونس پروگراموں کے ساتھ کام کرنے کے لیے ابھی بھی عمل باقی ہیں۔
مختصر پس منظر
ابتدائی طور پر، ہم نے PostgreSQL کو واحد ڈیٹا اسٹور کے طور پر استعمال کیا۔ ڈی بی ایم ایس کے لیے اس کے معیاری فوائد: لین دین کی موجودگی، ڈیٹا کے نمونے لینے کی ایک ترقی یافتہ زبان، انضمام کے لیے ٹولز کی ایک وسیع رینج؛ اچھی کارکردگی کے ساتھ مل کر کافی عرصے تک ہماری ضروریات کو پورا کیا۔
ہم نے پوسٹگریس میں بالکل تمام ڈیٹا اسٹور کیا: لین دین سے لے کر خبروں تک۔ لیکن صارفین کی تعداد میں اضافہ ہوا، اور اس کے ساتھ درخواستوں کی تعداد میں اضافہ ہوا۔
سمجھنے کے لیے، 2017 میں صرف ڈیسک ٹاپ سائٹ پر سیشنز کی سالانہ تعداد 131 ملین ہے۔ 2018 میں - 125 ملین۔ 2019 پھر 130 ملین۔ سائٹ کے موبائل ورژن اور موبائل ایپلیکیشن سے مزید 100-200 ملین شامل کریں، اور آپ درخواستوں کی ایک بڑی تعداد ملے گی.
پروجیکٹ کی ترقی کے ساتھ، پوسٹگریس نے بوجھ کا مقابلہ کرنا چھوڑ دیا، ہمارے پاس وقت نہیں تھا - مختلف سوالات کی ایک بڑی تعداد سامنے آئی، جس کے لیے ہم کافی تعداد میں انڈیکس نہیں بنا سکے۔
ہم سمجھ گئے کہ دوسرے ڈیٹا اسٹورز کی ضرورت ہے جو ہماری ضروریات فراہم کریں گے اور PostgreSQL کا بوجھ ختم کریں گے۔ Elasticsearch اور MongoDB کو ممکنہ اختیارات کے طور پر سمجھا جاتا تھا۔ مؤخر الذکر مندرجہ ذیل نکات پر ہار گیا:
- اشاریہ سازی کی رفتار سست ہو جاتی ہے کیونکہ اشاریہ جات میں ڈیٹا کی مقدار بڑھ جاتی ہے۔ لچکدار کے ساتھ، رفتار ڈیٹا کی مقدار پر منحصر نہیں ہے.
- مکمل متن کی تلاش نہیں۔
لہذا ہم نے اپنے لیے لچکدار کا انتخاب کیا اور منتقلی کے لیے تیار کیا۔
لچکدار میں منتقلی۔
1. ہم نے پوائنٹ آف سیل سرچ سروس سے منتقلی شروع کی۔ ہمارے کلائنٹ کے پاس فروخت کے تقریباً 70 پوائنٹس ہیں، اور اس کے لیے سائٹ پر اور ایپلیکیشن میں کئی قسم کی تلاش کی ضرورت ہے:
- شہر کے نام سے متن کی تلاش
- کسی نقطہ سے دیئے گئے رداس کے اندر جیو سرچ کریں۔ مثال کے طور پر، اگر صارف یہ دیکھنا چاہتا ہے کہ فروخت کے کون سے پوائنٹس اس کے گھر کے قریب ہیں۔
- دیئے گئے مربع کے ذریعہ تلاش کریں - صارف نقشے پر ایک مربع کھینچتا ہے، اور اس رداس کے تمام پوائنٹس اسے دکھائے جاتے ہیں۔
- اضافی فلٹرز کے ذریعے تلاش کریں۔ فروخت کے پوائنٹس درجہ بندی میں ایک دوسرے سے مختلف ہیں۔
اگر ہم تنظیم کے بارے میں بات کرتے ہیں، تو پوسٹگریس میں ہمارے پاس نقشہ اور خبر دونوں کے لیے ڈیٹا کا ذریعہ ہے، اور لچکدار اسنیپ شاٹس میں اصل ڈیٹا سے لیا جاتا ہے۔ حقیقت یہ ہے کہ ابتدائی طور پر پوسٹگریس تمام معیار کے مطابق تلاش کا مقابلہ نہیں کرسکا۔ نہ صرف بہت سے اشاریہ جات تھے، وہ اوورلیپ بھی ہو سکتے تھے، اس لیے پوسٹگریس شیڈولر کھو گیا اور سمجھ نہیں پایا کہ کون سا اشاریہ استعمال کرنا ہے۔
2. اگلی لائن میں نیوز سیکشن تھا۔ اشاعتیں ہر روز سائٹ پر ظاہر ہوتی ہیں تاکہ صارف معلومات کے بہاؤ میں گم نہ ہو جائے، جاری کرنے سے پہلے ڈیٹا کو ترتیب دینا ضروری ہے۔ تلاش یہی ہے: آپ ٹیکسٹ میچ کے ذریعے سائٹ کو تلاش کر سکتے ہیں، اور ساتھ ہی اضافی فلٹرز کو جوڑ سکتے ہیں، کیونکہ وہ بھی لچکدار کے ذریعے بنائے گئے ہیں۔
3. پھر ہم نے ٹرانزیکشن پروسیسنگ کو منتقل کیا۔ صارفین سائٹ پر ایک مخصوص پروڈکٹ خرید سکتے ہیں اور انعامی قرعہ اندازی میں حصہ لے سکتے ہیں۔ اس طرح کی خریداریوں کے بعد، ہم خاص طور پر اختتام ہفتہ اور تعطیلات پر ڈیٹا کی ایک بڑی مقدار پر کارروائی کرتے ہیں۔ مقابلے کے لیے، اگر عام دنوں میں خریداریوں کی تعداد کہیں 1,5 سے 2 ملین کے درمیان ہوتی ہے، تو چھٹیوں پر یہ تعداد 53 ملین تک پہنچ سکتی ہے۔
ایک ہی وقت میں، ڈیٹا کو کم سے کم وقت میں پروسیس کیا جانا چاہئے - صارفین کئی دنوں تک نتیجہ کا انتظار کرنا پسند نہیں کرتے ہیں۔ پوسٹگریس کے ذریعے ایسی ڈیڈ لائن حاصل کرنے کا کوئی طریقہ نہیں ہے - ہمیں اکثر تالے موصول ہوتے ہیں، اور جب ہم تمام درخواستوں پر کارروائی کر رہے تھے، صارفین یہ جانچ نہیں کر سکے کہ آیا انہیں انعامات ملے ہیں یا نہیں۔ یہ کاروبار کے لیے زیادہ خوشگوار نہیں ہے، اس لیے ہم نے پروسیسنگ کو Elasticsearch پر منتقل کر دیا۔
دورانیہ
اب اپ ڈیٹس کو ایونٹ کی بنیاد پر ترتیب دیا گیا ہے، درج ذیل شرائط کے مطابق:
- سیلز پوائنٹس۔ جیسے ہی ہمیں کسی بیرونی ذریعہ سے ڈیٹا موصول ہوتا ہے، ہم فوری طور پر اپ ڈیٹ شروع کر دیتے ہیں۔
- خبریں سائٹ پر جیسے ہی کوئی خبر ایڈٹ ہوتی ہے، وہ خود بخود Elastic پر بھیج دی جاتی ہے۔
یہاں ایک بار پھر ایلاسٹک کے فوائد کا ذکر کرنا ضروری ہے۔ پوسٹگریس میں، درخواست بھیجتے وقت، آپ کو اس وقت تک انتظار کرنا پڑتا ہے جب تک کہ یہ تمام ریکارڈز پر ایمانداری سے کارروائی نہ کرے۔ آپ 10 ریکارڈز Elastic کو بھیج سکتے ہیں اور ریکارڈز کے تمام شارڈز میں تقسیم کیے جانے کا انتظار کیے بغیر فوری طور پر کام کرنا شروع کر سکتے ہیں۔ یقیناً، کچھ شارڈ یا ریپلیکا کو ابھی ڈیٹا نظر نہیں آ سکتا، لیکن سب کچھ بہت جلد دستیاب ہو جائے گا۔
انضمام کے طریقے
لچکدار کے ساتھ ضم کرنے کے 2 طریقے ہیں:
- TCP پر مقامی کلائنٹ کے ذریعے۔ مقامی ڈرائیور آہستہ آہستہ ختم ہو رہا ہے: یہ اب تعاون یافتہ نہیں ہے، اس کا ایک بہت ہی تکلیف دہ نحو ہے۔ لہذا، ہم عملی طور پر اس کا استعمال نہیں کرتے اور اسے مکمل طور پر ترک کرنے کی کوشش کرتے ہیں۔
- ایک HTTP انٹرفیس کے ذریعے جو JSON درخواستوں اور لوسین نحو دونوں کو استعمال کر سکتا ہے۔ آخری ایک ٹیکسٹ انجن ہے جو لچکدار استعمال کرتا ہے۔ اس ورژن میں، ہمیں HTTP پر JSON درخواستوں کے ذریعے بیچ کرنے کی صلاحیت ملتی ہے۔ یہ وہ آپشن ہے جسے ہم استعمال کرنے کی کوشش کر رہے ہیں۔
HTTP انٹرفیس کی بدولت، ہم ایسی لائبریریوں کا استعمال کر سکتے ہیں جو HTTP کلائنٹ کا غیر مطابقت پذیر نفاذ فراہم کرتی ہیں۔ ہم بیچ اور غیر مطابقت پذیر API کا فائدہ اٹھا سکتے ہیں، جس کے نتیجے میں اعلی کارکردگی ہوتی ہے، جس نے بڑے پروموشن کے دنوں میں بہت مدد کی (نیچے اس پر مزید)
موازنہ کے لیے کچھ نمبر:
- پوسٹگریس باؤنٹی صارفین کو 20 تھریڈز میں بغیر گروپ بندی کے محفوظ کرنا: 460713 سیکنڈ میں 42 ریکارڈ
- 10 تھریڈز کے لیے لچکدار + رد عمل والا کلائنٹ + 1000 عناصر کے لیے بیچ: 596749 سیکنڈ میں 11 ریکارڈ
- 10 تھریڈز کے لیے لچکدار + رد عمل والا کلائنٹ + 1000 عناصر کے لیے بیچ: 23801684 منٹ میں 4 اندراجات
اب ہم نے ایک HTTP درخواست مینیجر لکھا ہے جو JSON کو Batch/not Batch کے طور پر بناتا ہے اور لائبریری سے قطع نظر کسی بھی HTTP کلائنٹ کے ذریعے بھیجتا ہے۔ آپ مطابقت پذیر یا غیر مطابقت پذیر طور پر درخواستیں بھیجنے کا بھی انتخاب کر سکتے ہیں۔
کچھ انضمام میں، ہم اب بھی آفیشل ٹرانسپورٹ کلائنٹ استعمال کرتے ہیں، لیکن یہ صرف اگلے ری فیکٹرنگ کا معاملہ ہے۔ اس صورت میں، Spring WebClient کی بنیاد پر بنایا گیا ایک مقامی کلائنٹ پروسیسنگ کے لیے استعمال کیا جاتا ہے۔
بڑا فروغ
سال میں ایک بار، پروجیکٹ صارفین کے لیے ایک بڑے پروموشن کی میزبانی کرتا ہے - یہ وہی ہائی لوڈ ہے، کیونکہ اس وقت ہم ایک ہی وقت میں لاکھوں صارفین کے ساتھ کام کرتے ہیں۔
عام طور پر تعطیلات کے دوران بوجھ کی چوٹییں ہوتی ہیں، لیکن یہ پروموشن بالکل مختلف سطح پر ہے۔ پچھلے سال، پروموشن کے دن، ہم نے 27 یونٹس سامان فروخت کیے تھے۔ ڈیٹا پر آدھے گھنٹے سے زیادہ عمل کیا گیا جس کی وجہ سے صارفین کو پریشانی کا سامنا کرنا پڑا۔ صارفین کو شرکت کے لیے انعامات ملے، لیکن یہ واضح ہو گیا کہ اس عمل کو تیز کرنے کی ضرورت ہے۔
2019 کے آغاز میں، ہم نے فیصلہ کیا کہ ہمیں ElasticSearch کی ضرورت ہے۔ پورے ایک سال کے لیے، ہم نے ایلاسٹک میں موصول ہونے والے ڈیٹا کی پروسیسنگ اور موبائل ایپلیکیشن اور ویب سائٹ کے API میں ان کے اجراء کا اہتمام کیا۔ اس کے نتیجے میں، اگلے سال مہم کے دوران، ہم نے کارروائی کی۔ 15 منٹ میں 131 اندراجات۔
چونکہ ہمارے پاس بہت سارے لوگ ہیں جو سامان خریدنا چاہتے ہیں اور پروموشنز میں انعامات کی ڈرائنگ میں حصہ لینا چاہتے ہیں، یہ ایک عارضی اقدام ہے۔ اب ہم تازہ ترین معلومات Elastic کو بھیج رہے ہیں، لیکن مستقبل میں ہم گزشتہ مہینوں کی محفوظ شدہ معلومات کو پوسٹگریس کو مستقل اسٹوریج کے طور پر منتقل کرنے کا ارادہ رکھتے ہیں۔ لچکدار انڈیکس کو روکنے کے لئے، جس کی اپنی حدود بھی ہیں.
نتیجہ/نتیجہ
اس وقت، ہم نے ان تمام سروسز کو منتقل کر دیا ہے جو ہم چاہتے تھے Elastic پر اور ابھی کے لیے اسے روک دیا ہے۔ اب ہم پوسٹگریس میں اہم مستقل اسٹوریج کے سب سے اوپر لچکدار میں ایک انڈیکس بنا رہے ہیں، جو صارف کے بوجھ کو سنبھالتا ہے۔
مستقبل میں، ہم خدمات کو منتقل کرنے کا ارادہ رکھتے ہیں اگر ہم سمجھتے ہیں کہ ڈیٹا کی درخواست بہت متنوع ہو جاتی ہے اور کالموں کی لامحدود تعداد کے لیے تلاش کی جاتی ہے۔ پوسٹگریس کے لیے اب یہ کام نہیں ہے۔
اگر ہمیں فعالیت میں مکمل متن کی تلاش کی ضرورت ہے یا اگر ہمارے پاس تلاش کے بہت سے مختلف معیار ہیں، تو ہم پہلے ہی جانتے ہیں کہ اسے لچکدار میں ترجمہ کرنے کی ضرورت ہے۔
⌘⌘⌘
پڑھنے کا شکریہ. اگر آپ کی کمپنی بھی ElasticSearch استعمال کرتی ہے اور اس کے اپنے نفاذ کے معاملات ہیں، تو ہمیں بتائیں۔ یہ جاننا دلچسپ ہوگا کہ دوسرے کیسے ہیں 🙂
ماخذ: www.habr.com