اڃا تائين فلم مان "اسان جي راز ڪائنات: سيل جي پوشیدہ زندگي"
سيڙپڪاري جو ڪاروبار بينڪن جي دنيا ۾ سڀ کان وڌيڪ پيچيده علائقن مان هڪ آهي، ڇاڪاڻ ته هتي نه رڳو قرض، قرض ۽ جمع آهن، پر سيڪيورٽيز، ڪرنسي، شيون، نڪتل شيون ۽ سڀني قسمن جي پيچيدگين کي منظم مصنوعات جي صورت ۾.
تازو، اسان ڏٺو آهي ته آبادي جي مالي خواندگي ۾ اضافو. وڌيڪ ۽ وڌيڪ ماڻهو سيڪيورٽي مارڪيٽن ۾ واپار ۾ شامل ٿي رهيا آهن. انفرادي سيڙپڪاري جا اڪائونٽ گهڻو وقت اڳ ظاهر نه ٿيا. اهي توهان کي سيڪيورٽي مارڪيٽن کي واپار ڪرڻ جي اجازت ڏين ٿا ۽ يا ته ٽيڪس ڪٽيون وصول ڪن ٿا يا ٽيڪس ادا ڪرڻ کان پاسو ڪن ٿا. ۽ سڀئي گراهڪ جيڪي اسان وٽ ايندا آهن انهن جي پورٽ فوليو کي منظم ڪرڻ ۽ حقيقي وقت ۾ رپورٽنگ ڏسڻ چاهيندا آهن. ان کان علاوه، اڪثر ڪري هي پورٽ فوليو ملٽي پراڊڪٽ آهي، اهو آهي، ماڻهو مختلف ڪاروباري لائينن جا گراهڪ آهن.
ان کان سواء، ريگيوليٽر جي ضرورتن، روسي ۽ غير ملڪي، وڌي رهيا آهن.
موجوده ضرورتن کي پورو ڪرڻ ۽ مستقبل جي واڌاري لاءِ بنياد رکڻ لاءِ، اسان Tarantool جي بنياد تي هڪ سيڙپڪاري جو ڪاروبار تيار ڪيو آهي.
ڪجھ انگ اکر. Alfa-Bank جي سيڙپڪاري جو ڪاروبار فردن ۽ قانوني ادارن لاءِ بروکرج جون خدمتون مهيا ڪري ٿو ته جيئن مختلف سڪيورٽي مارڪيٽن تي واپار ڪرڻ جو موقعو فراهم ڪري، سيڪيورٽيز جي ذخيري لاءِ ذخيري جون خدمتون، پرائيويٽ ۽ وڏي سرمائي وارن ماڻهن لاءِ اعتماد جي انتظام جون خدمتون، ٻين ڪمپنين لاءِ سيڪيورٽيز جاري ڪرڻ جون خدمتون. . Alfa-Bank جي سيڙپڪاري جي ڪاروبار ۾ 3 هزار کان وڌيڪ حوالا في سيڪنڊ شامل آهن، جيڪي مختلف تجارتي پليٽ فارمن تان ڊائون لوڊ ڪيا ويا آهن. ڪم ڪندڙ ڏينهن دوران، 300 هزار کان وڌيڪ ٽرانزيڪشن مارڪيٽ تي بينڪ يا ان جي گراهڪن جي طرفان ختم ڪيا ويا آهن. في سيڪنڊ تائين 5 هزار آرڊر تي عملدرآمد خارجي ۽ اندروني پليٽ فارمن تي ٿئي ٿو. ساڳئي وقت، سڀئي گراهڪ، اندروني ۽ بيروني، حقيقي وقت ۾ انهن جي پوزيشن کي ڏسڻ چاهيندا آهن.
prehistory
2000 واري ڏهاڪي جي شروعات کان وٺي، اسان جي سيڙپڪاري جي ڪاروبار جا علائقا آزاد طور تي ترقي ڪئي: مٽا سٽا واپار، بروکرج خدمتون، ڪرنسي واپار، سيڪيورٽيز ۾ اوور دي ڪائونٽر واپار ۽ مختلف نڪتل شيون. نتيجي طور، اسان فنڪشنل کوهن جي ڄار ۾ ڦاسي ويا آهيون. هي ڇا آهي؟ ڪاروبار جي هر قطار ۾ پنهنجا سسٽم آهن جيڪي هڪ ٻئي جي افعال کي نقل ڪن ٿا. هر سسٽم جو پنهنجو ڊيٽا ماڊل آهي، جيتوڻيڪ اهي ساڳيون تصورن سان هلن ٿا: ٽرانزيڪشن، اوزار، هم منصب، حوالا، وغيره. ۽ جيئن ته هر نظام آزاد طور تي ترقي ڪئي، ٽيڪنالاجي جو هڪ متنوع زو ظاهر ٿيو.
ان کان سواء، سسٽم جو ڪوڊ بنيادي طور تي اڳ ۾ ئي پراڻي آهي، ڇاڪاڻ ته ڪجهه شين جي وچ ۾ 1990s جي وچ ۾ پيدا ٿيو. ۽ ڪجهه علائقن ۾ هن ترقي جي عمل کي سست ڪيو، ۽ ڪارڪردگي جا مسئلا هئا.
نئين حل لاء گهرجون
ڪاروبار اهو محسوس ڪيو آهي ته ٽيڪنالاجي تبديلي وڌيڪ ترقي لاء ضروري آهي. اسان کي ڪم ڏنو ويو:
- سڀ ڪاروباري ڊيٽا گڏ ڪريو ھڪڙي ھڪڙي، تيز اسٽوريج ۾ ۽ ھڪڙي ڊيٽا ماڊل ۾.
- اسان کي هن معلومات کي وڃائڻ يا تبديل نه ڪرڻ گهرجي.
- اهو ضروري آهي ته ڊيٽا کي ورجائي، ڇاڪاڻ ته ڪنهن به وقت ريگيوليٽر گذريل سالن جي انگن اکرن لاء پڇي سگهي ٿو.
- اسان کي نه رڳو ڪجهه نوان، فيشن وارا ڊي بي ايم ايس آڻڻ گهرجن، پر ڪاروباري مسئلن کي حل ڪرڻ لاءِ هڪ پليٽ فارم ٺاهيو.
ان کان سواء، اسان جي معمار پنهنجون شرطون مقرر ڪيون آهن:
- نئون حل لازمي طور تي انٽرنيشنل ڪلاس هجڻ گهرجي، اهو آهي، اهو اڳ ۾ ئي ڪجهه وڏين ڪمپنين ۾ آزمائشي ٿيڻ گهرجي.
- حل جو آپريٽنگ موڊ مشن نازڪ هجڻ گهرجي. هن جو مطلب اهو آهي ته اسان کي لازمي طور تي ڪيترن ئي ڊيٽا سينٽرن ۾ موجود هجڻ گهرجي ۽ آرام سان هڪ ڊيٽا سينٽر جي بند ٿيڻ کان بچڻ گهرجي.
- سسٽم کي افقي طور تي اسپيبلبل هجڻ گهرجي. حقيقت اها آهي ته اسان جا سڀئي موجوده نظام صرف عمودي طور تي اسپيبلبل آهن، ۽ اسان اڳ ۾ ئي هارڊويئر پاور جي گهٽ ترقي جي ڪري ڇت کي ڇڪي رهيا آهيون. تنهن ڪري، اهو وقت اچي ويو آهي جڏهن اسان کي زندهه رکڻ لاء افقي طور تي اسپيبلبل سسٽم جي ضرورت آهي.
- ٻين شين مان، اسان کي ٻڌايو ويو ته حل سستو هجڻ گهرجي.
اسان معياري رستي تي عمل ڪيو: اسان گهرجون تيار ڪيون ۽ خريداري کاتي سان رابطو ڪيو. اتان کان اسان کي ڪمپنين جي هڪ فهرست ملي ٿي، عام طور تي، اسان لاء هي ڪرڻ لاء تيار آهن. اسان سڀني کي مسئلي بابت ٻڌايو، ۽ انهن مان ڇهن حلن جو جائزو ورتو.
ڪناري تي، اسان ان لاءِ ڪنهن جو لفظ نه ٿا وٺون؛ اسان چاهيون ٿا ته هر شيءِ پاڻ کي آزمائي. تنهن ڪري، اسان جي ٽيلر مقابلي جو هڪ لازمي شرط لوڊ ٽيسٽ پاس ڪرڻ هو. اسان لوڊ ٽيسٽ جا ڪم ٺاهيا آهن، ۽ ڇهن مان ٽي ڪمپنيون اڳ ۾ ئي هڪ پروٽوٽائپ حل لاڳو ڪرڻ تي راضي ٿي چڪيون آهن، ان جي ٽيسٽ ڪرڻ لاءِ پنهنجي خرچ تي ان-ميموري ٽيڪنالاجيز جي بنياد تي.
مان توهان کي اهو نه ٻڌائيندس ته اسان هر شيءِ کي ڪيئن آزمايو ۽ ان ۾ ڪيترو وقت لڳي ويو، مان صرف اختصار ڪندس: لوڊ ٽيسٽ ۾ بهترين ڪارڪردگي ڏيکاريو ويو هڪ پروٽوٽائپ حل جي بنياد تي Mail.ru گروپ ڊولپمينٽ ٽيم کان Tarantool. اسان هڪ معاهدي تي دستخط ڪيو ۽ ترقي شروع ڪيو. Mail.ru گروپ مان چار ماڻهو هئا، ۽ Alfa-Bank مان ٽي ڊولپر، ٽي سسٽم تجزيه نگار، هڪ حل آرڪيٽيڪٽ، هڪ پراڊڪٽ مالڪ ۽ هڪ اسڪرم ماسٽر.
اڳتي هلي مان توهان کي ٻڌايان ٿو ته اسان جو نظام ڪيئن وڌو، اهو ڪيئن ترقي ڪيو، اسان ڇا ڪيو ۽ بلڪل ائين ڇو.
ترقي
پهريون سوال جيڪو اسان پاڻ کان پڇيو هو ته اسان جي موجوده سسٽم مان ڊيٽا ڪيئن حاصل ڪجي. اسان فيصلو ڪيو ته HTTP اسان لاءِ ڪافي موزون هو، ڇاڪاڻ ته سڀ موجوده سسٽم هڪ ٻئي سان رابطو ڪندا آهن XML يا JSON موڪلڻ سان HTTP تي.
اسان استعمال ڪريون ٿا HTTP سرور ٺاهيو جيڪو Tarantool ۾ ٺاهيو ويو ڇو ته اسان کي SSL سيشن کي ختم ڪرڻ جي ضرورت ناهي، ۽ ان جي ڪارڪردگي اسان لاء ڪافي آهي.
جيئن ته مون اڳ ۾ ئي چيو آهي، اسان جا سڀئي سسٽم مختلف ڊيٽا ماڊلز ۾ رهن ٿا، ۽ ان پٽ تي اسان کي اعتراض کي ماڊل ڏانهن آڻڻ جي ضرورت آهي جيڪا اسان پاڻ کي بيان ڪريون ٿا. هڪ ٻولي جي ضرورت هئي جيڪا ڊيٽا کي تبديل ڪرڻ جي اجازت ڏئي ٿي. اسان لازمي لوا چونڊيو. اسان سڀ ڊيٽا جي تبادلي واري ڪوڊ کي سينڊ باڪس ۾ هلون ٿا - هي هڪ محفوظ جڳهه آهي جنهن کان ٻاهر هلندڙ ڪوڊ نه ٿو وڃي. هن کي ڪرڻ لاءِ، اسان صرف گهربل ڪوڊ لوڊ ڪري رهيا آهيون، هڪ ماحول ٺاهيو جيڪو ڪم ڪري سگهي ٿو جيڪو ڪنهن به شيءِ کي بلاڪ يا ڇڏي نه ٿو سگهي.
تبادلي کان پوء، ڊيٽا کي چڪاس ڪيو وڃي ته اسان جي ٺاهيل ماڊل جي تعميل لاء. اسان هڪ ڊگهي وقت تائين بحث ڪيو ته ماڊل ڇا هجڻ گهرجي ۽ ان کي بيان ڪرڻ لاء ڪهڙي ٻولي استعمال ڪرڻ گهرجي. اسان چونڊيو Apache Avro ڇاڪاڻ ته ٻولي سادي آهي ۽ ان کي Tarantool جي حمايت حاصل آهي. ماڊل جا نوان ورجن ۽ ڪسٽم ڪوڊ، ڏينهن ۾ ڪيترائي ڀيرا آپريشن ۾ رکي سگھجن ٿا، جيتوڻيڪ لوڊ يا بغير، ڏينهن جي ڪنهن به وقت، ۽ تبديلين کي تمام جلدي ترتيب ڏيو.
تصديق کان پوء، ڊيٽا کي محفوظ ڪيو وڃي. اسان اهو ڪندا آهيون vshard استعمال ڪندي (اسان وٽ شارڊز جي جيو منتشر ٿيل نقل آهن).
ان کان علاوه، خاصيت اهڙي آهي ته اڪثر سسٽم جيڪي اسان کي ڊيٽا موڪليندا آهن پرواه ناهي ته اسان ان کي حاصل ڪيو يا نه. ان ڪري اسان شروع کان ئي مرمت جي قطار لاڳو ڪئي. هي ڇا آهي؟ جيڪڏهن ڪنهن سبب جي ڪري هڪ اعتراض ڊيٽا جي تبديلي يا تصديق نه ٿي ڪري، اسان اڃا تائين رسيد جي تصديق ڪريون ٿا، پر ساڳئي وقت مرمت جي قطار ۾ اعتراض کي بچايو. اهو هڪجهڙائي آهي ۽ مکيه ڪاروباري ڊيٽا گودام ۾ واقع آهي. اسان فوري طور تي ان لاءِ ايڊمنسٽريٽر انٽرفيس لکيو، مختلف ميٽرڪ ۽ الرٽ. نتيجي طور، اسان ڊيٽا نه وڃايو. ايستائين جو ذريعو ۾ ڪجھ تبديل ٿي چڪو آھي، جيڪڏھن ڊيٽا ماڊل تبديل ٿي ويو آھي، اسان ان کي فوري طور تي معلوم ڪنداسين ۽ ترتيب ڏئي سگھون ٿا.
هاڻي توهان کي سکڻ جي ضرورت آهي ته ڪيئن محفوظ ڪيل ڊيٽا ٻيهر حاصل ڪجي. اسان پنهنجي سسٽم جو احتياط سان تجزيو ڪيو ۽ ڏٺو ته جاوا ۽ اوريڪل جي کلاسک اسٽيڪ ۾ لازمي طور تي ڪجهه قسم جي ORM شامل آهي جيڪا ڊيٽا کي تعلقي کان اعتراض ۾ تبديل ڪري ٿي. پوء ڇو نه فوري طور تي هڪ گراف جي صورت ۾ سسٽم کي شيون ڏيو؟ تنهنڪري اسان خوشيءَ سان GraphQL اختيار ڪيو، جيڪو اسان جي سڀني ضرورتن کي پورو ڪيو. اهو توهان کي گراف جي صورت ۾ ڊيٽا حاصل ڪرڻ جي اجازت ڏئي ٿو ۽ صرف ان کي ڪڍڻ جي اجازت ڏئي ٿو جيڪو توهان کي هن وقت ضرورت آهي. توهان شايد API جو نسخو پڻ ڪري سگهو ٿا ڪافي لچڪ سان.
تقريبن فوري طور تي اسان محسوس ڪيو ته ڊيٽا جيڪا اسان ڪڍي رهيا هئاسين ڪافي نه هئي. اسان فنڪشن ٺاهيا آهن جيڪي ماڊل ۾ شيون سان ڳنڍيل هوندا - لازمي طور تي، حساب ڪتاب. اھو آھي، اسان ھڪڙي خاص فنڪشن کي فيلڊ سان ڳنڍيندا آھيون، جيڪو مثال طور، اوسط اقتباس جي قيمت جي حساب سان. ۽ ٻاهرين صارف جيڪو ڊيٽا جي درخواست ڪري ٿو اهو به نه ڄاڻندو آهي ته هي هڪ حساب ڪتاب آهي.
هڪ تصديق واري نظام کي لاڳو ڪيو.
ان کان پوء اسان محسوس ڪيو ته ڪيترن ئي ڪردارن اسان جي فيصلي ۾ crystallized. ڪردار هڪ قسم جي ڪمن جو مجموعو آهي. عام طور تي، ڪردار ۾ مختلف سامان جي استعمال جا پروفائل آهن:
- T-Connect: ايندڙ ڪنيڪشن کي سنڀاليندو، سي پي يو محدود، گھٽ ميموري واپرائڻ، بي رياست.
- IB-Core: ٽرانٽول پروٽوڪول ذريعي حاصل ڪيل ڊيٽا کي تبديل ڪري ٿو، اهو آهي، اهو ٽيبل سان هلندي آهي. اهو پڻ رياست کي ذخيرو نٿو ڪري ۽ اسڪيلبل آهي.
- اسٽوريج: صرف ڊيٽا کي ذخيرو ڪري ٿو، ڪنهن به منطق کي استعمال نٿو ڪري. هي ڪردار آسان ترين انٽرفيس کي لاڳو ڪري ٿو. اسپيبلبل vshard جي مهرباني.
اهو آهي، ڪردار استعمال ڪندي، اسان ڪلستر جي مختلف حصن کي هڪ ٻئي کان ڌار ڪري ڇڏيو، جيڪي هڪ ٻئي کان آزاديء سان ماپ ڪري سگهجن ٿيون.
تنهن ڪري، اسان ٺاهيا آهن هڪ غير مطابقت واري ٽرانزيڪشنل ڊيٽا جي وهڪري جي رڪارڊنگ ۽ هڪ مرمت جي قطار هڪ منتظم انٽرفيس سان. رڪارڊنگ هڪ ڪاروباري نقطه نظر کان غير مطابقت رکندڙ آهي: جيڪڏهن اسان کي ضمانت ڏني وڃي ته اسان پاڻ ڏانهن ڊيٽا لکنداسين، ڪٿي به نه، پوء اسان ان جي تصديق ڪنداسين. جيڪڏهن اها تصديق نه ڪئي وئي آهي، ته پوء ڪجهه غلط ٿي ويو ۽ ڊيٽا کي موڪلڻ جي ضرورت آهي. هي آهي غير مطابقت واري رڪارڊنگ.
جاچ
منصوبي جي شروعات کان وٺي، اسان فيصلو ڪيو ته اسان ڪوشش ڪنداسين ته آزمائشي ترقي تي عمل ڪرڻ جي. اسان tarantool/tap فريم ورڪ استعمال ڪندي Lua ۾ يونٽ ٽيسٽ لکون ٿا، ۽ Pytest فريم ورڪ استعمال ڪندي Python ۾ انٽيگريشن ٽيسٽ. ساڳئي وقت، اسان ٻنهي ڊولپرز ۽ تجزيه نگارن کي انضمام ٽيسٽ لکڻ ۾ شامل ڪريون ٿا.
اسان ڪيئن استعمال ڪريون آزمائشي ترقي يافته ترقي؟
جيڪڏهن اسان ڪجهه نئين خاصيت چاهيون ٿا، اسان ڪوشش ڪريون ٿا ته پهرين ان لاءِ ٽيسٽ لکون. جڏهن اسان ڪو بگ ڳوليون ٿا، اسان پڪ ڪريون ٿا ته پهرين ٽيسٽ لکون، ۽ پوءِ ئي ان کي درست ڪريو. پهرين ته اهو ڪم ڪرڻ ڏکيو آهي، ملازمن جي طرفان غلط فهمي آهي، ايستائين جو تخريبڪاري: "اچو ته جلدي ان کي درست ڪريون، ڪجهه نئون ڪريو، ۽ پوء ان کي ٽيسٽ سان ڍڪايو." صرف هي "بعد ۾" تقريبا ڪڏهن به نه ايندو.
تنهن ڪري، توهان کي پنهنجي پاڻ کي مجبور ڪرڻ جي ضرورت آهي ٽيسٽ لکڻ لاءِ پهريان ۽ ٻين کان پڇڻ لاءِ. مون کي يقين ڪر، ٽيسٽ هلائيندڙ ترقي مختصر مدت ۾ به فائدا آڻيندو آهي. توهان محسوس ڪندا ته توهان جي زندگي آسان ٿي وئي آهي. اسان محسوس ڪيو ته ڪوڊ جو 99٪ هاڻي ٽيسٽن سان ڍڪيل آهي. اهو تمام گهڻو لڳي ٿو، پر اسان وٽ ڪو مسئلو ناهي: ٽيسٽ هر ڪم تي هلندا آهن.
بهرحال، جيڪو اسان کي تمام گهڻو پسند آهي اهو آهي لوڊ جاچ؛ اسان ان کي سڀ کان اهم سمجهون ٿا ۽ ان کي باقاعدگي سان انجام ڏيون ٿا.
مان توهان کي هڪ ننڍڙي ڪهاڻي ٻڌايان ٿو ته اسان پهرين ورزن مان هڪ لوڊ ٽيسٽ جي پهرين مرحلي کي ڪيئن ڪيو. اسان ڊولپر جي ليپ ٽاپ تي سسٽم انسٽال ڪيو، لوڊ آن ڪيو ۽ في سيڪنڊ 4 هزار ٽرانزيڪشن حاصل ڪيا. هڪ ليپ ٽاپ لاء سٺو نتيجو. اسان ان کي چار سرورز جي ورچوئل لوڊ بينچ تي نصب ڪيو، پيداوار جي ڀيٽ ۾ ڪمزور. گھٽ ۾ گھٽ مقرر ٿيل. اسان ان کي هلائيندا آهيون، ۽ اسان هڪ ٿريڊ ۾ ليپ ٽاپ کان وڌيڪ خراب نتيجا حاصل ڪندا آهيون. جھٽڪو وارو مواد.
اسان ڏاڍا اداس هئاسين. اسان سرور جي لوڊ کي ڏسو، پر اهو ظاهر ٿئي ٿو ته اهي بيڪار آهن.
اسان ڊولپرز کي سڏيندا آهيون، ۽ اهي اسان کي وضاحت ڪندا آهن، جيڪي ماڻهو جاوا جي دنيا مان ايندا آهن، ته Tarantool هڪ واحد موضوع آهي. اهو صرف مؤثر طريقي سان استعمال ڪري سگهجي ٿو هڪ پروسيسر ڪور طرفان لوڊ هيٺ. پوءِ اسان هر سرور تي Tarantool مثالن جو وڌ ۾ وڌ ممڪن تعداد لڳايو، لوڊ آن ڪيو ۽ اڳ ۾ ئي 14,5 هزار ٽرانزيڪشن في سيڪنڊ وصول ڪيو.
مون کي ٻيهر وضاحت ڪرڻ ڏيو. ڪردارن ۾ ورهائڻ جي ڪري جيڪي وسيلن کي مختلف طريقي سان استعمال ڪن ٿا، اسان جا ڪردار پروسيسنگ ڪنيڪشن ۽ ڊيٽا جي تبديليءَ لاءِ ذميوار آهن صرف پروسيسر لوڊ ڪيو، ۽ سختي سان لوڊ جي تناسب سان.
هن معاملي ۾، ياداشت صرف پروسيسنگ ايندڙ ڪنيڪشن ۽ عارضي شيون لاء استعمال ڪيو ويو.
ان جي برعڪس، اسٽوريج سرورز تي، پروسيسر لوڊ وڌايو ويو، پر سرورز جي ڀيٽ ۾ تمام گهڻو سست جيڪي ڪنيڪشن کي پروسيس ڪن ٿا.
۽ ميموري جو استعمال سڌو سنئون تناسب ۾ لوڊ ٿيل ڊيٽا جي مقدار ۾ وڌيو.
خدمتون
اسان جي نئين پراڊڪٽ کي خاص طور تي ايپليڪيشن پليٽ فارم جي طور تي ترقي ڪرڻ لاء، اسان ان تي خدمتون ۽ لائبريرين کي ترتيب ڏيڻ لاء هڪ جزو ٺاهيو.
خدمتون صرف ڪوڊ جا ننڍا ٽڪرا نه آھن جيڪي ڪجھ شعبن تي ڪم ڪن ٿيون. اهي ٿي سگهن ٿيون ڪافي وڏيون ۽ پيچيده ڍانچو جيڪي ڪلستر جو حصو آهن، ريفرنس ڊيٽا چيڪ ڪريو، ڪاروباري منطق هلائڻ ۽ جوابن جي واپسي. اسان پڻ خدمت اسڪيما کي GraphQL ڏانهن برآمد ڪريون ٿا، ۽ صارف حاصل ڪري ٿو ڊيٽا تائين هڪ آفاقي رسائي پوائنٽ، سڄي ماڊل ۾ خودڪشي سان. اهو تمام آرامده آهي.
جيئن ته خدمتن ۾ ڪيترائي وڌيڪ افعال شامل آهن، اسان فيصلو ڪيو ته اتي لائبريريون هجڻ گهرجن جن ۾ اسين اڪثر استعمال ٿيل ڪوڊ منتقل ڪنداسين. اسان انهن کي محفوظ ماحول ۾ شامل ڪيو، اڳ ۾ چڪاس ڪيو ويو آهي ته اهو اسان لاء ڪجهه به نه ڀڃي. ۽ ھاڻي اسان لائبريرين جي صورت ۾ افعالن لاءِ اضافي ماحول تفويض ڪري سگھون ٿا.
اسان چاهيون ٿا ته هڪ پليٽ فارم نه رڳو اسٽوريج لاءِ، پر ڪمپيوٽنگ لاءِ به. ۽ جيئن ته اسان وٽ اڳ ۾ ئي replicas ۽ شارڊز جو هڪ گروپ هو، تنهن ڪري اسان هڪ قسم جي ورهايل ڪمپيوٽنگ کي لاڳو ڪيو ۽ ان کي ميپ ريڊڊ سڏيو، ڇاڪاڻ ته اهو اصل نقشي جي گهٽتائي سان ملندڙ جلندڙ نڪتو.
پراڻي نظام
نه اسان جا سڀئي ورثي وارا نظام اسان کي HTTP تي ڪال ڪري سگھن ٿا ۽ GraphQL استعمال ڪن ٿا، جيتوڻيڪ اهي پروٽوڪول جي حمايت ڪن ٿا. ان ڪري، اسان ھڪڙو ميکانيزم ٺاھيو آھي جيڪو ڊيٽا کي انھن سسٽم ۾ نقل ڪرڻ جي اجازت ڏئي ٿو.
جيڪڏهن اسان لاءِ ڪا شيءِ تبديل ٿئي ٿي، اسٽوريج جي ڪردار ۾ منفرد ٽريگر شروع ڪيا ويندا آهن ۽ تبديلين سان گڏ پيغام پروسيسنگ قطار ۾ ختم ٿي ويندو آهي. اهو هڪ الڳ replicator ڪردار استعمال ڪندي هڪ خارجي نظام ڏانهن موڪليو ويو آهي. هي ڪردار رياست کي ذخيرو نٿو ڪري.
نيون واڌايون
جيئن توهان کي ياد آهي، ڪاروباري نقطي نظر کان، اسان غير مطابقت واري رڪارڊنگ ڪئي. پر پوءِ انهن محسوس ڪيو ته اهو ڪافي نه هوندو، ڇاڪاڻ ته اتي سسٽم جو هڪ طبقو آهي جنهن کي فوري طور تي آپريشن جي صورتحال بابت جواب حاصل ڪرڻ جي ضرورت آهي. تنهن ڪري اسان اسان جي GraphQL کي وڌايو ۽ ميوٽيشنز شامل ڪيو. اهي منظم طور تي ڊيٽا سان ڪم ڪرڻ جي موجوده پيراگراف ۾ مناسب آهن. اسان لاءِ، هي ٻئي درجي جي سسٽم لاءِ پڙهڻ ۽ لکڻ ٻنهي جو هڪ نقطو آهي.
اسان اهو پڻ محسوس ڪيو ته صرف خدمتون اسان لاء ڪافي نه هونديون، ڇاڪاڻ ته اتي ڪافي ڳري رپورٽون آهن جيڪي هڪ ڏينهن، هڪ هفتي، مهيني ۾ هڪ ڀيرو تعمير ڪرڻ جي ضرورت آهي. اهو هڪ ڊگهو وقت وٺي سگهي ٿو، ۽ رپورٽون به بلاڪ ڪري سگهن ٿيون Tarantool جي ايونٽ لوپ. تنهن ڪري، اسان الڳ الڳ ڪردار ٺاهيا: شيڊولر ۽ رنر. ڊوڙندڙ رياست کي ذخيرو نٿا ڪن. اهي وڏا ڪم هلائيندا آهن جن جو اسان اڏام تي حساب نه ٿا ڪري سگهون. ۽ شيڊولر ڪردار انهن ڪمن جي لانچ شيڊول کي مانيٽر ڪري ٿو، جيڪو تشڪيل ۾ بيان ڪيو ويو آهي. ڪم پاڻ کي ساڳي جاءِ تي محفوظ ٿيل آهن جيئن ڪاروباري ڊيٽا. جڏهن صحيح وقت اچي ٿو، شيڊولر ڪم وٺي ٿو، اهو ڪجهه رنر کي ڏئي ٿو، جيڪو ان کي شمار ڪري ٿو ۽ نتيجو بچائي ٿو.
سڀني ڪمن کي شيڊول تي هلائڻ جي ضرورت ناهي. ڪجهه رپورٽون گهربل پڙهڻ گهرجن. جيترو جلدي هي گهرج اچي ٿو، هڪ ڪم سينڊ باڪس ۾ ٺاهيو ويو آهي ۽ عملدرآمد لاء رنر ڏانهن موڪليو ويو آهي. ڪجهه وقت کان پوء، صارف هڪ غير مطابقت وارو جواب حاصل ڪري ٿو ته هر شيء جو حساب ڪيو ويو آهي ۽ رپورٽ تيار آهي.
شروعات ۾، اسان سڀني ڊيٽا کي محفوظ ڪرڻ، ان کي ورزن ڪرڻ ۽ ان کي حذف نه ڪرڻ جي پيراگراف تي عمل ڪيو. پر زندگيءَ ۾، وقت بوقت، توهان کي اڃا به ڪجهه ختم ڪرڻو پوندو، گهڻو ڪري ڪجهه خام يا وچولي معلومات. ختم ٿيڻ جي بنياد تي، اسان پراڻي ڊيٽا مان اسٽوريج کي صاف ڪرڻ لاء هڪ ميڪانيزم ٺاهيو.
اسان اهو پڻ سمجهون ٿا ته جلد يا بعد ۾ هڪ صورتحال ايندي جڏهن ميموري ۾ ڊيٽا کي ذخيرو ڪرڻ لاء ڪافي جاء نه هوندي، پر ان جي باوجود ڊيٽا کي ذخيرو ڪرڻ گهرجي. انهن مقصدن لاء، اسان جلد ئي ڊسڪ اسٽوريج ٺاهينداسين.
ٿڪل
اسان ڊيٽا کي هڪ واحد ماڊل ۾ لوڊ ڪرڻ جي ڪم سان شروع ڪيو ۽ ان کي ترقي ڪندي ٽي مهينا گذاريا. اسان وٽ ڇهه ڊيٽا سپلائي سسٽم هئا. هڪ واحد ماڊل ۾ مڪمل تبديلي ڪوڊ Lua ۾ اٽڪل 30 هزار لائينون آهن. ۽ گهڻو ڪم اڃا اڳتي آهي. ڪڏهن ڪڏهن پاڙيسري ٽيمن کان حوصلا افزائي جي کوٽ آهي، ۽ اتي ڪيتريون ئي حالتون آهن جيڪي ڪم کي پيچيده ڪن ٿا. جيڪڏهن توهان کي ڪڏهن به هڪ جهڙو ڪم منهن ڏيڻو پوي ٿو، ته پوءِ ان تي عمل ڪرڻ لاءِ معمولي لڳي وقت کي ٽي، يا ان کان به چار ڀيرا وڌايو.
اهو پڻ ياد رکو ته ڪاروباري عملن ۾ موجود مسئلا حل نه ٿي ڪري سگهجن هڪ نئين DBMS استعمال ڪندي، جيتوڻيڪ هڪ تمام پيداوار وارو. منهنجو مطلب ڇا آهي؟ اسان جي منصوبي جي شروعات ۾، اسان گراهڪن جي وچ ۾ اهو تاثر پيدا ڪيو ته هاڻي اسان هڪ نئون تيز ڊيٽابيس آڻينداسين ۽ اسان رهنداسين! عمل تيز ٿي ويندا، سڀ ڪجھ ٺيڪ ٿي ويندو. حقيقت ۾، ٽيڪنالاجي انهن مسئلن کي حل نه ڪندو آهي جيڪي ڪاروباري عمل آهن، ڇاڪاڻ ته ڪاروباري عمل ماڻهو آهن. ۽ توهان کي ماڻهن سان ڪم ڪرڻ جي ضرورت آهي، ٽيڪنالاجي نه.
ٽيسٽ تي مبني ترقي دردناڪ ۽ شروعاتي مرحلن ۾ وقت سازي ٿي سگهي ٿي. پر ان جو مثبت اثر مختصر مدت ۾ به قابل ذڪر هوندو، جڏهن توهان کي رجعت جي جاچ ڪرڻ لاءِ ڪجهه ڪرڻ جي ضرورت ناهي.
اهو تمام ضروري آهي ته ترقي جي سڀني مرحلن تي لوڊ ٽيسٽ کي منظم ڪرڻ. جيترو جلدي توهان فن تعمير ۾ ڪجهه نقص محسوس ڪندا، ان کي درست ڪرڻ آسان ٿي ويندو، جيڪو مستقبل ۾ توهان جو گهڻو وقت بچائيندو.
لوا سان ڪجھ به غلط ناهي. ڪو به ماڻهو ان ۾ لکڻ سکي سگهي ٿو: جاوا ڊولپر، جاوا اسڪرپٽ ڊولپر، پٿون ڊولپر، فرنٽ-اينڊ يا پوئتي-اينڊ. اسان جا تجزيا نگار به ان تي لکن ٿا.
جڏهن اسان حقيقت جي باري ۾ ڳالهايون ٿا ته اسان وٽ SQL ناهي، اهو ماڻهن کي خوفزده ڪري ٿو. "توهان SQL کان سواء ڊيٽا ڪيئن حاصل ڪندا؟ ڇا اهو ممڪن آهي؟ يقينن. OLTP ڪلاس سسٽم ۾، SQL جي ضرورت ناهي. ڪجھھ قسم جي ٻولي جي صورت ۾ ھڪڙو متبادل آھي جيڪو توھان کي فوري طور تي ھڪڙي دستاويز تي مبني ڏسڻ ڏانھن موٽائي ٿو. مثال طور، GraphQL. ۽ ورهايل ڪمپيوٽنگ جي صورت ۾ ھڪڙو متبادل آھي.
جيڪڏھن توھان سمجھو ٿا ته توھان کي ماپ ڪرڻ جي ضرورت پوندي، پوءِ پنھنجي حل کي Tarantool تي اھڙي طرح ٺاھيو ته جيئن اھو متوازي طور تي ھلائي سگھي. جيڪڏهن توهان ائين نه ڪيو، اهو بعد ۾ ڏکيو ۽ ڏکوئيندڙ ٿيندو، ڇو ته Tarantool صرف هڪ پروسيسر ڪور کي مؤثر طريقي سان استعمال ڪري سگهي ٿو.
جو ذريعو: www.habr.com