پریشانی کو کیسے روکا جائے اور یک سنگی کے بغیر جینا شروع کیا جائے۔

ہم سب کو کہانیاں پسند ہیں۔ ہم آگ کے گرد بیٹھ کر اپنی ماضی کی فتوحات، لڑائیوں یا محض اپنے کام کے تجربے کے بارے میں بات کرنا پسند کرتے ہیں۔

آج کا دن ایسا ہی ہے۔ اور یہاں تک کہ اگر آپ ابھی آگ پر نہیں ہیں، تو ہمارے پاس آپ کے لیے ایک کہانی ہے۔ اس کی کہانی کہ کس طرح ہم نے ترن ٹول پر اسٹوریج کے ساتھ کام کرنا شروع کیا۔

ایک زمانے میں، ہماری کمپنی کے پاس سب کے لیے دو "مونولیتھز" اور ایک "چھت" تھی، جس تک یہ یک سنگی آہستہ آہستہ لیکن یقینی طور پر قریب آ رہے تھے، ہماری کمپنی کی پرواز، ہماری ترقی کو محدود کر رہے تھے۔ اور ایک واضح فہم تھا: ایک دن ہم اس چھت کو سختی سے ٹکرائیں گے۔

یہ اب ہر چیز اور ہر چیز کو الگ کرنے کا مروجہ نظریہ ہے، آلات سے لے کر کاروباری منطق تک۔ نتیجے کے طور پر، ہمارے پاس، مثال کے طور پر، دو DCs ہیں جو نیٹ ورک کی سطح پر عملی طور پر آزاد ہیں۔ اور پھر سب کچھ بالکل مختلف تھا۔

آج، CI/CD، K8S، وغیرہ کی شکل میں تبدیلیاں کرنے کے لیے بہت سارے اوزار اور اوزار موجود ہیں۔ "ایک سنگی" وقت میں، ہمیں اتنے غیر ملکی الفاظ کی ضرورت نہیں تھی۔ ڈیٹا بیس میں صرف "اسٹوریج" کو درست کرنا کافی تھا۔

لیکن وقت آگے بڑھتا گیا، اور درخواستوں کی تعداد اس کے ساتھ ساتھ آگے بڑھی، بعض اوقات آر پی ایس کو ہماری صلاحیتوں سے باہر کر دیتا ہے۔ مارکیٹ میں CIS ممالک کے داخلے کے ساتھ، پہلے مونولیتھ کے ڈیٹا بیس پروسیسر پر بوجھ 90% سے نیچے نہیں آیا، اور RPS 2400 کی سطح پر رہا۔ اور یہ صرف چھوٹے سلیکٹرز نہیں تھے، بلکہ بھاری سوالات تھے چیکس اور JOINs کا ایک گروپ جو بڑے IO کے پس منظر کے خلاف تقریباً نصف ڈیٹا تک چل سکتا ہے۔

جب بلیک فرائیڈے کی مکمل فروخت منظرعام پر آنا شروع ہوئی - اور وائلڈ بیریز روس میں ان کا انعقاد کرنے والے پہلے لوگوں میں سے ایک تھا - صورت حال مکمل طور پر افسوسناک ہوگئی۔ سب کے بعد، اس طرح کے دنوں پر بوجھ تین گنا بڑھ جاتا ہے.
اوہ، یہ "یک سنگی اوقات"! مجھے یقین ہے کہ آپ نے بھی کچھ ایسا ہی تجربہ کیا ہوگا، اور آپ ابھی تک نہیں سمجھ سکتے کہ یہ آپ کے ساتھ کیسے ہوسکتا ہے۔

آپ کیا کر سکتے ہیں - فیشن ٹیکنالوجی میں موروثی ہے. تقریباً 5 سال پہلے، ہمیں .NET اور MS SQL سرور پر موجود سائٹ کی شکل میں ان طریقوں میں سے ایک پر دوبارہ غور کرنا پڑا، جس نے سائٹ کی تمام منطق کو احتیاط سے محفوظ کر لیا تھا۔ میں نے اسے اتنی احتیاط سے رکھا کہ اس طرح کی یک سنگی کو دیکھنا ایک لمبا اور بالکل آسان نہیں تھا۔
ایک چھوٹا سا اختلاف۔

مختلف تقریبات میں میں کہتا ہوں: "اگر آپ نے یک سنگی نہیں دیکھا، تو آپ بڑھے نہیں!" میں اس معاملے پر آپ کی رائے میں دلچسپی رکھتا ہوں، براہ کرم اسے تبصروں میں لکھیں۔

