ورهايل ايپليڪيشنن جي بلڊنگ بلاڪ. ٻيو لڳ ڀڳ

اعلان

ساٿيو، اونهاري جي وچ ۾ آئون قطار واري نظام جي ڊيزائن تي آرٽيڪل جو هڪ ٻيو سلسلو جاري ڪرڻ جو ارادو ڪريان ٿو: “The VTrade Experiment” - واپاري نظام لاءِ فريم ورڪ لکڻ جي ڪوشش. سيريز هڪ بدلي، نيلام ۽ اسٽور جي تعمير جي نظريي ۽ عمل کي جانچيندو. مضمون جي آخر ۾، آئون توهان کي دعوت ڏيان ٿو ووٽ ڏيڻ لاءِ انهن عنوانن لاءِ جيڪي توهان جي تمام گهڻي دلچسپي رکن ٿا.

ھي آخري مضمون آھي سيريز ۾ تقسيم ٿيل رد عمل واري ايپليڪيشنن تي Erlang/Elixir ۾. IN پهريون مضمون توهان رد عمل واري فن تعمير جا نظرياتي بنياد ڳولي سگهو ٿا. ٻيو آرٽيڪل اهڙي نظام جي تعمير لاء بنيادي نمونن ۽ ميڪانيزم کي بيان ڪري ٿو.

اڄ اسان عام طور تي ڪوڊ بنيادي ۽ منصوبن جي ترقي جي مسئلن کي اٿارينداسين.

خدمتن جي تنظيم

حقيقي زندگي ۾، جڏهن هڪ خدمت ٺاهيندي، توهان کي اڪثر هڪ ڪنٽرولر ۾ ڪيترن ئي رابطي جي نمونن کي گڏ ڪرڻو پوندو. مثال طور، صارفين جي خدمت، جيڪا پروجيڪٽ جي صارف پروفائلز کي منظم ڪرڻ جو مسئلو حل ڪري ٿي، req-resp جي درخواستن جو جواب ڏيڻ ۽ پب-سب ذريعي پروفائل اپڊيٽ جي رپورٽ ڪرڻ گهرجي. اهو معاملو بلڪل سادو آهي: پيغام ڏيڻ جي پويان هڪ ڪنٽرولر آهي جيڪو سروس منطق کي لاڳو ڪري ٿو ۽ تازه ڪاريون شايع ڪري ٿو.

صورتحال وڌيڪ پيچيده ٿي ويندي آهي جڏهن اسان کي هڪ غلطي برداشت ڪرڻ واري ورهايل خدمت کي لاڳو ڪرڻ جي ضرورت آهي. اچو ته تصور ڪريون ته صارفين جون گهرجون تبديل ٿي ويون آهن:

1. هاڻي خدمت کي 5 ڪلستر نوڊس تي درخواستن تي عمل ڪرڻ گهرجي،
2. پس منظر پروسيسنگ ڪمن کي انجام ڏيڻ جي قابل ٿي،
3. ۽ پروفائل اپڊيٽ لاءِ رڪنيت جي فهرستن کي متحرڪ طور تي منظم ڪرڻ جي قابل پڻ.

ويچار: اسان مسلسل اسٽوريج ۽ ڊيٽا جي نقل جي مسئلي تي غور نه ڪندا آهيون. اچو ته فرض ڪريون ته اهي مسئلا اڳ ۾ حل ڪيا ويا آهن ۽ سسٽم اڳ ۾ ئي هڪ قابل اعتماد ۽ اسپيبلبل اسٽوريج پرت آهي، ۽ هٿيارن کي ان سان رابطو ڪرڻ لاء ميڪانيزم آهي.

صارفين جي خدمت جي رسمي وضاحت وڌيڪ پيچيده ٿي چڪي آهي. پروگرامر جي نقطي نظر کان، تبديليون گهٽ ۾ گهٽ آهن پيغام جي استعمال جي ڪري. پهرين گهرج کي پورو ڪرڻ لاءِ، اسان کي ضرورت آهي ته بيلنس کي ترتيب ڏيڻ جي req-resp ايڪسچينج پوائنٽ تي.

