انٹرپرائز کے لیے تقسیم شدہ DBMS

CAP تھیوریم ڈسٹری بیوٹڈ سسٹم تھیوری کا سنگ بنیاد ہے۔ بلاشبہ، اس کے ارد گرد کا تنازعہ ختم نہیں ہوتا: اس میں تعریفیں اصولی نہیں ہیں، اور اس کا کوئی سخت ثبوت نہیں ہے... اس کے باوجود، روزمرہ کی عقل کے موقف پر مضبوطی سے قائم رہتے ہوئے، ہم بدیہی طور پر سمجھتے ہیں کہ نظریہ درست ہے۔

انٹرپرائز کے لیے تقسیم شدہ DBMS

صرف ایک چیز جو واضح نہیں ہے وہ ہے حرف "P" کا مفہوم۔ جب کلسٹر تقسیم ہو جاتا ہے، تو یہ فیصلہ کرتا ہے کہ آیا کورم پورا ہونے تک جواب نہ دینا، یا دستیاب ڈیٹا کو واپس دینا۔ اس انتخاب کے نتائج پر منحصر ہے، سسٹم کو یا تو CP یا AP کے طور پر درجہ بندی کیا گیا ہے۔ مثال کے طور پر، Cassandra کسی بھی طرح سے برتاؤ کر سکتا ہے، یہاں تک کہ کلسٹر کی ترتیبات پر نہیں، بلکہ ہر مخصوص درخواست کے پیرامیٹرز پر منحصر ہے۔ لیکن اگر نظام "P" نہیں ہے اور یہ الگ ہوجاتا ہے، تو پھر کیا؟

اس سوال کا جواب کچھ غیر متوقع ہے: CA کلسٹر تقسیم نہیں ہو سکتا۔
یہ کس قسم کا جھرمٹ ہے جو تقسیم نہیں ہو سکتا؟

اس طرح کے کلسٹر کی ایک ناگزیر خصوصیت مشترکہ ڈیٹا اسٹوریج سسٹم ہے۔ زیادہ تر معاملات میں، اس کا مطلب SAN سے جڑنا ہے، جو SAN کے بنیادی ڈھانچے کو برقرار رکھنے کے قابل بڑے اداروں کے لیے CA سلوشنز کے استعمال کو محدود کرتا ہے۔ ایک ہی ڈیٹا کے ساتھ کام کرنے کے لیے متعدد سرورز کے لیے، ایک کلسٹرڈ فائل سسٹم کی ضرورت ہے۔ اس طرح کے فائل سسٹم HPE (CFS)، Veritas (VxCFS) اور IBM (GPFS) پورٹ فولیو میں دستیاب ہیں۔

اوریکل آر اے سی

اصلی ایپلیکیشن کلسٹر آپشن پہلی بار 2001 میں اوریکل 9i کی ریلیز کے ساتھ نمودار ہوا۔ اس طرح کے کلسٹر میں، کئی سرور مثالیں ایک ہی ڈیٹا بیس کے ساتھ کام کرتی ہیں۔
اوریکل کلسٹرڈ فائل سسٹم اور اس کے اپنے حل - ASM، آٹومیٹک اسٹوریج مینجمنٹ دونوں کے ساتھ کام کر سکتا ہے۔

ہر ایک کاپی اپنا جریدہ رکھتا ہے۔ لین دین ایک مثال کے ذریعہ انجام دیا جاتا ہے اور اس کا ارتکاب کیا جاتا ہے۔ اگر کوئی مثال ناکام ہو جاتی ہے تو، زندہ رہنے والے کلسٹر نوڈس (مثالوں) میں سے ایک اس کا لاگ پڑھتا ہے اور کھوئے ہوئے ڈیٹا کو بحال کرتا ہے - اس طرح دستیابی کو یقینی بناتا ہے۔

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

انٹرپرائز کے لیے تقسیم شدہ DBMS

لیکن کیا ہوتا ہے اگر کسی ایک مثال کو ڈیٹا کو تبدیل کرنے کی ضرورت ہو؟

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

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

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

Oracle RAC کا صحیح استعمال ڈیٹا کو جسمانی طور پر تقسیم کرنا ہے (مثال کے طور پر، تقسیم شدہ ٹیبل میکانزم کا استعمال کرتے ہوئے) اور ایک وقف نوڈ کے ذریعے پارٹیشنز کے ہر سیٹ تک رسائی حاصل کرنا ہے۔ RAC کا بنیادی مقصد افقی اسکیلنگ نہیں تھا، بلکہ غلطی کی برداشت کو یقینی بنانا تھا۔

