وہ کہتے ہیں کہ زندگی میں ہر چیز کم از کم ایک بار آزمانے کے قابل ہے۔ اور اگر آپ رشتہ دار DBMSs کے ساتھ کام کرنے کے عادی ہیں، تو یہ عملی طور پر NoSQL سے واقف ہونے کے قابل ہے، سب سے پہلے، کم از کم عام ترقی کے لیے۔ اب، اس ٹیکنالوجی کی تیز رفتار ترقی کی وجہ سے، اس موضوع پر بہت سی متضاد آراء اور گرما گرم بحثیں ہیں، جو خاص طور پر دلچسپی کو ہوا دیتی ہیں۔
اگر آپ ان تمام تنازعات کے نچوڑ پر غور کریں تو آپ دیکھ سکتے ہیں کہ یہ غلط نقطہ نظر کی وجہ سے پیدا ہوئے ہیں۔ وہ لوگ جو NoSQL ڈیٹا بیس کو بالکل وہی جگہ استعمال کرتے ہیں جہاں ان کی ضرورت ہوتی ہے وہ مطمئن ہیں اور اس حل سے تمام فوائد حاصل کرتے ہیں۔ اور تجربہ کار جو اس ٹکنالوجی پر ایک علاج کے طور پر بھروسہ کرتے ہیں جہاں یہ بالکل بھی لاگو نہیں ہوتا ہے، وہ مایوس ہوتے ہیں، جنہوں نے اہم فوائد حاصل کیے بغیر متعلقہ ڈیٹا بیس کی طاقت کھو دی ہے۔
میں آپ کو کیسنڈرا ڈی بی ایم ایس پر مبنی حل کو نافذ کرنے کے اپنے تجربے کے بارے میں بتاؤں گا: ہمیں کس چیز کا سامنا کرنا پڑا، ہم مشکل حالات سے کیسے نکلے، کیا ہم NoSQL کے استعمال سے فائدہ اٹھانے کے قابل تھے اور ہمیں اضافی کوششیں/فنڈز کہاں لگانے پڑیں؟ .
ابتدائی کام ایک ایسا نظام بنانا ہے جو کسی قسم کی سٹوریج میں کالوں کو ریکارڈ کرے۔
نظام کے آپریٹنگ اصول مندرجہ ذیل ہے۔ ان پٹ میں ایک مخصوص ڈھانچہ والی فائلیں شامل ہوتی ہیں جو کال کی ساخت کو بیان کرتی ہیں۔ ایپلیکیشن پھر یقینی بناتی ہے کہ یہ ڈھانچہ مناسب کالموں میں محفوظ ہے۔ مستقبل میں، محفوظ کردہ کالز کا استعمال سبسکرائبرز (چارجز، کالز، بیلنس ہسٹری) کے لیے ٹریفک کی کھپت پر معلومات ظاہر کرنے کے لیے کیا جاتا ہے۔
یہ بالکل واضح ہے کہ انہوں نے کیسینڈرا کا انتخاب کیوں کیا - وہ مشین گن کی طرح لکھتی ہے، آسانی سے توسیع پذیر اور غلطی برداشت کرنے والی ہے۔
تو، یہ وہی ہے جو تجربہ نے ہمیں دیا
ہاں، ناکام نوڈ کوئی المیہ نہیں ہے۔ یہ کیسنڈرا کی غلطی برداشت کا نچوڑ ہے۔ لیکن ایک نوڈ زندہ ہوسکتا ہے اور ایک ہی وقت میں کارکردگی میں مبتلا ہونا شروع کر سکتا ہے۔. جیسا کہ یہ نکلا، یہ فوری طور پر پورے کلسٹر کی کارکردگی کو متاثر کرتا ہے۔
کیسینڈرا آپ کی حفاظت نہیں کرے گا جہاں اوریکل نے آپ کو اپنی رکاوٹوں سے بچایا تھا۔. اور اگر درخواست کے مصنف نے یہ بات پہلے سے نہیں سمجھی تھی، تو پھر کیسینڈرا کے لیے آنے والا دوہرا اصل سے بدتر نہیں ہے۔ ایک بار جب یہ پہنچ جائے گا، ہم اسے داخل کر دیں گے۔
آئی بی نے باکس سے باہر مفت کیسینڈرا کو سخت ناپسند کیا: صارف کے اعمال کی کوئی لاگنگ نہیں ہے، حقوق کی کوئی تفریق نہیں ہے۔. کالز کے بارے میں معلومات کو ذاتی ڈیٹا سمجھا جاتا ہے، جس کا مطلب ہے کہ کسی بھی طرح سے درخواست کرنے/تبدیل کرنے کی تمام کوششوں کو بعد میں آڈیٹنگ کے امکان کے ساتھ لاگ ان ہونا چاہیے۔ اس کے علاوہ، آپ کو مختلف صارفین کے لیے مختلف سطحوں پر حقوق کو الگ کرنے کی ضرورت سے آگاہ ہونے کی ضرورت ہے۔ ایک سادہ آپریشن انجینئر اور ایک سپر ایڈمن جو پوری کلیدی جگہ کو آزادانہ طور پر حذف کر سکتا ہے مختلف کردار، مختلف ذمہ داریاں اور قابلیت ہیں۔ رسائی کے حقوق کی اس طرح کی تفریق کے بغیر، ڈیٹا کی قدر اور سالمیت کسی بھی مستقل مزاجی کی سطح کے مقابلے میں تیزی سے سوال میں آجائے گی۔
ہم نے اس بات کو مدنظر نہیں رکھا کہ کالز کے لیے مختلف حالات کے لیے سنجیدہ تجزیات اور متواتر نمونے لینے کی ضرورت ہوتی ہے۔ چونکہ منتخب کردہ ریکارڈز کو پھر حذف کر کے دوبارہ لکھا جانا چاہیے (کام کے حصے کے طور پر، ہمیں ڈیٹا کو اپ ڈیٹ کرنے کے عمل کی حمایت کرنی چاہیے جب ڈیٹا ابتدائی طور پر ہمارے لوپ میں غلط طریقے سے داخل ہوا تھا)، کیسینڈرا یہاں ہماری دوست نہیں ہے۔ کیسینڈرا ایک گللک کی طرح ہے - چیزیں ڈالنا آسان ہے، لیکن آپ اس میں شمار نہیں کر سکتے۔
ہمیں ٹیسٹ زونز میں ڈیٹا منتقل کرنے میں دشواری کا سامنا کرنا پڑا (ٹیسٹ میں 5 نوڈس بمقابلہ پروم میں 20)۔ اس صورت میں، ڈمپ استعمال نہیں کیا جا سکتا.
کیسینڈرا کو لکھنے والی درخواست کے ڈیٹا اسکیما کو اپ ڈیٹ کرنے میں مسئلہ۔ ایک رول بیک بہت سے قبروں کے پتھر پیدا کرے گا، جو غیر متوقع طریقوں سے پیداواری نقصان کا باعث بن سکتا ہے۔. کیسینڈرا ریکارڈنگ کے لیے موزوں ہے، اور لکھنے سے پہلے زیادہ نہیں سوچتی۔ اس میں موجود ڈیٹا کے ساتھ کوئی بھی آپریشن بھی ایک ریکارڈنگ ہے۔ یعنی، غیر ضروری کو حذف کرنے سے، ہم صرف اور بھی زیادہ ریکارڈ تیار کریں گے، اور ان میں سے صرف کچھ پر قبروں کے پتھروں کے نشانات ہوں گے۔
داخل کرتے وقت ٹائم آؤٹ۔ Cassandra ریکارڈنگ میں خوبصورت ہے، لیکن کبھی کبھی آنے والا بہاؤ اسے نمایاں طور پر الجھا سکتا ہے۔. ایسا اس وقت ہوتا ہے جب ایپلیکیشن کئی ریکارڈز کے گرد چکر لگانا شروع کر دیتی ہے جو کسی وجہ سے داخل نہیں کیے جا سکتے۔ اور ہمیں ایک حقیقی DBA کی ضرورت ہوگی جو سست سوالات کے لیے gc.log، سسٹم اور ڈیبگ لاگز کی نگرانی کرے گا، کمپیکشن زیر التواء پر میٹرکس۔
ایک کلسٹر میں کئی ڈیٹا سینٹرز۔ کہاں سے پڑھیں اور کہاں سے لکھیں؟
شاید پڑھنے اور لکھنے میں تقسیم؟ اور اگر ایسا ہے تو کیا لکھنے یا پڑھنے کے لیے درخواست کے قریب ڈی سی ہونا چاہیے؟ اور اگر ہم غلط مستقل مزاجی کی سطح کا انتخاب کرتے ہیں تو کیا ہم حقیقی تقسیم دماغ کے ساتھ ختم نہیں ہوں گے؟ بہت سارے سوالات ہیں، بہت ساری نامعلوم ترتیبات، امکانات جن کے ساتھ آپ واقعی ٹنکر کرنا چاہتے ہیں۔
ہم نے کیسے فیصلہ کیا۔
نوڈ کو ڈوبنے سے روکنے کے لیے، SWAP کو غیر فعال کر دیا گیا تھا۔. اور اب، اگر میموری کی کمی ہے تو، نوڈ کو نیچے جانا چاہیے اور بڑے جی سی توقف نہیں بنانا چاہیے۔
لہذا، ہم اب ڈیٹا بیس میں منطق پر انحصار نہیں کرتے ہیں۔ ایپلیکیشن ڈویلپرز خود کو دوبارہ تربیت دے رہے ہیں اور اپنے کوڈ میں احتیاطی تدابیر کو فعال طور پر لینا شروع کر رہے ہیں۔ ڈیٹا اسٹوریج اور پروسیسنگ کی مثالی واضح علیحدگی۔
ہم نے DataStax سے سپورٹ خریدی۔ باکسڈ کیسنڈرا کی ترقی پہلے ہی بند ہو چکی ہے (آخری کمٹ فروری 2018 میں ہوئی تھی)۔ ایک ہی وقت میں، Datastax بہترین سروس اور موجودہ آئی پی کے حل کے لیے بڑی تعداد میں ترمیم شدہ اور موافقت پذیر حل پیش کرتا ہے۔
میں یہ بھی نوٹ کرنا چاہتا ہوں کہ Cassandra انتخاب کے سوالات کے لیے زیادہ آسان نہیں ہے۔ بلاشبہ، CQL صارفین کے لیے ایک بڑا قدم ہے (Trift کے مقابلے میں)۔ لیکن اگر آپ کے پاس پورے محکمے ہیں جو اس طرح کے آسان شمولیت کے عادی ہیں، کسی بھی فیلڈ کے ذریعے مفت فلٹرنگ اور استفسار کی اصلاح کی صلاحیتیں ہیں، اور یہ محکمے شکایات اور حادثات کو حل کرنے کے لیے کام کر رہے ہیں، تو کیسینڈرا کا حل ان کے لیے مخالفانہ اور احمقانہ لگتا ہے۔ اور ہم نے فیصلہ کرنا شروع کیا کہ ہمارے ساتھیوں کو کیسے نمونے بنانے چاہئیں۔
ہم نے دو آپشنز پر غور کیا۔ پہلے آپشن میں، ہم کالیں نہ صرف C* میں لکھتے ہیں بلکہ آرکائیو شدہ اوریکل ڈیٹا بیس میں بھی۔ صرف، C* کے برعکس، یہ ڈیٹا بیس صرف موجودہ مہینے کے لیے کالز کو اسٹور کرتا ہے (کیسز کو ری چارج کرنے کے لیے کافی کال اسٹوریج ڈیپتھ)۔ یہاں ہم نے فوری طور پر مندرجہ ذیل مسئلہ کو دیکھا: اگر ہم ہم آہنگی سے لکھتے ہیں، تو ہم تیزی سے اندراج سے منسلک C* کے تمام فوائد کھو دیتے ہیں؛ اگر ہم متضاد طور پر لکھتے ہیں، تو اس بات کی کوئی گارنٹی نہیں ہے کہ تمام ضروری کالیں اوریکل میں بالکل بھی آ گئی ہیں۔ ایک پلس تھا، لیکن ایک بڑا: آپریشن کے لیے وہی مانوس PL/SQL ڈویلپر باقی ہے، یعنی ہم عملی طور پر "Facade" پیٹرن کو نافذ کرتے ہیں۔ ایک متبادل آپشن۔ ہم ایک ایسا طریقہ کار نافذ کرتے ہیں جو C* سے کالز کو اتارتا ہے، اوریکل میں متعلقہ ٹیبلز سے افزودگی کے لیے کچھ ڈیٹا کھینچتا ہے، نتیجے میں آنے والے نمونوں میں شامل ہوتا ہے اور ہمیں نتیجہ فراہم کرتا ہے، جسے ہم پھر کسی نہ کسی طرح استعمال کرتے ہیں (رول بیک، دوبارہ، تجزیہ، تعریف)۔ Cons: عمل کافی کثیر مرحلہ ہے، اور اس کے علاوہ، آپریشن ملازمین کے لیے کوئی انٹرفیس نہیں ہے۔
آخر میں، ہم نے دوسرے آپشن پر طے کیا۔ اپاچی اسپارک کا استعمال مختلف جار سے نمونہ لینے کے لیے کیا گیا تھا۔ میکانزم کے جوہر کو جاوا کوڈ تک کم کر دیا گیا ہے، جو مخصوص کیز (سبسکرائبر، کال کا وقت - سیکشن کیز) کا استعمال کرتے ہوئے C* سے ڈیٹا نکالتا ہے، ساتھ ہی ساتھ کسی دوسرے ڈیٹا بیس سے افزودگی کے لیے ضروری ڈیٹا بھی نکالتا ہے۔ جس کے بعد یہ ان کو اپنی یادداشت میں جوڑتا ہے اور نتیجہ سامنے آنے والے ٹیبل میں دکھاتا ہے۔ ہم نے چنگاری پر ایک ویب چہرہ کھینچا اور یہ کافی قابل استعمال نکلا۔
صنعتی ٹیسٹ کے اعداد و شمار کو اپ ڈیٹ کرنے کے مسئلے کو حل کرتے وقت، ہم نے دوبارہ کئی حلوں پر غور کیا۔ Sstloader کے ذریعے منتقلی اور ٹیسٹ زون میں کلسٹر کو دو حصوں میں تقسیم کرنے کا اختیار، جن میں سے ہر ایک باری باری پروموشنل کے ساتھ ایک ہی کلسٹر سے تعلق رکھتا ہے، اس طرح اس کے ذریعے چلایا جاتا ہے۔ ٹیسٹ کو اپ ڈیٹ کرتے وقت، ان کو تبدیل کرنے کا منصوبہ بنایا گیا تھا: ٹیسٹ میں کام کرنے والے حصے کو صاف کر کے پروڈکشن میں داخل کیا جاتا ہے، اور دوسرا ڈیٹا کے ساتھ الگ سے کام کرنا شروع کر دیتا ہے۔ تاہم، دوبارہ سوچنے کے بعد، ہم نے زیادہ عقلی طور پر اس ڈیٹا کا اندازہ کیا جو منتقل کرنے کے قابل تھا، اور محسوس کیا کہ کالز خود ٹیسٹ کے لیے ایک متضاد ادارہ ہیں، اگر ضروری ہو تو فوری طور پر تیار کیا جاتا ہے، اور یہ پروموشنل ڈیٹا سیٹ ہے جس کی منتقلی کی کوئی قیمت نہیں ہے۔ پرکھ. بہت سی سٹوریج اشیاء ہیں جو حرکت کرنے کے قابل ہیں، لیکن یہ لفظی طور پر ایک دو میزیں ہیں، اور زیادہ بھاری نہیں ہیں۔ لہذا ہم ایک حل کے طور پر، سپارک ایک بار پھر بچاؤ کے لیے آیا، جس کی مدد سے ہم نے ٹیبلز، پروم ٹیسٹ کے درمیان ڈیٹا کی منتقلی کے لیے اسکرپٹ کو فعال طور پر استعمال کرنا شروع کیا۔
ہماری موجودہ تعیناتی پالیسی ہمیں رول بیکس کے بغیر کام کرنے کی اجازت دیتی ہے۔ پرومو سے پہلے، ایک لازمی ٹیسٹ رن ہے، جہاں ایک غلطی اتنی مہنگی نہیں ہے. ناکامی کی صورت میں، آپ ہمیشہ کیس اسپیس کو چھوڑ سکتے ہیں اور شروع سے ہی پوری اسکیم کو رول کر سکتے ہیں۔
کیسینڈرا کی مسلسل دستیابی کو یقینی بنانے کے لیے، آپ کو ڈی بی اے کی ضرورت ہے اور نہ صرف اسے۔ درخواست کے ساتھ کام کرنے والے ہر فرد کو یہ سمجھنا چاہیے کہ موجودہ صورتحال کو کہاں اور کیسے دیکھنا ہے اور بروقت مسائل کی تشخیص کیسے کی جائے۔ ایسا کرنے کے لیے، ہم فعال طور پر DataStax OpsCenter (انتظامیہ اور کام کے بوجھ کی نگرانی)، Cassandra ڈرائیور سسٹم میٹرکس (C* کو لکھنے کے لیے ٹائم آؤٹ کی تعداد، C* سے پڑھنے کے لیے ٹائم آؤٹ کی تعداد، زیادہ سے زیادہ لیٹنسی وغیرہ)، آپریشن کی نگرانی کرتے ہیں۔ کیسینڈرا کے ساتھ کام کرتے ہوئے، درخواست میں ہی۔
جب ہم نے پچھلے سوال کے بارے میں سوچا، تو ہمیں احساس ہوا کہ ہمارا اصل خطرہ کہاں ہو سکتا ہے۔ یہ ڈیٹا ڈسپلے فارمز ہیں جو کئی آزاد سوالات سے لے کر سٹوریج تک ڈیٹا ڈسپلے کرتے ہیں۔ اس طرح ہم کافی متضاد معلومات حاصل کر سکتے ہیں۔ لیکن یہ مسئلہ اتنا ہی متعلقہ ہوگا اگر ہم صرف ایک ڈیٹا سینٹر کے ساتھ کام کریں۔ اس لیے یہاں سب سے زیادہ معقول بات یہ ہے کہ کسی تھرڈ پارٹی ایپلی کیشن پر ڈیٹا پڑھنے کے لیے ایک بیچ فنکشن بنایا جائے، جو اس بات کو یقینی بنائے گا کہ ڈیٹا ایک ہی مدت میں موصول ہو جائے۔ جہاں تک کارکردگی کے لحاظ سے پڑھنے اور لکھنے میں تقسیم کا تعلق ہے، تو یہاں ہمیں اس خطرے سے روک دیا گیا تھا کہ ڈی سی کے درمیان رابطے کے کچھ نقصان کے ساتھ، ہم دو کلسٹرز کے ساتھ ختم ہو سکتے ہیں جو ایک دوسرے سے بالکل متضاد ہیں۔
نتیجے کے طور پر، اب کے لئے EACH_QUORUM لکھنے کے لیے مستقل مزاجی کی سطح پر روک دیا گیا، پڑھنے کے لیے - LOCAL_QUORUM
مختصر تاثرات اور نتائج
آپریشنل سپورٹ اور مزید ترقی کے امکانات کے نقطہ نظر سے نتیجہ خیز حل کا جائزہ لینے کے لیے، ہم نے اس بارے میں سوچنے کا فیصلہ کیا کہ اس طرح کی ترقی کو اور کہاں لاگو کیا جا سکتا ہے۔
بلے سے بالکل باہر، پھر پروگراموں کے لیے ڈیٹا اسکورنگ جیسے کہ "جب سہولت ہو تو ادائیگی کریں" (ہم معلومات کو C* میں لوڈ کرتے ہیں، اسپارک اسکرپٹ کا استعمال کرتے ہوئے کیلکولیشن)، رقبے کے لحاظ سے جمع کے ساتھ دعووں کا حساب لگانا، کرداروں کو اسٹور کرنا اور کردار کی بنیاد پر صارف کے رسائی کے حقوق کا حساب لگانا۔ میٹرکس.
جیسا کہ آپ دیکھ سکتے ہیں، ذخیرہ وسیع اور متنوع ہے۔ اور اگر ہم NoSQL کے حامیوں/مخالفین کے کیمپ کا انتخاب کرتے ہیں، تو ہم حامیوں میں شامل ہو جائیں گے، کیونکہ ہمیں اپنے فوائد حاصل ہوئے، اور بالکل وہیں جہاں ہماری توقع تھی۔
یہاں تک کہ باکس سے باہر کیسینڈرا آپشن بھی ریئل ٹائم میں افقی اسکیلنگ کی اجازت دیتا ہے، جو سسٹم میں ڈیٹا بڑھنے کے مسئلے کو بالکل بے درد طریقے سے حل کرتا ہے۔ ہم کال ایگریگیٹس کو ایک الگ سرکٹ میں شمار کرنے کے لیے ایک بہت زیادہ بوجھ والے میکانزم کو منتقل کرنے کے قابل تھے، اور ایپلیکیشن اسکیما اور منطق کو بھی الگ کرتے ہوئے، ڈیٹا بیس میں ہی اپنی مرضی کے مطابق کام اور اشیاء کو لکھنے کے غلط عمل سے چھٹکارا حاصل کر سکے۔ ہمیں رفتار بڑھانے کے لیے انتخاب اور ترتیب دینے کا موقع ملا، ہم کن ڈی سیز پر کیلکولیشن کریں گے اور کن پر ڈیٹا ریکارڈ کریں گے، ہم نے انفرادی نوڈس اور مجموعی طور پر ڈی سی دونوں کے کریش کے خلاف خود کو بیمہ کرایا۔
اپنے فن تعمیر کو نئے پراجیکٹس پر لاگو کرتے ہوئے، اور پہلے سے ہی کچھ تجربہ رکھتے ہوئے، میں اوپر بیان کردہ باریکیوں کو فوری طور پر ذہن میں رکھنا چاہوں گا، اور کچھ غلطیوں کو روکنا چاہتا ہوں، کچھ تیز گوشوں کو ہموار کرنا چاہوں گا جن سے ابتدائی طور پر گریز نہیں کیا جا سکتا تھا۔
مثال کے طور پر، بروقت انداز میں کیسینڈرا کی تازہ کاریوں سے باخبر رہیںکیونکہ ہمیں جو مسائل ملے ہیں ان میں سے کچھ پہلے سے ہی معلوم اور طے شدہ تھے۔
خود ڈیٹا بیس اور اسپارک دونوں کو ایک ہی نوڈس پر مت ڈالیں۔ (یا قابل اجازت وسائل کے استعمال کی مقدار سے سختی سے تقسیم کریں)، چونکہ Spark توقع سے زیادہ OP کھا سکتا ہے، اور ہمیں اپنی فہرست سے جلد ہی مسئلہ نمبر 1 مل جائے گا۔
پروجیکٹ کی جانچ کے مرحلے پر نگرانی اور آپریشنل قابلیت کو بہتر بنائیں۔ ابتدائی طور پر، ہمارے حل کے تمام ممکنہ صارفین کو زیادہ سے زیادہ مدنظر رکھیںکیونکہ ڈیٹا بیس کا ڈھانچہ بالآخر اسی پر منحصر ہوگا۔
ممکنہ اصلاح کے لیے نتیجے میں سرکٹ کو کئی بار گھمائیں۔ منتخب کریں کہ کن فیلڈز کو سیریلائز کیا جا سکتا ہے۔ سمجھیں کہ ہمیں سب سے زیادہ درست اور بہترین طریقے سے اکاؤنٹ میں لینے کے لیے کون سی اضافی جدولیں بنانا چاہئیں، اور پھر درخواست پر مطلوبہ معلومات فراہم کریں (مثال کے طور پر، یہ فرض کر کے کہ ہم ایک ہی ڈیٹا کو مختلف جدولوں میں محفوظ کر سکتے ہیں، مختلف خرابیوں کو مدنظر رکھتے ہوئے مختلف معیارات کے مطابق، ہم پڑھنے کی درخواستوں کے لیے CPU وقت کو نمایاں طور پر بچا سکتے ہیں)۔
برا نہیں TTL کو منسلک کرنے اور پرانے ڈیٹا کو صاف کرنے کے لیے فوری طور پر فراہم کریں۔
Cassandra سے ڈیٹا ڈاؤن لوڈ کرتے وقت درخواست کی منطق کو FETCH اصول پر کام کرنا چاہیے، تاکہ تمام قطاریں ایک ساتھ میموری میں لوڈ نہ ہوں، بلکہ بیچوں میں منتخب کی جائیں۔
اس منصوبے کو بیان کردہ حل میں منتقل کرنے سے پہلے مشورہ دیا جاتا ہے۔ کریش ٹیسٹوں کی ایک سیریز کر کے سسٹم کی غلطی برداشت کی جانچ کریں۔جیسے کہ ایک ڈیٹا سینٹر میں ڈیٹا کا نقصان، ایک مخصوص مدت کے دوران خراب شدہ ڈیٹا کی بحالی، ڈیٹا سینٹرز کے درمیان نیٹ ورک ڈراپ آؤٹ۔ اس طرح کے ٹیسٹ نہ صرف مجوزہ فن تعمیر کے فوائد اور نقصانات کا جائزہ لینے کی اجازت دیں گے، بلکہ ان کو چلانے والے انجینئرز کے لیے اچھی وارم اپ پریکٹس بھی فراہم کریں گے، اور اگر نظام کی خرابیوں کو پیداوار میں دوبارہ پیش کیا جائے تو حاصل کردہ مہارت ضرورت سے زیادہ نہیں ہوگی۔
اگر ہم اہم معلومات کے ساتھ کام کرتے ہیں (جیسے بلنگ کے لیے ڈیٹا، سبسکرائبر قرض کا حساب کتاب)، تو یہ ایسے ٹولز پر بھی توجہ دینے کے قابل ہے جو DBMS کی خصوصیات کی وجہ سے پیدا ہونے والے خطرات کو کم کریں گے۔ مثال کے طور پر، nodesync یوٹیلیٹی (Datastax) کا استعمال کریں، اس کے استعمال کے لیے ایک بہترین حکمت عملی ترتیب دے کر مستقل مزاجی کی خاطر، کیسینڈرا پر ضرورت سے زیادہ بوجھ نہ ڈالیں۔ اور اسے ایک مخصوص مدت میں صرف مخصوص میزوں کے لیے استعمال کریں۔
چھ ماہ کی زندگی کے بعد کیسینڈرا کے ساتھ کیا ہوتا ہے؟ عام طور پر، کوئی حل طلب مسائل نہیں ہیں. ہم نے کسی بھی سنگین حادثے یا ڈیٹا کے ضائع ہونے کی بھی اجازت نہیں دی۔ جی ہاں، ہمیں کچھ ایسے مسائل کی تلافی کے بارے میں سوچنا تھا جو پہلے پیدا نہیں ہوئے تھے، لیکن آخر کار اس نے ہمارے تعمیراتی حل کو بہت زیادہ متاثر نہیں کیا۔ اگر آپ چاہتے ہیں اور کچھ نیا کرنے کی کوشش کرنے سے نہیں ڈرتے، اور ساتھ ہی زیادہ مایوس نہیں ہونا چاہتے، تو اس حقیقت کے لیے تیار ہو جائیں کہ کچھ بھی مفت نہیں ہے۔ آپ کو سمجھنا پڑے گا، دستاویزات میں کھوج لگانا ہو گا اور اپنے ذاتی ریک کو پرانے میراثی حل سے زیادہ جمع کرنا ہو گا، اور کوئی نظریہ آپ کو پہلے سے نہیں بتائے گا کہ کون سا ریک آپ کا انتظار کر رہا ہے۔
ماخذ: www.habr.com