گرج کی آواز

آئیے اپنے "الاؤ" کی طرف لوٹتے ہیں۔ "مونولیتھک" فعالیت کے بوجھ کو تقسیم کرنے کے لیے، ہم نے اوپن سورس ٹیکنالوجیز کی بنیاد پر سسٹم کو مائیکرو سروسز میں تقسیم کرنے کا فیصلہ کیا۔ کیونکہ، کم از کم، وہ پیمانے پر سستے ہیں. اور ہمیں 100% سمجھ تھی کہ ہمیں پیمانے (اور بہت کچھ) کرنا پڑے گا۔ سب کے بعد، پہلے سے ہی اس وقت ہمسایہ ممالک کے بازاروں میں داخل ہونے کے لئے ممکن تھا، اور رجسٹریشن کی تعداد کے ساتھ ساتھ احکامات کی تعداد بھی زیادہ مضبوطی سے بڑھنے لگے.

یک سنگی سے مائیکرو سروسز کی طرف روانگی کے لیے پہلے امیدواروں کا تجزیہ کرنے کے بعد، ہم نے محسوس کیا کہ ان میں 80% تحریریں بیک آفس سسٹمز اور فرنٹ آفس سے پڑھنے سے آتی ہیں۔ سب سے پہلے، یہ ہمارے لیے چند اہم ذیلی نظاموں سے متعلق ہے - صارف کا ڈیٹا اور اضافی کسٹمر ڈسکاؤنٹس اور کوپنز کے بارے میں معلومات کی بنیاد پر سامان کی حتمی قیمت کا حساب لگانے کا نظام۔

حاشیہ دار اب یہ تصور کرنا خوفناک ہے، لیکن مذکورہ ذیلی نظاموں کے علاوہ، پروڈکٹ کیٹلاگ، صارف کی خریداری کی ٹوکری، ایک پروڈکٹ سرچ سسٹم، پروڈکٹ کیٹلاگ کے لیے فلٹرنگ سسٹم، اور مختلف قسم کے سفارشی نظاموں کو بھی ہمارے یک سنگی سے ہٹا دیا گیا تھا۔ ان میں سے ہر ایک کے آپریشن کے لئے، تنگ طور پر تیار کردہ نظاموں کی الگ الگ کلاسیں ہیں، لیکن ایک زمانے میں وہ سب ایک "گھر" میں رہتے تھے۔

ہم نے فوری طور پر اپنے کلائنٹس کا ڈیٹا شارڈ سسٹم میں منتقل کرنے کا منصوبہ بنایا۔ سامان کی حتمی قیمت کا حساب لگانے کے لیے فعالیت کو ہٹانے کے لیے پڑھنے کے لیے اچھی اسکیل ایبلٹی کی ضرورت تھی، کیونکہ اس نے RPS کا سب سے بڑا بوجھ پیدا کیا اور ڈیٹا بیس کے لیے اسے نافذ کرنا سب سے مشکل تھا (کیلکولیشن کے عمل میں بہت سا ڈیٹا شامل ہے)۔

نتیجے کے طور پر، ہم ایک اسکیم لے کر آئے جو ترن ٹول کے ساتھ اچھی طرح فٹ بیٹھتی ہے۔

اس وقت، مائیکرو سروسز کے آپریشن کے لیے، ورچوئل اور ہارڈ ویئر مشینوں پر کئی ڈیٹا سینٹرز کے ساتھ کام کرنے کے لیے اسکیمیں منتخب کی گئیں۔ جیسا کہ اعداد و شمار میں دکھایا گیا ہے، ٹرانٹول نقل کے اختیارات ماسٹر-ماسٹر اور ماسٹر-غلام دونوں طریقوں میں لاگو کیے گئے تھے۔

فن تعمیر۔ آپشن 1۔ صارف کی خدمت

موجودہ وقت میں، 24 شارڈز ہیں، جن میں سے ہر ایک میں 2 مثالیں ہیں (ہر ڈی سی کے لیے ایک)، سبھی ماسٹر-ماسٹر موڈ میں ہیں۔