پس منظر جي ڪمن کي پروسيس ڪرڻ جي ضرورت اڪثر ڪري ٿي. صارفين ۾، اهو ٿي سگهي ٿو صارف جي دستاويزن کي جانچڻ، پروسيسنگ ڊائون لوڊ ٿيل ملٽي ميڊيا، يا ڊيٽا کي هم وقت سازي سوشل ميڊيا سان. نيٽ ورڪ انهن ڪمن کي ڪنهن به طرح ڪلستر جي اندر ورهائڻ جي ضرورت آهي ۽ عملدرآمد جي ترقي جي نگراني ڪئي وڃي. تنهن ڪري، اسان وٽ حل جا ٻه آپشن آهن: يا ته پوئين آرٽيڪل مان ٽاسڪ ڊسٽريبيوشن ٽيمپليٽ استعمال ڪريو، يا، جيڪڏهن اهو مناسب نه هجي، هڪ ڪسٽم ٽاسڪ شيڊيولر لکو جيڪو پروسيسرز جي پول کي منظم ڪندو جيئن اسان جي ضرورت آهي.

پوائنٽ 3 کي پب-سب ٽيمپليٽ جي واڌ جي ضرورت آهي. ۽ عمل درآمد لاءِ، پب-سب ايڪسچينج پوائنٽ ٺاھڻ کان پوءِ، اسان کي ان پوائنٽ جي ڪنٽرولر کي اسان جي سروس ۾ شامل ڪرڻ جي ضرورت آھي. اهڙيء طرح، اهو آهي ته جيئن اسان پروسيسنگ سبسڪرپشن جي منطق کي منتقل ڪري رهيا آهيون ۽ پيغام جي پرت کان رڪنيت ختم ڪرڻ لاء صارفين جي عمل ۾.

نتيجي طور، مسئلي جي خراب ٿيڻ ڏيکاري ٿي ته ضرورتن کي پورو ڪرڻ لاء، اسان کي مختلف نوڊس تي سروس جا 5 مثال شروع ڪرڻ ۽ هڪ اضافي ادارو ٺاهڻ جي ضرورت آهي - هڪ پب-سب ڪنٽرولر، رڪنيت لاء ذميوار.
5 هينڊلر هلائڻ لاءِ، توهان کي سروس ڪوڊ تبديل ڪرڻ جي ضرورت ناهي. صرف اضافي عمل کي ترتيب ڏيڻ آهي توازن جي ضابطن جي بدلي واري نقطي تي، جنهن بابت اسان ٿوري دير بعد ڳالهائينداسين.
اتي پڻ ھڪڙو اضافي پيچيدگي آھي: پب-ذيلي ڪنٽرولر ۽ ڪسٽم ٽاسڪ شيڊولر کي ھڪڙي ڪاپي ۾ ڪم ڪرڻ گھرجي. ٻيهر، پيغام پهچائڻ جي خدمت، هڪ بنيادي طور تي، هڪ ليڊر چونڊڻ لاء هڪ ميکانيزم مهيا ڪرڻ گهرجي.

ليڊر جي چونڊ

ورهايل سسٽم ۾، ليڊر اليڪشن هڪ واحد عمل کي مقرر ڪرڻ جو طريقو آهي جيڪو ڪجهه لوڊ جي تقسيم ٿيل پروسيسنگ کي شيڊول ڪرڻ لاء ذميوار آهي.

سسٽم ۾ جيڪي مرڪزيت جو شڪار نه آهن، عالمگير ۽ اتفاق جي بنياد تي الگورتھم، جهڙوڪ پيڪسس يا راف، استعمال ٿيندا آهن.
جيئن ته پيغام پهچائڻ هڪ بروکر ۽ هڪ مرڪزي عنصر آهي، اهو سڀني سروس ڪنٽرولرز بابت ڄاڻي ٿو - اميدوار اڳواڻن. ميسيج بغير ووٽ جي اڳواڻ مقرر ڪري سگهي ٿو.

تبادلي واري نقطي کي شروع ڪرڻ ۽ ڳنڍڻ کان پوء، سڀني خدمتن کي سسٽم پيغام ملي ٿي #'$leader'{exchange = ?EXCHANGE, pid = LeaderPid, servers = Servers}. جيڪڏهن LeaderPid سان ٺهڪي اچي ٿو pid موجوده عمل، ان کي مقرر ڪيو ويو آهي اڳواڻ، ۽ فهرست Servers سڀني نوڊس ۽ انهن جي پيٽرولن تي مشتمل آهي.
هن وقت هڪ نئون ظاهر ٿئي ٿو ۽ هڪ ڪم ڪندڙ ڪلستر نوڊ ڊسڪ ڪيو ويو آهي، سڀ خدمت سنڀاليندڙ وصول ڪن ٿا #'$slave_up'{exchange = ?EXCHANGE, pid = SlavePid, options = SlaveOpts} и #'$slave_down'{exchange = ?EXCHANGE, pid = SlavePid, options = SlaveOpts} مطابق.

