ان-میموری ڈیٹا کو ذخیرہ کرنے کے تصورات کا ایک مجموعہ ہے جب اسے ایپلی کیشن کی RAM میں ذخیرہ کیا جاتا ہے، اور ڈسک کو بیک اپ کے لیے استعمال کیا جاتا ہے۔ کلاسیکی نقطہ نظر میں، ڈیٹا ڈسک پر ذخیرہ کیا جاتا ہے اور میموری کیش میں ذخیرہ کیا جاتا ہے. مثال کے طور پر، ڈیٹا کی پروسیسنگ کے لیے بیک اینڈ کے ساتھ ایک ویب ایپلیکیشن اسے اسٹوریج میں درخواست کرتی ہے: یہ اسے وصول کرتی ہے، اسے تبدیل کرتی ہے، اور بہت سا ڈیٹا نیٹ ورک پر منتقل ہوتا ہے۔ ان-میموری میں، حسابات ڈیٹا کو - اسٹوریج میں بھیجے جاتے ہیں، جہاں ان پر کارروائی ہوتی ہے اور نیٹ ورک کم لوڈ ہوتا ہے۔
ان-میموری کے ساتھ کون سے دوسرے امکانات دستیاب ہیں اور یہ کس قسم کا طریقہ ہے؟ ولادیمیر پلگین - گرڈ گین میں انجینئر۔ یہ جائزہ مواد ان ویب ایپلیکیشن بیک اینڈ ڈویلپرز کے لیے کارآمد ہو گا جنہوں نے ان-میموری کے ساتھ کام نہیں کیا ہے اور وہ کوشش کرنا چاہتے ہیں، یا سافٹ ویئر ڈویلپمنٹ اور آرکیٹیکچر ڈیزائن میں جدید رجحانات میں دلچسپی رکھتے ہیں۔
نوٹ. مضمون #GetIT Conf میں ولادیمیر کی رپورٹ کی نقل پر مبنی ہے۔ خود کو الگ تھلگ کرنے سے پہلے، ہم ماسکو اور سینٹ پیٹرزبرگ میں ڈویلپرز کے لیے باقاعدگی سے میٹنگز اور کانفرنسیں منعقد کرتے تھے: ہم نے رجحانات، موجودہ ترقی کے مسائل، مسائل اور ان کے حل پر تبادلہ خیال کیا۔ ابھی کانفرنس کا انعقاد ممکن نہیں ہے، لیکن ماضی کے مفید مواد کو شیئر کرنے کا وقت آگیا ہے۔
ان میموری کون استعمال کرتا ہے اور کیسے
ان-میموری اکثر استعمال ہوتی ہے جہاں صارف کی تیز رفتار تعامل یا ڈیٹا کی بڑی مقدار کی پروسیسنگ کی ضرورت ہوتی ہے۔
- بینکوں ان-میموری کا استعمال کریں، مثال کے طور پر، جب کلائنٹ ایپلیکیشنز استعمال کرتے ہیں تو تاخیر کو کم کرنے کے لیے یا قرض جاری کرنے سے پہلے کلائنٹ کا تجزیہ کرنے کے لیے۔
- فنٹیک ان-میموری کا استعمال ان بینکوں کے لیے خدمات اور ایپلیکیشنز کی کارکردگی کو بہتر بنانے کے لیے کرتا ہے جو ڈیٹا پروسیسنگ اور تجزیہ کو آؤٹ سورس کرتے ہیں۔
- بیمہ کمپنیاں: خطرات کا حساب لگانے کے لیے، مثال کے طور پر، کئی سالوں کے کسٹمر ڈیٹا کا تجزیہ کرکے۔
- لاجسٹک کمپنیاں. وہ بہت سارے ڈیٹا پر کارروائی کرتے ہیں، مثال کے طور پر، ہزاروں پیرامیٹرز کے ساتھ مال برداری اور مسافروں کی نقل و حمل کے لیے بہترین راستوں کا حساب لگانا، اور ترسیل کی حالت کا پتہ لگانا۔
- پرچون. ان-میموری سلوشنز صارفین کو تیزی سے پیش کرنے اور معلومات کی بڑی مقدار پر کارروائی کرنے میں مدد کرتے ہیں: ترسیل، رسیدیں، لین دین، گوداموں میں ہزاروں سامان کی موجودگی، اور تجزیاتی رپورٹیں تیار کرنا۔
- В IOT ان-میموری روایتی ڈیٹا بیس کی جگہ لے لیتی ہے۔
- فارماسیوٹیکل کمپنیاں ان-میموری کا استعمال کرتی ہیں، مثال کے طور پر، دواؤں کے مرکبات کو ترتیب دینے کے لیے۔
میں آپ کو چند مثالیں بتاؤں گا کہ ہمارے کلائنٹس ان-میموری سلوشنز کو کس طرح استعمال کرتے ہیں اور آپ خود انہیں کیسے نافذ کر سکتے ہیں۔
بنیادی اسٹوریج کے طور پر ان میموری
ہمارے گاہکوں میں سے ایک امریکہ سے طبی سائنسی آلات کا ایک بڑا سپلائر ہے۔ وہ اپنے مرکزی ڈیٹا اسٹوریج کے طور پر ایک ان-میموری حل استعمال کرتے ہیں۔ تمام ڈیٹا ڈسک پر محفوظ ہوتا ہے، اور ڈیٹا کا سب سیٹ جو فعال طور پر استعمال ہوتا ہے اسے RAM میں رکھا جاتا ہے۔ اسٹوریج تک رسائی کے طریقے معیاری ہیں - GDBC (Generic Database Connector) اور SQL استفسار کی زبان۔
اجتماعی طور پر اسے ان-میموری ڈیٹا بیس (IMDB) یا میموری سینٹرک اسٹوریج کہا جاتا ہے۔ حل کے اس طبقے کے بہت سے نام ہیں، یہ صرف وہی نہیں ہیں۔
IMDB خصوصیات:
- ڈیٹا جو ان-میموری میں محفوظ کیا جاتا ہے اور ایس کیو ایل کے ذریعے اس تک رسائی حاصل کی جاتی ہے وہی دوسرے طریقوں کی طرح ہے۔ وہ مطابقت پذیر ہیں، صرف پیش کرنے کا طریقہ، ان سے خطاب کرنے کا طریقہ مختلف ہے۔ لین دین ڈیٹا کے درمیان کام کرتا ہے۔
- IMDB متعلقہ ڈیٹا بیس سے تیز ہے کیونکہ یہ ڈسک کے مقابلے RAM سے معلومات حاصل کرنا تیز تر ہے۔
- اندرونی اصلاح کے الگورتھم میں کم ہدایات ہیں۔
- آئی ایم ڈی بیز ایپلی کیشنز میں ڈیٹا، ایونٹس اور لین دین کے انتظام کے لیے موزوں ہیں۔
IMDBs جزوی طور پر ACID کی حمایت کرتے ہیں: جوہری، مستقل مزاجی، اور تنہائی۔ لیکن وہ "پائیداری" کی حمایت نہیں کرتے ہیں - جب بجلی بند ہو جاتی ہے، تمام ڈیٹا ضائع ہو جاتا ہے۔ مسئلے کو حل کرنے کے لیے، آپ اسنیپ شاٹس استعمال کر سکتے ہیں - ڈیٹا بیس کا ایک "اسنیپ شاٹ"، جو ہارڈ ڈرائیو پر ڈیٹا بیس کے بیک اپ کے مشابہ ہے، یا ریبوٹ کے بعد ڈیٹا کو بحال کرنے کے لیے لین دین (لاگز) ریکارڈ کر سکتے ہیں۔
غلطی برداشت کرنے والی ایپلی کیشنز بنانے کے لیے
آئیے غلطی برداشت کرنے والی ویب ایپلیکیشن کے کلاسک فن تعمیر کا تصور کریں۔ یہ اس طرح کام کرتا ہے: تمام درخواستیں سرور کے درمیان ویب بیلنسر کے ذریعہ تقسیم کی جاتی ہیں۔ یہ سسٹم مستحکم ہے کیونکہ سرورز ایک دوسرے کی نقل تیار کرتے ہیں اور واقعات کی صورت میں بیک اپ لیتے ہیں۔
بیلنس ایک سیشن سے تمام درخواستوں کو سختی سے ایک سرور پر بھیجتا ہے۔ یہ ایک اسٹک سیشن میکانزم ہے: ہر سیشن ایک سرور سے منسلک ہوتا ہے جہاں اسے مقامی طور پر اسٹور اور پروسیس کیا جاتا ہے۔
جب سرورز میں سے ایک ناکام ہوجاتا ہے تو کیا ہوتا ہے؟
سروس متاثر نہیں ہوگی کیونکہ آرکیٹیکچر ڈپلیکیٹ ہے۔ لیکن ہم ڈیڈ سرور کے سیشنز کا سب سیٹ کھو دیں گے۔. اور ساتھ ہی وہ صارفین جو ان سیشنز سے منسلک ہیں۔ مثال کے طور پر، ایک کلائنٹ آرڈر دیتا ہے اور اچانک اسے دفتر سے باہر پھینک دیتا ہے۔ وہ ناخوش ہو گا جب وہ دوبارہ لاگ ان کرے گا اور اسے پتہ چلے گا کہ سب کچھ دوبارہ کرنا پڑے گا۔
ایک ویب ایپلیکیشن کی ضرورت ہوتی ہے تاکہ صارفین کی ایک بڑی تعداد کو سپورٹ کیا جائے اور سست نہ کیا جائے تاکہ وہ آرام سے کام کر سکیں۔ لیکن اگر اس سے انکار کر دیا جاتا ہے، تو ہر بعد کی درخواست کے ساتھ سیشن اسٹور کے ساتھ بات چیت کرنے میں لگنے والا وقت بڑھ جائے گا۔ یہ دوسرے صارفین کے لیے اوسط تاخیر کو بڑھاتا ہے۔ لیکن وہ پہلے سے زیادہ انتظار نہیں کرنا چاہتے۔
یہ مسئلہ ہمارے دوسرے کلائنٹ کی طرح حل کیا جا سکتا ہے، جو کہ USA کا ایک بڑا PASS فراہم کنندہ ہے۔ یہ ویب سیشنز کو کلسٹر کرنے کے لیے ان-میموری کا استعمال کرتا ہے۔ ایسا کرنے کے لیے، یہ انہیں مقامی طور پر نہیں، بلکہ مرکزی طور پر - ان-میموری کلسٹر میں اسٹور کرتا ہے۔ اس صورت میں، سیشنز بہت تیزی سے دستیاب ہیں کیونکہ وہ پہلے سے ہی RAM میں ہیں۔
جب سرور کریش ہو جاتا ہے، تو بیلنس کریش ہونے والے سرور سے درخواستیں دوسرے سرورز کو بھیجتا ہے، جیسا کہ کلاسیکی فن تعمیر میں ہوتا ہے۔ لیکن ایک اہم فرق ہے: سیشنز ان میموری کلسٹر میں محفوظ ہوتے ہیں۔ اور سرورز کو گرے ہوئے سرور کے سیشنز تک رسائی حاصل ہے۔
یہ فن تعمیر پورے نظام کی غلطی برداشت کو بڑھاتا ہے۔ مزید یہ کہ اسٹک سیشن میکانزم کو مکمل طور پر ترک کرنا ممکن ہے۔
ہائبرڈ ٹرانزیکشنل اینالیٹیکل پروسیسنگ (HTAP)
عام طور پر، لین دین اور تجزیاتی نظام الگ الگ رکھے جاتے ہیں۔ جب وہ الگ ہوجاتے ہیں، تو مرکزی بنیاد بوجھ کے نیچے آجاتی ہے۔ تجزیاتی پروسیسنگ کے لیے، ڈیٹا کو نقل میں کاپی کیا جاتا ہے تاکہ تجزیاتی پروسیسنگ لین دین کے عمل میں مداخلت نہ کرے۔ لیکن نقل کرنا وقفے کے ساتھ ہوتا ہے - بغیر وقفے کے نقل کرنا ناممکن ہے۔ اگر ہم یہ کام ہم آہنگی سے کرتے ہیں تو یہ مرکزی بنیاد کو بھی سست کر دے گا اور ہمیں کوئی جیت نہیں ملے گی۔
HTAP میں، سب کچھ مختلف طریقے سے کام کرتا ہے - اسی ڈیٹا اسٹور کو ایپلی کیشنز سے ٹرانزیکشن لوڈ، اور تجزیاتی سوالات کے لیے استعمال کیا جاتا ہے جن کو مکمل ہونے میں کافی وقت لگ سکتا ہے۔ جب ڈیٹا RAM میں ہوتا ہے، تجزیاتی سوالات تیزی سے انجام پاتے ہیں، اور ڈیٹا بیس والا سرور کم لوڈ ہوتا ہے (اوسط)۔
ایک ہائبرڈ نقطہ نظر ٹرانزیکشن پروسیسنگ اور تجزیات کے درمیان دیوار کو توڑ دیتا ہے۔ اگر ہم اسی سٹوریج پر تجزیات کرتے ہیں، تو RAM سے ڈیٹا پر تجزیاتی سوالات شروع کیے جاتے ہیں۔ وہ بہت زیادہ درست، زیادہ قابل تشریح اور مناسب ہیں۔
ان-میموری حل کا انضمام
ایک (نسبتاً) آسان طریقہ - شروع سے سب کچھ تیار کریں. ہم ڈیٹا کو ڈسک پر رکھتے ہیں اور گرم ڈیٹا کو میموری میں محفوظ کرتے ہیں۔ یہ سرور ریبوٹس یا بندش سے بچنے میں مدد کرتا ہے۔
یہاں کام پر دو اہم منظرنامے ہیں جب ڈیٹا ڈسک پر محفوظ ہوتا ہے۔ سب سے پہلے، ہم کلسٹر یا حصوں کے کریشز یا ریبوٹ سے بچنا چاہتے ہیں - ہم اسے ایک سادہ ڈیٹا بیس کے طور پر استعمال کرنا چاہتے ہیں۔ دوسرے منظر نامے میں، جب بہت زیادہ ڈیٹا ہوتا ہے، اس میں سے کچھ میموری میں ہوتا ہے۔
اگر شروع سے سب کچھ بنانا ممکن نہیں ہے تو، ان میموری کو پہلے سے ہی میں ضم کرنا ممکن ہے موجودہ فن تعمیر. لیکن تمام ان میموری حل اس کے لیے موزوں نہیں ہیں۔ تین لازمی شرطیں ہیں۔ ان-میموری حل کو سپورٹ کرنا چاہیے:
- ڈیٹا بیس سے جڑنے کا معیاری طریقہ جو اس کے نیچے واقع ہوگا (مثال کے طور پر، MySQL)؛
- ایک معیاری استفسار کی زبان، تاکہ ذخیرہ کے ساتھ تعامل کی منطق کو دوبارہ نہ لکھا جائے اور تبدیل نہ کیا جائے۔
- لین دین - تعامل کے الفاظ کو محفوظ رکھیں۔
اگر تینوں شرائط پوری ہو جائیں تو انضمام ممکن ہے۔ ہم ان میموری ڈیٹا گرڈ کو ایپلیکیشن اور ڈیٹا بیس کے درمیان رکھتے ہیں۔ اب تحریری درخواستیں بنیادی ڈیٹا بیس کو سونپ دی جائیں گی، اور اگر ڈیٹا کیشے میں نہیں ہے تو پڑھنے کی درخواستیں بنیادی ڈیٹا بیس کو سونپی جائیں گی۔
اگر ڈیٹا تک تیز رسائی اور اس کی پروسیسنگ آپ کے لیے اہم ہے، مثال کے طور پر، کاروباری تجزیات کے لیے، آپ In-Memory کو لاگو کرنے کے بارے میں سوچ سکتے ہیں۔ اور نفاذ کے لیے، آپ نئے فن تعمیر کو ڈیزائن کرتے وقت دونوں طریقے استعمال کر سکتے ہیں۔
ماخذ: www.habr.com