اگر کوئی نوڈ دل کی دھڑکن کا جواب دینا بند کر دیتا ہے، تو جس نوڈ نے اس کا پتہ لگایا وہ پہلے ڈسک پر ووٹنگ کا عمل شروع کرتا ہے۔ اگر گمشدہ نوڈ کو یہاں نوٹ نہیں کیا گیا ہے، تو نوڈس میں سے ایک ڈیٹا ریکوری کی ذمہ داری لیتا ہے:

  • "منجمد" تمام صفحات جو غائب نوڈ کے کیش میں تھے؛
  • گمشدہ نوڈ کے لاگز (دوبارہ کرنا) پڑھتا ہے اور ان لاگز میں ریکارڈ کی گئی تبدیلیوں کو دوبارہ لاگو کرتا ہے، ساتھ ہی یہ جانچتا ہے کہ آیا دوسرے نوڈس میں صفحات کے حالیہ ورژن تبدیل کیے جا رہے ہیں۔
  • زیر التواء لین دین کو رول بیک کرتا ہے۔

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

لین دین کے لیے IBM خالص ڈیٹا سسٹم

DBMS کے لیے ایک کلسٹر حل 2009 میں بلیو جائنٹ پورٹ فولیو میں ظاہر ہوا۔ نظریاتی طور پر، یہ متوازی سیسپلیکس کلسٹر کا جانشین ہے، جو "باقاعدہ" آلات پر بنایا گیا ہے۔ 2009 میں، DB2 pureScale کو ایک سافٹ ویئر سوٹ کے طور پر جاری کیا گیا، اور 2012 میں، IBM نے لین دین کے لیے Pure Data Systems نامی ایک آلات پیش کیا۔ اسے خالص ڈیٹا سسٹمز برائے تجزیات کے ساتھ الجھن میں نہیں ڈالنا چاہیے، جو کہ نیٹیزا کا نام تبدیل کرنے سے زیادہ کچھ نہیں ہے۔

پہلی نظر میں، خالص اسکیل آرکیٹیکچر Oracle RAC سے ملتا جلتا ہے: اسی طرح، کئی نوڈس ایک مشترکہ ڈیٹا اسٹوریج سسٹم سے جڑے ہوئے ہیں، اور ہر نوڈ اپنے میموری ایریاز اور ٹرانزیکشن لاگز کے ساتھ اپنی DBMS مثال چلاتا ہے۔ لیکن، اوریکل کے برعکس، DB2 کے پاس ایک وقف شدہ لاکنگ سروس ہے جس کی نمائندگی db2LLM* عمل کے ایک سیٹ کے ذریعے کی جاتی ہے۔ کلسٹر کنفیگریشن میں، یہ سروس ایک علیحدہ نوڈ پر رکھی گئی ہے، جسے Parallel Sysplex میں Coupling Facility (CF) اور Pure Data میں PowerHA کہا جاتا ہے۔

پاور ایچ اے درج ذیل خدمات فراہم کرتا ہے:

  • تالا مینیجر؛
  • عالمی بفر کیشے؛
  • انٹر پروسیس مواصلات کا علاقہ۔

پاور ایچ اے سے ڈیٹا بیس نوڈس اور پیچھے منتقل کرنے کے لیے، ریموٹ میموری تک رسائی استعمال کی جاتی ہے، اس لیے کلسٹر انٹر کنیکٹ کو RDMA پروٹوکول کو سپورٹ کرنا چاہیے۔ PureScale ایتھرنیٹ پر Infiniband اور RDMA دونوں استعمال کر سکتا ہے۔

انٹرپرائز کے لیے تقسیم شدہ DBMS

اگر نوڈ کو ایک صفحہ کی ضرورت ہے، اور یہ صفحہ کیشے میں نہیں ہے، تو نوڈ عالمی کیش میں صفحہ کی درخواست کرتا ہے، اور صرف اس صورت میں جب یہ وہاں نہیں ہے، اسے ڈسک سے پڑھتا ہے۔ اوریکل کے برعکس، درخواست صرف پاور ایچ اے کو جاتی ہے، اور پڑوسی نوڈس کو نہیں۔

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

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

"ڈرٹی"، یعنی تبدیل شدہ، صفحات کو ڈسک پر باقاعدہ نوڈ اور پاور ایچ اے (کاسٹ آؤٹ) سے لکھا جا سکتا ہے۔

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

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

90% پڑھنے اور 10% لکھنے کے کام کے بوجھ پر IBM کے اندرونی ٹیسٹ، جو کہ حقیقی دنیا کے پیداواری کام کے بوجھ سے بہت مماثلت رکھتے ہیں، تقریباً 128 نوڈس تک لکیری اسکیلنگ دکھاتے ہیں۔ ٹیسٹ کے حالات، بدقسمتی سے، ظاہر نہیں کیے جاتے ہیں۔

HPE نان اسٹاپ ایس کیو ایل

Hewlett-Packard Enterprise پورٹ فولیو کا اپنا انتہائی دستیاب پلیٹ فارم بھی ہے۔ یہ نان اسٹاپ پلیٹ فارم ہے، جسے ٹینڈم کمپیوٹرز نے 1976 میں مارکیٹ میں جاری کیا تھا۔ 1997 میں، کمپنی کو Compaq نے حاصل کر لیا، جو بدلے میں 2002 میں Hewlett-Packard کے ساتھ ضم ہو گئی۔