هن طريقي سان، سڀئي اجزاء سڀني تبديلين کان واقف آهن، ۽ ڪلستر کي ضمانت ڏني وئي آهي ته ڪنهن به وقت تي هڪ اڳواڻ هجي.

وچولي

پيچيده ورهايل پروسيسنگ عملن کي لاڳو ڪرڻ لاء، انهي سان گڏ هڪ موجوده فن تعمير کي بهتر ڪرڻ جي مسئلن ۾، اهو وچولي استعمال ڪرڻ آسان آهي.
سروس ڪوڊ کي تبديل نه ڪرڻ ۽ حل ڪرڻ لاء، مثال طور، اضافي پروسيسنگ، روٽنگ يا لاگنگ پيغام جا مسئلا، توهان سروس کان اڳ هڪ پراکسي هينڊلر کي فعال ڪري سگهو ٿا، جيڪو سڀني اضافي ڪم کي انجام ڏيندو.

Pub-sub Optimization جو هڪ شاندار مثال هڪ ڪاروباري ڪور سان ورهايل ايپليڪيشن آهي جيڪا تازه ڪاري واقعا پيدا ڪري ٿي، جهڙوڪ مارڪيٽ ۾ قيمتون تبديليون، ۽ هڪ رسائي پرت - N سرور جيڪي ويب ڪلائنٽ لاء ويب ساکٽ API مهيا ڪن ٿا.
جيڪڏهن توهان سر تي فيصلو ڪيو، پوء ڪسٽمر سروس هن طرح نظر اچي ٿو:

• ڪلائنٽ پليٽ فارم سان رابطا قائم ڪري ٿو. سرور جي پاسي تي جيڪو ٽرئفڪ کي ختم ڪري ٿو، ھڪڙو عمل شروع ڪيو ويو آھي ھن ڪنيڪشن کي خدمت ڪرڻ لاء.
• خدمت جي عمل جي حوالي سان، اختيار ۽ تازه ڪاري جي رڪنيت حاصل ٿئي ٿي. اهو عمل عنوانن لاءِ سبسڪرائب جو طريقو سڏي ٿو.
• هڪ دفعو هڪ واقعو ڪرنل ۾ پيدا ٿئي ٿو، اهو پروسيس تائين پهچايو ويندو آهي ڪنيڪشن جي خدمت ڪندي.

اچو ته تصور ڪريون ته اسان وٽ 50000 سبسڪرائبر آهن ”خبر“ جي موضوع تي. سبسڪرائبر 5 سرورن تي برابر ورهايل آهن. نتيجي طور، هر تازه ڪاري، ايڪسچينج پوائنٽ تي پهچڻ، 50000 ڀيرا نقل ڪيو ويندو: 10000 ڀيرا هر سرور تي، ان تي رڪنيت جي تعداد جي مطابق. هڪ تمام مؤثر منصوبو ناهي، صحيح؟
صورتحال کي بهتر ڪرڻ لاء، اچو ته هڪ پراکسي متعارف ڪرايو جنهن جو نالو ساڳيو آهي ايڪسچينج پوائنٽ. عالمي نالو رجسٽرار کي لازمي طور تي ويجھي عمل کي واپس ڪرڻ جي قابل هوندو نالو طرفان، اهو ضروري آهي.

اچو ته هن پراڪسي کي رسائي پرت سرورز تي لانچ ڪريون، ۽ اسان جا سڀئي عمل جيڪي ويب ساکٽ اي پي آئي جي خدمت ڪري رهيا آهن ان کي سبسڪرائب ڪندا، نه ته ڪرنل ۾ اصل پب-سب ايڪسچينج پوائنٽ ڏانهن. پراکسي صرف هڪ منفرد سبسڪرپشن جي صورت ۾ ڪور جي رڪنيت حاصل ڪري ٿو ۽ ايندڙ پيغام کي ان جي سڀني رڪنن ڏانهن نقل ڪري ٿو.
نتيجي طور، 5 جي بدران، 50000 پيغام ڪرنل ۽ رسائي سرور جي وچ ۾ موڪليا ويندا.