ڈیٹا بیس کے اوپر ایپلی کیشنز ہیں جو ڈیٹا بیس کی نقل تک رسائی حاصل کرتی ہیں۔ ایپلیکیشنز ہماری کسٹم لائبریری کے ذریعے Tarantool کے ساتھ کام کرتی ہیں، جو Tarantool Go ڈرائیور انٹرفیس کو لاگو کرتی ہے۔ وہ تمام نقلیں دیکھتی ہے اور پڑھنے لکھنے کے لیے ماسٹر کے ساتھ کام کر سکتی ہے۔ بنیادی طور پر، یہ ریپلیکا سیٹ ماڈل کو لاگو کرتا ہے، جو ریپلیکا کو منتخب کرنے، دوبارہ کوششیں کرنے، سرکٹ بریکر اور شرح کی حد کے لیے منطق کا اضافہ کرتا ہے۔

اس صورت میں، شارڈز کے تناظر میں نقل کے انتخاب کی پالیسی کو ترتیب دینا ممکن ہے۔ مثال کے طور پر، راؤنڈ روبن۔

فن تعمیر۔ آپشن 2۔ سامان کی حتمی قیمت کا حساب لگانے کے لیے سروس

کچھ مہینے پہلے، سامان کی حتمی لاگت کا حساب لگانے کے لیے زیادہ تر درخواستیں ایک نئی سروس کے پاس گئی تھیں، جو اصولی طور پر ڈیٹا بیس کے بغیر کام کرتی ہے، لیکن کچھ عرصہ پہلے ترانٹول کے ساتھ ایک سروس کے ذریعے ہر چیز پر 100 فیصد کارروائی کی گئی تھی۔

سروس ڈیٹا بیس 4 ماسٹرز پر مشتمل ہوتا ہے جس میں سنکرونائزر ڈیٹا اکٹھا کرتا ہے، اور ان میں سے ہر ایک ریپلیکشن ماسٹر ڈیٹا کو صرف پڑھنے کے لیے نقل کرتا ہے۔ ہر ماسٹر کے پاس تقریباً 15 ایسی نقلیں ہوتی ہیں۔

یا تو پہلی یا دوسری سکیم میں، اگر ایک ڈی سی دستیاب نہیں ہے، تو درخواست دوسری سکیم میں ڈیٹا حاصل کر سکتی ہے۔

یہ بات قابل غور ہے کہ ٹرانٹول میں نقل تیار کرنا کافی لچکدار ہے اور اسے رن ٹائم پر ترتیب دیا جا سکتا ہے۔ دوسرے نظاموں میں مشکلات پیدا ہوئیں۔ مثال کے طور پر، PostgreSQL میں max_wal_senders اور max_replication_slots پیرامیٹرز کو تبدیل کرنے کے لیے وزرڈ کو دوبارہ شروع کرنے کی ضرورت ہوتی ہے، جو کچھ صورتوں میں ایپلیکیشن اور DBMS کے درمیان کنکشن منقطع کرنے کا باعث بن سکتا ہے۔

تلاش کریں اور آپ کو مل جائے گا!

ہم نے اسے "عام لوگوں کی طرح" کیوں نہیں کیا، لیکن ایک غیر معمولی طریقہ کا انتخاب کیا؟ یہ اس بات پر منحصر ہے کہ کیا عام سمجھا جاتا ہے۔ بہت سے لوگ عام طور پر مونگو سے کلسٹر بناتے ہیں اور اسے تین جیو ڈسٹری بیوٹڈ ڈی سی میں پھیلا دیتے ہیں۔

اس وقت، ہمارے پاس پہلے سے ہی دو Redis منصوبے تھے۔ پہلا ایک کیشے تھا، اور دوسرا بہت زیادہ اہم ڈیٹا نہ ہونے کے لیے مستقل اسٹوریج تھا۔ یہ اس کے ساتھ کافی مشکل تھا، جزوی طور پر ہماری غلطی سے۔ بعض اوقات کافی بڑی مقداریں کلید میں ہوتی تھیں، اور وقتاً فوقتاً سائٹ بیمار ہوتی جاتی تھی۔ ہم نے اس سسٹم کو ماسٹر غلام ورژن میں استعمال کیا۔ اور بہت سے ایسے معاملات تھے جہاں ماسٹر کے ساتھ کچھ ہوا اور نقل ٹوٹ گئی۔

یعنی، Redis بے وطن کاموں کے لیے اچھا ہے، ریاستی کاموں کے لیے نہیں۔ اصولی طور پر، اس نے زیادہ تر مسائل کو حل کرنے کی اجازت دی، لیکن صرف اس صورت میں جب وہ انڈیکس کے جوڑے کے ساتھ کلیدی قدر کے حل ہوں۔ لیکن ریڈیس اس وقت استقامت اور نقل کے ساتھ کافی اداس تھا۔ اس کے علاوہ کارکردگی کے حوالے سے بھی شکایات سامنے آئیں۔

