TL؛ DR: چار سال پہلے میں نے گوگل کو ایک نئے سرور مانیٹرنگ ٹول کے خیال کے ساتھ چھوڑ دیا۔ خیال عام طور پر الگ تھلگ افعال کو ایک خدمت میں جوڑنا تھا۔ اور لاگ تجزیہ، میٹرکس کا مجموعہ، اور ڈیش بورڈز۔ ایک اصول یہ ہے کہ خدمت صحیح معنوں میں ہونی چاہیے۔ تیزڈیوپس کو ایک آسان، انٹرایکٹو، لطف اندوز تجربہ فراہم کرنا۔ اس کے لیے بجٹ کے اندر رہتے ہوئے ملٹی گیگا بائٹ ڈیٹا سیٹس کو سیکنڈ کے حصوں میں پروسیسنگ کی ضرورت ہوتی ہے۔ لاگ مینجمنٹ کے موجودہ ٹولز اکثر سست اور پیچیدہ ہوتے ہیں، اس لیے ہمیں ایک اچھے چیلنج کا سامنا کرنا پڑا: صارفین کو ایک نیا تجربہ دینے کے لیے ہوشیاری سے ایک ٹول ڈیزائن کرنا۔
یہ مضمون بیان کرتا ہے کہ کس طرح ہم نے Scalyr میں اس مسئلے کو پرانے اسکول کے طریقوں، ایک بری طاقت اپروچ، غیر ضروری تہوں کو ختم کرکے اور پیچیدہ ڈیٹا ڈھانچے سے بچ کر اس مسئلے کو حل کیا۔ آپ ان اسباق کو اپنے انجینئرنگ کے مسائل پر لاگو کر سکتے ہیں۔
پرانے اسکول کی طاقت
لاگ تجزیہ عام طور پر ایک تلاش کے ساتھ شروع ہوتا ہے: تمام پیغامات تلاش کریں جو ایک مخصوص پیٹرن سے مماثل ہوں۔ Scalyr میں، یہ کئی سرورز کے دسیوں یا سینکڑوں گیگا بائٹس لاگ ہیں۔ جدید طریقوں میں، ایک اصول کے طور پر، تلاش کے لیے موزوں ڈیٹا کے کچھ پیچیدہ ڈھانچے کی تعمیر شامل ہے۔ میں نے اسے یقینی طور پر گوگل پر دیکھا ہے، جہاں وہ اس طرح کی چیزوں میں بہت اچھے ہیں۔ لیکن ہم نے ایک بہت ہی مشکل نقطہ نظر پر طے کیا: نوشتہ جات کی لکیری اسکیننگ۔ اور اس نے کام کیا - ہم ایک تلاش کے قابل انٹرفیس فراہم کرتے ہیں جو ہمارے حریفوں سے زیادہ تیز رفتاری کا حکم دیتا ہے (آخر میں اینیمیشن دیکھیں)۔
کلیدی بصیرت یہ تھی کہ جدید پروسیسر واقعی آسان، سیدھے سادے آپریشنز میں بہت تیز ہیں۔ پیچیدہ، ملٹی لیئر سسٹمز جو I/O کی رفتار اور نیٹ ورک آپریشنز پر انحصار کرتے ہیں، میں اس سے محروم ہونا آسان ہے، اور اس طرح کے سسٹمز آج بہت عام ہیں۔ لہذا ہم نے ایک ایسا ڈیزائن تیار کیا جو تہوں اور اضافی ملبے کو کم سے کم کرتا ہے۔ متوازی طور پر متعدد پروسیسرز اور سرورز کے ساتھ، تلاش کی رفتار 1 TB فی سیکنڈ تک پہنچ جاتی ہے۔
اس مضمون سے اہم نکات:
- حقیقی دنیا، بڑے پیمانے پر مسائل کو حل کرنے کے لیے Brute-force search ایک قابل عمل طریقہ ہے۔
- بروٹ فورس ایک ڈیزائن تکنیک ہے، کام سے پاک حل نہیں۔ کسی بھی تکنیک کی طرح، یہ دوسروں کے مقابلے میں کچھ مسائل کے لیے بہتر طور پر موزوں ہے، اور اسے خراب یا اچھی طرح سے لاگو کیا جا سکتا ہے۔
- برٹ فورس خاص طور پر حاصل کرنے کے لیے اچھی ہے۔ مستحکم کارکردگی
- بروٹ فورس کے مؤثر استعمال کے لیے کوڈ کو بہتر بنانے اور مناسب وقت پر کافی وسائل کا استعمال کرنے کی ضرورت ہوتی ہے۔ یہ مناسب ہے اگر آپ کے سرورز غیر صارف کے بھاری بوجھ میں ہوں اور صارف کے آپریشنز ایک ترجیح رہیں۔
- کارکردگی کا انحصار پورے نظام کے ڈیزائن پر ہے، نہ صرف اندرونی لوپ الگورتھم پر۔
(یہ مضمون میموری میں ڈیٹا کی تلاش کی وضاحت کرتا ہے۔ زیادہ تر معاملات میں، جب کوئی صارف لاگ سرچ کرتا ہے، تو Scalyr سرورز اسے پہلے ہی کیش کر چکے ہوتے ہیں۔ اگلا مضمون غیر محفوظ شدہ لاگز کی تلاش پر بات کرے گا۔ وہی اصول لاگو ہوتے ہیں: موثر کوڈ، بروٹ فورس بڑے کمپیوٹیشنل وسائل کے ساتھ)۔
وحشیانہ طاقت کا طریقہ
روایتی طور پر، ایک بڑے ڈیٹا سیٹ کو مطلوبہ الفاظ کے اشاریہ کا استعمال کرتے ہوئے تلاش کیا جاتا ہے۔ سرور لاگز پر لاگو ہونے پر، اس کا مطلب ہے لاگ میں موجود ہر منفرد لفظ کو تلاش کرنا۔ ہر لفظ کے لیے، آپ کو تمام شمولیتوں کی فہرست بنانے کی ضرورت ہے۔ یہ اس لفظ کے ساتھ تمام پیغامات کو تلاش کرنا آسان بناتا ہے، مثال کے طور پر 'خرابی'، 'فائر فاکس' یا "ٹرانزیکشن_16851951" - صرف انڈیکس میں دیکھیں۔
میں نے اس نقطہ نظر کو گوگل میں استعمال کیا اور اس نے اچھا کام کیا۔ لیکن Scalyr میں ہم لاگ بائٹ بائٹ بائٹ تلاش کرتے ہیں۔
کیوں؟ ایک تجریدی الگورتھمک نقطہ نظر سے، مطلوبہ الفاظ کے اشاریہ جات بریٹ فورس کی تلاش سے کہیں زیادہ موثر ہیں۔ تاہم، ہم الگورتھم نہیں بیچتے، ہم کارکردگی بیچتے ہیں۔ اور کارکردگی نہ صرف الگورتھم کے بارے میں ہے بلکہ سسٹم انجینئرنگ کے بارے میں بھی ہے۔ ہمیں ہر چیز پر غور کرنا چاہیے: ڈیٹا کا حجم، تلاش کی قسم، دستیاب ہارڈ ویئر اور سافٹ ویئر کا سیاق و سباق۔ ہم نے فیصلہ کیا کہ ہمارے خاص مسئلے کے لیے، 'گریپ' جیسی کوئی چیز انڈیکس سے بہتر تھی۔
اشاریہ جات بہت اچھے ہیں، لیکن ان کی حدود ہیں۔ ایک لفظ تلاش کرنا آسان ہے۔ لیکن متعدد الفاظ کے ساتھ پیغامات تلاش کرنا، جیسے 'googlebot' اور '404'، بہت زیادہ مشکل ہے۔ 'uncaught exception' جیسے فقرے کو تلاش کرنے کے لیے ایک زیادہ بوجھل انڈیکس کی ضرورت ہوتی ہے جو نہ صرف اس لفظ کے ساتھ تمام پیغامات بلکہ لفظ کے مخصوص مقام کو بھی ریکارڈ کرے۔
اصل مشکل تب آتی ہے جب الفاظ کی تلاش نہ ہو۔ ہم کہتے ہیں کہ آپ دیکھنا چاہتے ہیں کہ بوٹس سے کتنی ٹریفک آرہی ہے۔ پہلا خیال لفظ 'بوٹ' کے لیے نوشتہ جات تلاش کرنا ہے۔ اس طرح آپ کو کچھ بوٹس ملیں گے: Googlebot، Bingbot اور بہت سے دوسرے۔ لیکن یہاں 'بوٹ' کوئی لفظ نہیں بلکہ اس کا ایک حصہ ہے۔ اگر ہم انڈیکس میں 'بوٹ' تلاش کرتے ہیں، تو ہمیں 'Googlebot' لفظ والی کوئی پوسٹ نہیں ملے گی۔ اگر آپ انڈیکس میں موجود ہر لفظ کو چیک کرتے ہیں اور پھر پائے جانے والے مطلوبہ الفاظ کے لیے انڈیکس کو اسکین کرتے ہیں، تو تلاش بہت سست ہو جائے گی۔ نتیجے کے طور پر، کچھ لاگ پروگرام جزوی الفاظ کی تلاش کی اجازت نہیں دیتے ہیں یا (بہترین طور پر) کم کارکردگی کے ساتھ خصوصی نحو کی اجازت دیتے ہیں۔ ہم اس سے بچنا چاہتے ہیں۔
ایک اور مسئلہ اوقاف کا ہے۔ کیا آپ سے تمام درخواستیں تلاش کرنا چاہتے ہیں۔ 50.168.29.7? ڈیبگنگ لاگز کے بارے میں کیا خیال ہے؟ [error]? سبسکرپٹس عام طور پر اوقاف کو چھوڑ دیتے ہیں۔
آخر میں، انجینئرز طاقتور ٹولز کو پسند کرتے ہیں، اور بعض اوقات ایک مسئلہ صرف باقاعدہ اظہار سے حل کیا جا سکتا ہے۔ مطلوبہ الفاظ کا اشاریہ اس کے لیے زیادہ موزوں نہیں ہے۔
اس کے علاوہ، انڈیکس پیچیدہ. ہر پیغام کو متعدد مطلوبہ الفاظ کی فہرستوں میں شامل کرنے کی ضرورت ہے۔ ان فہرستوں کو ہر وقت آسانی سے تلاش کرنے کے قابل فارمیٹ میں رکھا جانا چاہیے۔ فقرے، الفاظ کے ٹکڑوں، یا ریگولر ایکسپریشنز کے ساتھ استفسارات کو ملٹی لسٹ آپریشنز میں ترجمہ کرنے کی ضرورت ہے، اور نتائج کو اسکین کرکے جوڑ کر نتیجہ کا سیٹ تیار کرنا ہوگا۔ ایک بڑے پیمانے پر، کثیر کرایہ دار سروس کے تناظر میں، یہ پیچیدگی کارکردگی کے مسائل پیدا کرتی ہے جو الگورتھم کا تجزیہ کرتے وقت نظر نہیں آتے۔
مطلوبہ الفاظ کے اشاریہ جات بھی کافی جگہ لیتے ہیں، اور لاگ منیجمنٹ سسٹم میں اسٹوریج ایک بڑی قیمت ہے۔
دوسری طرف، ہر تلاش کمپیوٹنگ کی بہت زیادہ طاقت استعمال کر سکتی ہے۔ ہمارے صارفین منفرد سوالات کے لیے تیز رفتار تلاش کی تعریف کرتے ہیں، لیکن اس طرح کے سوالات نسبتاً کم ہی کیے جاتے ہیں۔ عام تلاش کے سوالات کے لیے، مثال کے طور پر، ڈیش بورڈ کے لیے، ہم خصوصی تکنیک استعمال کرتے ہیں (ہم اگلے مضمون میں ان کی وضاحت کریں گے)۔ دوسری درخواستیں اتنی کم ہوتی ہیں کہ آپ کو شاذ و نادر ہی ایک وقت میں ایک سے زیادہ پر کارروائی کرنی پڑتی ہے۔ لیکن اس کا مطلب یہ نہیں ہے کہ ہمارے سرور مصروف نہیں ہیں: وہ نئے پیغامات وصول کرنے، ان کا تجزیہ کرنے اور کمپریس کرنے، انتباہات کا جائزہ لینے، پرانے ڈیٹا کو کمپریس کرنے اور اسی طرح کے کاموں میں مصروف ہیں۔ اس طرح، ہمارے پاس پروسیسرز کی کافی اہم فراہمی ہے جو استفسارات کو انجام دینے کے لیے استعمال کیے جا سکتے ہیں۔
بروٹ فورس کام کرتی ہے اگر آپ کو کوئی بریٹ مسئلہ ہے (اور بہت زیادہ طاقت)
بروٹ فورس چھوٹے اندرونی لوپس کے ساتھ آسان مسائل پر بہترین کام کرتی ہے۔ اکثر آپ اندرونی لوپ کو بہت زیادہ رفتار سے چلانے کے لیے بہتر بنا سکتے ہیں۔ اگر کوڈ پیچیدہ ہے، تو اسے بہتر بنانا زیادہ مشکل ہے۔
ہمارے سرچ کوڈ میں اصل میں کافی بڑا اندرونی لوپ تھا۔ ہم صفحات پر پیغامات 4K پر محفوظ کرتے ہیں۔ ہر صفحہ میں کچھ پیغامات (UTF-8 میں) اور ہر پیغام کے لیے میٹا ڈیٹا ہوتا ہے۔ میٹا ڈیٹا ایک ایسا ڈھانچہ ہے جو قدر کی لمبائی، داخلی پیغام ID، اور دیگر فیلڈز کو انکوڈ کرتا ہے۔ تلاش کا چکر اس طرح نظر آیا:
یہ اصل کوڈ کا ایک آسان ورژن ہے۔ لیکن یہاں بھی، ایک سے زیادہ آبجیکٹ پلیسمنٹ، ڈیٹا کاپیز، اور فنکشن کالز نظر آتی ہیں۔ JVM فنکشن کالز کو بہتر بنانے اور عارضی اشیاء کو مختص کرنے میں بہت اچھا ہے، لہذا اس کوڈ نے ہمارے حقدار سے بہتر کام کیا۔ جانچ کے دوران، صارفین نے اسے کافی کامیابی سے استعمال کیا۔ لیکن آخر کار ہم اسے اگلے درجے پر لے گئے۔
(آپ پوچھ سکتے ہیں کہ ہم براہ راست لاگز کے ساتھ کام کرنے کے بجائے اس فارمیٹ میں 4K صفحات، متن اور میٹا ڈیٹا کے ساتھ پیغامات کیوں ذخیرہ کرتے ہیں۔ اس کی بہت سی وجوہات ہیں، جو اس حقیقت کی طرف ابلتی ہیں کہ اندرونی طور پر Scalyr انجن ایک تقسیم شدہ ڈیٹا بیس کی طرح ہے۔ فائل سسٹم۔ ٹیکسٹ سرچ کو اکثر لاگ پارس کرنے کے بعد مارجنز میں DBMS طرز کے فلٹرز کے ساتھ ملایا جاتا ہے۔ ہم بیک وقت کئی ہزار لاگز کو ایک ساتھ تلاش کر سکتے ہیں، اور سادہ ٹیکسٹ فائلیں ہمارے لین دین، نقل شدہ، تقسیم شدہ ڈیٹا مینجمنٹ کے لیے موزوں نہیں ہیں)۔
ابتدائی طور پر، ایسا لگتا تھا کہ ایسا کوڈ بروٹ فورس کی اصلاح کے لیے زیادہ موزوں نہیں تھا۔ "حقیقی کام" میں String.indexOf() یہاں تک کہ CPU پروفائل پر غلبہ حاصل نہیں کیا۔ یعنی صرف اس طریقہ کو بہتر بنانے سے کوئی خاص اثر نہیں ہوگا۔
ایسا ہوتا ہے کہ ہم ہر صفحے کے شروع میں میٹا ڈیٹا ذخیرہ کرتے ہیں، اور UTF-8 میں تمام پیغامات کا متن دوسرے سرے پر بھرا ہوتا ہے۔ اس کا فائدہ اٹھاتے ہوئے، ہم نے پورے صفحے کو ایک ساتھ تلاش کرنے کے لیے لوپ کو دوبارہ لکھا:
یہ ورژن براہ راست منظر پر کام کرتا ہے۔ raw byte[] اور پورے 4K صفحہ پر ایک ساتھ تمام پیغامات تلاش کرتا ہے۔
بروٹ فورس کے طریقہ کار کے لیے یہ بہت آسان ہے۔ اندرونی سرچ لوپ کو ہر پوسٹ پر الگ الگ کرنے کے بجائے پورے 4K صفحہ کے لیے بیک وقت بلایا جاتا ہے۔ ڈیٹا کی کوئی کاپی نہیں ہے، اشیاء کی کوئی تخصیص نہیں ہے۔ اور زیادہ پیچیدہ میٹا ڈیٹا آپریشنز صرف اس وقت کال کیے جاتے ہیں جب نتیجہ مثبت ہو، ہر پیغام پر نہیں۔ اس طرح ہم نے ایک ٹن اوور ہیڈ کو ختم کر دیا ہے، اور بقیہ بوجھ ایک چھوٹے سے اندرونی سرچ لوپ میں مرتکز ہے، جو مزید اصلاح کے لیے موزوں ہے۔
ہمارا اصل تلاش الگورتھم پر مبنی ہے۔ . یہ Boyer-Moore الگورتھم کی طرح ہے، ہر قدم پر تلاش کے تار کی تقریباً لمبائی کو چھوڑ کر۔ بنیادی فرق یہ ہے کہ یہ جھوٹے میچوں کو کم سے کم کرنے کے لیے ایک وقت میں دو بائٹس چیک کرتا ہے۔
ہمارے نفاذ کے لیے ہر تلاش کے لیے 64K تلاش کی میز بنانے کی ضرورت ہوتی ہے، لیکن یہ گیگا بائٹس ڈیٹا کے مقابلے میں کچھ بھی نہیں ہے جس کے ذریعے ہم تلاش کر رہے ہیں۔ اندرونی لوپ ایک کور پر کئی گیگا بائٹس فی سیکنڈ کی رفتار سے عمل کرتا ہے۔ عملی طور پر، ہر کور پر مستحکم کارکردگی تقریباً 1,25 GB فی سیکنڈ ہے، اور اس میں بہتری کی گنجائش ہے۔ اندرونی لوپ کے باہر کچھ اوور ہیڈ کو ختم کرنا ممکن ہے، اور ہم جاوا کے بجائے سی میں اندرونی لوپ کے ساتھ تجربہ کرنے کا ارادہ رکھتے ہیں۔
ہم طاقت کا استعمال کرتے ہیں۔
ہم نے بحث کی ہے کہ لاگ سرچنگ کو "تقریباً" لاگو کیا جا سکتا ہے، لیکن ہمارے پاس کتنی "طاقت" ہے؟ کافی زیادہ.
1 کور: جب صحیح طریقے سے استعمال کیا جائے تو، جدید پروسیسر کا ایک کور اپنے طور پر کافی طاقتور ہوتا ہے۔
8 کور: ہم فی الحال Amazon hi1.4xlarge اور i2.4xlarge SSD سرورز پر چل رہے ہیں، ہر ایک 8 کور (16 تھریڈز) کے ساتھ۔ جیسا کہ اوپر ذکر کیا گیا ہے، یہ کور عام طور پر پس منظر کی کارروائیوں میں مصروف ہوتے ہیں۔ جب صارف تلاش کرتا ہے، پس منظر کی کارروائیاں معطل ہو جاتی ہیں، جس سے تلاش کے لیے تمام 8 کور خالی ہو جاتے ہیں۔ تلاش عام طور پر ایک سپلٹ سیکنڈ میں مکمل ہوتی ہے، جس کے بعد بیک گراؤنڈ کا کام دوبارہ شروع ہو جاتا ہے (تھروٹلنگ پروگرام اس بات کو یقینی بناتا ہے کہ تلاش کے سوالات کی بیراج اہم پس منظر کے کام میں مداخلت نہ کرے)۔
16 کور: وشوسنییتا کے لیے، ہم سرورز کو ماسٹر/غلام گروپوں میں منظم کرتے ہیں۔ ہر ماسٹر کے پاس اس کی کمان میں ایک SSD اور ایک EBS سرور ہوتا ہے۔ اگر مین سرور کریش ہو جاتا ہے تو SSD سرور فوراً اپنی جگہ لے لیتا ہے۔ تقریباً ہر وقت، آقا اور غلام ٹھیک کام کرتے ہیں، تاکہ ہر ڈیٹا بلاک کو دو مختلف سرورز پر تلاش کیا جا سکے (EBS غلام سرور میں کمزور پروسیسر ہے، اس لیے ہم اس پر غور نہیں کرتے)۔ ہم ان کے درمیان کام کو تقسیم کرتے ہیں، تاکہ ہمارے پاس کل 16 کور دستیاب ہوں۔
بہت سے کور: مستقبل قریب میں، ہم ڈیٹا کو سرورز پر اس طرح تقسیم کریں گے کہ وہ سبھی ہر غیر معمولی درخواست پر کارروائی میں حصہ لیں۔ ہر کور کام کرے گا۔ [نوٹ: ہم نے منصوبہ نافذ کیا اور تلاش کی رفتار کو 1 TB/s تک بڑھا دیا، مضمون کے آخر میں نوٹ دیکھیں].
سادگی وشوسنییتا کو یقینی بناتی ہے۔
بروٹ فورس کے طریقہ کار کا ایک اور فائدہ اس کی کافی مستقل کارکردگی ہے۔ عام طور پر، تلاش مسئلہ کی تفصیلات اور ڈیٹا سیٹ کے لیے زیادہ حساس نہیں ہوتی ہے (میرا اندازہ ہے کہ اسی لیے اسے "موٹے" کہا جاتا ہے)۔
مطلوبہ الفاظ کا اشاریہ بعض اوقات ناقابل یقین حد تک تیز رفتار نتائج دیتا ہے، اور دوسری بار ایسا نہیں ہوتا ہے۔ فرض کریں کہ آپ کے پاس 50 جی بی لاگز ہیں جن میں 'کسٹمر_5987235982' کی اصطلاح بالکل تین بار ظاہر ہوتی ہے۔ اس اصطلاح کی تلاش انڈیکس سے براہ راست تین مقامات کو شمار کرتی ہے اور فوری طور پر مکمل ہو جائے گی۔ لیکن پیچیدہ وائلڈ کارڈ کی تلاش ہزاروں مطلوبہ الفاظ کو اسکین کر سکتی ہے اور اس میں کافی وقت لگ سکتا ہے۔
دوسری طرف، بریٹ فورس کی تلاشیں کسی بھی سوال کے لیے کم و بیش اسی رفتار سے انجام دیتی ہیں۔ لمبے الفاظ کی تلاش بہتر ہے، لیکن یہاں تک کہ ایک حرف کی تلاش بھی کافی تیز ہے۔
بروٹ فورس کے طریقہ کار کی سادگی کا مطلب یہ ہے کہ اس کی کارکردگی اس کی نظریاتی زیادہ سے زیادہ کے قریب ہے۔ غیر متوقع ڈسک اوورلوڈز، لاک تنازعہ، پوائنٹر کا پیچھا کرنے، اور ناکامی کی ہزاروں دیگر وجوہات کے لیے کم اختیارات ہیں۔ میں نے ابھی پچھلے ہفتے ہمارے مصروف ترین سرور پر Scalyr صارفین کی طرف سے کی گئی درخواستوں کو دیکھا۔ 14 درخواستیں تھیں۔ ان میں سے بالکل آٹھ نے ایک سیکنڈ سے زیادہ وقت لیا۔ 000% 99 ملی سیکنڈ میں مکمل ہو گیا (اگر آپ نے لاگ انالیسس ٹولز استعمال نہیں کیے ہیں تو مجھ پر بھروسہ کریں: یہ تیز ہے).
سروس کے استعمال میں آسانی کے لیے مستحکم، قابل اعتماد کارکردگی اہم ہے۔ اگر یہ وقتاً فوقتاً پیچھے رہتا ہے، تو صارفین اسے ناقابل اعتبار سمجھیں گے اور اسے استعمال کرنے سے گریزاں ہوں گے۔
لاگ ان ایکشن میں تلاش کریں۔
یہاں ایک مختصر حرکت پذیری ہے جو Scalyr تلاش کو عمل میں دکھاتی ہے۔ ہمارے پاس ایک ڈیمو اکاؤنٹ ہے جہاں ہم ہر عوامی گیتھب ریپوزٹری میں ہر ایونٹ درآمد کرتے ہیں۔ اس ڈیمو میں، میں ایک ہفتے کے ڈیٹا کی جانچ کرتا ہوں: تقریباً 600 MB خام لاگز۔
ویڈیو میرے ڈیسک ٹاپ پر (سرور سے تقریباً 5000 کلومیٹر کے فاصلے پر) بغیر کسی خاص تیاری کے لائیو ریکارڈ کی گئی۔ آپ جو کارکردگی دیکھیں گے اس کی بڑی وجہ ہے۔ ، نیز ایک تیز اور قابل اعتماد پسدید۔ جب بھی 'لوڈنگ' اشارے کے بغیر کوئی وقفہ ہوتا ہے، تو یہ میں روک رہا ہوں تاکہ آپ پڑھ سکیں کہ میں کیا دبانے والا ہوں۔
آخر میں
ڈیٹا کی بڑی مقدار پر کارروائی کرتے وقت، ایک اچھا الگورتھم کا انتخاب کرنا ضروری ہے، لیکن "اچھے" کا مطلب "پسند" نہیں ہے۔ اس بارے میں سوچیں کہ آپ کا کوڈ عملی طور پر کیسے کام کرے گا۔ الگورتھم کا نظریاتی تجزیہ کچھ ایسے عوامل کو چھوڑ دیتا ہے جو حقیقی دنیا میں بہت اہمیت کے حامل ہو سکتے ہیں۔ آسان الگورتھم بہتر بنانے میں آسان اور کنارے کے حالات میں زیادہ مستحکم ہوتے ہیں۔
اس سیاق و سباق کے بارے میں بھی سوچیں جس میں کوڈ کو عمل میں لایا جائے گا۔ ہمارے معاملے میں، ہمیں پس منظر کے کاموں کو منظم کرنے کے لیے کافی طاقتور سرورز کی ضرورت ہے۔ صارفین نسبتاً کبھی کبھار ہی تلاش شروع کرتے ہیں، اس لیے ہم ہر تلاش کو مکمل کرنے کے لیے درکار مختصر مدت کے لیے سرورز کے پورے گروپ کو ادھار لے سکتے ہیں۔
بروٹ فورس کے طریقہ کار کا استعمال کرتے ہوئے، ہم نے لاگز کے ایک سیٹ میں ایک تیز، قابل اعتماد، لچکدار تلاش کو لاگو کیا۔ ہم امید کرتے ہیں کہ یہ خیالات آپ کے منصوبوں کے لیے کارآمد ہوں گے۔
ترمیم: پچھلے کچھ سالوں میں کارکردگی میں اضافے کی عکاسی کرنے کے لیے عنوان اور متن کو "20 GB فی سیکنڈ پر تلاش کریں" سے "1 TB فی سیکنڈ پر تلاش کریں" میں تبدیل کر دیا گیا ہے۔ رفتار میں یہ اضافہ بنیادی طور پر EC2 سرورز کی قسم اور تعداد میں تبدیلیوں کی وجہ سے ہے جو ہم آج اپنے بڑھے ہوئے کسٹمر بیس کی خدمت کے لیے پیش کر رہے ہیں۔ جلد ہی ایسی تبدیلیاں آ رہی ہیں جو آپریشنل کارکردگی میں ایک اور ڈرامائی فروغ فراہم کریں گی، اور ہم ان کا اشتراک کرنے کا انتظار نہیں کر سکتے۔
ماخذ: www.habr.com