رستو ۽ توازن

Req- جواب

موجوده پيغام جي عمل ۾، 7 درخواستون ورهائڻ واريون حڪمت عمليون آهن:

• default. درخواست سڀني ڪنٽرولرز ڏانهن موڪلي وئي آهي.
• round-robin. درخواستون شمار ڪيا ويا آهن ۽ ڪنٽرولرز جي وچ ۾ سائيڪل طور تي ورهايل آهن.
• consensus. سنڀاليندڙ جيڪي خدمت ڪن ٿا، اڳواڻن ۽ غلامن ۾ ورهايل آهن. درخواستون صرف ليڊر ڏانهن موڪليا ويا آهن.
• consensus & round-robin. گروپ جو هڪ اڳواڻ آهي، پر درخواستون سڀني ميمبرن ۾ ورهايل آهن.
• sticky. هيش فنڪشن ڳڻپيو ويو آهي ۽ هڪ مخصوص هينڊلر کي لڳايو ويو آهي. هن دستخط سان گڏ ايندڙ درخواستون ساڳئي هينڊلر ڏانهن وڃو.
• sticky-fun. جڏهن مٽا سٽا واري نقطي کي شروع ڪندي، هيش حساب ڪتاب لاء فنڪشن sticky توازن رکڻ.
• fun. لچڪدار مذاق وانگر، صرف توهان ان کي اضافي طور تي ريڊريٽ ڪري سگھو ٿا، رد ڪري سگھو ٿا يا ان کان اڳ پروسيس ڪري سگھو ٿا.

تقسيم جي حڪمت عملي مقرر ڪئي وئي آهي جڏهن مٽا سٽا واري نقطي جي شروعات ڪئي وئي آهي.

توازن جي اضافي ۾، پيغام ڏيڻ توهان کي ادارن کي ٽيگ ڪرڻ جي اجازت ڏئي ٿي. اچو ته سسٽم ۾ ٽيگ جي قسمن کي ڏسو:

• ڪنيڪشن ٽيگ. اهو توهان کي سمجهڻ جي اجازت ڏئي ٿو ته ڪهڙي ڪنيڪشن ذريعي واقعا آيا آهن. استعمال ڪيو ويندو آهي جڏهن هڪ ڪنٽرولر پروسيس ساڳئي مٽا سٽا واري نقطي سان ڳنڍيندو آهي، پر مختلف رستن واري چابين سان.
• سروس ٽيگ. توهان کي هڪ خدمت لاءِ هينڊلرن کي گروپن ۾ گڏ ڪرڻ ۽ روٽنگ ۽ توازن جي صلاحيتن کي وڌائڻ جي اجازت ڏئي ٿي. req-resp نموني لاءِ، روئنگ لڪير آهي. اسان ايڪسچينج پوائنٽ ڏانهن هڪ درخواست موڪليندا آهيون، پوء اهو ان کي خدمت تي منتقل ڪري ٿو. پر جيڪڏهن اسان کي هينڊلرن کي منطقي گروپن ۾ ورهائڻ جي ضرورت آهي، پوء تقسيم ٽيگ استعمال ڪندي ڪيو ويندو آهي. جڏهن هڪ ٽيگ جي وضاحت ڪندي، درخواست موڪلي ويندي ڪنٽرولرز جي مخصوص گروپ ڏانهن.
• درخواست ٽيگ. توهان کي جوابن جي وچ ۾ فرق ڪرڻ جي اجازت ڏئي ٿي. جيئن ته اسان جو سسٽم هم وقت ساز آهي، خدمت جي جوابن کي پروسيس ڪرڻ لاءِ اسان کي ضرورت پوندي ته هڪ درخواست موڪلڻ وقت RequestTag بيان ڪري سگهون. ان مان اسان کي سمجهه ۾ اچي سگهنداسين ته ڪهڙي درخواست جو جواب اسان وٽ آيو.

پب-ذيلي

پب-سب لاءِ هر شي ٿورو آسان آهي. اسان وٽ ھڪڙو مٽا سٽا نقطو آھي جنھن تي پيغام شايع ٿيل آھن. ايڪسچينج پوائنٽ پيغامن کي ورهائي ٿو انهن رڪنن جي وچ ۾ جيڪي سبسڪرائب ڪيا آهن انهن جي روٽنگ ڪنجيز جي انهن کي ضرورت آهي (اسان چئي سگهون ٿا ته هي عنوانن سان هڪجهڙائي آهي).

