TL؛ DR: چار سال اڳ مون گوگل کي نئين سرور مانيٽرنگ ٽول جي خيال سان ڇڏيو. خيال عام طور تي الڳ ٿيل افعال کي ھڪڙي خدمت ۾ گڏ ڪرڻ ھو ۽ لاگ تجزيو، ميٽرڪ گڏ ڪرڻ، ۽ ڊيش بورڊ. ھڪڙو اصول اھو آھي ته خدمت ضرور ھجڻ گھرجي تيز, هڪ آسان، پرڪشش، لطف اندوز تجربو سان devops مهيا ڪري. انهي جي ضرورت آهي پروسيسنگ ملٽي گيگا بائيٽ ڊيٽا سيٽن کي سيڪنڊ جي حصن ۾ جڏهن بجيٽ ۾ رهندي. لاگ مئنيجمينٽ جا موجوده اوزار اڪثر سست ۽ چست هوندا آهن، تنهنڪري اسان کي هڪ سٺي چيلنج سان منهن ڏيڻو پيو: هوشياريءَ سان هڪ اوزار ڊزائين ڪرڻ ته جيئن صارفين کي هڪ نئون تجربو ڏئي سگهجي.
اهو آرٽيڪل بيان ڪري ٿو ته اسان ڪيئن اسڪالر تي هن مسئلي کي حل ڪيو پراڻن اسڪول جي طريقن کي لاڳو ڪندي، هڪ وحشي قوت جو طريقو، غير ضروري تہن کي ختم ڪرڻ ۽ پيچيده ڊيٽا جي جوڙجڪ کان بچڻ. توھان انھن سبقن کي پنھنجي انجنيئرنگ جي مسئلن تي لاڳو ڪري سگھو ٿا.
پراڻي اسڪول پاور
لاگ تجزيو عام طور تي ڳولا سان شروع ٿئي ٿو: سڀني پيغامن کي ڳولھيو جيڪي ھڪڙي نموني سان ملن. اسڪيلر ۾، اهي ڏهه يا سوين گيگا بائيٽ جا لاگ ڪيترن ئي سرورن مان آهن. جديد طريقا، ضابطي جي طور تي، ڪجهه پيچيده ڊيٽا جي جوڙجڪ جي تعمير ۾ شامل آهن ڳولا لاء بهتر. مون اهو ضرور ڏٺو آهي گوگل تي، جتي اهي هن قسم جي شين تي تمام سٺا آهن. پر اسان هڪ تمام خراب طريقي تي آباد ٿي ويا آهيون: لاگز جي لڪير اسڪيننگ. ۽ اهو ڪم ڪيو - اسان هڪ ڳولها قابل انٽرفيس مهيا ڪندا آهيون جيڪو اسان جي مقابلي کان تيزيءَ جو آرڊر آهي (آخر ۾ اينيميشن ڏسو).
اهم بصيرت اها هئي ته جديد پروسيسر حقيقت ۾ بلڪل تيز آهن، سادي، سڌي عملن تي. اهو پيچيده، گھڻ-پرت سسٽم ۾ ياد ڪرڻ آسان آهي جيڪو I / O اسپيڊ ۽ نيٽ ورڪ آپريشن تي ڀاڙي ٿو، ۽ اهڙا سسٽم اڄ تمام عام آهن. تنهنڪري اسان هڪ ڊزائن ٺاهيا جيڪا گهٽ ۾ گهٽ پرت ۽ اضافي ملبي کي گهٽائي ٿي. متوازي ۾ گھڻن پروسيسرز ۽ سرورز سان، ڳولا جي رفتار 1 ٽي بي في سيڪنڊ تائين پھچندي آھي.
هن آرٽيڪل مان اهم نڪتا:
- Brute-force ڳولا حقيقي دنيا، وڏي پيماني تي مسئلن کي حل ڪرڻ لاء هڪ قابل عمل طريقو آهي.
- Brute Force هڪ ڊزائين ٽيڪنڪ آهي، نه ڪم کان آزاد حل. ڪنهن به ٽيڪنڪ وانگر، اهو ٻين جي ڀيٽ ۾ ڪجهه مسئلن لاء بهتر آهي، ۽ خراب يا چڱي طرح لاڳو ٿي سگهي ٿو.
- برٽ فورس خاص طور تي حاصل ڪرڻ لاء سٺو آهي مستحڪم ڪارڪردگي.
- برٽ فورس جي مؤثر استعمال جي ضرورت آهي ڪوڊ کي بهتر ڪرڻ ۽ مناسب وقت تي ڪافي وسيلن کي لاڳو ڪرڻ. اهو مناسب آهي جيڪڏهن توهان جا سرور ڳري غير استعمال ڪندڙ لوڊ هيٺ آهن ۽ صارف جي عملن کي ترجيح ڏني وڃي.
- ڪارڪردگي پوري نظام جي ڊيزائن تي منحصر آهي، نه رڳو اندروني لوپ الگورتھم.
(هي آرٽيڪل ميموري ۾ ڊيٽا جي ڳولا کي بيان ڪري ٿو. اڪثر صورتن ۾، جڏهن ڪو صارف لاگ سرچ ڪندو آهي، اسڪيلر سرور اڳ ۾ ئي ان کي ڪيش ڪيو آهي. ايندڙ مضمون ۾ غير محفوظ ٿيل لاگز جي ڳولا تي بحث ڪيو ويندو. ساڳيا اصول لاڳو ٿين ٿا: موثر ڪوڊ، برٽ فورس وڏي حسابي وسيلن سان).
طاقت جو طريقو
روايتي طور تي، هڪ وڏي ڊيٽا سيٽ کي ڳولهيو ويندو آهي لفظي انڊيڪس استعمال ڪندي. جڏهن سرور لاگز تي لاڳو ٿئي ٿو، ان جو مطلب آهي لاگ ۾ هر منفرد لفظ ڳولڻ. هر لفظ لاء، توهان کي سڀني شاملن جي هڪ فهرست ٺاهڻ جي ضرورت آهي. اهو هن لفظ سان سڀني پيغامن کي ڳولڻ آسان بڻائي ٿو، مثال طور 'غلطي'، 'فائر فاڪس' يا "transaction_16851951" - صرف انڊيڪس ۾ ڏسو.
مون هن طريقي کي گوگل تي استعمال ڪيو ۽ اهو سٺو ڪم ڪيو. پر اسڪيلر ۾ اسان لاگ بائيٽ بائيٽ بائيٽ ڳوليندا آهيون.
ڇو؟ هڪ تجريدي الگورٿمڪ نقطي نظر کان، لفظي انڊيڪس تمام گهڻو ڪارائتو آهن برٽ فورس ڳولها کان. تنهن هوندي، اسان الگورتھم نه وڪڻندا آهيون، اسان ڪارڪردگي وڪرو ڪندا آهيون. ۽ ڪارڪردگي نه رڳو الگورتھم بابت، پر سسٽم انجنيئرنگ بابت پڻ. اسان کي هر شيء تي غور ڪرڻ گهرجي: ڊيٽا جو حجم، ڳولا جو قسم، دستياب هارڊويئر ۽ سافٽ ويئر جي حوالي سان. اسان فيصلو ڪيو ته اسان جي خاص مسئلي لاء، 'گريپ' وانگر ڪا شيء هڪ انڊيڪس کان بهتر هئي.
انڊيڪس عظيم آهن، پر انهن جون حدون آهن. ھڪڙو لفظ ڳولڻ آسان آھي. پر ڪيترن ئي لفظن سان پيغامن جي ڳولا، جهڙوڪ 'googlebot' ۽ '404'، تمام گهڻو ڏکيو آهي. هڪ جملي جي ڳولا ڪرڻ جهڙوڪ 'uncaught exception' لاءِ هڪ وڌيڪ منجهيل انڊيڪس جي ضرورت آهي جيڪا نه صرف ان لفظ سان گڏ سمورا پيغام رڪارڊ ڪري، پر لفظ جي مخصوص جڳهه کي به رڪارڊ ڪري.
اصل مشڪل تڏهن ايندي آهي جڏهن توهان لفظن جي تلاش ۾ نه هوندا آهيو. اچو ته توهان کي ڏسڻ چاهيو ته ڪيترو ٽرئفڪ بوٽن مان اچي رهيو آهي. پهريون فڪر لفظ 'بوٽ' جي لاگن کي ڳولڻ لاء آهي. هي آهي توهان کي ڪجهه بوٽ ملندا: Googlebot، Bingbot ۽ ٻيا ڪيترائي. پر هتي ’بوٽ‘ لفظ نه، پر ان جو حصو آهي. جيڪڏهن اسان انڊيڪس ۾ ’بوٽ‘ ڳولهينداسين، اسان کي لفظ ’Googlebot‘ سان ڪا به پوسٽ نه ملندي. جيڪڏھن توھان انڊيڪس ۾ ھر لفظ کي چيڪ ڪريو ۽ پوءِ مليل لفظن جي انڊيڪس کي اسڪين ڪريو، ڳولا تمام سست ٿي ويندي. نتيجي طور، ڪجھ لاگ پروگرامن کي جزوي لفظ ڳولڻ جي اجازت نه ڏيندا آھن يا (بهترين طور تي) خاص نحو کي گھٽ ڪارڪردگي سان اجازت ڏين ٿا. اسان هن کان بچڻ چاهيون ٿا.
ٻيو مسئلو اوقاف آهي. ڇا توھان چاھيو ٿا ته سڀني درخواستن مان ڳولا ڪريو 50.168.29.7؟ ڊيبگنگ لاگن تي مشتمل ڇا بابت [error]؟ رڪنيت عام طور تي اوقاف کي ڇڏي ڏيو.
آخرڪار، انجنيئر طاقتور اوزار سان پيار ڪندا آهن، ۽ ڪڏهن ڪڏهن هڪ مسئلو صرف باقاعده اظهار سان حل ڪري سگهجي ٿو. لفظي انڊيڪس هن لاءِ بلڪل مناسب ناهي.
ان کان سواء، انڊيڪس پيچيده. هر پيغام کي ڪيترن ئي لفظن جي فهرستن ۾ شامل ڪرڻ جي ضرورت آهي. انهن لسٽن کي هر وقت آساني سان ڳولهي سگهڻ واري شڪل ۾ رکڻ گهرجي. جملن، لفظن جا ٽڪرا، يا باقاعده اظهار سان گڏ سوالن کي ملٽي لسٽ آپريشنز ۾ ترجمو ڪرڻ جي ضرورت آهي، ۽ نتيجن کي اسڪين ڪيو ۽ گڏيل نتيجو سيٽ پيدا ڪرڻ لاء. ھڪڙي وڏي پيماني تي، گھڻن نوڪردار سروس جي حوالي سان، ھي پيچيدگي ڪارڪردگي جي مسئلن کي پيدا ڪري ٿي جيڪي الورورٿم جو تجزيو ڪرڻ وقت نظر نه ايندا آھن.
Keyword Indexes پڻ تمام گھڻي جاءِ وٺي ٿو، ۽ اسٽوريج ھڪڙي وڏي قيمت آھي لاگ مئنيجمينٽ سسٽم ۾.
ٻئي طرف، هر ڳولا تمام گهڻو ڪمپيوٽنگ پاور استعمال ڪري سگهي ٿو. اسان جا صارف منفرد سوالن لاءِ تيز رفتار ڳولها جي تعريف ڪندا آهن، پر اهڙا سوال نسبتاً گهٽ ڪيا ويندا آهن. عام ڳولا جي سوالن لاءِ، مثال طور، ڊيش بورڊ لاءِ، اسان خاص ٽيڪنالاجي استعمال ڪندا آهيون (اسان انهن کي ايندڙ مضمون ۾ بيان ڪنداسين). ٻيون درخواستون ڪافي ناياب آهن ته توهان کي گهٽ ۾ گهٽ هڪ وقت ۾ هڪ کان وڌيڪ عمل ڪرڻو پوندو. پر هن جو مطلب اهو ناهي ته اسان جا سرور مصروف نه آهن: اهي نوان پيغام وصول ڪرڻ، تجزيو ڪرڻ ۽ دٻائڻ جي ڪم ۾ مصروف آهن، خبردارين جو جائزو وٺڻ، پراڻي ڊيٽا کي دٻائڻ، وغيره. اهڙيء طرح، اسان وٽ پروسيسرز جي هڪ انتهائي اهم فراهمي آهي جيڪا سوالن تي عمل ڪرڻ لاء استعمال ڪري سگهجي ٿي.
برٽ فورس ڪم ڪري ٿو جيڪڏهن توهان وٽ هڪ خراب مسئلو آهي (۽ تمام گهڻي طاقت)
Brute فورس ننڍن اندروني لوپس سان سادي مسئلن تي بهترين ڪم ڪري ٿو. گهڻو ڪري توهان تمام تيز رفتار تي هلائڻ لاء اندروني لوپ کي بهتر ڪري سگهو ٿا. جيڪڏهن ڪوڊ پيچيده آهي، اهو تمام گهڻو ڏکيو آهي ان کي بهتر ڪرڻ.
اسان جي ڳولا جو ڪوڊ اصل ۾ ڪافي وڏو اندروني لوپ هو. اسان 4K تي صفحن تي پيغام ذخيرو ڪندا آهيون؛ هر صفحي تي ڪجهه نياپا شامل آهن (UTF-8 ۾) ۽ هر پيغام لاءِ ميٽا ڊيٽا. Metadata هڪ ڍانچي آهي جيڪو انڪوڊ ڪري ٿو قدر جي ڊيگهه، اندروني پيغام جي ID، ۽ ٻين شعبن. ڳولا جي چڪر هن طرح نظر آئي:
هي اصل ڪوڊ جو هڪ آسان نسخو آهي. پر هتي به، هڪ کان وڌيڪ اعتراض جي جڳهه، ڊيٽا ڪاپيون، ۽ فنڪشن ڪالون نظر اچن ٿيون. JVM فنڪشن ڪالز کي بهتر ڪرڻ ۽ عارضي شيون مختص ڪرڻ ۾ تمام سٺو آهي، تنهنڪري هي ڪوڊ اسان کان وڌيڪ بهتر ڪم ڪيو. جاچ دوران، گراهڪن ان کي ڪافي ڪاميابي سان استعمال ڪيو. پر آخرڪار اسان ان کي ايندڙ سطح تي وٺي ويا.
(توهان اهو پڇي سگهو ٿا ته اسان هن فارميٽ ۾ پيغامن کي 4K صفحن، ٽيڪسٽ ۽ ميٽا ڊيٽا سان گڏ ڇو رکون ٿا، بجاءِ سڌو سنئون لاگ سان ڪم ڪرڻ جي. اهڙا ڪيترائي سبب آهن، جيڪي هن حقيقت ڏانهن وڌي رهيا آهن ته اندروني طور تي اسڪيلر انجڻ وڌيڪ ورهايل ڊيٽابيس وانگر آهي. فائل سسٽم. ٽيڪسٽ ڳولها اڪثر ڪري لاگ پارس ڪرڻ کان پوءِ مارجن ۾ DBMS طرز جي فلٽرن سان گڏ ڪئي ويندي آهي. اسان هڪ ئي وقت ڪيترن ئي هزار لاگن کي ڳولي سگهون ٿا، ۽ سادي ٽيڪسٽ فائلون اسان جي ٽرانزيڪشن، نقل ٿيل، ورهايل ڊيٽا جي انتظام لاءِ مناسب نه آهن).
شروعات ۾، اهو لڳي ٿو ته اهڙي ڪوڊ تمام مناسب نه هو برٽ فورس جي اصلاح لاء. "حقيقي ڪم" ۾ String.indexOf() سي پي يو جي پروفائيل تي به غالب نه ٿيو. اهو آهي، صرف هن طريقي کي بهتر ڪرڻ هڪ اهم اثر نه آڻيندو.
ائين ٿئي ٿو ته اسان هر صفحي جي شروعات ۾ ميٽاڊيٽا ذخيرو ڪندا آهيون، ۽ UTF-8 ۾ سڀني پيغامن جو متن ٻئي آخر ۾ ڀريل هوندو آهي. ان جو فائدو وٺندي، اسان سڄي صفحي کي هڪ ڀيرو ڳولڻ لاءِ لوپ کي ٻيهر لکيو.
هي نسخو سڌو سنئون تي ڪم ڪري ٿو raw byte[] ۽ سڄي 4K پيج تي هڪ ڀيرو سڀني پيغامن کي ڳولهي ٿو.
اھو بھترين طاقت جي طريقي لاءِ اصلاح ڪرڻ تمام آسان آھي. اندروني ڳولها لوپ سڄي 4K صفحي لاء هڪ ئي وقت سڏيو ويندو آهي، بلڪه هر پوسٽ تي الڳ الڳ. ڊيٽا جي ڪا نقل نه آهي، شيون جي مختص نه آهي. ۽ وڌيڪ پيچيده ميٽاداٽا عملن کي صرف سڏيو ويندو آهي جڏهن نتيجو مثبت آهي، ۽ هر پيغام تي نه. هن طريقي سان اسان هڪ ٽين اوور هيڊ کي ختم ڪري ڇڏيو آهي، ۽ باقي لوڊ هڪ ننڍڙي اندروني سرچ لوپ ۾ مرڪوز ڪيو ويو آهي، جيڪو وڌيڪ بهتر ڪرڻ لاء مناسب آهي.
اسان جي حقيقي ڳولا الگورتھم تي ٻڌل آهي . اهو Boyer-Moore algorithm سان ملندڙ جلندڙ آهي، هر قدم تي لڳ ڀڳ ڳولها واري اسٽرنگ جي ڊيگهه کي ڇڏيندي. بنيادي فرق اهو آهي ته اهو غلط ميچن کي گهٽائڻ لاءِ هڪ وقت ۾ ٻه بائيٽ چيڪ ڪري ٿو.
اسان جي عمل درآمد لاءِ هر ڳولا لاءِ 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 GB لاگ ان آهي جنهن ۾ اصطلاح 'customer_5987235982' بلڪل ٽي دفعا ظاهر ٿئي ٿو. هن اصطلاح جي ڳولا انڊيڪس مان سڌو سنئون ٽن هنڌن کي ڳڻائي ٿي ۽ فوري طور تي مڪمل ٿي ويندي. پر پيچيده وائلڊ ڪارڊ ڳولها هزارين لفظن کي اسڪين ڪري سگهن ٿيون ۽ گهڻو وقت وٺي سگهن ٿيون.
ٻئي طرف، برٽ فورس ڳولها ڪنهن به سوال لاءِ وڌيڪ يا گهٽ ساڳئي رفتار تي انجام ڏين ٿيون. ڊگھا لفظ ڳولهڻ بھتر آھي، پر ھڪ اکرن جي ڳولھا به تمام تيز آھي.
برٽ فورس جي طريقي جي سادگي جو مطلب آهي ته ان جي ڪارڪردگي ان جي نظرياتي وڌ کان وڌ آهي. اڻڄاتل ڊسڪ اوورلوڊ، تالا تڪرار، پوائنٽر چيسنگ، ۽ ناڪامي جي هزارين ٻين سببن لاء گهٽ اختيار آهن. مون صرف اسان جي مصروف ترين سرور تي گذريل هفتي اسڪيلر استعمال ڪندڙن پاران ڪيل درخواستن کي ڏٺو. 14 درخواستون هيون. انهن مان بلڪل اٺ هڪ سيڪنڊ کان وڌيڪ ورتو. 000% 99 مليسيڪنڊن اندر مڪمل ٿيو (جيڪڏهن توهان لاگ تجزيي جا اوزار استعمال نه ڪيا آهن، مون تي ڀروسو ڪريو: اهو تيز آهي).
مستحڪم، قابل اعتماد ڪارڪردگي خدمت جي استعمال ۾ آساني لاء اهم آهي. جيڪڏهن اهو وقتي طور تي دير ٿي وڃي، صارف ان کي ناقابل اعتبار سمجهندا ۽ ان کي استعمال ڪرڻ کان انڪار ڪندا.
عمل ۾ لاگ ان ڳولا
هتي هڪ مختصر اينيميشن آهي جيڪو ڏيکاري ٿو اسڪيلر ڳولا عمل ۾. اسان وٽ هڪ ڊيمو اڪائونٽ آهي جتي اسان هر واقعي کي هر عوامي Github مخزن ۾ درآمد ڪندا آهيون. هن ڊيم ۾، مان هڪ هفتي جي قيمت جي ڊيٽا جي جانچ ڪريان ٿو: تقريبن 600 MB خام لاگز.
وڊيو رڪارڊ ڪئي وئي، بغير خاص تياري جي، منهنجي ڊيسڪ ٽاپ تي (سرور کان اٽڪل 5000 ڪلوميٽر). ڪارڪردگي جيڪو توهان ڏسندا سين گهڻو ڪري سبب آهي ، انهي سان گڏ هڪ تيز ۽ قابل اعتماد پس منظر. جڏهن به 'لوڊنگ' اشاري کان سواءِ ڪو وقفو هوندو آهي، اهو مون کي روڪي رهيو آهي ته جيئن توهان پڙهي سگهو ته مان ڇا ڪرڻ وارو آهيان.
نتيجو
جڏهن ڊيٽا جي وڏي مقدار کي پروسيس ڪندي، اهو ضروري آهي ته هڪ سٺو الگورٿم چونڊيو، پر "سٺو" جو مطلب ناهي "فينسي." سوچيو ته توهان جو ڪوڊ عملي طور تي ڪيئن ڪم ڪندو. الگورتھم جو نظرياتي تجزيو ڪجھ عنصرن کي ڇڏي ٿو جيڪي حقيقي دنيا ۾ وڏي اهميت رکن ٿا. آسان الگورتھم بهتر ڪرڻ ۾ آسان آھن ۽ ڪنارن جي حالتن ۾ وڌيڪ مستحڪم.
انهي حوالي سان پڻ سوچيو جنهن ۾ ڪوڊ تي عمل ڪيو ويندو. اسان جي حالت ۾، اسان کي پس منظر جي ڪمن کي منظم ڪرڻ لاء ڪافي طاقتور سرور جي ضرورت آهي. استعمال ڪندڙ ڳولھا شروع ڪن ٿا نسبتاً گھٽ، تنھنڪري اسين قرض وٺي سگھون ٿا سرور جو ھڪڙو گروپ مختصر مدت لاءِ ھر ڳولا کي مڪمل ڪرڻ لاءِ.
هڪ وحشي قوت جو طريقو استعمال ڪندي، اسان لاگن جي هڪ سيٽ ۾ هڪ تيز، قابل اعتماد، لچڪدار ڳولا لاڳو ڪئي. اسان کي اميد آهي ته اهي خيال توهان جي منصوبن لاء مفيد هوندا.
ترميم ڪريو: عنوان ۽ ٽيڪسٽ تبديل ٿي ويا آهن "ڳولا 20 GB في سيڪنڊ تي" مان "ڳولا 1 ٽي بي في سيڪنڊ" ۾ گذريل ڪجهه سالن ۾ ڪارڪردگي جي واڌ کي ظاهر ڪرڻ لاءِ. رفتار ۾ اهو اضافو بنيادي طور تي EC2 سرورز جي قسم ۽ تعداد ۾ تبديلين جي ڪري آهي جيڪو اسان ا today رکي رهيا آهيون اسان جي وڌندڙ ڪسٽمر بنياد جي خدمت ڪرڻ لاءِ. جلد ئي تبديليون اچي رهيون آهن جيڪي آپريشنل ڪارڪردگي ۾ هڪ ٻيو ڊرامائي واڌارو فراهم ڪنديون، ۽ اسان انهن کي شيئر ڪرڻ جو انتظار نٿا ڪري سگهون.
جو ذريعو: www.habr.com