ہیلو، Khabrovsk کے رہائشیوں. کورس کے پہلے گروپ کی کلاسز آج سے شروع ہو رہی ہیں۔ . اس سلسلے میں، ہم آپ کو بتانا چاہیں گے کہ اس کورس پر اوپن ویبنار کیسے ہوا۔
В ہم نے بادلوں اور کبرنیٹس کے دور میں SQL ڈیٹا بیس کو درپیش چیلنجوں کے بارے میں بات کی۔ ایک ہی وقت میں، ہم نے دیکھا کہ کس طرح ایس کیو ایل ڈیٹا بیس ان چیلنجوں کے زیر اثر اپناتے اور بدلتے ہیں۔
ویبنار کا انعقاد کیا گیا۔ , EPAM سسٹمز میں گوگل کلاؤڈ پریکٹس ڈیلیوری مینیجر۔
جب درخت چھوٹے تھے...
سب سے پہلے، یاد رکھیں کہ ڈی بی ایم ایس کا انتخاب پچھلی صدی کے آخر میں کیسے شروع ہوا۔ تاہم، یہ مشکل نہیں ہوگا، کیونکہ ان دنوں میں ڈی بی ایم ایس کا انتخاب شروع ہوا اور ختم ہوا۔ اوریکل.
90 کی دہائی کے آخر اور 2 کی دہائی کے اوائل میں، جب صنعتی توسیع پذیر ڈیٹا بیس کی بات کی جائے تو بنیادی طور پر کوئی چارہ نہیں تھا۔ جی ہاں، وہاں IBM DBXNUMX، Sybase اور کچھ دوسرے ڈیٹا بیس تھے جو آئے اور چلے گئے، لیکن عام طور پر وہ اوریکل کے پس منظر میں اتنے نمایاں نہیں تھے۔ اس کے مطابق، اس وقت کے انجینئروں کی مہارتیں کسی نہ کسی طرح سے واحد انتخاب سے منسلک تھیں جو موجود تھا.
اوریکل ڈی بی اے کو اس قابل ہونا تھا:
- ڈسٹری بیوشن کٹ سے اوریکل سرور انسٹال کریں۔
- اوریکل سرور کو ترتیب دیں:
- init.ora؛
- listener.ora
- بنانا:
- میز کی جگہ؛
- اسکیمیں؛
- صارفین؛
- بیک اپ اور بحالی انجام دیں؛
- نگرانی کرنا؛
- سب سے زیادہ درخواستوں سے نمٹیں۔
ایک ہی وقت میں، اوریکل ڈی بی اے سے کوئی خاص ضرورت نہیں تھی:
- ڈیٹا کو ذخیرہ کرنے اور اس پر کارروائی کرنے کے لیے بہترین DBMS یا دیگر ٹیکنالوجی کا انتخاب کرنے کے قابل ہونا؛
- اعلی دستیابی اور افقی اسکیل ایبلٹی فراہم کریں (یہ ہمیشہ DBA کا مسئلہ نہیں تھا)؛
- موضوع کے علاقے، انفراسٹرکچر، ایپلیکیشن آرکیٹیکچر، OS کا اچھا علم؛
- ڈیٹا لوڈ اور ان لوڈ کریں، ڈیٹا کو مختلف DBMSs کے درمیان منتقل کریں۔
عام طور پر، اگر ہم ان دنوں میں انتخاب کے بارے میں بات کرتے ہیں، تو یہ 80 کی دہائی کے آخر میں سوویت اسٹور کے انتخاب سے ملتا جلتا ہے:
ہمارا وقت
اس کے بعد سے، یقینا، درخت بڑھے ہیں، دنیا بدل گئی ہے، اور یہ کچھ یوں ہوا:
ڈی بی ایم ایس مارکیٹ بھی بدل گئی ہے، جیسا کہ گارٹنر کی تازہ ترین رپورٹ سے واضح طور پر دیکھا جا سکتا ہے:
اور یہاں یہ واضح رہے کہ بادلوں نے، جن کی مقبولیت بڑھ رہی ہے، ان کے مقام پر قبضہ جما لیا ہے۔ اگر ہم اسی گارٹنر رپورٹ کو پڑھیں، تو ہمیں درج ذیل نتائج نظر آئیں گے:
- بہت سے صارفین ایپلی کیشنز کو کلاؤڈ پر منتقل کرنے کے راستے پر ہیں۔
- نئی ٹیکنالوجیز سب سے پہلے کلاؤڈ میں ظاہر ہوتی ہیں اور یہ حقیقت نہیں ہے کہ وہ کبھی بھی غیر کلاؤڈ انفراسٹرکچر میں منتقل ہو جائیں گی۔
- قیمتوں کا تعین کرتے ہوئے ادائیگی کا ماڈل عام ہو گیا ہے۔ ہر کوئی صرف اس کی ادائیگی کرنا چاہتا ہے جو وہ استعمال کرتے ہیں، اور یہ ایک رجحان بھی نہیں ہے، بلکہ محض حقیقت کا بیان ہے۔
اب کیا؟
آج ہم سب بادل میں ہیں۔ اور ہمارے لیے جو سوالات پیدا ہوتے ہیں وہ انتخاب کے سوالات ہیں۔ اور یہ بہت بڑا ہے، یہاں تک کہ اگر ہم صرف آن پریمیسس فارمیٹ میں ڈی بی ایم ایس ٹیکنالوجیز کے انتخاب کے بارے میں بات کریں۔ ہم نے خدمات اور SaaS کا بھی انتظام کیا ہے۔ اس طرح، انتخاب صرف ہر سال زیادہ مشکل ہو جاتا ہے.
انتخاب کے سوالات کے ساتھ، وہاں بھی ہیں محدود کرنے والے عوامل:
- قیمت. بہت سی ٹیکنالوجیز اب بھی پیسہ خرچ کرتی ہیں؛
- مہارت. اگر ہم مفت سافٹ ویئر کے بارے میں بات کر رہے ہیں، تو پھر مہارت کا سوال پیدا ہوتا ہے، کیونکہ مفت سافٹ ویئر کو ان لوگوں سے کافی قابلیت کی ضرورت ہوتی ہے جو اسے استعمال کرتے ہیں؛
- فعال. تمام خدمات جو کلاؤڈ میں دستیاب ہیں اور بنی ہوئی ہیں، یوں کہیے، ایک ہی پوسٹگریس پر بھی، پوسٹگریس آن پریمیسس جیسی خصوصیات نہیں رکھتیں۔ یہ ایک ضروری عنصر ہے جسے جاننے اور سمجھنے کی ضرورت ہے۔ مزید یہ کہ یہ عنصر کسی ایک DBMS کی کچھ پوشیدہ صلاحیتوں کے علم سے زیادہ اہم ہو جاتا ہے۔
DA/DE سے اب کیا توقع ہے:
- موضوع کے علاقے اور درخواست کے فن تعمیر کی اچھی سمجھ؛
- مناسب DBMS ٹکنالوجی کو صحیح طریقے سے منتخب کرنے کی صلاحیت، ہاتھ میں کام کو مدنظر رکھتے ہوئے؛
- موجودہ حدود کے تناظر میں منتخب ٹیکنالوجی کو نافذ کرنے کے لیے بہترین طریقہ منتخب کرنے کی صلاحیت؛
- ڈیٹا کی منتقلی اور منتقلی کو انجام دینے کی صلاحیت؛
- منتخب حل کو نافذ کرنے اور چلانے کی صلاحیت۔
ذیل میں مثال GCP کی بنیاد پر یہ ظاہر کرتا ہے کہ ڈیٹا کے ساتھ کام کرنے کے لیے ایک یا دوسری ٹیکنالوجی کا انتخاب اس کی ساخت کے لحاظ سے کیسے کام کرتا ہے:
براہ کرم نوٹ کریں کہ PostgreSQL اسکیما میں شامل نہیں ہے، اور اس کی وجہ یہ ہے کہ یہ اصطلاحات کے تحت پوشیدہ ہے۔ کلاؤڈ SQL. اور جب ہم کلاؤڈ ایس کیو ایل پر پہنچتے ہیں، تو ہمیں دوبارہ انتخاب کرنا ہوگا:
واضح رہے کہ یہ انتخاب ہمیشہ واضح نہیں ہوتا، اس لیے ایپلیکیشن ڈویلپرز کو اکثر وجدان سے رہنمائی حاصل ہوتی ہے۔
کل:
- آپ جتنا آگے بڑھیں گے، انتخاب کا سوال اتنا ہی زیادہ دبایا جائے گا۔ اور یہاں تک کہ اگر آپ صرف GCP، منظم خدمات اور SaaS پر نظر ڈالیں، تب بھی RDBMS کا کچھ ذکر صرف چوتھے مرحلے پر ظاہر ہوتا ہے (اور وہاں اسپنر قریب ہی ہے)۔ اس کے علاوہ، PostgreSQL کا انتخاب 4ویں مرحلے میں ظاہر ہوتا ہے، اور اس کے آگے MySQL اور SQL Server بھی ہیں، یعنی سب کچھ ہے، لیکن آپ کو منتخب کرنا ہوگا.
- ہمیں فتنوں کے پس منظر میں پابندیوں کو نہیں بھولنا چاہیے۔ بنیادی طور پر ہر کوئی اسپینر چاہتا ہے، لیکن یہ مہنگا ہے۔ نتیجے کے طور پر، ایک عام درخواست کچھ اس طرح نظر آتی ہے: "براہ کرم ہمیں اسپینر بنائیں لیکن Cloud SQL کی قیمت کے لیے، آپ پیشہ ور ہیں!"
ہمیں کیا کرنا چاہئے؟
حتمی سچائی ہونے کا دعوی کیے بغیر، آئیے درج ذیل کہتے ہیں:
ہمیں سیکھنے کے لیے اپنا نقطہ نظر تبدیل کرنے کی ضرورت ہے:
- جس طرح سے ڈی بی اے کو پہلے پڑھایا جاتا تھا اس کو سکھانے کا کوئی فائدہ نہیں ہے۔
- ایک پروڈکٹ کا علم اب کافی نہیں ہے۔
- لیکن درجنوں کو ایک کی سطح پر جاننا ناممکن ہے۔
آپ کو نہ صرف یہ جاننے کی ضرورت ہے کہ پروڈکٹ کتنی ہے بلکہ:
- اس کی درخواست کا استعمال کیس؛
- مختلف تعیناتی کے طریقے؛
- ہر طریقہ کے فوائد اور نقصانات؛
- مماثل اور متبادل مصنوعات ایک باخبر اور بہترین انتخاب کرنے کے لیے اور ہمیشہ کسی مانوس پروڈکٹ کے حق میں نہیں۔
آپ کو ڈیٹا کو منتقل کرنے اور ETL کے ساتھ انضمام کے بنیادی اصولوں کو سمجھنے کے قابل ہونے کی بھی ضرورت ہے۔
اصلی کیس
ماضی قریب میں، موبائل ایپلیکیشن کے لیے بیک اینڈ بنانا ضروری تھا۔ جب تک اس پر کام شروع ہوا، بیک اینڈ پہلے ہی تیار ہو چکا تھا اور عمل درآمد کے لیے تیار تھا، اور ترقیاتی ٹیم نے اس منصوبے پر تقریباً دو سال گزارے۔ مندرجہ ذیل کاموں کو مقرر کیا گیا تھا:
- CI/CD کی تعمیر؛
- فن تعمیر کا جائزہ لیں؛
- یہ سب آپریشن میں ڈالو.
ایپلی کیشن خود مائیکرو سروسز تھی، اور Python/Jjango کوڈ کو شروع سے اور براہ راست GCP میں تیار کیا گیا تھا۔ جہاں تک ہدف کے سامعین کا تعلق ہے، یہ فرض کیا گیا تھا کہ دو خطے ہوں گے - US اور EU، اور ٹریفک کو گلوبل لوڈ بیلنسر کے ذریعے تقسیم کیا گیا تھا۔ تمام کام کا بوجھ اور کمپیوٹ کام کا بوجھ Google Kubernetes Engine پر چلتا ہے۔
اعداد و شمار کے طور پر، وہاں 3 ڈھانچے تھے:
- کلاؤڈ اسٹوریج؛
- ڈیٹا اسٹور؛
- Cloud SQL (PostgreSQL)۔
کوئی سوچ سکتا ہے کہ کلاؤڈ ایس کیو ایل کا انتخاب کیوں کیا گیا؟ سچ کہوں تو، اس طرح کے ایک سوال نے حالیہ برسوں میں کچھ عجیب و غریب توقف کا باعث بنا ہے - ایک ایسا احساس ہے کہ لوگ متعلقہ ڈیٹا بیس کے بارے میں شرمندہ ہو گئے ہیں، لیکن اس کے باوجود وہ انہیں فعال طور پر استعمال کرتے رہتے ہیں ؛-)۔
جہاں تک ہمارے معاملے کا تعلق ہے، کلاؤڈ ایس کیو ایل کو درج ذیل وجوہات کی بنا پر منتخب کیا گیا تھا۔
- جیسا کہ ذکر کیا گیا ہے، ایپلی کیشن کو جینگو کا استعمال کرتے ہوئے تیار کیا گیا تھا، اور اس میں ایس کیو ایل ڈیٹا بیس سے پائتھون آبجیکٹ (جیانگو او آر ایم) پر مستقل ڈیٹا میپ کرنے کا ایک ماڈل ہے۔
- فریم ورک نے خود DBMSs کی کافی محدود فہرست کی حمایت کی:
- PostgreSQL؛
- ماریا ڈی بی؛
- MySQL؛
- اوریکل؛
- ایس کیو ایلائٹ۔
اسی مناسبت سے، PostgreSQL کا انتخاب اس فہرست سے بدیہی طور پر کیا گیا تھا (ٹھیک ہے، یہ واقعی اوریکل کا انتخاب نہیں ہے)۔
کیا غائب تھا:
- ایپلیکیشن صرف 2 خطوں میں تعینات کی گئی تھی، اور تیسرا ایک منصوبہ (ایشیا) میں ظاہر ہوا؛
- ڈیٹا بیس شمالی امریکہ کے علاقے (آئیووا) میں واقع تھا۔
- گاہک کی طرف سے ممکنہ کے بارے میں خدشات تھے۔ رسائی میں تاخیر یورپ اور ایشیا سے اور رکاوٹیں سروس میں DBMS ڈاؤن ٹائم کی صورت میں۔
اس حقیقت کے باوجود کہ جیانگو خود متعدد ڈیٹا بیس کے ساتھ متوازی طور پر کام کر سکتا ہے اور انہیں پڑھنے اور لکھنے میں تقسیم کر سکتا ہے، درخواست میں اتنی زیادہ تحریر نہیں تھی (90% سے زیادہ پڑھ رہا ہے)۔ اور عام طور پر، اور عام طور پر، اگر یہ کرنا ممکن تھا یورپ اور ایشیا میں مرکزی اڈے کی ریڈ ریپلیکا، یہ ایک سمجھوتہ حل ہوگا۔ ٹھیک ہے، اس میں کیا پیچیدہ ہے؟
مشکل یہ تھی کہ صارف منظم خدمات اور کلاؤڈ ایس کیو ایل کا استعمال ترک نہیں کرنا چاہتا تھا۔ اور کلاؤڈ ایس کیو ایل کی صلاحیتیں فی الحال محدود ہیں۔ کلاؤڈ ایس کیو ایل ہائی دستیابی (HA) اور ریڈ ریپلیکا (RR) کو سپورٹ کرتا ہے، لیکن وہی RR صرف ایک علاقے میں سپورٹ کیا جاتا ہے۔ امریکی خطے میں ڈیٹا بیس بنانے کے بعد، آپ کلاؤڈ ایس کیو ایل کا استعمال کرتے ہوئے یورپی خطے میں پڑھنے کی نقل نہیں بنا سکتے، حالانکہ پوسٹگریس خود آپ کو ایسا کرنے سے نہیں روکتا ہے۔ گوگل ملازمین کے ساتھ خط و کتابت کہیں بھی نہیں پہنچی اور "ہم مسئلہ کو جانتے ہیں اور اس پر کام کر رہے ہیں، ایک دن یہ مسئلہ حل ہو جائے گا" کے انداز میں وعدوں پر ختم ہوا۔
اگر ہم کلاؤڈ ایس کیو ایل کی صلاحیتوں کو مختصراً درج کریں تو یہ کچھ اس طرح نظر آئے گا:
1. اعلی دستیابی (HA):
- ایک علاقے کے اندر؛
- ڈسک نقل کے ذریعے؛
- PostgreSQL انجن استعمال نہیں کیے جاتے ہیں۔
- خودکار اور دستی کنٹرول ممکن - فیل اوور/فیل بیک؛
- سوئچ کرتے وقت، DBMS کئی منٹ تک دستیاب نہیں ہوتا ہے۔
2. نقل (RR) پڑھیں:
- ایک علاقے کے اندر؛
- گرم اسٹینڈ بائی؛
- PostgreSQL سٹریمنگ نقل۔
اس کے علاوہ، جیسا کہ رواج ہے، ٹیکنالوجی کا انتخاب کرتے وقت آپ کو ہمیشہ کچھ کا سامنا کرنا پڑتا ہے۔ پابندیاں:
- گاہک GKE کے علاوہ، ادارے بنانا اور IaaS استعمال نہیں کرنا چاہتا تھا۔
- کسٹمر خود سروس PostgreSQL/MySQL تعینات کرنا پسند نہیں کرے گا؛
- ٹھیک ہے، عام طور پر، گوگل اسپنر کافی موزوں ہوگا اگر یہ اس کی قیمت کے لیے نہ ہوتا، تاہم، Django ORM اس کے ساتھ کام نہیں کرسکتا، لیکن یہ ایک اچھی بات ہے۔
صورت حال پر غور کرتے ہوئے، گاہک کو ایک فالو اپ سوال موصول ہوا: "کیا آپ کچھ ایسا ہی کر سکتے ہیں تاکہ یہ گوگل اسپنر کی طرح ہو، لیکن Django ORM کے ساتھ بھی کام کرے؟"
حل آپشن نمبر 0
پہلی بات جو ذہن میں آئی:
- CloudSQL کے اندر رہیں؛
- کسی بھی شکل میں خطوں کے درمیان کوئی بلٹ ان نقل نہیں ہو گی۔
- پوسٹگری ایس کیو ایل کے ذریعہ موجودہ کلاؤڈ ایس کیو ایل کے ساتھ نقل منسلک کرنے کی کوشش کریں۔
- پوسٹگری ایس کیو ایل مثال کہیں اور کسی نہ کسی طرح لانچ کریں، لیکن کم از کم ماسٹر کو نہ چھوئے۔
افسوس، یہ پتہ چلا کہ ایسا نہیں کیا جا سکتا، کیونکہ میزبان تک رسائی نہیں ہے (یہ مکمل طور پر ایک مختلف پروجیکٹ میں ہے) - pg_hba اور اسی طرح، اور سپر یوزر کے تحت بھی رسائی نہیں ہے۔
حل آپشن نمبر 1
مزید غور و فکر اور سابقہ حالات کو مدنظر رکھنے کے بعد سوچ کی ٹرین کچھ بدل گئی:
- ہم اب بھی CloudSQL کے اندر رہنے کی کوشش کر رہے ہیں، لیکن ہم MySQL پر جا رہے ہیں، کیونکہ Cloud SQL by MySQL کا ایک بیرونی ماسٹر ہے، جو:
- بیرونی MySQL کے لیے ایک پراکسی ہے؛
- ایک MySQL مثال کی طرح لگتا ہے؛
- دوسرے بادلوں یا آن پریمیسس سے ڈیٹا کو منتقل کرنے کے لیے ایجاد کیا گیا۔
چونکہ MySQL نقل ترتیب دینے کے لیے میزبان تک رسائی کی ضرورت نہیں ہوتی، اصولی طور پر سب کچھ کام کرتا تھا، لیکن یہ بہت غیر مستحکم اور تکلیف دہ تھا۔ اور جب ہم آگے گئے تو یہ مکمل طور پر خوفناک ہو گیا، کیونکہ ہم نے پورے ڈھانچے کو ٹیرافارم کے ساتھ تعینات کیا تھا، اور اچانک پتہ چلا کہ بیرونی ماسٹر کو ٹیرافارم سے تعاون حاصل نہیں تھا۔ ہاں، گوگل کے پاس ایک CLI ہے، لیکن کسی وجہ سے یہاں ہر چیز کام کرتی ہے - کبھی کبھی یہ بنتی ہے، کبھی نہیں بنتی ہے۔ شاید اس لیے کہ CLI کی ایجاد بیرونی ڈیٹا کی منتقلی کے لیے کی گئی تھی، نہ کہ نقل کے لیے۔
دراصل، اس مقام پر یہ واضح ہو گیا کہ Cloud SQL بالکل بھی موزوں نہیں ہے۔ جیسا کہ وہ کہتے ہیں، ہم نے ہر ممکن کوشش کی۔
حل آپشن نمبر 2
چونکہ کلاؤڈ ایس کیو ایل فریم ورک کے اندر رہنا ممکن نہیں تھا، اس لیے ہم نے سمجھوتے کے حل کے لیے تقاضے وضع کرنے کی کوشش کی۔ تقاضے درج ذیل نکلے:
- Kubernetes میں کام، وسائل کا زیادہ سے زیادہ استعمال اور Kubernetes (DCS، ...) اور GCP (LB، ...)؛
- HA پراکسی جیسے بادل میں غیر ضروری چیزوں کے ایک گروپ سے گٹی کی کمی؛
- اہم HA خطے میں PostgreSQL یا MySQL چلانے کی صلاحیت؛ دوسرے خطوں میں - مرکزی علاقے کے RR سے HA اور اس کی کاپی (اعتماد کے لیے)؛
- ملٹی ماسٹر (میں اس سے رابطہ نہیں کرنا چاہتا تھا، لیکن یہ بہت اہم نہیں تھا)
.
ان مطالبات کے نتیجے میں پیمناسب DBMS اور بائنڈنگ کے اختیارات:
- MySQL گیلیرا؛
- کاکروچ ڈی بی؛
- PostgreSQL ٹولز
:
- pgpool-II؛
- پیٹرونی۔
مائی ایس کیو ایل گیلیرا
MySQL Galera ٹیکنالوجی Codership کے ذریعے تیار کی گئی تھی اور InnoDB کے لیے ایک پلگ ان ہے۔ خصوصیات:
- ملٹی ماسٹر؛
- ہم وقت ساز نقل؛
- کسی بھی نوڈ سے پڑھنا؛
- کسی بھی نوڈ پر ریکارڈنگ؛
- بلٹ میں HA میکانزم؛
- بٹ نامی سے ایک ہیلم چارٹ ہے۔
کاکروچ ڈی بی
تفصیل کے مطابق بات بالکل بم کی ہے اور گو میں لکھا ہوا اوپن سورس پروجیکٹ ہے۔ مرکزی حصہ لینے والا کاکروچ لیبز (گوگل کے لوگوں کے ذریعہ قائم کیا گیا) ہے۔ یہ رشتہ دار DBMS اصل میں تقسیم کرنے کے لیے ڈیزائن کیا گیا تھا (باکس سے باہر افقی اسکیلنگ کے ساتھ) اور غلطی برداشت کرنے والا۔ کمپنی کے اس کے مصنفین نے "NoSQL حلوں سے واقف افقی رسائی کے ساتھ SQL فعالیت کی بھرپوریت کو یکجا کرنے" کے مقصد کا خاکہ پیش کیا۔
ایک اچھا بونس پوسٹ گریس کنکشن پروٹوکول کے لیے سپورٹ ہے۔
پی جی پول
یہ PostgreSQL میں ایک اضافہ ہے، درحقیقت، ایک نئی ہستی جو تمام کنکشن لے لیتی ہے اور ان پر کارروائی کرتی ہے۔ اس کا اپنا لوڈ بیلنسر اور پارسر ہے، جو BSD لائسنس کے تحت لائسنس یافتہ ہے۔ یہ کافی مواقع فراہم کرتا ہے، لیکن کچھ خوفناک لگتا ہے، کیونکہ ایک نئی ہستی کی موجودگی کچھ اضافی مہم جوئی کا ذریعہ بن سکتی ہے۔
پیٹرونی
یہ آخری چیز ہے جس پر میری نظر پڑی، اور جیسا کہ یہ نکلا، بیکار نہیں۔ Patroni ایک اوپن سورس یوٹیلیٹی ہے، جو کہ بنیادی طور پر ایک Python ڈیمون ہے جو آپ کو خود بخود PostgreSQL کلسٹرز کو مختلف اقسام کی نقل اور خودکار رول سوئچنگ کے ساتھ برقرار رکھنے کی اجازت دیتا ہے۔ بات بہت دلچسپ نکلی، کیونکہ یہ کیوبر کے ساتھ اچھی طرح سے مربوط ہے اور کوئی نئی ہستی متعارف نہیں کراتی ہے۔
آپ نے آخر میں کیا انتخاب کیا؟
انتخاب آسان نہیں تھا:
- کاکروچ ڈی بی - آگ، لیکن سیاہ؛
- مائی ایس کیو ایل گیلیرا - یہ بھی برا نہیں ہے، یہ بہت سی جگہوں پر استعمال ہوتا ہے، لیکن MySQL؛
- پی جی پول - بہت ساری غیر ضروری ہستی، کلاؤڈ اور K8s کے ساتھ انضمام؛
- پیٹرونی - K8s کے ساتھ بہترین انضمام، کوئی غیر ضروری ہستی نہیں، GCP LB کے ساتھ اچھی طرح سے مربوط ہے۔
اس طرح، انتخاب پیٹرونی پر گر گیا.
نتائج
مختصراً خلاصہ کرنے کا وقت آگیا ہے۔ جی ہاں، آئی ٹی کے بنیادی ڈھانچے کی دنیا میں نمایاں تبدیلی آئی ہے، اور یہ صرف شروعات ہے۔ اور اگر بادلوں سے پہلے صرف ایک اور قسم کا انفراسٹرکچر تھا، اب سب کچھ مختلف ہے۔ مزید برآں، بادلوں میں اختراعات مسلسل نمودار ہو رہی ہیں، وہ ظاہر ہوں گی اور، شاید، وہ صرف بادلوں میں نظر آئیں گی اور تب ہی، اسٹارٹ اپس کی کوششوں سے، انہیں آن پریمیسس میں منتقل کیا جائے گا۔
جہاں تک SQL کا تعلق ہے، SQL زندہ رہے گا۔ اس کا مطلب یہ ہے کہ آپ کو PostgreSQL اور MySQL کو جاننے اور ان کے ساتھ کام کرنے کے قابل ہونے کی ضرورت ہے، لیکن اس سے بھی زیادہ اہم ان کا صحیح استعمال کرنے کے قابل ہونا ہے۔
ماخذ: www.habr.com