نان اسٹاپ کو اہم ایپلی کیشنز بنانے کے لیے استعمال کیا جاتا ہے - مثال کے طور پر، HLR یا بینک کارڈ پروسیسنگ۔ یہ پلیٹ فارم ایک سافٹ ویئر اور ہارڈویئر کمپلیکس (آلہ) کی شکل میں فراہم کیا جاتا ہے، جس میں کمپیوٹنگ نوڈس، ڈیٹا اسٹوریج سسٹم اور مواصلاتی آلات شامل ہیں۔ ServerNet نیٹ ورک (جدید نظاموں میں - Infiniband) نوڈس کے درمیان تبادلے اور ڈیٹا اسٹوریج سسٹم تک رسائی کے لیے دونوں کام کرتا ہے۔

سسٹم کے ابتدائی ورژن میں ملکیتی پروسیسرز کا استعمال کیا گیا جو ایک دوسرے کے ساتھ مطابقت پذیر تھے: تمام کارروائیاں متعدد پروسیسرز کے ذریعے ہم آہنگی سے انجام دی گئیں، اور جیسے ہی کسی ایک پروسیسر نے غلطی کی، اسے بند کر دیا گیا، اور دوسرا کام کرتا رہا۔ بعد میں، نظام نے روایتی پروسیسرز (پہلے MIPS، پھر Itanium اور آخر میں x86) میں تبدیل کر دیا، اور ہم آہنگی کے لیے دیگر میکانزم استعمال کیے جانے لگے:

  • پیغامات: ہر نظام کے عمل میں ایک "شیڈو" جڑواں ہوتا ہے، جس میں فعال عمل وقتا فوقتا اپنی حیثیت کے بارے میں پیغامات بھیجتا ہے۔ اگر مرکزی عمل ناکام ہو جاتا ہے، تو شیڈو کا عمل آخری پیغام کے ذریعے طے شدہ لمحے سے کام کرنا شروع کر دیتا ہے۔
  • ووٹنگ: سٹوریج سسٹم میں ہارڈویئر کا ایک خاص جزو ہوتا ہے جو ایک سے زیادہ ایک جیسی رسائی کو قبول کرتا ہے اور انہیں صرف اس صورت میں انجام دیتا ہے جب رسائی مماثل ہو۔ فزیکل سنکرونائزیشن کے بجائے، پروسیسرز متضاد طور پر کام کرتے ہیں، اور ان کے کام کے نتائج کا موازنہ صرف I/O لمحات میں کیا جاتا ہے۔

1987 سے، ایک رشتہ دار DBMS نان اسٹاپ پلیٹ فارم پر چل رہا ہے - پہلے SQL/MP، اور بعد میں SQL/MX۔

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

انٹرپرائز کے لیے تقسیم شدہ DBMS

نان اسٹاپ ایس کیو ایل عمل کو ترجیح دے سکتا ہے تاکہ طویل تجزیاتی سوالات لین دین کے عمل میں مداخلت نہ کریں۔ تاہم، اس کا مقصد مختصراً لین دین کی پروسیسنگ ہے، تجزیات نہیں۔ ڈویلپر پانچ "نائن" کی سطح پر نان اسٹاپ کلسٹر کی دستیابی کی ضمانت دیتا ہے، یعنی ڈاؤن ٹائم صرف 5 منٹ فی سال ہے۔

SAP ہانا

HANA DBMS (1.0) کی پہلی مستحکم ریلیز نومبر 2010 میں ہوئی، اور SAP ERP پیکیج مئی 2013 میں HANA میں تبدیل ہو گیا۔ پلیٹ فارم خریدی گئی ٹیکنالوجیز پر مبنی ہے: TREX سرچ انجن (کالمر اسٹوریج میں تلاش کریں)، P*TIME DBMS اور MAX DB۔

لفظ "HANA" بذات خود ایک مخفف ہے، ہائی پرفارمنس اینالیٹیکل ایپلائینس۔ یہ DBMS کوڈ کی شکل میں فراہم کیا جاتا ہے جو کسی بھی x86 سرورز پر چل سکتا ہے، تاہم صنعتی تنصیبات کی اجازت صرف تصدیق شدہ آلات پر ہے۔ HP، Lenovo، Cisco، Dell، Fujitsu، Hitachi، NEC سے دستیاب حل۔ کچھ Lenovo کنفیگریشنز SAN کے بغیر بھی کام کرنے کی اجازت دیتی ہیں - ایک مشترکہ اسٹوریج سسٹم کا کردار مقامی ڈسکوں پر GPFS کلسٹر ادا کرتا ہے۔

اوپر درج پلیٹ فارمز کے برعکس، HANA ایک ان میموری DBMS ہے، یعنی بنیادی ڈیٹا امیج RAM میں محفوظ ہے، اور کسی آفت کی صورت میں بحالی کے لیے ڈسک پر صرف لاگ اور متواتر سنیپ شاٹس لکھے جاتے ہیں۔

انٹرپرائز کے لیے تقسیم شدہ DBMS

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

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

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

ماخذ: www.habr.com

نیا تبصرہ شامل کریں