اسڪاليبلٽي ۽ غلطي رواداري

مجموعي طور تي سسٽم جي اسپيبلبليت تي دارومدار رکي ٿو ته سسٽم جي تہن ۽ اجزاء جي اسپيبلبلٽي جي درجي تي:

• هن خدمت لاءِ هينڊلر سان گڏ ڪلستر ۾ اضافي نوڊس شامل ڪندي خدمتون ماپ ڪيون وينديون آهن. آزمائشي آپريشن دوران، توھان چونڊي سگھوٿا بھترين توازن واري پاليسي.
• ميسيجنگ سروس پاڻ هڪ الڳ ڪلستر جي اندر عام طور تي ماپي ويندي آهي يا ته خاص طور تي لوڊ ٿيل ايڪسچينج پوائنٽس کي الڳ ڪلستر نوڊس ڏانهن منتقل ڪندي، يا ڪلسٽر جي خاص طور تي لوڊ ٿيل علائقن ۾ پراکسي عمل شامل ڪندي.
• هڪ خاصيت جي طور تي پوري نظام جي اسپيبلٽي جو دارومدار فن تعمير جي لچڪ ۽ انفرادي ڪلستر کي هڪ عام منطقي وجود ۾ گڏ ڪرڻ جي صلاحيت تي آهي.

منصوبي جي ڪاميابي اڪثر ڪري اسڪيلنگ جي سادگي ۽ رفتار تي منحصر آهي. پيغام ان جي موجوده ورزن ۾ ايپليڪيشن سان گڏ وڌندو آهي. جيتوڻيڪ اسان وٽ 50-60 مشينن جو ڪلسٽر نه آهي، اسان وفاق ڏانهن رجوع ڪري سگهون ٿا. بدقسمتي سان، وفاق جو موضوع هن مضمون جي دائري کان ٻاهر آهي.

رزرويشن

جڏهن لوڊ بيلنس جو تجزيو ڪيو، اسان اڳ ۾ ئي بحث ڪيو آهي سروس ڪنٽرولرز جي بيڪارگي. بهرحال، پيغام ڏيڻ لازمي آهي ته محفوظ هجي. نوڊ يا مشين جي حادثي جي صورت ۾، پيغام خودڪار طريقي سان بحال ٿيڻ گهرجي، ۽ گهٽ ۾ گهٽ وقت ۾.

منهنجي منصوبن ۾ آئون اضافي نوڊس استعمال ڪريان ٿو جيڪي زوال جي صورت ۾ لوڊ کڻندا آهن. Erlang OTP ايپليڪيشنن لاءِ معياري ورهايل موڊ تي عملدرآمد آهي. ورهايل موڊ ناڪامي جي صورت ۾ وصولي انجام ڏئي ٿو ناڪامي ايپليڪيشن کي شروع ڪندي ٻي اڳوڻي شروع ڪيل نوڊ تي. اهو عمل شفاف آهي؛ هڪ ناڪامي کان پوء، ايپليڪيشن خودڪار طريقي سان ناڪامي نوڊ ڏانهن هلندو آهي. توھان وڌيڪ پڙھي سگھوٿا ھن ڪارڪردگي بابت هتي.

پيداوار

اچو ته ڪوشش ڪريون ته گهٽ ۾ گهٽ rabbitmq ۽ اسان جي ڪسٽم ميسيجنگ جي ڪارڪردگي جو مقابلو ڪريون.
مون لڌو سرڪاري نتيجا اوپن اسٽيڪ ٽيم کان rabbitmq جاچ.

پيراگراف 6.14.1.2.1.2.2 ۾. اصل دستاويز RPC CAST جو نتيجو ڏيکاري ٿو:

اسان اڳ ۾ OS kernel يا erlang VM تي ڪا به اضافي سيٽنگ نه ڪنداسين. ٽيسٽ جا شرط:

• erl opts: +A1 +sbtu.
• هڪ واحد erlang نوڊ اندر ٽيسٽ هڪ ليپ ٽاپ تي هلندي آهي هڪ پراڻي i7 موبائل ورزن ۾.
• ڪلستر ٽيسٽ 10G نيٽ ورڪ سان سرورز تي ڪيا ويندا آهن.
• ڪوڊ ڊاکر ڪنٽينرز ۾ هلندو آهي. نيٽ ورڪ NAT موڊ ۾.

