ہیلو، خبررساں۔ روایتی طور پر، ہم نئے کورسز کے آغاز کے موقع پر دلچسپ مواد کا اشتراک کرتے رہتے ہیں۔ آج، خاص طور پر آپ کے لیے، ہم نے گوگل کلاؤڈ اسپنر کے بارے میں ایک مضمون کا ترجمہ کیا ہے، جو کورس کے آغاز کے موقع پر ہے۔ .
اصل میں شائع ہوا۔ .
ایک کمپنی کے طور پر جو دنیا بھر میں خوردہ فروشوں، ریسٹوریٹروں اور آن لائن تاجروں کے لیے کلاؤڈ پر مبنی POS حل پیش کرتی ہے، Lightspeed مختلف قسم کے لین دین، تجزیات، اور تلاش کے استعمال کے کیسز کے لیے ڈیٹا بیس پلیٹ فارمز کی متعدد اقسام کا استعمال کرتی ہے۔ ان ڈیٹابیس پلیٹ فارمز میں سے ہر ایک کی اپنی طاقتیں اور کمزوریاں ہیں۔ اس لیے، جب گوگل نے کلاؤڈ اسپنر کو مارکیٹ میں متعارف کرایا - امید افزا خصوصیات جو کہ متعلقہ ڈیٹا بیس کی دنیا میں پہلے کبھی نہیں دیکھی گئیں، جیسے کہ عملی طور پر لامحدود افقی اسکیل ایبلٹی اور 99,999% سروس لیول معاہدہ (SLA) ، ہم اسے اپنے ہاتھ میں لینے کا موقع ہاتھ سے جانے نہیں دے سکتے تھے!
Cloud Spanner کے ساتھ اپنے تجربے کا ایک جامع جائزہ دینے کے ساتھ ساتھ تشخیص کے معیارات جو ہم نے استعمال کیے ہیں، ہم درج ذیل عنوانات کا احاطہ کریں گے:
- ہماری تشخیص کا معیار
- کلاؤڈ اسپنر مختصر طور پر
- ہماری تشخیص
- ہمارے نتائج۔
1. ہماری تشخیص کا معیار
کلاؤڈ اسپنر کی تفصیلات، مارکیٹ میں موجود دیگر حلوں کے ساتھ اس کی مماثلت اور فرق کو جاننے سے پہلے، آئیے سب سے پہلے ان بنیادی استعمال کے معاملات کے بارے میں بات کرتے ہیں جو ہمارے ذہن میں تھے جب ہم اپنے انفراسٹرکچر میں کلاؤڈ اسپنر کو کہاں تعینات کریں:
- (موجودہ) روایتی SQL ڈیٹا بیس حل کے متبادل کے طور پر
- OLAP سپورٹ کے ساتھ OLTP حل کے طور پر
نوٹ: موازنہ میں آسانی کے لیے، یہ مضمون کلاؤڈ اسپنر کا موازنہ GCP Cloud SQL اور Amazon AWS RDS سلوشن فیملیز کے MySQL متغیرات سے کرتا ہے۔
روایتی SQL ڈیٹا بیس حل کے متبادل کے طور پر کلاؤڈ اسپنر کا استعمال
ماحول میں روایتی ڈیٹا بیس، جب ڈیٹا بیس کے استفسار کے لیے جوابی وقت قریب آتا ہے یا اس سے بھی پہلے سے طے شدہ درخواست کی حد سے تجاوز کر جاتا ہے (بنیادی طور پر صارفین اور/یا درخواستوں کی تعداد میں اضافے کی وجہ سے)، جوابی وقت کو قابل قبول سطح تک کم کرنے کے کئی طریقے ہوتے ہیں۔ تاہم، ان میں سے زیادہ تر حلوں میں دستی مداخلت شامل ہے۔
مثال کے طور پر، پہلا قدم یہ ہے کہ کارکردگی سے متعلق ڈیٹا بیس کی مختلف ترتیبات کو دیکھیں اور انہیں ایپلی کیشن کے استعمال کے منظر نامے کے نمونوں سے بہترین میچ کے لیے ٹیون کریں۔ اگر یہ کافی نہیں ہے تو، آپ ڈیٹا بیس کو عمودی یا افقی طور پر پیمانہ کرنے کا انتخاب کر سکتے ہیں۔
کسی ایپلیکیشن کو اسکیل کرنے میں سرور کی مثال کو اپ ڈیٹ کرنا شامل ہے، عام طور پر مزید پروسیسرز/کورز، زیادہ RAM، تیز اسٹوریج وغیرہ شامل کرنے سے۔ مزید ہارڈویئر وسائل شامل کرنے سے ڈیٹا بیس کی کارکردگی میں اضافہ ہوتا ہے، بنیادی طور پر فی سیکنڈ لین دین میں ماپا جاتا ہے، اور OLTP سسٹمز کے لیے لین دین میں تاخیر ہوتی ہے۔ متعلقہ ڈیٹا بیس سسٹمز (جو ملٹی تھریڈڈ اپروچ استعمال کرتے ہیں) جیسے MySQL اسکیل عمودی طور پر اچھی طرح سے۔
اس نقطہ نظر میں کئی خرابیاں ہیں، لیکن سب سے واضح مارکیٹ میں سرور کا زیادہ سے زیادہ سائز ہے۔ ایک بار سرور کی سب سے بڑی مثال کی حد تک پہنچ جانے کے بعد، صرف ایک راستہ بچا ہے: اسکیل آؤٹ۔
اسکیل آؤٹ ایک ایسا نقطہ نظر ہے جو کلسٹر میں مزید سرورز کا اضافہ کرتا ہے تاکہ زیادہ سرورز کے شامل ہونے کے ساتھ ہی کارکردگی کو مثالی طور پر بڑھایا جا سکے۔ اکثریت روایتی ڈیٹا بیس سسٹم اچھی طرح سے پیمانہ نہیں ہے یا بالکل بھی پیمانہ نہیں ہے۔ مثال کے طور پر، MySQL غلام قارئین کو شامل کرکے پڑھنے کی کارروائیوں کے لیے اسکیل آؤٹ کر سکتا ہے، لیکن تحریری کارروائیوں کے لیے اسکیل آؤٹ نہیں کر سکتا۔
دوسری طرف، اپنی نوعیت کی وجہ سے، کلاؤڈ اسپنر کم سے کم مداخلت کے ساتھ آسانی سے افقی طور پر پیمائش کر سکتا ہے۔
مکمل خصوصیات والا ڈی بی ایم ایس بطور سروس مختلف زاویوں سے جائزہ لینا چاہیے۔ ایک بنیاد کے طور پر، ہم نے کلاؤڈ میں سب سے زیادہ مقبول DBMS لیا - Google، GCP Cloud SQL اور Amazon، AWS RDS کے لیے۔ اپنی تشخیص میں، ہم نے درج ذیل زمروں پر توجہ مرکوز کی:
- فیچر میپنگ: SQL extent, DDL, DML; کنکشن لائبریریاں/ کنیکٹرز، ٹرانزیکشن سپورٹ، وغیرہ۔
- ترقیاتی تعاون: ترقی اور جانچ میں آسانی۔
- ایڈمنسٹریشن سپورٹ: انسٹینس مینجمنٹ جیسے اسکیلنگ اوپر/نیچے اور مثالوں کو اپ گریڈ کرنا۔ SLA، بیک اپ اور ریکوری؛ سیکورٹی / رسائی کنٹرول.
OLAP- فعال OLTP حل کے طور پر کلاؤڈ اسپنر کا استعمال
اگرچہ گوگل واضح طور پر یہ نہیں بتاتا ہے کہ کلاؤڈ اسپنر تجزیات کے لیے ہے، لیکن یہ دیگر انجنوں جیسے کہ اپاچی امپالا اور کڈو اور یوگا بائٹ کے ساتھ کچھ اوصاف کا اشتراک کرتا ہے جو OLAP ورک بوجھ کے لیے ڈیزائن کیے گئے ہیں۔
یہاں تک کہ اگر اس بات کا ایک چھوٹا سا موقع تھا کہ کلاؤڈ اسپنر میں ایک (کم یا زیادہ) قابل استعمال OLAP فیچر سیٹ کے ساتھ ایک مستقل اسکیل آؤٹ HTAP (Hybrid Transactional/Analytic Processing) انجن شامل ہو، ہمارے خیال میں یہ ہماری توجہ کے قابل ہوگا۔
اس کو ذہن میں رکھتے ہوئے، ہم نے درج ذیل زمروں کو دیکھا:
- ڈیٹا لوڈنگ، اشاریہ جات اور پارٹیشننگ سپورٹ
- استفسار کارکردگی اور DML
2. کلاؤڈ اسپنر مختصر طور پر
گوگل اسپنر ایک کلسٹرڈ ریلیشنل ڈیٹا بیس مینجمنٹ سسٹم (RDBMS) ہے جسے گوگل اپنی کئی سروسز کے لیے استعمال کرتا ہے۔ گوگل نے اسے 2017 کے اوائل میں گوگل کلاؤڈ پلیٹ فارم کے صارفین کے لیے عوامی طور پر دستیاب کرایا۔
یہاں کلاؤڈ اسپنر کی کچھ خصوصیات ہیں:
- انتہائی مستقل، توسیع پذیر RDBMS کلسٹر: ڈیٹا کی مستقل مزاجی کو یقینی بنانے کے لیے ہارڈ ویئر ٹائم سنکرونائزیشن کا استعمال کرتا ہے۔
- کراس ٹیبل ٹرانزیکشن سپورٹ: لین دین ایک سے زیادہ ٹیبلز پر محیط ہو سکتا ہے - ضروری نہیں کہ ایک ٹیبل تک محدود ہو (اپاچی ایچ بیس یا اپاچی کوڈو کے برعکس)۔
- بنیادی کلید پر مبنی میزیں: تمام جدولوں میں ایک اعلان کردہ بنیادی کلید (PC) ہونی چاہیے، جو متعدد ٹیبل کالموں پر مشتمل ہو سکتی ہے۔ ٹیبلر ڈیٹا PC ترتیب میں ذخیرہ کیا جاتا ہے، جو اسے PC کی تلاش کے لیے بہت موثر اور تیز بناتا ہے۔ دوسرے پی سی پر مبنی نظاموں کی طرح، عمل درآمد کو پہلے سے تصور شدہ استعمال کے معاملات کے خلاف نمونہ بنایا جانا چاہیے تاکہ حاصل کیا جا سکے۔ .
- دھاری دار میزیں: میزیں ایک دوسرے پر جسمانی انحصار کر سکتی ہیں۔ چائلڈ ٹیبل کی قطاروں کو پیرنٹ ٹیبل کی قطاروں سے ملایا جا سکتا ہے۔ یہ نقطہ نظر ان رشتوں کی تلاش کو تیز کرتا ہے جن کا تعین ڈیٹا ماڈلنگ کے مرحلے پر کیا جا سکتا ہے، مثال کے طور پر، گاہکوں اور ان کی رسیدوں کو ایک ساتھ رکھتے وقت۔
- اشاریہ جات: کلاؤڈ اسپنر ثانوی اشاریہ جات کو سپورٹ کرتا ہے۔ ایک انڈیکس انڈیکس شدہ کالموں اور تمام PC کالموں پر مشتمل ہوتا ہے۔ اختیاری طور پر، انڈیکس میں دوسرے غیر اشاریہ والے کالم بھی شامل ہو سکتے ہیں۔ سوالات کو تیز کرنے کے لیے انڈیکس کو پیرنٹ ٹیبل کے ساتھ ملایا جا سکتا ہے۔ اشاریہ جات پر کئی پابندیاں لاگو ہوتی ہیں، جیسے کہ اضافی کالموں کی زیادہ سے زیادہ تعداد جو انڈیکس میں محفوظ کی جا سکتی ہے۔ اس کے علاوہ، اشاریہ جات کے ذریعے سوالات دوسرے RDBMSs کی طرح سیدھے نہیں ہو سکتے۔
"کلاؤڈ اسپنر صرف غیر معمولی معاملات میں خود بخود ایک انڈیکس منتخب کرتا ہے۔ خاص طور پر، کلاؤڈ اسپنر خود بخود ثانوی انڈیکس کا انتخاب نہیں کرتا ہے اگر استفسار کسی ایسے کالم کی درخواست کرتا ہے جو '.
- سروس لیول ایگریمنٹ (SLA): 99,99% SLA کے ساتھ سنگل ریجن کی تعیناتی۔ 99,999% SLA کے ساتھ کثیر علاقائی تعیناتیاں۔ جب کہ SLA بذات خود ایک معاہدہ ہے اور کسی بھی قسم کی ضمانت نہیں ہے، مجھے یقین ہے کہ گوگل کے لوگوں کے پاس اس طرح کا مضبوط دعویٰ کرنے کے لیے کچھ مشکل ڈیٹا موجود ہے۔ (حوالہ کے لیے، 99,999% کا مطلب ہے 26,3 سیکنڈ سروس ڈاؤن ٹائم ہر ماہ۔)
- مزید:
نوٹ: Apache Tephra پروجیکٹ نے Apache HBase (اب Apache Phoenix میں بھی بیٹا کے طور پر لاگو کیا گیا ہے) میں ایڈوانس ٹرانزیکشن سپورٹ شامل کرتا ہے۔
3. ہماری تشخیص
لہذا، ہم سب نے کلاؤڈ اسپنر کے فوائد کے بارے میں گوگل کے بیانات پڑھے ہیں - اعلی مستقل مزاجی اور بہت اعلی SLA کو برقرار رکھتے ہوئے عملی طور پر لامحدود افقی اسکیلنگ۔ اگرچہ یہ دعوے، کسی بھی صورت میں، حاصل کرنا انتہائی مشکل ہیں، لیکن ہمارا مقصد ان کی تردید کرنا نہیں تھا۔ اس کے بجائے، آئیے دوسری چیزوں پر توجہ مرکوز کریں جن کا زیادہ تر ڈیٹا بیس صارفین خیال رکھتے ہیں: برابری اور استعمال۔
ہم نے کلاؤڈ اسپنر کو Sharded MySQL کے متبادل کے طور پر درجہ دیا۔
گوگل کلاؤڈ ایس کیو ایل اور ایمیزون AWS RDS، کلاؤڈ مارکیٹ میں دو سب سے زیادہ مقبول OLTP ڈیٹا بیس، میں ایک بہت بڑا فیچر سیٹ ہے۔ تاہم، ان ڈیٹا بیسز کو ایک نوڈ کے سائز سے زیادہ پیمانے کے لیے، آپ کو ایپلیکیشن اسپلٹنگ انجام دینے کی ضرورت ہے۔ یہ نقطہ نظر ایپلی کیشنز اور انتظامیہ دونوں کے لیے اضافی پیچیدگی پیدا کرتا ہے۔ ہم نے دیکھا کہ اسپنر ایک مثال میں متعدد شارڈز کو یکجا کرنے کے منظر نامے میں کس طرح فٹ بیٹھتا ہے اور کن خصوصیات (اگر کوئی ہیں) کو قربان کرنا پڑ سکتا ہے۔
SQL، DML اور DDL کے ساتھ ساتھ کنیکٹر اور لائبریریوں کے لیے سپورٹ؟
سب سے پہلے، کسی بھی ڈیٹا بیس کے ساتھ شروع کرتے وقت، آپ کو ڈیٹا ماڈل بنانا ہوگا۔ اگر آپ کو لگتا ہے کہ آپ JDBC Spanner کو اپنے پسندیدہ SQL ٹول سے جوڑ سکتے ہیں، تو آپ دیکھیں گے کہ آپ اس کے ساتھ اپنے ڈیٹا سے استفسار کر سکتے ہیں، لیکن آپ اسے ٹیبل بنانے یا اپ ڈیٹ (DDL) یا کوئی داخل/اپ ڈیٹ/ڈیلیٹ کرنے کے لیے استعمال نہیں کر سکتے۔ آپریشنز (DML)۔ گوگل کا آفیشل جے ڈی بی سی بھی سپورٹ نہیں کرتا ہے۔
"ڈرائیور فی الحال DML یا DDL بیانات کی حمایت نہیں کرتے ہیں۔"
اسپینر دستاویزات
GCP کنسول کے ساتھ صورتحال بہتر نہیں ہے - آپ صرف SELECT سوالات بھیج سکتے ہیں۔ خوش قسمتی سے ایک JDBC ڈرائیور موجود ہے جس میں DML اور DDL کمیونٹی کی طرف سے لین دین بھی شامل ہے۔ . اگرچہ یہ ڈرائیور انتہائی مفید ہے، لیکن گوگل کے اپنے JDBC ڈرائیور کی عدم موجودگی حیران کن ہے۔ خوش قسمتی سے، گوگل کافی وسیع کلائنٹ لائبریری سپورٹ پیش کرتا ہے (gRPC کی بنیاد پر): C#, Go, Java, node.js, PHP, Python, اور Ruby۔
کلاؤڈ اسپنر کے حسب ضرورت APIs کے قریب سے لازمی استعمال (JDBC میں DDL اور DML کی کمی کی وجہ سے) کوڈ کے متعلقہ شعبوں جیسے کنکشن پولنگ یا ڈیٹا بیس بائنڈنگ فریم ورک (جیسے اسپرنگ MVC) کے لیے کچھ حدود کا نتیجہ ہوتا ہے۔ عام طور پر، JDBC استعمال کرتے وقت، آپ اپنے پسندیدہ کنکشن پول (مثلاً HikariCP، DBCP، C3PO، وغیرہ) کو منتخب کرنے کے لیے آزاد ہیں جو ٹیسٹ کیا جاتا ہے اور اچھی طرح سے کام کرتا ہے۔ حسب ضرورت اسپینر APIs کے معاملے میں، ہمیں فریم ورک/بائنڈنگ/سیشن پولز پر انحصار کرنا ہوگا جو ہم نے خود بنائے ہیں۔
بنیادی کلید (PC) پر مبنی ڈیزائن کلاؤڈ اسپنر کو پی سی کے ذریعے ڈیٹا تک رسائی کے وقت بہت تیز رہنے کی اجازت دیتا ہے، لیکن کچھ سوالات کے مسائل بھی متعارف کراتا ہے۔
- آپ بنیادی کلید کی قدر کو اپ ڈیٹ نہیں کر سکتے ہیں۔ آپ کو پہلے اصل پی سی اندراج کو حذف کرنا ہوگا اور اسے نئی قدر کے ساتھ دوبارہ داخل کرنا ہوگا۔ (یہ دوسرے پی سی پر مبنی ڈیٹا بیس/اسٹوریج انجنوں کی طرح ہے۔)
- کسی بھی UPDATE اور DELETE کے بیانات میں PC کی وضاحت WHERE میں ہونی چاہیے، اس لیے تمام سٹیٹمنٹس کو حذف کرنا خالی نہیں ہو سکتا - ہمیشہ ایک ذیلی استفسار ہونا چاہیے، مثال کے طور پر: UPDATE xxx WHERE id IN ( SELECT id FROM table1)
- آٹو انکریمنٹ آپشن کی کمی یا اس سے ملتی جلتی کوئی چیز جو PC فیلڈ کے لیے ترتیب کو متعین کرتی ہے۔ اس کے کام کرنے کے لیے، متعلقہ قدر کو درخواست کی طرف سے بنایا جانا چاہیے۔
سیکنڈری انڈیکس؟
گوگل کلاؤڈ اسپنر کے پاس ثانوی اشاریہ جات کے لیے بلٹ ان سپورٹ ہے۔ یہ ایک بہت اچھی خصوصیت ہے جو ہمیشہ دوسری ٹیکنالوجیز میں موجود نہیں ہوتی ہے۔ Apache Kudu فی الحال ثانوی اشاریہ جات کو بالکل بھی سپورٹ نہیں کرتا ہے، اور Apache HBase براہ راست اشاریہ جات کو سپورٹ نہیں کرتا ہے، لیکن انہیں Apache Phoenix کے ذریعے شامل کر سکتا ہے۔
Kudu اور HBase میں اشاریہ جات کو پرائمری کیز کی مختلف ساخت کے ساتھ ایک علیحدہ جدول کے طور پر ماڈل بنایا جا سکتا ہے، لیکن پیرنٹ ٹیبل اور متعلقہ انڈیکس ٹیبلز پر کیے جانے والے آپریشنز کی ایٹمیسیٹی کو ایپلیکیشن کی سطح پر انجام دیا جانا چاہیے اور درست طریقے سے نافذ کرنے کے لیے کوئی معمولی بات نہیں ہے۔
جیسا کہ کلاؤڈ اسپنر جائزہ میں ذکر کیا گیا ہے، اس کے اشاریہ جات MySQL اشاریہ جات سے مختلف ہو سکتے ہیں۔ لہٰذا، استفسارات کی تعمیر اور پروفائلنگ میں خاص خیال رکھا جانا چاہیے تاکہ یہ یقینی بنایا جا سکے کہ جہاں ضرورت ہو درست اشاریہ استعمال کیا جائے۔
نمائندگی؟
ڈیٹا بیس میں ایک بہت مقبول اور کارآمد چیز ویوز ہے۔ وہ بڑی تعداد میں استعمال کے معاملات کے لیے مفید ہو سکتے ہیں۔ میرے دو پسندیدہ ہیں منطقی تجریدی تہہ اور سلامتی کی تہہ۔ بدقسمتی سے کلاؤڈ اسپنر آراء کی حمایت نہیں کرتا ہے۔ تاہم، یہ ہمیں صرف جزوی طور پر محدود کرتا ہے، کیوں کہ رسائی کی اجازتوں کے لیے کالم کی سطح کی کوئی تفصیل نہیں ہے جہاں آراء قابل قبول حل ہو سکتے ہیں۔
کوٹہ اور حدود کی تفصیل والے حصے کے لیے کلاؤڈ اسپنر دستاویزات دیکھیں ()، خاص طور پر ایک ایسی چیز ہے جو کچھ ایپلیکیشنز کے لیے پریشانی کا باعث ہو سکتی ہے: Cloud Spanner آؤٹ آف دی باکس میں فی مثال زیادہ سے زیادہ 100 ڈیٹا بیس ہوتے ہیں۔ ظاہر ہے، یہ ایک ایسے ڈیٹا بیس کے لیے ایک بڑی رکاوٹ ہو سکتی ہے جسے 100 سے زیادہ ڈیٹا بیس تک پیمانے کے لیے ڈیزائن کیا گیا ہے۔ خوش قسمتی سے، ہمارے Google تکنیکی نمائندے سے بات کرنے کے بعد، ہمیں پتہ چلا کہ اس حد کو گوگل سپورٹ کے ذریعے تقریباً کسی بھی قدر تک بڑھایا جا سکتا ہے۔
ترقی کی حمایت؟
کلاؤڈ اسپنر اپنے API کے ساتھ کام کرنے کے لیے کافی مہذب پروگرامنگ لینگویج سپورٹ پیش کرتا ہے۔ سرکاری طور پر تعاون یافتہ لائبریریاں C#, Go, Java, node.js, PHP, Python اور Ruby کے علاقے میں ہیں۔ دستاویزات کافی تفصیلی ہیں، لیکن دیگر جدید ٹیکنالوجیز کی طرح، کمیونٹی زیادہ تر مشہور ڈیٹا بیس ٹیکنالوجیز کے مقابلے میں کافی چھوٹی ہے، جس کے نتیجے میں کم عام استعمال کے معاملات یا مسائل پر زیادہ وقت صرف کیا جا سکتا ہے۔
تو مقامی ترقیاتی امداد کے بارے میں کیا خیال ہے؟
ہمیں آن پریمیسس میں کلاؤڈ اسپنر مثال بنانے کا کوئی طریقہ نہیں ملا ہے۔ ہمارے پاس سب سے قریب ایک ڈوکر امیج ہے۔ جو اصولی طور پر ایک جیسا ہے، لیکن عملی طور پر بہت مختلف ہے۔ مثال کے طور پر کاکروچ ڈی بی PostgreSQL JDBC استعمال کر سکتا ہے۔ چونکہ ترقی کا ماحول پیداواری ماحول کے جتنا ممکن ہو قریب ہونا چاہیے، اس لیے کلاؤڈ اسپنر مثالی نہیں ہے کیونکہ آپ کو مکمل اسپنر مثال پر انحصار کرنے کی ضرورت ہے۔ لاگت بچانے کے لیے، آپ کسی ایک علاقے کی مثال منتخب کر سکتے ہیں۔
انتظامیہ کا تعاون؟
کلاؤڈ اسپنر مثال بنانا بہت آسان ہے۔ آپ کو صرف ایک ملٹی ریجن یا سنگل ریجن مثال بنانے کے درمیان انتخاب کرنے کی ضرورت ہے، علاقہ (زبانیں) اور نوڈس کی تعداد کی وضاحت کریں۔ ایک منٹ سے بھی کم وقت میں، مثال تیار ہو جائے گی۔
متعدد ابتدائی میٹرکس گوگل کنسول میں اسپینر صفحہ پر براہ راست دستیاب ہیں۔ مزید تفصیلی آراء Stackdriver کے ذریعے دستیاب ہیں، جہاں آپ میٹرک تھریشولڈز اور الرٹ پالیسیاں بھی سیٹ کر سکتے ہیں۔
وسائل تک رسائی؟
MySQL وسیع اور انتہائی دانے دار صارف کی اجازت/ کردار کی ترتیبات پیش کرتا ہے۔ آپ آسانی سے کسی مخصوص ٹیبل تک رسائی کو اپنی مرضی کے مطابق بنا سکتے ہیں، یا یہاں تک کہ اس کے کالموں کا صرف ایک ذیلی سیٹ۔ Cloud Spanner Google Identity & Access Management (IAM) ٹول کا استعمال کرتا ہے، جو صرف آپ کو انتہائی اعلیٰ سطح پر پالیسیاں اور اجازتیں ترتیب دینے کی اجازت دیتا ہے۔ سب سے زیادہ دانے دار آپشن ڈیٹا بیس کی سطح کی اجازت ہے، جو زیادہ تر پروڈکشن کیسز میں فٹ نہیں ہوتی ہے۔ یہ پابندی آپ کو اسپینر وسائل کے غیر مجاز استعمال کو روکنے کے لیے اپنے کوڈ، انفراسٹرکچر، یا دونوں میں اضافی حفاظتی اقدامات شامل کرنے پر مجبور کرتی ہے۔
بیک اپ؟
سیدھے الفاظ میں، کلاؤڈ اسپنر میں کوئی بیک اپ نہیں ہے۔ جبکہ گوگل کی اعلیٰ SLA تقاضے اس بات کو یقینی بنا سکتے ہیں کہ آپ ہارڈ ویئر یا ڈیٹا بیس کی ناکامیوں، انسانی غلطیوں، ایپلیکیشن کی خرابیوں وغیرہ کی وجہ سے کوئی ڈیٹا ضائع نہ کریں۔ فی الحال، ڈیٹا کو بیک اپ کرنے کا واحد طریقہ یہ ہے کہ پروگرام کے مطابق اسے ڈیٹا بیس سے علیحدہ اسٹوریج ماحول میں منتقل کیا جائے۔
استفسار کارکردگی؟
ہم نے ڈیٹا لوڈ کرنے اور درخواستوں کی جانچ کرنے کے لیے Yahoo! کلاؤڈ سرونگ بینچ مارک۔ نیچے دی گئی جدول B YCSB ورک بوجھ کو 95% پڑھنے سے 5% لکھنے کے تناسب کے ساتھ دکھاتی ہے۔
* لوڈ ٹیسٹ n1-standard-32 Compute Engine (CE) (32 vCPUs، 120 GB میموری) پر چلایا گیا تھا اور ٹیسٹ کی مثال کبھی بھی ٹیسٹ میں رکاوٹ نہیں تھی۔
** ایک YCSB انسٹینس میں تھریڈز کی زیادہ سے زیادہ تعداد 400 ہے۔ کل 2400 تھریڈز حاصل کرنے کے لیے YCSB ٹیسٹ کے چھ متوازی مثالوں کو چلانا پڑتا ہے۔
بینچ مارک کے نتائج کو دیکھتے ہوئے، خاص طور پر CPU لوڈ اور TPS کے امتزاج کو، ہم واضح طور پر دیکھ سکتے ہیں کہ کلاؤڈ اسپنر کا پیمانہ کافی اچھا ہے۔ دھاگوں کی ایک بڑی تعداد کے ذریعہ پیدا ہونے والے بڑے بوجھ کو کلاؤڈ اسپنر کلسٹر میں نوڈس کی ایک بڑی تعداد کے ذریعہ آفسیٹ کیا جاتا ہے۔ اگرچہ لیٹنسی کافی زیادہ نظر آتی ہے، خاص طور پر جب 2400 تھریڈز پر چل رہا ہو، زیادہ درست نمبر حاصل کرنے کے لیے کمپیوٹ انجن کی 6 چھوٹی مثالوں کے ساتھ دوبارہ ٹیسٹ کرنا ضروری ہو سکتا ہے۔ ہر ایک مثال 6 متوازی ٹیسٹ کے ساتھ ایک بڑی سی ای مثال کے بجائے ایک YCSB ٹیسٹ چلائے گی۔ اس سے کلاؤڈ اسپنر کی درخواست میں تاخیر اور Cloud Spanner اور CE مثال کے ٹیسٹ کے درمیان نیٹ ورک کنکشن کے ذریعے شامل ہونے والی تاخیر کے درمیان فرق کرنا آسان ہو جاتا ہے۔
کلاؤڈ اسپنر OLAP کے طور پر کیسے کام کرتا ہے؟
تقسیم؟
ڈیٹا کو جسمانی طور پر اور/یا منطقی طور پر آزاد حصوں میں تقسیم کرنا، جسے پارٹیشنز کہتے ہیں، ایک بہت مقبول تصور ہے جو زیادہ تر OLAP انجنوں میں پایا جاتا ہے۔ پارٹیشنز استفسار کی کارکردگی اور ڈیٹا بیس کی برقراری کو بہت بہتر بنا سکتے ہیں۔ تقسیم کے بارے میں مزید معلومات حاصل کرنا ایک الگ مضمون (مضمون) ہوگا، تو آئیے صرف تقسیم کاری کی اسکیم اور ذیلی تقسیم کی اہمیت کا ذکر کرتے ہیں۔ ڈیٹا کو پارٹیشنز اور اس سے بھی آگے ذیلی پارٹیشنز میں تقسیم کرنے کی صلاحیت تجزیاتی سوالات کی کارکردگی کی کلید ہے۔
کلاؤڈ اسپنر پارٹیشنز کو فی سی سپورٹ نہیں کرتا ہے۔ یہ ڈیٹا کو اندرونی طور پر نام نہاد میں الگ کرتا ہے۔ تقسیم-s بنیادی کلیدی حدود پر مبنی ہے۔ کلاؤڈ اسپنر کلسٹر پر بوجھ کو متوازن کرنے کے لیے تقسیم خود بخود ہو جاتی ہے۔ کلاؤڈ اسپنر کی ایک بہت ہی آسان خصوصیت پیرنٹ ٹیبل کے بنیادی بوجھ کو تقسیم کر رہی ہے (ایک ٹیبل جو کسی دوسرے کے ساتھ جڑی ہوئی نہیں ہے)۔ اسپینر خود بخود پتہ لگاتا ہے کہ آیا اس میں موجود ہے۔ تقسیم دوسرے ڈیٹا کے مقابلے میں زیادہ کثرت سے پڑھا جانے والا ڈیٹا تقسیم-آہ، اور مزید علیحدگی کا فیصلہ کر سکتا ہے۔ اس طرح، ایک درخواست میں مزید نوڈس شامل ہوسکتے ہیں، جو مؤثر طریقے سے تھرو پٹ کو بھی بڑھاتا ہے۔
ڈیٹا لوڈ ہو رہا ہے؟
بلک ڈیٹا کے لیے کلاؤڈ اسپنر کا طریقہ وہی ہے جو کہ ایک باقاعدہ اپ لوڈ کے لیے ہے۔ زیادہ سے زیادہ کارکردگی کے لیے، آپ کو کچھ ہدایات پر عمل کرنے کی ضرورت ہے، بشمول:
- اپنے ڈیٹا کو بنیادی کلید کے مطابق ترتیب دیں۔
- انہیں 10* سے تقسیم کریںنوڈس کی تعداد انفرادی حصے.
- کارکن کے کاموں کا ایک سیٹ بنائیں جو ڈیٹا کو متوازی طور پر لوڈ کرتے ہیں۔
یہ ڈیٹا لوڈ تمام کلاؤڈ اسپنر نوڈس کا استعمال کرتا ہے۔
ہم نے 10M قطار ڈیٹاسیٹ بنانے کے لیے A YCSB ورک لوڈ کا استعمال کیا۔
* لوڈ ٹیسٹ n1-standard-32 کمپیوٹ انجن (32 vCPUs، 120 GB میموری) پر چلایا گیا تھا اور ٹیسٹ کی مثال کبھی بھی ٹیسٹوں میں رکاوٹ نہیں تھی۔
** کسی بھی پیداواری کام کے بوجھ کے لیے 1 نوڈ سیٹ اپ کی سفارش نہیں کی جاتی ہے۔
جیسا کہ اوپر ذکر کیا گیا ہے، کلاؤڈ اسپنر خود بخود ان کے بوجھ کے لحاظ سے اسپلٹ پر کارروائی کرتا ہے، لہذا ٹیسٹ کے مسلسل کئی تکرار کے بعد نتائج میں بہتری آتی ہے۔ یہاں پیش کردہ نتائج ہمارے حاصل کردہ بہترین نتائج ہیں۔ اوپر دیے گئے نمبروں کو دیکھتے ہوئے، ہم دیکھ سکتے ہیں کہ کلاؤڈ اسپنر کلسٹر میں نوڈس کی تعداد بڑھنے کے ساتھ کیسے (اچھی طرح سے) ترازو کرتا ہے۔ جو نمبر نمایاں ہیں وہ انتہائی کم اوسط تاخیر کے ہیں، جو اوپر والے حصے میں بیان کیے گئے مخلوط کام کے بوجھ (95% پڑھنے اور 5% لکھنے) کے نتائج سے متصادم ہیں۔
پیمانہ کاری؟
کلاؤڈ اسپنر نوڈس کی تعداد کو بڑھانا اور کم کرنا ایک کلک کا کام ہے۔ اگر آپ ڈیٹا کو تیزی سے لوڈ کرنا چاہتے ہیں، تو آپ مثال کو زیادہ سے زیادہ بڑھانے پر غور کر سکتے ہیں (ہمارے معاملے میں یہ US-EAST ریجن میں 25 نوڈس تھے) اور پھر تمام ڈیٹا کے بعد آپ کے نارمل لوڈ کے لیے موزوں نوڈس کی تعداد کو کم کر سکتے ہیں۔ ڈیٹا بیس میں، 2 ٹی بی/نوڈ کی حد کو ذہن میں رکھتے ہوئے۔
ہمیں بہت چھوٹے ڈیٹا بیس کے ساتھ بھی اس حد کی یاد دلائی گئی۔ کئی لوڈ ٹیسٹ چلانے کے بعد، ہمارے ڈیٹا بیس کا سائز تقریباً 155 جی بی تھا، اور جب اسے 1 نوڈ مثال کے طور پر چھوٹا کیا گیا، تو ہمیں درج ذیل خرابی ملی:
ہم 25 سے 2 مثالوں تک پیمانہ کرنے کے قابل تھے، لیکن ہم دو نوڈس پر پھنس گئے ہیں۔
کلاؤڈ اسپنر کلسٹر میں نوڈس کی تعداد کو بڑھانا اور کم کرنا REST API کا استعمال کرتے ہوئے خودکار کیا جا سکتا ہے۔ یہ خاص طور پر مصروف اوقات کے دوران سسٹم پر بڑھتے ہوئے بوجھ کو کم کرنے کے لیے مفید ہو سکتا ہے۔
OLAP استفسار کی کارکردگی؟
ہم نے اصل میں اس حصے پر اسپنر کی اپنی تشخیص کے لیے کافی وقت دینے کا منصوبہ بنایا تھا۔ چند SELECT COUNTs کے بعد، ہم نے فوراً محسوس کیا کہ ٹیسٹ مختصر ہوگا اور اسپینر OLAP کے لیے موزوں انجن نہیں ہوگا۔ کلسٹر میں نوڈس کی تعداد سے قطع نظر، 10M قطار کے ٹیبل میں قطاروں کی تعداد کا انتخاب کرنے میں 55 سے 60 سیکنڈ لگے۔ نیز، کوئی بھی استفسار جس میں انٹرمیڈیٹ کے نتائج کو ذخیرہ کرنے کے لیے زیادہ میموری کی ضرورت ہوتی ہے OOM کی خرابی کے ساتھ ناکام ہوگئی۔
SELECT COUNT(DISTINCT(field0)) FROM usertable; — (10M distinct values)-> SpoolingHashAggregateIterator ran out of memory during new row.
TPC-H سوالات کے لیے کچھ نمبرز Todd Lipcon کے مضمون میں مل سکتے ہیں۔ ، سلائیڈز 42 اور 43۔ یہ نمبر ہمارے اپنے نتائج سے مطابقت رکھتے ہیں (بدقسمتی سے)۔
4. ہمارے نتائج
کلاؤڈ اسپنر کی خصوصیات کی موجودہ حالت کو دیکھتے ہوئے، اسے موجودہ OLTP حل کے ایک سادہ متبادل کے طور پر دیکھنا مشکل ہے، خاص طور پر جب آپ کی ضروریات اس سے بڑھ جائیں۔ کلاؤڈ اسپنر کی کوتاہیوں کے گرد ایک حل بنانے میں کافی وقت صرف کرنا پڑے گا۔
جب ہم نے کلاؤڈ اسپنر کا جائزہ لینا شروع کیا، تو ہم نے توقع کی کہ اس کی انتظامی خصوصیات گوگل کے دوسرے ایس کیو ایل حلوں کے برابر ہوں گی، یا کم از کم اس سے دور نہیں۔ لیکن ہم بیک اپ کی مکمل کمی اور وسائل تک بہت محدود رسائی کے کنٹرول سے حیران تھے۔ کوئی آراء، مقامی ترقیاتی ماحول، غیر تعاون یافتہ ترتیب، DML اور DDL کی حمایت کے بغیر JDBC، وغیرہ کا ذکر نہ کرنا۔
تو، کسی ایسے شخص کے لیے کہاں جانا ہے جس کو لین دین کے ڈیٹا بیس کی پیمائش کرنے کی ضرورت ہے؟ ایسا لگتا ہے کہ مارکیٹ میں ابھی تک ایک بھی حل نہیں ہے جو استعمال کے تمام معاملات میں فٹ بیٹھتا ہے۔ بہت سے بند اور اوپن سورس حل ہیں (جن میں سے کچھ کا ذکر اس مضمون میں کیا گیا ہے)، ہر ایک اپنی اپنی طاقت اور کمزوریوں کے ساتھ، لیکن ان میں سے کوئی بھی SaaS کو 99,999% SLA اور اعلی درجے کی مستقل مزاجی کے ساتھ پیش نہیں کرتا ہے۔ اگر ایک اعلی SLA آپ کا بنیادی مقصد ہے اور آپ متعدد کلاؤڈز کے لیے اپنا حل خود بنانے کے لیے مائل نہیں ہیں، تو Cloud Spanner وہ حل ہو سکتا ہے جس کی آپ تلاش کر رہے ہیں۔ لیکن آپ کو اس کی تمام حدود سے آگاہ ہونا چاہئے۔
منصفانہ طور پر، Cloud Spanner کو صرف 2017 کے موسم بہار میں عوام کے لیے جاری کیا گیا تھا، اس لیے یہ توقع کرنا مناسب ہے کہ اس کی کچھ موجودہ خامیاں بالآخر دور ہو جائیں گی (امید ہے)، اور جب ایسا ہوتا ہے تو یہ گیم چینجر ہو سکتا ہے۔ سب کے بعد، Cloud Spanner گوگل کے لیے صرف ایک ضمنی پروجیکٹ نہیں ہے۔ گوگل اسے دیگر گوگل پروڈکٹس کی بنیاد کے طور پر استعمال کرتا ہے۔ اور جب گوگل نے حال ہی میں گوگل کلاؤڈ سٹوریج میں میگاسٹور کو کلاؤڈ اسپنر سے تبدیل کیا، تو اس نے گوگل کلاؤڈ سٹوریج کو عالمی سطح پر آبجیکٹ لسٹوں کے لیے انتہائی مستقل مزاج ہونے کی اجازت دی (جو کہ اب بھی ایسا نہیں ہے۔ ).
لہذا، اب بھی امید ہے ... ہم امید کرتے ہیں.
بس۔ مضمون کے مصنف کی طرح ہم بھی امیدیں لگاتے رہتے ہیں لیکن اس بارے میں آپ کا کیا خیال ہے؟ کمنٹس میں لکھیں۔
ہم سب کو دعوت دیتے ہیں کہ ہمارا دورہ کریں۔ جس میں ہم آپ کو کورس کے بارے میں تفصیل سے بتائیں گے۔ OTUS سے
ماخذ: www.habr.com