سب کو سلام! میرا نام گولوف نکولے ہے۔ پہلے، میں نے Avito میں کام کیا اور چھ سال تک ڈیٹا پلیٹ فارم کا انتظام کیا، یعنی میں نے تمام ڈیٹا بیسز پر کام کیا: تجزیاتی (ورٹیکا، کلک ہاؤس)، اسٹریمنگ اور OLTP (Redis، Tarantool، VoltDB، MongoDB، PostgreSQL)۔ اس وقت کے دوران، میں نے ڈیٹا بیس کی ایک بڑی تعداد سے نمٹا - بہت مختلف اور غیر معمولی، اور ان کے استعمال کے غیر معیاری معاملات کے ساتھ۔
میں فی الحال ManyChat میں کام کر رہا ہوں۔ جوہر میں، یہ ایک آغاز ہے - نیا، مہتواکانکشی اور تیزی سے بڑھ رہا ہے۔ اور جب میں نے پہلی بار کمپنی میں شمولیت اختیار کی تو ایک کلاسک سوال پیدا ہوا: "اب ایک نوجوان اسٹارٹ اپ کو DBMS اور ڈیٹا بیس مارکیٹ سے کیا لینا چاہیے؟"
اس مضمون میں، میری رپورٹ کی بنیاد پر ، میں اس سوال کا جواب دوں گا۔ رپورٹ کا ویڈیو ورژن دستیاب ہے۔ .
عام طور پر جانا جاتا ڈیٹا بیس 2020
یہ 2020 ہے، میں نے ارد گرد دیکھا اور تین طرح کے ڈیٹا بیس دیکھے۔
پہلی قسم - کلاسک OLTP ڈیٹا بیس: PostgreSQL, SQL Server, Oracle, MySQL۔ وہ بہت پہلے لکھے گئے تھے، لیکن اب بھی متعلقہ ہیں کیونکہ وہ ڈویلپر کمیونٹی سے بہت واقف ہیں۔
دوسری قسم ہے۔ "صفر" سے اڈے. انہوں نے ایس کیو ایل، روایتی ڈھانچے اور ACID کو چھوڑ کر، بلٹ ان شارڈنگ اور دیگر پرکشش خصوصیات کو شامل کرکے کلاسک نمونوں سے دور جانے کی کوشش کی۔ مثال کے طور پر، یہ Cassandra، MongoDB، Redis یا Tarantool ہے۔ یہ تمام حل مارکیٹ کو بنیادی طور پر کچھ نیا پیش کرنا چاہتے تھے اور ان کی جگہ پر قبضہ کر لیا تھا کیونکہ وہ بعض کاموں کے لیے انتہائی آسان نکلے تھے۔ میں ان ڈیٹابیس کو NOSQL کی اصطلاح سے ظاہر کروں گا۔
"زیروز" ختم ہو گئے، ہمیں NOSQL ڈیٹا بیس کی عادت ہو گئی، اور دنیا نے، میرے نقطہ نظر سے، اگلا قدم اٹھایا۔ منظم ڈیٹا بیس. ان ڈیٹا بیس میں وہی بنیادی ہے جو کلاسک OLTP ڈیٹا بیس یا نئے NoSQL والے ہیں۔ لیکن انہیں DBA اور DevOps کی کوئی ضرورت نہیں ہے اور وہ بادلوں میں منظم ہارڈ ویئر پر چلتے ہیں۔ ایک ڈویلپر کے لیے، یہ "صرف ایک بنیاد" ہے جو کہیں کام کرتا ہے، لیکن کسی کو پرواہ نہیں کہ یہ سرور پر کیسے انسٹال ہے، سرور کو کس نے کنفیگر کیا اور کون اسے اپ ڈیٹ کرتا ہے۔
اس طرح کے ڈیٹا بیس کی مثالیں:
- AWS RDS PostgreSQL/MySQL کے لیے ایک منظم ریپر ہے۔
- DynamoDB ایک دستاویز پر مبنی ڈیٹا بیس کا AWS اینالاگ ہے، جو Redis اور MongoDB کی طرح ہے۔
- Amazon Redshift ایک منظم تجزیاتی ڈیٹا بیس ہے۔
یہ بنیادی طور پر پرانے ڈیٹا بیس ہیں، لیکن ہارڈ ویئر کے ساتھ کام کرنے کی ضرورت کے بغیر، ایک منظم ماحول میں پرورش پاتے ہیں۔
نوٹ. مثالیں AWS ماحول کے لیے لی گئی ہیں، لیکن ان کے analogues Microsoft Azure، Google Cloud، یا Yandex.Cloud میں بھی موجود ہیں۔
اس میں نیا کیا ہے؟ 2020 میں، اس میں سے کوئی نہیں۔
بے سرور تصور
2020 میں مارکیٹ میں جو واقعی نیا ہے وہ سرور لیس یا سرور لیس حل ہے۔
میں یہ بتانے کی کوشش کروں گا کہ اس کا کیا مطلب ہے ایک باقاعدہ سروس یا بیک اینڈ ایپلیکیشن کی مثال استعمال کرتے ہوئے۔
ایک باقاعدہ بیک اینڈ ایپلیکیشن کی تعیناتی کے لیے، ہم سرور خریدتے یا کرایہ پر لیتے ہیں، اس پر کوڈ کاپی کرتے ہیں، اختتامی نقطہ باہر شائع کرتے ہیں اور کرایہ، بجلی اور ڈیٹا سینٹر کی خدمات کے لیے باقاعدگی سے ادائیگی کرتے ہیں۔ یہ معیاری اسکیم ہے۔
کیا کوئی اور راستہ ہے؟ سرور لیس خدمات کے ساتھ آپ کر سکتے ہیں۔
اس نقطہ نظر کا فوکس کیا ہے: یہاں کوئی سرور نہیں ہے، یہاں تک کہ کلاؤڈ میں کوئی ورچوئل مثال کرایہ پر لینا بھی نہیں ہے۔ سروس کو تعینات کرنے کے لیے، کوڈ (فنکشنز) کو ریپوزٹری میں کاپی کریں اور اسے اینڈ پوائنٹ پر شائع کریں۔ پھر ہم اس فنکشن کے لیے ہر کال کے لیے صرف ادائیگی کرتے ہیں، اس ہارڈ ویئر کو مکمل طور پر نظر انداز کرتے ہوئے جہاں اس پر عمل ہوتا ہے۔
میں اس نقطہ نظر کو تصویروں کے ساتھ واضح کرنے کی کوشش کروں گا۔
کلاسیکی تعیناتی۔. ہمارے پاس ایک خاص بوجھ کے ساتھ ایک خدمت ہے۔ ہم دو مثالیں اٹھاتے ہیں: جسمانی سرورز یا AWS میں مثالیں۔ بیرونی درخواستیں ان مثالوں پر بھیجی جاتی ہیں اور وہاں کارروائی کی جاتی ہیں۔
جیسا کہ آپ تصویر میں دیکھ سکتے ہیں، سرورز کو مساوی طور پر ضائع نہیں کیا گیا ہے۔ ایک 100% استعمال شدہ ہے، دو درخواستیں ہیں، اور ایک صرف 50% ہے - جزوی طور پر بیکار۔ اگر تین نہیں بلکہ 30 درخواستیں آتی ہیں تو پورا نظام بوجھ کا مقابلہ نہیں کر سکے گا اور سست ہونا شروع ہو جائے گا۔
سرور کے بغیر تعیناتی۔. سرور کے بغیر ماحول میں، ایسی سروس میں مثالیں یا سرور نہیں ہوتے ہیں۔ گرم وسائل کا ایک خاص تالاب ہے - تعینات فنکشن کوڈ کے ساتھ چھوٹے تیار ڈوکر کنٹینرز۔ سسٹم کو بیرونی درخواستیں موصول ہوتی ہیں اور ان میں سے ہر ایک کے لیے سرور لیس فریم ورک کوڈ کے ساتھ ایک چھوٹا کنٹینر اٹھاتا ہے: یہ اس مخصوص درخواست پر کارروائی کرتا ہے اور کنٹینر کو مار دیتا ہے۔
ایک درخواست - ایک کنٹینر اٹھایا گیا، 1000 درخواستیں - 1000 کنٹینرز۔ اور ہارڈ ویئر سرورز پر تعیناتی پہلے سے ہی کلاؤڈ فراہم کرنے والے کا کام ہے۔ یہ سرور لیس فریم ورک کے ذریعہ مکمل طور پر پوشیدہ ہے۔ اس تصور میں ہم ہر کال کے لیے ادائیگی کرتے ہیں۔ مثال کے طور پر، ایک دن میں ایک کال آئی - ہم نے ایک کال کی ادائیگی کی، ایک ملین فی منٹ آئے - ہم نے ایک ملین کی ادائیگی کی۔ یا ایک سیکنڈ میں یہ بھی ہو جاتا ہے۔
سرور لیس فنکشن کی اشاعت کا تصور اسٹیٹ لیس سروس کے لیے موزوں ہے۔ اور اگر آپ کو (ریاست) سٹیٹ فل سروس کی ضرورت ہے، تو ہم سروس میں ایک ڈیٹا بیس شامل کرتے ہیں۔ اس صورت میں، جب ریاست کے ساتھ کام کرنے کی بات آتی ہے، تو ہر سٹیٹ فل فنکشن صرف ڈیٹا بیس سے لکھتا اور پڑھتا ہے۔ مزید یہ کہ مضمون کے شروع میں بیان کردہ تین اقسام میں سے کسی کے ڈیٹا بیس سے۔
ان تمام ڈیٹا بیس کی مشترکہ حد کیا ہے؟ یہ مسلسل استعمال ہونے والے کلاؤڈ یا ہارڈویئر سرور (یا متعدد سرورز) کے اخراجات ہیں۔ اس سے کوئی فرق نہیں پڑتا کہ ہم کلاسک یا منظم ڈیٹا بیس استعمال کرتے ہیں، چاہے ہمارے پاس ڈیوپس اور ایڈمن ہوں یا نہ ہوں، ہم پھر بھی ہارڈ ویئر، بجلی اور ڈیٹا سینٹر کے کرایے کے لیے 24/7 ادائیگی کرتے ہیں۔ اگر ہمارے پاس کلاسک بنیاد ہے، تو ہم آقا اور غلام کے لیے ادائیگی کرتے ہیں۔ اگر یہ انتہائی بھری ہوئی شارڈڈ ڈیٹا بیس ہے، تو ہم 10، 20 یا 30 سرورز کے لیے ادائیگی کرتے ہیں، اور ہم مسلسل ادائیگی کرتے ہیں۔
لاگت کے ڈھانچے میں مستقل طور پر محفوظ سرورز کی موجودگی کو پہلے ایک ضروری برائی کے طور پر سمجھا جاتا تھا۔ روایتی ڈیٹا بیس میں دیگر مشکلات بھی ہوتی ہیں، جیسے کنکشنز کی تعداد کی حد، اسکیلنگ کی پابندیاں، جیو ڈسٹری بیوٹڈ کننسنس - وہ کسی نہ کسی طرح سے مخصوص ڈیٹا بیس میں حل کیے جا سکتے ہیں، لیکن سب ایک ساتھ نہیں اور مثالی طور پر نہیں۔
سرور لیس ڈیٹا بیس - تھیوری
2020 کا سوال: کیا ڈیٹا بیس کو بھی سرور لیس کرنا ممکن ہے؟ سب نے سرور لیس بیک اینڈ کے بارے میں سنا ہے... آئیے ڈیٹا بیس کو سرور لیس بنانے کی کوشش کریں؟
یہ عجیب لگتا ہے، کیونکہ ڈیٹا بیس ایک سٹیٹ فل سروس ہے، جو سرور کے بغیر انفراسٹرکچر کے لیے زیادہ موزوں نہیں ہے۔ ایک ہی وقت میں، ڈیٹا بیس کی حالت بہت بڑی ہے: گیگا بائٹس، ٹیرا بائٹس، اور تجزیاتی ڈیٹا بیس میں بھی پیٹا بائٹس۔ ہلکے وزن والے ڈوکر کنٹینرز میں اسے بڑھانا اتنا آسان نہیں ہے۔
دوسری طرف، تقریباً تمام جدید ڈیٹا بیس میں بہت زیادہ منطق اور اجزاء ہوتے ہیں: لین دین، سالمیت کوآرڈینیشن، طریقہ کار، رشتہ دارانہ انحصار اور بہت سی منطق۔ ڈیٹا بیس کی کافی منطق کے لیے، ایک چھوٹی سی ریاست کافی ہے۔ گیگا بائٹس اور ٹیرا بائٹس براہ راست ڈیٹا بیس منطق کے صرف ایک چھوٹے سے حصے کے ذریعہ استعمال ہوتے ہیں جو براہ راست سوالات کو انجام دینے میں شامل ہیں۔
اس کے مطابق، خیال یہ ہے کہ: اگر منطق کا حصہ ریاست کے بغیر عمل درآمد کی اجازت دیتا ہے، تو کیوں نہ بنیاد کو ریاستی اور بے ریاست حصوں میں تقسیم کیا جائے۔
OLAP حل کے لیے بے سرور
آئیے دیکھتے ہیں کہ عملی مثالوں کا استعمال کرتے ہوئے ڈیٹا بیس کو اسٹیٹفل اور اسٹیٹ لیس حصوں میں کاٹنا کیسا لگتا ہے۔
مثال کے طور پر، ہمارے پاس ایک تجزیاتی ڈیٹا بیس ہے۔: بیرونی ڈیٹا (بائیں طرف سرخ سلنڈر)، ایک ETL عمل جو ڈیٹا بیس میں ڈیٹا لوڈ کرتا ہے، اور ایک تجزیہ کار جو ڈیٹا بیس کو SQL سوالات بھیجتا ہے۔ یہ ایک کلاسک ڈیٹا گودام آپریشن اسکیم ہے۔
اس اسکیم میں، ETL مشروط طور پر ایک بار انجام دیا جاتا ہے۔ پھر آپ کو ان سرورز کے لیے مسلسل ادائیگی کرنے کی ضرورت ہے جن پر ڈیٹا بیس ETL سے بھرے ڈیٹا کے ساتھ چلتا ہے، تاکہ سوالات بھیجنے کے لیے کچھ ہو۔
آئیے AWS Athena Serverless میں نافذ کردہ ایک متبادل نقطہ نظر کو دیکھتے ہیں۔ کوئی مستقل طور پر وقف کردہ ہارڈ ویئر نہیں ہے جس پر ڈاؤن لوڈ کردہ ڈیٹا محفوظ کیا جاتا ہے۔ اس کے بجائے:
- صارف ایک ایس کیو ایل استفسار ایتھینا کو بھیجتا ہے۔ ایتھینا آپٹیمائزر SQL استفسار کا تجزیہ کرتا ہے اور استفسار کو انجام دینے کے لیے درکار مخصوص ڈیٹا کے لیے میٹا ڈیٹا اسٹور (میٹا ڈیٹا) کو تلاش کرتا ہے۔
- جمع کردہ ڈیٹا کی بنیاد پر اصلاح کار، بیرونی ذرائع سے ضروری ڈیٹا کو عارضی اسٹوریج (عارضی ڈیٹا بیس) میں ڈاؤن لوڈ کرتا ہے۔
- صارف کی طرف سے ایک SQL استفسار عارضی اسٹوریج میں عمل میں لایا جاتا ہے اور نتیجہ صارف کو واپس کر دیا جاتا ہے۔
- عارضی اسٹوریج کو صاف کیا جاتا ہے اور وسائل جاری کیے جاتے ہیں۔
اس فن تعمیر میں، ہم صرف درخواست پر عمل درآمد کے لیے ادائیگی کرتے ہیں۔ کوئی درخواست نہیں - کوئی لاگت نہیں۔
یہ ایک کام کرنے کا طریقہ ہے اور نہ صرف ایتھینا سرور لیس میں بلکہ Redshift Spectrum (AWS میں) میں بھی لاگو ہوتا ہے۔
ایتھینا کی مثال سے پتہ چلتا ہے کہ سرور لیس ڈیٹا بیس دسیوں اور سینکڑوں ٹیرا بائٹس ڈیٹا کے ساتھ حقیقی سوالات پر کام کرتا ہے۔ سیکڑوں ٹیرابائٹس کے لیے سینکڑوں سرورز کی ضرورت ہوگی، لیکن ہمیں ان کے لیے ادائیگی کرنے کی ضرورت نہیں ہے - ہم درخواستوں کے لیے ادائیگی کرتے ہیں۔ ورٹیکا جیسے خصوصی تجزیاتی ڈیٹا بیس کے مقابلے ہر درخواست کی رفتار (بہت) کم ہے، لیکن ہم ڈاؤن ٹائم پیریڈ کے لیے ادائیگی نہیں کرتے ہیں۔
اس طرح کا ڈیٹا بیس نایاب تجزیاتی ایڈہاک سوالات کے لیے لاگو ہوتا ہے۔ مثال کے طور پر، جب ہم بے ساختہ ڈیٹا کی کچھ بڑی مقدار پر ایک مفروضے کی جانچ کرنے کا فیصلہ کرتے ہیں۔ ایتھینا ان معاملات کے لیے بہترین ہے۔ باقاعدہ درخواستوں کے لئے، اس طرح کا نظام مہنگا ہے. اس صورت میں، ڈیٹا کو کچھ مخصوص حل میں کیش کریں۔
OLTP حل کے لیے بغیر سرور
پچھلی مثال نے OLAP (تجزیاتی) کاموں کو دیکھا۔ اب OLTP کے کاموں کو دیکھتے ہیں۔
آئیے اسکیل ایبل PostgreSQL یا MySQL کا تصور کریں۔ آئیے کم سے کم وسائل کے ساتھ ایک باقاعدہ منظم مثال PostgreSQL یا MySQL اٹھاتے ہیں۔ جب مثال زیادہ بوجھ حاصل کرتی ہے، تو ہم اضافی نقلیں جوڑیں گے جس میں ہم پڑھنے کے بوجھ کا کچھ حصہ تقسیم کریں گے۔ اگر کوئی درخواستیں یا لوڈ نہیں ہیں، تو ہم نقلیں بند کر دیتے ہیں۔ پہلی مثال ماسٹر ہے، اور باقی نقلیں ہیں۔
یہ خیال Aurora Serverless AWS نامی ڈیٹا بیس میں لاگو کیا گیا ہے۔ اصول آسان ہے: بیرونی ایپلی کیشنز کی درخواستیں پراکسی فلیٹ کے ذریعے قبول کی جاتی ہیں۔ بوجھ میں اضافہ دیکھ کر، یہ پہلے سے گرم ہونے والے کم سے کم مثالوں سے کمپیوٹنگ کے وسائل مختص کرتا ہے - جتنی جلدی ممکن ہو رابطہ کیا جاتا ہے۔ غیر فعال کرنے کی مثالیں اسی طرح ہوتی ہیں۔
Aurora کے اندر Aurora Capacity Unit، ACU کا تصور موجود ہے۔ یہ (مشروط طور پر) ایک مثال (سرور) ہے۔ ہر مخصوص ACU ایک آقا یا غلام ہو سکتا ہے۔ ہر کیپسٹی یونٹ کی اپنی RAM، پروسیسر اور کم سے کم ڈسک ہوتی ہے۔ اس کے مطابق، ایک ماسٹر ہے، باقی صرف پڑھے ہوئے نقلیں ہیں۔
ان ارورہ کیپیسیٹی یونٹس کی تعداد جو چل رہی ہے ایک قابل ترتیب پیرامیٹر ہے۔ کم از کم مقدار ایک یا صفر ہو سکتی ہے (اس صورت میں، اگر کوئی درخواستیں نہ ہوں تو ڈیٹا بیس کام نہیں کرتا)۔
جب بیس کو درخواستیں موصول ہوتی ہیں، پراکسی فلیٹ Aurora CapacityUnits کو بڑھاتا ہے، جس سے سسٹم کی کارکردگی کے وسائل میں اضافہ ہوتا ہے۔ وسائل کو بڑھانے اور کم کرنے کی صلاحیت سسٹم کو وسائل کو "جگل" کرنے کی اجازت دیتی ہے: خود بخود انفرادی ACUs کو ظاہر کرتا ہے (ان کی جگہ نئے سے) اور واپس لیے گئے وسائل میں تمام موجودہ اپ ڈیٹس کو رول آؤٹ کرتا ہے۔
ارورہ سرور لیس بیس پڑھنے کے بوجھ کو پیمانہ کر سکتا ہے۔ لیکن دستاویزات یہ براہ راست نہیں بتاتی ہیں۔ ایسا محسوس ہو سکتا ہے کہ وہ ملٹی ماسٹر کو اٹھا سکتے ہیں۔ کوئی جادو نہیں ہے۔
یہ ڈیٹا بیس غیر متوقع رسائی والے سسٹمز پر بھاری رقم خرچ کرنے سے بچنے کے لیے موزوں ہے۔ مثال کے طور پر، MVP یا مارکیٹنگ بزنس کارڈ سائٹس بناتے وقت، ہم عام طور پر مستحکم بوجھ کی توقع نہیں کرتے ہیں۔ اس کے مطابق، اگر رسائی نہیں ہے، تو ہم مثال کے طور پر ادائیگی نہیں کرتے ہیں۔ جب غیر متوقع بوجھ ہوتا ہے، مثال کے طور پر کسی کانفرنس یا اشتہاری مہم کے بعد، لوگوں کا ہجوم سائٹ کا دورہ کرتا ہے اور لوڈ ڈرامائی طور پر بڑھ جاتا ہے، Aurora Serverless خود بخود اس بوجھ کو اٹھا لیتا ہے اور جلدی سے غائب وسائل (ACU) کو جوڑ دیتا ہے۔ پھر کانفرنس گزر جاتی ہے، ہر کوئی پروٹوٹائپ کے بارے میں بھول جاتا ہے، سرورز (ACU) تاریک ہو جاتے ہیں، اور لاگت صفر ہو جاتی ہے - آسان۔
یہ حل مستحکم ہائی لوڈ کے لیے موزوں نہیں ہے کیونکہ یہ تحریری بوجھ کو پیمانہ نہیں کرتا ہے۔ وسائل کے یہ تمام رابطے اور منقطع نام نہاد "اسکیل پوائنٹ" پر ہوتے ہیں - وقت کا ایک نقطہ جب ڈیٹا بیس کو کسی لین دین یا عارضی ٹیبلز کے ذریعے تعاون نہیں کیا جاتا ہے۔ مثال کے طور پر، ایک ہفتے کے اندر سکیل پوائنٹ نہیں ہو سکتا، اور بنیاد ایک ہی وسائل پر کام کرتی ہے اور محض توسیع یا معاہدہ نہیں کر سکتی۔
کوئی جادو نہیں ہے - یہ باقاعدہ PostgreSQL ہے۔ لیکن مشینوں کو شامل کرنے اور ان کو منقطع کرنے کا عمل جزوی طور پر خودکار ہے۔
ڈیزائن کے لحاظ سے بے سرور
Aurora Serverless ایک پرانا ڈیٹا بیس ہے جسے کلاؤڈ کے لیے سرور لیس کے کچھ فوائد سے فائدہ اٹھانے کے لیے دوبارہ لکھا گیا ہے۔ اور اب میں آپ کو بیس کے بارے میں بتاؤں گا، جو کہ اصل میں کلاؤڈ کے لیے لکھا گیا تھا، سرور لیس اپروچ کے لیے - Serverless-by-design۔ یہ فوری طور پر اس تصور کے بغیر تیار کیا گیا تھا کہ یہ جسمانی سرورز پر چلے گا۔
اس اڈے کو Snowflake کہا جاتا ہے۔ اس میں تین کلیدی بلاکس ہیں۔
پہلا میٹا ڈیٹا بلاک ہے۔ یہ ایک تیز رفتار ان میموری سروس ہے جو سیکیورٹی، میٹا ڈیٹا، لین دین، اور استفسار کی اصلاح کے مسائل حل کرتی ہے (بائیں طرف کی مثال میں دکھایا گیا ہے)۔
دوسرا بلاک حساب کے لیے ورچوئل کمپیوٹنگ کلسٹرز کا ایک سیٹ ہے (تمثال میں نیلے دائروں کا ایک سیٹ ہے)۔
تیسرا بلاک S3 پر مبنی ڈیٹا اسٹوریج سسٹم ہے۔ S3 AWS میں ڈائمینشن لیس آبجیکٹ اسٹوریج ہے، کاروبار کے لیے ڈائمینشن لیس ڈراپ باکس کی طرح۔
آئیے دیکھتے ہیں کہ کولڈ اسٹارٹ فرض کرتے ہوئے سنو فلیک کیسے کام کرتا ہے۔ یعنی، ایک ڈیٹا بیس ہے، اس میں ڈیٹا بھرا ہوا ہے، کوئی رننگ سوالات نہیں ہیں۔ اس کے مطابق، اگر ڈیٹا بیس سے کوئی درخواستیں نہیں ہیں، تو ہم نے فاسٹ ان میموری میٹا ڈیٹا سروس (پہلا بلاک) بڑھا دیا ہے۔ اور ہمارے پاس S3 اسٹوریج ہے، جہاں ٹیبل ڈیٹا محفوظ کیا جاتا ہے، نام نہاد مائکرو پارٹیشنز میں تقسیم کیا جاتا ہے۔ سادگی کے لیے: اگر ٹیبل میں لین دین ہے، تو مائیکرو پارٹیشنز لین دین کے دن ہیں۔ ہر دن ایک الگ مائیکرو پارٹیشن ہے، ایک الگ فائل۔ اور جب ڈیٹا بیس اس موڈ میں کام کرتا ہے، تو آپ صرف ڈیٹا کے زیر قبضہ جگہ کے لیے ادائیگی کرتے ہیں۔ مزید یہ کہ، فی سیٹ کی شرح بہت کم ہے (خاص طور پر اہم کمپریشن کو مدنظر رکھتے ہوئے)۔ میٹا ڈیٹا سروس بھی مسلسل کام کرتی ہے، لیکن آپ کو سوالات کو بہتر بنانے کے لیے بہت زیادہ وسائل کی ضرورت نہیں ہے، اور سروس کو شیئر ویئر سمجھا جا سکتا ہے۔
اب تصور کریں کہ ایک صارف ہمارے ڈیٹا بیس پر آیا اور ایک ایس کیو ایل استفسار بھیجا۔ ایس کیو ایل کا استفسار فوری طور پر میٹا ڈیٹا سروس کو پروسیسنگ کے لیے بھیجا جاتا ہے۔ اس کے مطابق، درخواست موصول ہونے پر، یہ سروس درخواست، دستیاب ڈیٹا، صارف کی اجازتوں کا تجزیہ کرتی ہے اور، اگر سب کچھ ٹھیک ہے، درخواست پر کارروائی کے لیے ایک منصوبہ تیار کرتا ہے۔
اگلا، سروس کمپیوٹنگ کلسٹر کے آغاز کا آغاز کرتی ہے۔ ایک کمپیوٹنگ کلسٹر سرورز کا ایک کلسٹر ہے جو حسابات انجام دیتا ہے۔ یعنی یہ ایک ایسا کلسٹر ہے جس میں 1 سرور، 2 سرورز، 4، 8، 16، 32 - جتنے آپ چاہیں پر مشتمل ہوسکتے ہیں۔ آپ ایک درخواست دیتے ہیں اور اس کلسٹر کا اجراء فوراً شروع ہو جاتا ہے۔ یہ واقعی سیکنڈ لیتا ہے.
اگلا، کلسٹر شروع ہونے کے بعد، آپ کی درخواست پر کارروائی کرنے کے لیے درکار مائیکرو پارٹیشنز S3 سے کلسٹر میں کاپی ہونا شروع ہو جاتے ہیں۔ یعنی، آئیے تصور کریں کہ ایس کیو ایل کے استفسار پر عمل کرنے کے لیے آپ کو ایک ٹیبل سے دو پارٹیشنز کی ضرورت ہے اور ایک دوسرے سے۔ اس صورت میں، صرف تین ضروری پارٹیشنز کو کلسٹر میں کاپی کیا جائے گا، اور تمام ٹیبلز کو مکمل طور پر نہیں۔ یہی وجہ ہے، اور قطعی طور پر چونکہ ہر چیز ایک ڈیٹا سینٹر کے اندر واقع ہے اور بہت تیز چینلز سے منسلک ہے، اس لیے منتقلی کا پورا عمل بہت تیزی سے ہوتا ہے: سیکنڈوں میں، بہت کم منٹوں میں، جب تک کہ ہم کچھ خوفناک درخواستوں کے بارے میں بات نہ کر رہے ہوں۔ اس کے مطابق، مائیکرو پارٹیشنز کو کمپیوٹنگ کلسٹر میں کاپی کیا جاتا ہے، اور، مکمل ہونے پر، اس کمپیوٹنگ کلسٹر پر ایس کیو ایل استفسار پر عمل درآمد کیا جاتا ہے۔ اس درخواست کا نتیجہ ایک لائن، کئی لائنیں یا ایک میز ہو سکتا ہے - وہ صارف کو بیرونی طور پر بھیجے جاتے ہیں تاکہ وہ اسے ڈاؤن لوڈ کر سکے، اسے اپنے BI ٹول میں ڈسپلے کر سکے، یا کسی اور طریقے سے استعمال کر سکے۔
ہر SQL استفسار نہ صرف پہلے سے بھرے ہوئے ڈیٹا سے مجموعی طور پر پڑھ سکتا ہے، بلکہ ڈیٹا بیس میں نیا ڈیٹا لوڈ/جنریٹ بھی کر سکتا ہے۔ یعنی، یہ ایک سوال ہو سکتا ہے کہ، مثال کے طور پر، نئے ریکارڈز کو کسی اور ٹیبل میں داخل کرتا ہے، جس سے کمپیوٹنگ کلسٹر پر ایک نیا پارٹیشن ظاہر ہوتا ہے، جو بدلے میں، ایک ہی S3 اسٹوریج میں خود بخود محفوظ ہو جاتا ہے۔
اوپر بیان کردہ منظر نامے، صارف کی آمد سے لے کر کلسٹر کو بڑھانے تک، ڈیٹا لوڈ کرنے، سوالات کو انجام دینے، نتائج حاصل کرنے تک، اٹھائے گئے ورچوئل کمپیوٹنگ کلسٹر، ورچوئل گودام کو استعمال کرنے کے منٹوں کے حساب سے ادائیگی کی جاتی ہے۔ شرح AWS زون اور کلسٹر سائز کے لحاظ سے مختلف ہوتی ہے، لیکن اوسطاً یہ چند ڈالر فی گھنٹہ ہے۔ چار مشینوں کا ایک کلسٹر دو مشینوں کے کلسٹر سے دوگنا مہنگا ہے، اور آٹھ مشینوں کا کلسٹر اب بھی دوگنا مہنگا ہے۔ درخواستوں کی پیچیدگی کے لحاظ سے 16، 32 مشینوں کے اختیارات دستیاب ہیں۔ لیکن آپ صرف ان منٹوں کے لیے ادائیگی کرتے ہیں جب کلسٹر درحقیقت چل رہا ہو، کیونکہ جب کوئی درخواستیں نہیں ہوتی ہیں، تو آپ ایک طرح سے ہاتھ ہٹا لیتے ہیں، اور 5-10 منٹ کے انتظار کے بعد (ایک قابل ترتیب پیرامیٹر) یہ خود ہی چلا جائے گا، وسائل کو آزاد کریں اور آزاد ہوجائیں۔
ایک مکمل حقیقت پسندانہ منظر نامہ یہ ہے کہ جب آپ کوئی درخواست بھیجتے ہیں، تو کلسٹر پاپ اپ ہوجاتا ہے، نسبتاً ایک منٹ میں، یہ ایک اور منٹ گنتا ہے، پھر بند ہونے کے لیے پانچ منٹ، اور آپ اس کلسٹر کے آپریشن کے سات منٹ کے لیے ادائیگی کرتے ہیں، اور مہینوں اور سالوں کے لیے نہیں۔
ایک واحد صارف کی ترتیب میں سنو فلیک کا استعمال کرتے ہوئے بیان کردہ پہلا منظر۔ اب تصور کریں کہ بہت سے صارفین ہیں، جو حقیقی منظر نامے کے قریب ہیں۔
ہم کہتے ہیں کہ ہمارے پاس بہت سارے تجزیہ کار اور ٹیبلو رپورٹس ہیں جو ہمارے ڈیٹا بیس پر بڑی تعداد میں سادہ تجزیاتی SQL سوالات کے ساتھ مسلسل بمباری کرتی ہیں۔
اس کے علاوہ، ہم یہ بتاتے چلیں کہ ہمارے پاس اختراعی ڈیٹا سائنسدان ہیں جو ڈیٹا کے ساتھ خوفناک کام کرنے کی کوشش کر رہے ہیں، دسیوں ٹیرابائٹس کے ساتھ کام کرتے ہیں، ڈیٹا کی اربوں اور کھربوں قطاروں کا تجزیہ کرتے ہیں۔
اوپر بیان کیے گئے کام کے بوجھ کی دو اقسام کے لیے، Snowflake آپ کو مختلف صلاحیتوں کے کئی آزاد کمپیوٹنگ کلسٹرز کو بڑھانے کی اجازت دیتا ہے۔ مزید یہ کہ، یہ کمپیوٹنگ کلسٹرز آزادانہ طور پر کام کرتے ہیں، لیکن عام مستقل ڈیٹا کے ساتھ۔
روشنی کے سوالات کی ایک بڑی تعداد کے لیے، آپ 2-3 چھوٹے کلسٹرز، ہر ایک میں تقریباً 2 مشینیں اٹھا سکتے ہیں۔ خودکار ترتیبات کا استعمال کرتے ہوئے دیگر چیزوں کے ساتھ ساتھ اس رویے کو لاگو کیا جا سکتا ہے۔ تو آپ کہتے ہیں، "سنو فلیک، ایک چھوٹا سا جھرمٹ اٹھاؤ۔ اگر اس پر بوجھ ایک مخصوص پیرامیٹر سے بڑھ جاتا ہے تو اسی طرح کا دوسرا، تیسرا بڑھائیں۔ جب بوجھ کم ہونے لگے تو اضافی کو بجھا دیں۔" تاکہ جتنے بھی تجزیہ نگار آئیں اور رپورٹیں دیکھنا شروع کر دیں، ہر ایک کے پاس کافی وسائل ہیں۔
ایک ہی وقت میں، اگر تجزیہ کار سو رہے ہیں اور کوئی بھی رپورٹس کو نہیں دیکھ رہا ہے، تو کلسٹر مکمل طور پر تاریک ہو سکتے ہیں، اور آپ ان کی ادائیگی بند کر دیتے ہیں۔
ایک ہی وقت میں، بھاری سوالات کے لیے (ڈیٹا سائنسدانوں سے)، آپ 32 مشینوں کے لیے ایک بہت بڑا کلسٹر بڑھا سکتے ہیں۔ اس کلسٹر کو بھی صرف ان منٹوں اور گھنٹوں کے لیے ادا کیا جائے گا جب آپ کی بڑی درخواست وہاں چل رہی ہو گی۔
اوپر بیان کردہ موقع آپ کو نہ صرف 2، بلکہ کام کے بوجھ کی مزید اقسام کو کلسٹرز میں تقسیم کرنے کی اجازت دیتا ہے (ETL، نگرانی، رپورٹ کا مواد بنانا،...)۔
آئیے Snowflake کا خلاصہ کرتے ہیں۔ بنیاد ایک خوبصورت خیال اور قابل عمل نفاذ کو یکجا کرتی ہے۔ ManyChat میں، ہم اپنے پاس موجود تمام ڈیٹا کا تجزیہ کرنے کے لیے Snowflake کا استعمال کرتے ہیں۔ ہمارے پاس تین کلسٹرز نہیں ہیں، جیسا کہ مثال میں ہے، لیکن 5 سے 9 تک، مختلف سائز کے ہیں۔ ہمارے پاس کچھ کاموں کے لیے روایتی 16-مشین، 2-مشین، اور انتہائی چھوٹی 1-مشینیں بھی ہیں۔ وہ کامیابی سے بوجھ کو تقسیم کرتے ہیں اور ہمیں بہت کچھ بچانے کی اجازت دیتے ہیں۔
ڈیٹا بیس پڑھنے اور لکھنے کے بوجھ کو کامیابی سے پیمانہ کرتا ہے۔ یہ ایک بہت بڑا فرق ہے اور اسی "ارورہ" کے مقابلے میں ایک بہت بڑی پیش رفت ہے، جو صرف پڑھنے کا بوجھ اٹھاتی ہے۔ سنو فلیک آپ کو ان کمپیوٹنگ کلسٹرز کے ساتھ اپنے تحریری کام کا بوجھ پیمانہ کرنے کی اجازت دیتا ہے۔ یعنی جیسا کہ میں نے ذکر کیا ہے، ہم ManyChat میں کئی کلسٹرز استعمال کرتے ہیں، چھوٹے اور انتہائی چھوٹے کلسٹرز بنیادی طور پر ETL کے لیے، ڈیٹا لوڈ کرنے کے لیے استعمال ہوتے ہیں۔ اور تجزیہ کار پہلے ہی درمیانے درجے کے کلسٹرز پر رہتے ہیں، جو کہ ETL بوجھ سے بالکل متاثر نہیں ہوتے، اس لیے وہ بہت تیزی سے کام کرتے ہیں۔
اس کے مطابق، ڈیٹا بیس OLAP کے کاموں کے لیے موزوں ہے۔ تاہم، بدقسمتی سے، یہ ابھی تک OLTP کام کے بوجھ کے لیے قابل اطلاق نہیں ہے۔ سب سے پہلے، یہ ڈیٹا بیس کالمی ہے، جس کے تمام آنے والے نتائج ہیں۔ دوم، نقطہ نظر خود، جب ہر درخواست کے لیے، اگر ضروری ہو تو، آپ ایک کمپیوٹنگ کلسٹر بڑھاتے ہیں اور اسے ڈیٹا سے بھر دیتے ہیں، بدقسمتی سے، ابھی تک OLTP لوڈز کے لیے کافی تیز نہیں ہے۔ OLAP کاموں کے لیے سیکنڈوں کا انتظار کرنا معمول کی بات ہے، لیکن OLTP کاموں کے لیے یہ ناقابل قبول ہے؛ 100 ms بہتر ہوگا، یا 10 ms اس سے بھی بہتر ہوگا۔
کل
ڈیٹا بیس کو اسٹیٹ لیس اور اسٹیٹ فل حصوں میں تقسیم کرکے سرور لیس ڈیٹا بیس ممکن ہے۔ آپ نے دیکھا ہوگا کہ مذکورہ بالا تمام مثالوں میں، اسٹیٹفول حصہ، نسبتاً بولتے ہوئے، مائیکرو پارٹیشنز کو S3 میں اسٹور کرنا ہے، اور اسٹیٹ لیس آپٹیمائزر ہے، میٹا ڈیٹا کے ساتھ کام کرنا، سیکیورٹی کے مسائل کو ہینڈل کرنا جو آزادانہ ہلکی پھلکی اسٹیٹ لیس خدمات کے طور پر اٹھائے جاسکتے ہیں۔
ایس کیو ایل کے سوالات پر عمل درآمد کو لائٹ اسٹیٹ سروسز کے طور پر بھی سمجھا جا سکتا ہے جو سرور لیس موڈ میں پاپ اپ ہو سکتی ہیں، جیسے سنو فلیک کمپیوٹنگ کلسٹرز، صرف ضروری ڈیٹا ڈاؤن لوڈ کر سکتے ہیں، استفسار پر عمل درآمد کر سکتے ہیں اور "باہر جا سکتے ہیں۔"
سرور لیس پروڈکشن لیول ڈیٹا بیس پہلے ہی استعمال کے لیے دستیاب ہیں، وہ کام کر رہے ہیں۔ یہ سرور لیس ڈیٹا بیس پہلے ہی OLAP کے کاموں کو سنبھالنے کے لیے تیار ہیں۔ بدقسمتی سے، OLTP کاموں کے لیے ان کا استعمال کیا جاتا ہے... باریکیوں کے ساتھ، کیونکہ اس کی حدود ہیں۔ ایک طرف، یہ مائنس ہے۔ لیکن، دوسری طرف، یہ ایک موقع ہے. شاید قارئین میں سے کوئی ایک OLTP ڈیٹا بیس کو مکمل طور پر سرور لیس بنانے کا طریقہ تلاش کرے گا، بغیر ارورہ کی حدود کے۔
مجھے امید ہے کہ آپ کو یہ دلچسپ لگا۔ بے سرور مستقبل ہے :)
ماخذ: www.habr.com