ہم نے MySQL اور PostgreSQL کے بارے میں سوچا۔ لیکن پہلی چیز کسی نہ کسی طرح ہمارے سامنے نہیں آئی، اور دوسرا اپنے آپ میں ایک انتہائی نفیس پروڈکٹ ہے، اور اس پر سادہ خدمات بنانا نامناسب ہوگا۔
ہم نے RIAK، Cassandra، یہاں تک کہ ایک گراف ڈیٹا بیس بھی آزمایا۔ یہ تمام مناسب حل ہیں جو خدمات تخلیق کرنے کے لیے ایک عام آفاقی ٹول کے کردار کے لیے موزوں نہیں تھے۔

بالآخر ہم ترن ٹول پر آباد ہو گئے۔

ہم اس کی طرف متوجہ ہوئے جب یہ ورژن 1.6 میں تھا۔ ہمیں کلیدی قدر کی علامت اور متعلقہ ڈیٹا بیس کی فعالیت سے اس میں دلچسپی تھی۔ ثانوی اشاریہ جات، لین دین اور خالی جگہیں ہیں، یہ میزوں کی طرح ہیں، لیکن آسان نہیں، آپ ان میں کالم کی مختلف تعداد کو محفوظ کر سکتے ہیں۔ لیکن ٹرانٹول کی قاتل خصوصیت کلیدی قدر اور لین دین کے ساتھ مل کر ثانوی اشاریہ جات تھی۔

جوابدہ روسی بولنے والی کمیونٹی، جو بات چیت میں مدد کے لیے تیار ہے، نے بھی اپنا کردار ادا کیا۔ ہم نے اسے فعال طور پر استعمال کیا اور براہ راست چیٹ میں رہتے ہیں۔ اور واضح غلطیوں اور غلطیوں کے بغیر مہذب مستقل کے بارے میں مت بھولنا۔ اگر آپ ترن ٹول کے ساتھ ہماری تاریخ پر نظر ڈالیں تو ہمیں نقل کے ساتھ بہت تکلیف اور ناکامیوں کا سامنا کرنا پڑا، لیکن اس کی غلطی کی وجہ سے ہم نے کبھی ڈیٹا ضائع نہیں کیا!

عمل درآمد کا آغاز مشکل سے ہوا۔

اس وقت، ہمارا بنیادی ترقیاتی اسٹیک .NET تھا، جس میں Tarantool کے لیے کوئی کنیکٹر نہیں تھا۔ ہم نے فوراً گو میں کچھ کرنا شروع کر دیا۔ اس نے لوا کے ساتھ بھی اچھا کام کیا۔ اس وقت بنیادی مسئلہ ڈیبگنگ کا تھا: .NET میں اس کے ساتھ سب کچھ بہت اچھا ہے، لیکن اس کے بعد ایمبیڈڈ Lua کی دنیا میں جانا مشکل تھا، جب آپ کے پاس لاگز کے علاوہ کوئی ڈیبگنگ نہیں ہے۔ اس کے علاوہ، کسی وجہ سے نقل وقتاً فوقتاً الگ ہو جاتی ہے، اس لیے مجھے ترن ٹول انجن کی ساخت کا جائزہ لینا پڑا۔ چیٹ نے اس میں مدد کی، اور کچھ حد تک، دستاویزات؛ کبھی کبھی ہم نے کوڈ کو دیکھا۔ اس وقت، دستاویزات اس طرح کی تھی.

اس لیے، کئی مہینوں کے دوران، میں نے اپنا سر پکڑ لیا اور Tarantool کے ساتھ کام کرنے سے اچھے نتائج حاصل کر لیے۔ ہم نے گٹ میں حوالہ جاتی پیش رفت کو مرتب کیا جس نے نئی مائیکرو سروسز کی تشکیل میں مدد کی۔ مثال کے طور پر، جب کوئی کام شروع ہوا: ایک اور مائیکرو سروس بنانے کے لیے، ڈویلپر نے ریپوزٹری میں حوالہ حل کے سورس کوڈ کو دیکھا، اور ایک نیا بنانے میں ایک ہفتے سے زیادہ وقت نہیں لگا۔

