اسان سڀ ڪهاڻيون پيار ڪندا آهيون. اسان کي باهه جي چوڌاري ويهڻ ۽ اسان جي ماضي جي فتوحات، جنگين، يا صرف اسان جي ڪم جي تجربي بابت ڳالهائڻ پسند آهي.
اڄ اهڙو ڏينهن آهي. ۽ جيتوڻيڪ توهان هن وقت باهه تي نه آهيو، اسان وٽ توهان لاء هڪ ڪهاڻي آهي. ڪهاڻي ڪيئن اسان Tarantool تي اسٽوريج سان ڪم ڪرڻ شروع ڪيو.
هڪ دفعي، اسان جي ڪمپني وٽ ڪجهه ”مونولٿس“ ۽ سڀني لاءِ هڪ ”ڇت“ هوندي هئي، جن ڏانهن اهي مونولٿس آهستي آهستي پر يقيني طور تي پهچي رهيا هئا، اسان جي ڪمپني جي اڏام کي محدود ڪندي، اسان جي ترقي. ۽ اتي هڪ واضح سمجهه هئي: هڪ ڏينهن اسان هن ڇت کي سخت مارينداسين.
اهو هاڻي هر شيءِ ۽ هر ڪنهن کي الڳ ڪرڻ جو غالب نظريو آهي، سامان کان وٺي ڪاروباري منطق تائين. نتيجي طور، اسان وٽ، مثال طور، ٻه ڊي سي آهن جيڪي عملي طور تي نيٽ ورڪ جي سطح تي آزاد آهن. ۽ پوء هر شيء بلڪل مختلف هئي.
اڄ، CI/CD، K8S وغيره جي صورت ۾ تبديليون ڪرڻ لاءِ ڪيترائي اوزار ۽ اوزار موجود آهن. ”مونوليٿڪ“ وقت ۾، اسان کي ايتريون غير ملڪي لفظن جي ضرورت نه هئي. اهو صرف ڊيٽابيس ۾ "اسٽوريج" کي درست ڪرڻ لاء ڪافي هو.
پر وقت اڳتي وڌندو ويو، ۽ درخواستن جو تعداد ان سان گڏ اڳتي وڌيو، ڪڏهن ڪڏهن آر پي ايس کي اسان جي صلاحيتن کان وڌيڪ شوٽنگ. مارڪيٽ ۾ CIS ملڪن جي داخل ٿيڻ سان، پهرين مونولٿ جي ڊيٽابيس پروسيسر تي لوڊ 90 سيڪڙو کان گهٽ نه ٿيو، ۽ آر پي ايس 2400 جي سطح تي رهي. ۽ اهي صرف ننڍا چونڊيندڙ نه هئا، پر وڏا سوال هئا. چيڪ ۽ JOINs جو گروپ جيڪو وڏي IO جي پس منظر جي خلاف تقريبا اڌ ڊيٽا لاء هلائي سگھي ٿو.
جڏهن مڪمل طور تي بليڪ فرائيڊي سيلز منظر تي ظاهر ٿيڻ شروع ڪيو - ۽ وائلڊ بيريز انهن مان هڪ هو جنهن کي روس ۾ منعقد ڪيو ويو - صورتحال مڪمل طور تي اداس ٿي وئي. سڀ کان پوء، اهڙي ڏينهن تي لوڊ ٽي ڀيرا وڌي ٿو.
اوه، هي ”مونوليٿڪ ٽائيم“! مون کي پڪ آھي ته توھان ڪجھھ ساڳيو تجربو ڪيو آھي، ۽ توھان اڃا تائين نه سمجھندا آھيو ته اھو توھان سان ڪيئن ٿي سگھي ٿو.
توهان ڇا ڪري سگهو ٿا - فيشن ٽيڪنالاجي ۾ موروثي آهي. اٽڪل 5 سال اڳ، اسان کي .NET ۽ MS SQL سرور تي موجود سائيٽ جي صورت ۾ انهن مان هڪ موڊ تي ٻيهر سوچڻو هو، جيڪو احتياط سان پنهنجي سائيٽ جي سڀني منطق کي محفوظ ڪري ٿو. مون ان کي ايترو احتياط سان رکيو آهي ته اهڙي اڪيلي سر کي ڏسڻ هڪ ڊگهو ۽ بلڪل آسان نه هو.
هڪ ننڍڙو تڪرار.
مختلف واقعن تي مان چوان ٿو: "جيڪڏهن توهان هڪ سنگت نه ڏٺو، ته پوء توهان نه وڌو!" مان هن معاملي تي توهان جي راء ۾ دلچسپي وٺان ٿو، مهرباني ڪري تبصرن ۾ لکندا.
گجگوڙ جو آواز
اچو ته اسان جي "الون فائر" ڏانهن واپس وڃو. "مونوليٿڪ" ڪارڪردگي جي لوڊ کي ورهائڻ لاء، اسان سسٽم کي ورهائڻ جو فيصلو ڪيو مائڪرو سروسز ۾ اوپن سورس ٽيڪنالاجيز جي بنياد تي. ڇاڪاڻ ته، گهٽ ۾ گهٽ، اهي پيماني تي سستا آهن. ۽ اسان کي 100٪ سمجھ هئي ته اسان کي ماپ ڪرڻو پوندو (۽ گهڻو ڪجهه). سڀ کان پوء، اڳ ۾ ئي ان وقت پاڙيسري ملڪن جي مارڪيٽ ۾ داخل ٿيڻ ممڪن هو، ۽ رجسٽريشن جو تعداد، گڏو گڏ حڪم جو تعداد، اڃا به وڌيڪ مضبوطيء سان وڌڻ لڳو.
monolith کان microservices ڏانهن روانگي لاءِ پهرين اميدوارن جو تجزيو ڪندي، اسان محسوس ڪيو ته انهن ۾ 80 سيڪڙو لکڻيون پوئين آفيس جي سسٽم مان اينديون آهن، ۽ پڙهڻ واري آفيس مان. سڀ کان پهريان، هي اسان لاءِ ڪجهه اهم سب سسٽم متعلق آهي - صارف جي ڊيٽا ۽ اضافي ڪسٽمر رعايتن ۽ ڪوپن بابت معلومات جي بنياد تي سامان جي آخري قيمت جي حساب لاءِ هڪ نظام.
داخل ٿيل. هاڻي اهو تصور ڪرڻ خوفناڪ آهي، پر مٿي ذڪر ڪيل سب سسٽم کان علاوه، پراڊڪٽ ڪيٽلاگ، هڪ صارف شاپنگ ڪارٽ، هڪ پراڊڪٽ سرچ سسٽم، پراڊڪٽ جي فهرستن لاءِ فلٽرنگ سسٽم، ۽ مختلف قسم جا سفارشي نظام پڻ اسان جي مونولٿ مان هٽايا ويا. انهن مان هر هڪ جي آپريشن لاء، اتي تنگ ٺهيل نظام جي جدا جدا طبقن آهن، پر هڪ ڀيري اهي سڀ هڪ "گهر" ۾ رهندو هو.
اسان فوري طور تي منصوبابندي ڪئي ته اسان جي ڪلائنٽ بابت ڊيٽا کي ڇڪيل سسٽم ڏانهن منتقل ڪيو وڃي. سامان جي آخري قيمت کي ڳڻڻ لاءِ ڪارڪردگيءَ کي ختم ڪرڻ لاءِ پڙهڻ لاءِ سٺي اسڪاليبلٽي جي ضرورت آهي، ڇاڪاڻ ته اهو تمام وڏو RPS لوڊ پيدا ڪيو ۽ ڊيٽابيس لاءِ عمل ڪرڻ تمام ڏکيو هو (ڪيترائي ڊيٽا حساب جي عمل ۾ شامل آهي).
نتيجي طور، اسان ھڪڙي اسڪيم سان گڏ آيا آھيو جيڪو چڱيءَ طرح سان ٺھي ٿو Tarantool.
ان وقت، microservices جي آپريشن لاء، ورچوئل ۽ هارڊويئر مشينن تي ڪيترن ئي ڊيٽا مرڪز سان ڪم ڪرڻ لاء اسڪيمون چونڊيو ويو. جيئن انگن اکرن ۾ ڏيکاريل آهي، ٽرانٽول نقل جا اختيار ٻنهي ماسٽر-ماسٽر ۽ ماسٽر-غلام طريقن ۾ لاڳو ڪيا ويا.
آرڪيٽيڪچر. اختيار 1. استعمال ڪندڙ جي خدمت
هن وقت، 24 شارڊز آهن، جن مان هر هڪ ۾ 2 مثال آهن (هر هڪ ڊي سي لاءِ)، سڀ ماسٽر-ماسٽر موڊ ۾ آهن.
ڊيٽابيس جي چوٽي تي ايپليڪيشنون آهن جيڪي ڊيٽابيس جي نقلن تائين رسائي ڪن ٿيون. ايپليڪيشنون اسان جي ڪسٽم لائبريري ذريعي Tarantool سان ڪم ڪن ٿيون، جيڪو Tarantool Go ڊرائيور انٽرفيس کي لاڳو ڪري ٿو. هوءَ سڀني نقلن کي ڏسي ٿي ۽ پڙهڻ ۽ لکڻ لاءِ ماسٽر سان ڪم ڪري سگهي ٿي. لازمي طور تي، اهو ريپليڪا سيٽ ماڊل کي لاڳو ڪري ٿو، جيڪو ريپليڪس کي چونڊڻ لاء منطق شامل ڪري ٿو، ٻيهر ڪوششون، سرڪٽ برڪر ۽ شرح جي حد.
انهي صورت ۾، اهو ممڪن آهي ته ريپليڪا جي چونڊ پاليسي کي ترتيب ڏيڻ لاء شارڊ جي حوالي سان. مثال طور، roundrobin.
آرڪيٽيڪچر. اختيار 2. سامان جي آخري قيمت جي حساب لاء خدمت
ڪجھ مهينا اڳ، سامان جي آخري قيمت کي ڳڻڻ لاء سڀ کان وڌيڪ درخواستون هڪ نئين خدمت ڏانهن ويا، جيڪا اصول ۾، ڊيٽابيس کان سواء ڪم ڪري ٿي، پر ڪجهه وقت اڳ، هر شيء 100٪ تي عمل ڪيو ويو هود تحت Tarantool جي خدمت سان.
سروس ڊيٽابيس 4 ماسٽرن تي مشتمل آهي جنهن ۾ هم وقت ساز ڊيٽا گڏ ڪري ٿو، ۽ انهن مان هر هڪ ريپليڪيشن ماسٽر ڊيٽا کي صرف پڙهڻ لاءِ ورهائي ٿو. هر ماسٽر وٽ لڳ ڀڳ 15 اهڙيون نقلون آهن.
يا ته پهرين يا ٻئي اسڪيم ۾، جيڪڏهن هڪ ڊي سي دستياب ناهي، ايپليڪيشن ٻئي ۾ ڊيٽا حاصل ڪري سگهي ٿي.
اهو قابل ذڪر آهي ته ٽرانٽول ۾ نقل ڪافي لچڪدار آهي ۽ رن ٽائم تي ترتيب ڏئي سگهجي ٿو. ٻين سسٽم ۾، مشڪلات پيدا ٿي. مثال طور، PostgreSQL ۾ max_wal_senders ۽ max_replication_slots پيرا ميٽرز کي تبديل ڪرڻ لاءِ وزرڊ کي ٻيهر شروع ڪرڻ جي ضرورت آھي، جيڪا ڪجھ ڪيسن ۾ ايپليڪيشن ۽ DBMS جي وچ ۾ ڪنيڪشن کي ختم ڪري سگھي ٿي.
ڳولهيو ۽ توهان ڳوليندا!
اسان اهو ڇو نه ڪيو "عام ماڻهن وانگر"، پر هڪ غير معمولي طريقو چونڊيو؟ اهو ان تي منحصر آهي جيڪو عام سمجهيو ويندو آهي. ڪيترائي عام طور تي مونگو مان هڪ ڪلستر ٺاهيندا آهن ۽ ان کي ٽن جيو ورهايل ڊي سي ۾ پکڙيل آهن.
ان وقت، اسان وٽ اڳ ۾ ئي ٻه ريڊس منصوبا هئا. پهريون هڪ ڪيش هو، ۽ ٻيو هڪ مسلسل اسٽوريج هو نه تمام نازڪ ڊيٽا لاء. اهو هن سان ڪافي ڏکيو هو، جزوي طور تي اسان جي غلطي ذريعي. ڪڏھن ڪڏھن ڪڏھن ڪڏھن وڏي مقدار ۾ ھوا، ۽ وقت بوقت سائيٽ خراب ٿي وئي. اسان هن سسٽم کي ماسٽر-غلام ورزن ۾ استعمال ڪيو. ۽ اهڙا ڪيترائي ڪيس هئا جتي ماسٽر سان ڪجهه ٿيو ۽ نقل ڀڄي ويو.
اھو آھي، ريڊس غير ملڪي ڪمن لاءِ سٺو آھي، رياستي ڪمن لاءِ نه. اصول ۾، اهو سڀ کان وڌيڪ مسئلا حل ڪرڻ جي اجازت ڏئي ٿو، پر صرف ان صورت ۾ جيڪڏهن اهي اهم-قدر حل هئا انڊيڪس جي هڪ جوڙي سان. پر ريڊيس ان وقت مسلسل ۽ نقل سان ڪافي اداس هو. ان کان علاوه ڪارڪردگي بابت شڪايتون هيون.
اسان MySQL ۽ PostgreSQL بابت سوچيو. پر پھريون ڪنھن به طرح اسان وٽ نه آيو، ۽ ٻيو ھڪڙو پاڻ ۾ ھڪڙو نفيس پراڊڪٽ آھي، ۽ ان تي سادي خدمتن کي تعمير ڪرڻ غير مناسب ٿيندو.
اسان ڪوشش ڪئي RIAK، Cassandra، حتي هڪ گراف ڊيٽابيس. اهي سڀئي مناسب حل آهن جيڪي خدمتون ٺاهڻ لاء عام آفاقي اوزار جي ڪردار لاء مناسب نه هئا.
آخرڪار اسان Tarantool تي آباد ٿياسين.
اسان ان ڏانهن رخ ڪيو جڏهن اهو نسخو 1.6 ۾ هو. اسان ان ۾ دلچسپي وٺندا هئاسين اهم-قدر جي symbiosis ۽ هڪ تعلقي ڊيٽابيس جي ڪارڪردگي. هتي ثانوي انڊيڪس، ٽرانزيڪشن ۽ اسپيس آهن، اهي ٽيبل وانگر آهن، پر سادو نه آهن، توهان انهن ۾ مختلف نمبرن جي ڪالمن کي ذخيرو ڪري سگهو ٿا. پر Tarantool جي قاتل خصوصيت ثانوي انڊيڪسس هئي، جنهن ۾ اهم-قدر ۽ ٽرانزيڪشن سان گڏ.
جوابي روسي ڳالهائيندڙ ڪميونٽي، چيٽ ۾ مدد ڪرڻ لاء تيار، پڻ ڪردار ادا ڪيو. اسان هن کي فعال طور تي استعمال ڪيو ۽ سڌو سنئون چيٽ ۾ رهن ٿا. ۽ واضح غلطين ۽ غلطين کان سواءِ مهذب لڳاتار جي باري ۾ نه وساريو. جيڪڏهن توهان Tarantool سان اسان جي تاريخ تي نظر رکون ٿا، اسان کي نقل ڪرڻ سان تمام گهڻو درد ۽ ناڪامي هئي، پر اسان ان جي غلطي جي ڪري ڊيٽا کي ڪڏهن به نه وڃائي ڇڏيو!
عمل درآمد هڪ خراب شروع ٿي ويو
ان وقت، اسان جو مکيه ڊولپمينٽ اسٽيڪ .NET هو، جنهن ۾ Tarantool لاءِ ڪو به ڪنيڪٽر نه هو. اسان فوري طور تي گو ۾ ڪجهه ڪرڻ شروع ڪيو. اهو لوا سان پڻ سٺو ڪم ڪيو. ان وقت جو بنيادي مسئلو ڊيبگنگ سان هو: .NET ۾ ان سان گڏ سڀ ڪجهه تمام سٺو آهي، پر ان کان پوءِ ايمبيڊڊ لوا جي دنيا ۾ وڃڻ ڏکيو ٿي پيو، جڏهن توهان وٽ لاگس کانسواءِ ڪا به ڊيبگنگ نه هئي. ان کان سواء، ڪجهه سببن لاء نقل وقتي طور تي الڳ ٿي ويو، تنهنڪري مون کي ٽرانٽول انجڻ جي جوڙجڪ ۾ وڃڻو پيو. چيٽ هن سان مدد ڪئي، ۽ گهٽ حد تائين، دستاويز؛ ڪڏهن ڪڏهن اسان ڪوڊ کي ڏٺو. ان وقت، دستاويز بلڪل ائين هو.
تنهن ڪري، ڪيترن ئي مهينن جي دوران، مون پنهنجي سر جي چوڌاري حاصل ڪرڻ ۽ Tarantool سان ڪم ڪرڻ جا سٺا نتيجا حاصل ڪيا. اسان گٽ ۾ ريفرنس ڊولپمينٽ مرتب ڪيو جيڪي نئين مائڪرو سروسز جي ٺهڻ ۾ مدد ڪن ٿيون. مثال طور، جڏهن هڪ ڪم پيدا ٿيو: هڪ ٻيو microservice ٺاهڻ لاء، ڊولپر ريفرنس جي حل جي سورس ڪوڊ کي مخزن ۾ ڏٺو، ۽ اهو هڪ نئين ٺاهڻ ۾ هڪ هفتي کان وڌيڪ نه ورتو.
اهي خاص وقت هئا. روايتي طور تي، پوءِ توھان وڃي سگھوٿا منتظم ڏانھن ايندڙ ٽيبل تي ۽ پڇو: ”مون کي ھڪ ورچوئل مشين ڏيو. اٽڪل ٽيهن منٽن کان پوءِ ڪار اڳ ۾ ئي توهان سان گڏ هئي. توهان پنهنجو پاڻ کي ڳنڍيو، هر شيء کي نصب ڪيو، ۽ ٽرئفڪ توهان ڏانهن موڪليو ويو.
اڄ اهو وڌيڪ ڪم نه ڪندو: توهان کي خدمت ۾ مانيٽرنگ ۽ لاگنگ شامل ڪرڻ جي ضرورت آهي، ڪارڪردگي کي ٽيسٽ سان ڍڪڻ، هڪ ورچوئل مشين آرڊر ڪرڻ يا ڪبر کي پهچائڻ، وغيره. عام طور تي، اهو طريقو بهتر ٿيندو، جيتوڻيڪ اهو وڌيڪ وقت وٺندو ۽ وڌيڪ ڏکيو ٿيندو.
ورهايو ۽ حڪومت ڪريو. لوا سان ڪهڙو معاملو آهي؟
اتي هڪ سنگين دشمني هئي: ڪجهه ٽيمون قابل اعتماد طريقي سان سروس ۾ تبديلين کي رول آئوٽ ڪرڻ کان قاصر هيون لوا ۾ تمام گهڻي منطق سان. اهو اڪثر ڪري خدمت نه ڪرڻ سان گڏ هوندو هو.
اهو آهي، ڊولپر ڪجهه قسم جي تبديلي تيار ڪري رهيا آهن. Tarantool لڏپلاڻ ڪرڻ شروع ڪري ٿو، پر نقل اڃا تائين پراڻي ڪوڊ سان آهي؛ ڪجھ ڊي ڊي ايل يا ٻيو ڪجھ اچي ٿو اتي نقل جي ذريعي، ۽ ڪوڊ صرف ڌار ٿي ويندو آھي ڇاڪاڻ ته اھو حساب ۾ نه ورتو ويو آھي. نتيجي طور، منتظمين لاء تازه ڪاري جي طريقيڪار A4 شيٽ تي رکيل هئي: نقل بند ڪريو، هن کي اپڊيٽ ڪريو، نقل کي بند ڪريو، هتي بند ڪريو، اتي تازه ڪاري ڪريو. رات جو خواب!
نتيجي طور، هاڻي اسان گهڻو ڪري لوا ۾ ڪجھ به نه ڪرڻ جي ڪوشش ڪندا آهيون. بس استعمال ڪريو iproto (سرور سان رابطي لاء هڪ بائنري پروٽوڪول)، ۽ اهو آهي. شايد اهو ڊولپرز جي وچ ۾ ڄاڻ جي کوٽ آهي، پر هن نقطي نظر کان سسٽم پيچيده آهي.
اسان هميشه ان اسڪرپٽ جي پيروي نه ڪندا آهيون. اڄ اسان وٽ ڪارو ۽ اڇو نه آهي: يا ته هر شيء لوا ۾ آهي، يا هر شيء گو ۾ آهي. اسان اڳ ۾ ئي سمجهون ٿا ته اسان انهن کي ڪيئن گڏ ڪري سگهون ٿا ته جيئن اسان بعد ۾ لڏپلاڻ جي مسئلن سان ختم نه ڪريون.
Tarantool هاڻي ڪٿي آهي؟
Tarantool خدمت ۾ استعمال ڪيو ويندو آهي ڳڻپ ڪرڻ لاءِ سامان جي آخري قيمت جي حساب سان رعايتي ڪوپنن کي، جنهن کي ”پروموٽر“ پڻ چيو ويندو آهي. جيئن مون اڳ ۾ چيو هو، هو هاڻي رٽائر ٿي رهيو آهي: هو اڳ ۾ ڪيل قيمتن سان هڪ نئين ڪيٽلاگ سروس سان تبديل ٿي رهيو آهي، پر ڇهه مهينا اڳ پروموٽائيزر ۾ سڀ حساب ڪيا ويا. اڳي، ان جو اڌ منطق لوا ۾ لکيل هو. ٻه سال اڳ، سروس کي اسٽوريج جي سهولت ۾ تبديل ڪيو ويو، ۽ منطق گو ۾ ٻيهر لکيو ويو، ڇاڪاڻ ته رعايت جي ميڪانيڪس ٿورو تبديل ٿي چڪو هو ۽ خدمت جي ڪارڪردگي نه هئي.
سڀ کان وڌيڪ نازڪ خدمتن مان هڪ آهي صارف پروفائل. يعني، سڀ Wildberries استعمال ڪندڙ Tarantool ۾ محفوظ ٿيل آهن، ۽ انهن مان اٽڪل 50 ملين آهن. صارف جي ID سان شارڊ ٿيل هڪ سسٽم، ڪيترن ئي DCs ۾ ورهايل آهي جيڪو Go سروسز سان ڳنڍيل آهي.
آر پي ايس جي مطابق، پروموٽر هڪ ڀيرو اڳواڻ هو، 6 هزار درخواستن تائين پهچي ويو. هڪ وقت اسان وٽ 50-60 ڪاپيون هيون. ھاڻي RPS ۾ ليڊر آھي يوزر پروفائلز، اٽڪل 12 ھزار. ھي سروس ڪسٽم شارڊنگ استعمال ڪري ٿي، استعمال ڪندڙ IDs جي حدن سان ورهايل آھي. خدمت 20 مشينن کان وڌيڪ ڪم ڪري ٿو، پر اهو تمام گهڻو آهي؛ اسان مختص ڪيل وسيلن کي گهٽائڻ جو منصوبو ڪريون ٿا، ڇاڪاڻ ته 4-5 مشينن جي گنجائش ان لاء ڪافي آهي.
سيشن سروس vshard ۽ ڪارٽريج تي اسان جي پهرين خدمت آهي. vshard کي ترتيب ڏيڻ ۽ ڪارٽريج کي اپڊيٽ ڪرڻ لاءِ اسان کان ڪجهه ڪوشش جي ضرورت آهي، پر آخر ۾ سڀ ڪجهه ڪم ٿي ويو.
ويب سائيٽ ۽ موبائيل ايپليڪيشن ۾ مختلف بينر ڏيکارڻ جي سروس پهرين هئي جيڪا سڌي طرح Tarantool تي جاري ڪئي وئي. هي خدمت قابل ذڪر آهي حقيقت اها آهي ته اها 6-7 سال پراڻي آهي، اهو اڃا تائين آپريشن ۾ آهي ۽ ڪڏهن به ريبوٽ نه ڪيو ويو آهي. ماسٽر-ماسٽر نقل استعمال ڪيو ويو. ڪجھ به نه ڀڃي.
اتي ھڪڙو مثال آھي Tarantool استعمال ڪرڻ لاءِ جلدي ريفرنس جي ڪارڪردگي لاءِ گودام سسٽم ۾ ڪجھ ڪيسن ۾ معلومات کي ڊبل چيڪ ڪرڻ لاءِ. اسان ان لاءِ Redis استعمال ڪرڻ جي ڪوشش ڪئي، پر ميموري ۾ موجود ڊيٽا Tarantool کان وڌيڪ جاءِ ورتي.
ويٽنگ لسٽ جون خدمتون، ڪلائنٽ سبسڪرپشن، في الحال فيشني ڪهاڻيون ۽ ڊفر ٿيل سامان پڻ Tarantool سان ڪم ڪن ٿيون. ياداشت ۾ آخري خدمت لڳ ڀڳ 120 GB تائين. هي مٿي ڏنل سڀ کان وڌيڪ جامع خدمت آهي.
ٿڪل
مھرباني ڪري ثانوي انڊيڪسس جي گڏيل قدر ۽ ٽرانزيڪشن سان گڏ، Tarantool چڱيءَ طرح موزون آھي مائڪرو سروسز تي ٻڌل آرڪيٽيڪچرز لاءِ. تنهن هوندي، اسان کي مشڪلاتن جو سامنا ٿيو جڏهن Lua ۾ تمام گهڻي منطق سان خدمتن ۾ تبديلين کي رول آئوٽ ڪيو - خدمتون اڪثر ڪري ڪم ڪرڻ بند ڪري ڇڏيون. اسان ان تي غالب نه ٿي سگهياسين، ۽ وقت گذرڻ سان گڏ اسان لوا ۽ گو جي مختلف مجموعن تي پهتاسين: اسان ڄاڻون ٿا ته هڪ ٻولي ڪٿي استعمال ڪجي ۽ ڪٿي ٻي استعمال ڪجي.
موضوع تي ٻيو ڇا پڙهو
- Tarantool استعمال ڪندي شروع کان هڪ اعلي لوڊ ايپليڪيشن ٺاهڻ
- ٽرانٽول ڪارٽريج ۾ قابل اعتماد اڳواڻ چونڊ
- ٽيليگرام چينل Tarantool پيداوار جي خبرن سان
- ڪميونٽي چيٽ ۾ Tarantool تي بحث ڪريو
جو ذريعو: www.habr.com