ٽيسٽ ڪوڊ:

req_resp_bench(_) ->
  W = perftest:comprehensive(10000,
    fun() ->
      messaging:request(?EXCHANGE, default, ping, self()),
      receive
        #'$msg'{message = pong} -> ok
      after 5000 ->
        throw(timeout)
      end
    end
  ),
  true = lists:any(fun(E) -> E >= 30000 end, W),
  ok.

منظر 1: ٽيسٽ هڪ ليپ ٽاپ تي پراڻي i7 موبائل ورزن سان هلندي آهي. ٽيسٽ، پيغام ۽ خدمت تي عمل ڪيو ويو آھي ھڪڙي نوڊ تي ھڪڙي ڊاکر ڪنٽينر ۾:

Sequential 10000 cycles in ~0 seconds (26987 cycles/s)
Sequential 20000 cycles in ~1 seconds (26915 cycles/s)
Sequential 100000 cycles in ~4 seconds (26957 cycles/s)
Parallel 2 100000 cycles in ~2 seconds (44240 cycles/s)
Parallel 4 100000 cycles in ~2 seconds (53459 cycles/s)
Parallel 10 100000 cycles in ~2 seconds (52283 cycles/s)
Parallel 100 100000 cycles in ~3 seconds (49317 cycles/s)

منظر 2: 3 نوڊس ڊاڪر (NAT) جي تحت مختلف مشينن تي هلندڙ.

Sequential 10000 cycles in ~1 seconds (8684 cycles/s)
Sequential 20000 cycles in ~2 seconds (8424 cycles/s)
Sequential 100000 cycles in ~12 seconds (8655 cycles/s)
Parallel 2 100000 cycles in ~7 seconds (15160 cycles/s)
Parallel 4 100000 cycles in ~5 seconds (19133 cycles/s)
Parallel 10 100000 cycles in ~4 seconds (24399 cycles/s)
Parallel 100 100000 cycles in ~3 seconds (34517 cycles/s)

سڀني حالتن ۾، سي پي يو جي استعمال 250٪ کان وڌيڪ نه هئي

نتيجو

مون کي اميد آهي ته هي چڪر دماغ جي ڊمپ وانگر نه ٿو لڳي ۽ منهنجو تجربو ورهايل نظام جي محققن ۽ عملي جي ٻنهي لاءِ حقيقي فائدو ٿيندو جيڪي پنهنجي ڪاروباري نظام لاءِ ورهايل فن تعمير جي شروعات ۾ آهن ۽ دلچسپي سان Erlang/Elixir کي ڏسي رهيا آهن. پر شڪ آهي ته ان جي قيمت آهي ...

تصوير @chuttersnap

صرف رجسٽرڊ استعمال ڪندڙ سروي ۾ حصو وٺي سگهن ٿا. سائن ان ڪريو، توهان جي مهرباني.

VTrade Experiment سيريز جي حصي جي طور تي مون کي ڪھڙن موضوعن کي وڌيڪ تفصيل سان ڍڪڻ گھرجي؟

• نظريو: مارڪيٽ، آرڊر ۽ انهن جو وقت: ڏينهن، GTD، GTC، IOC، FOK، MOO، MOC، LOO، LOC

• حڪم جو ڪتاب. گروهه سان گڏ ڪتاب کي لاڳو ڪرڻ جو نظريو ۽ عمل

• واپار جو تصور: ٽڪر، بار، قرارداد. ڪيئن ذخيرو ڪجي ۽ گلو ڪيئن ڪجي

• واپس دفتر. منصوبه بندي ۽ ترقي. ملازم جي نگراني ۽ واقعي جي تحقيقات

• API. اچو ته ڄاڻون ته ڪھڙي انٽرنيٽ جي ضرورت آھي ۽ انھن کي ڪيئن لاڳو ڪجي

• معلومات اسٽوريج: PostgreSQL, Timescale, Tarantool واپاري نظام ۾

• واپاري نظام ۾ رد عمل

• ٻيو. مان تبصرن ۾ لکندس

6 صارفين ووٽ ڪيو. 4 استعمال ڪندڙن کي روڪيو ويو.

جو ذريعو: www.habr.com