یہ خاص اوقات تھے۔ روایتی طور پر، پھر آپ اگلی ٹیبل پر ایڈمن کے پاس جا کر پوچھ سکتے ہیں: "مجھے ایک ورچوئل مشین دیں۔" تقریباً تیس منٹ بعد گاڑی آپ کے ساتھ تھی۔ آپ نے خود کو منسلک کیا، سب کچھ انسٹال کیا، اور ٹریفک آپ کو بھیجی گئی۔

آج یہ مزید کام نہیں کرے گا: آپ کو سروس میں مانیٹرنگ اور لاگنگ شامل کرنے، ٹیسٹوں کے ساتھ فعالیت کا احاطہ کرنے، ورچوئل مشین کا آرڈر دینے یا کوبیر کو ڈیلیوری کرنے کی ضرورت ہے۔ عام طور پر، یہ اس طرح بہتر ہو گا، اگرچہ اس میں زیادہ وقت لگے گا اور زیادہ پریشانی ہو گی۔

تقسیم کرو اور حکومت کرو۔ لوا کے ساتھ کیا معاملہ ہے؟

ایک سنگین مخمصہ تھا: کچھ ٹیمیں Lua میں بہت زیادہ منطق کے ساتھ سروس میں قابل اعتماد طریقے سے تبدیلیاں کرنے سے قاصر تھیں۔ یہ اکثر سروس کے کام نہ کرنے کے ساتھ ہوتا تھا۔

یعنی، ڈویلپرز کسی قسم کی تبدیلی کی تیاری کر رہے ہیں۔ ترن ٹول ہجرت کرنا شروع کر دیتا ہے، لیکن نقل اب بھی پرانے کوڈ کے ساتھ ہے۔ کچھ DDL یا کچھ اور نقل کے ذریعے وہاں پہنچتا ہے، اور کوڈ صرف اس لیے الگ ہو جاتا ہے کیونکہ اسے مدنظر نہیں رکھا جاتا ہے۔ نتیجے کے طور پر، منتظمین کے لیے اپ ڈیٹ کا طریقہ کار A4 شیٹ پر رکھا گیا تھا: نقل کو روکیں، اسے اپ ڈیٹ کریں، نقل کو آن کریں، یہاں بند کریں، وہاں اپ ڈیٹ کریں۔ ڈراؤنا خواب!

نتیجے کے طور پر، اب ہم اکثر Lua میں کچھ نہ کرنے کی کوشش کرتے ہیں۔ بس iproto (سرور کے ساتھ بات چیت کے لیے ایک بائنری پروٹوکول) استعمال کریں، اور بس۔ شاید یہ ڈویلپرز کے درمیان علم کی کمی ہے، لیکن اس نقطہ نظر سے نظام پیچیدہ ہے.

ہم ہمیشہ آنکھیں بند کرکے اس اسکرپٹ کی پیروی نہیں کرتے ہیں۔ آج ہمارے پاس سیاہ اور سفید نہیں ہے: یا تو سب کچھ Lua میں ہے، یا سب کچھ Go میں ہے۔ ہم پہلے ہی سمجھ چکے ہیں کہ ہم ان کو کیسے جوڑ سکتے ہیں تاکہ بعد میں ہجرت کے مسائل کا سامنا نہ کرنا پڑے۔

ترنتول اب کہاں ہے؟
ڈسکاؤنٹ کوپن، جسے "پروموٹر" کے نام سے بھی جانا جاتا ہے، کو مدنظر رکھتے ہوئے سامان کی حتمی قیمت کا حساب لگانے کے لیے سروس میں Tarantool کا استعمال کیا جاتا ہے۔ جیسا کہ میں نے پہلے کہا تھا، وہ اب ریٹائر ہو رہا ہے: اس کی جگہ پہلے سے حساب کی گئی قیمتوں کے ساتھ ایک نئی کیٹلاگ سروس لائی جا رہی ہے، لیکن چھ ماہ قبل تمام حسابات پروموٹیزر میں کیے گئے تھے۔ اس سے پہلے اس کی نصف منطق لوا میں لکھی جاتی تھی۔ دو سال پہلے، سروس کو اسٹوریج کی سہولت میں تبدیل کر دیا گیا تھا، اور گو میں منطق دوبارہ لکھی گئی تھی، کیونکہ رعایت کا میکانکس تھوڑا سا بدل گیا تھا اور سروس میں کارکردگی کا فقدان تھا۔

سب سے اہم خدمات میں سے ایک صارف پروفائل ہے۔ یعنی تمام وائلڈ بیریز استعمال کنندگان Tarantool میں محفوظ ہیں، اور ان میں سے تقریباً 50 ملین ہیں۔ صارف ID کے ذریعے شارڈ کردہ ایک سسٹم، Go سروسز سے منسلک کئی DCs میں تقسیم کیا جاتا ہے۔
آر پی ایس کے مطابق، پروموٹر ایک بار لیڈر تھا، 6 ہزار درخواستوں تک پہنچ گیا۔ ایک موقع پر ہمارے پاس 50-60 کاپیاں تھیں۔ اب RPS میں لیڈر صارف پروفائلز ہیں، تقریباً 12 ہزار۔ یہ سروس کسٹم شارڈنگ کا استعمال کرتی ہے، جسے صارف کی شناخت کی حدود سے تقسیم کیا جاتا ہے۔ سروس 20 سے زیادہ مشینیں فراہم کرتی ہے، لیکن یہ بہت زیادہ ہے؛ ہم مختص وسائل کو کم کرنے کا ارادہ رکھتے ہیں، کیونکہ اس کے لیے 4-5 مشینوں کی گنجائش کافی ہے۔

سیشن سروس vshard اور Cartridge پر ہماری پہلی سروس ہے۔ vshard کو ترتیب دینے اور کارٹریج کو اپ ڈیٹ کرنے کے لیے ہماری طرف سے کچھ محنت درکار تھی، لیکن آخر کار سب کچھ ہو گیا۔

ویب سائٹ اور موبائل ایپلیکیشن میں مختلف بینرز آویزاں کرنے کی سروس براہ راست ترن ٹول پر ریلیز ہونے والی پہلی سروس تھی۔ یہ سروس اس حقیقت کے لیے قابل ذکر ہے کہ یہ 6-7 سال پرانی ہے، یہ ابھی تک کام میں ہے اور اسے کبھی دوبارہ شروع نہیں کیا گیا ہے۔ ماسٹر-ماسٹر نقل استعمال کیا گیا تھا۔ کبھی کچھ نہیں ٹوٹا۔

کچھ صورتوں میں معلومات کی فوری جانچ پڑتال کرنے کے لیے گودام کے نظام میں فوری حوالہ کی فعالیت کے لیے Tarantool استعمال کرنے کی ایک مثال موجود ہے۔ ہم نے اس کے لیے Redis کو استعمال کرنے کی کوشش کی، لیکن میموری میں موجود ڈیٹا نے Tarantool سے زیادہ جگہ لی۔

ویٹنگ لسٹ، کلائنٹ سبسکرپشنز، فی الحال فیشن ایبل اسٹوریز اور ڈیفرڈ گڈز کی خدمات بھی Tarantool کے ساتھ کام کرتی ہیں۔ میموری میں آخری سروس تقریباً 120 جی بی لیتی ہے۔ یہ اوپر کی سب سے جامع خدمت ہے۔

حاصل يہ ہوا

کلیدی قدر اور لین دین کے ساتھ مل کر ثانوی اشاریہ جات کی بدولت، Tarantool مائیکرو سروسز پر مبنی فن تعمیر کے لیے موزوں ہے۔ تاہم، Lua میں بہت زیادہ منطق کے ساتھ سروسز میں تبدیلیاں لاتے وقت ہمیں مشکلات کا سامنا کرنا پڑا - سروسز نے اکثر کام کرنا چھوڑ دیا۔ ہم اس پر قابو پانے میں ناکام رہے، اور وقت گزرنے کے ساتھ ساتھ ہم Lua اور Go کے مختلف امتزاج میں آگئے: ہم جانتے ہیں کہ ایک زبان کہاں استعمال کرنی ہے اور دوسری زبان کہاں استعمال کرنی ہے۔

موضوع پر اور کیا پڑھنا ہے۔

• ٹرانٹول کا استعمال کرتے ہوئے شروع سے ہی زیادہ بوجھ والی ایپلی کیشن بنانا habr.com/ru/company/mailru/blog/510440
• ٹرانٹول کارتوس میں قابل اعتماد لیڈر کا انتخاب habr.com/ru/company/mailru/blog/513912
• پروڈکٹ کے بارے میں خبروں کے ساتھ ٹیلیگرام چینل ترن ٹول t.me/tarantool_news
• کمیونٹی چیٹ میں Tarantool پر بحث کریں۔ t.me/tarantoolru

ماخذ: www.habr.com