ان-ميموري ڊيٽا اسٽوريج تصورن جو هڪ سيٽ آهي جنهن ۾ ڊيٽا ايپليڪيشن جي ريم ۾ محفوظ ڪئي ويندي آهي، جڏهن ته ڊسڪ کي بيڪ اپ لاءِ استعمال ڪيو ويندو آهي. ڪلاسيڪل طريقن ۾، ڊيٽا ڊسڪ تي محفوظ ڪئي ويندي آهي، جڏهن ته ميموري کي ڪيش ڪيو ويندو آهي. مثال طور، ڊيٽا پروسيسنگ بيڪ اينڊ سان هڪ ويب ايپليڪيشن اسٽوريج مان ڊيٽا جي درخواست ڪري ٿي: اهو ان کي حاصل ڪري ٿو، ان کي تبديل ڪري ٿو، ۽ پوءِ نيٽ ورڪ تي وڏي مقدار ۾ ڊيٽا منتقل ڪري ٿو. ان-ميموري ۾، حساب ڪتاب ڊيٽا ڏانهن موڪليا ويندا آهن - اسٽوريج ڏانهن - جتي انهن کي پروسيس ڪيو ويندو آهي، نيٽ ورڪ لوڊ گهٽائي ٿو.
ان-ميموري سان ٻيون ڪهڙيون امڪان موجود آهن ۽ اهو ڪهڙي قسم جو طريقو آهي، ان جي وضاحت ڪئي ويندي. ولاديمير پليگين — گرڊ گين ۾ هڪ انجنيئر. هي جائزو بيڪ اينڊ ويب ايپليڪيشن ڊولپرز لاءِ ڪارآمد هوندو جن اڃا تائين ان-ميموري سان ڪم نه ڪيو آهي ۽ ان کي ڪوشش ڪرڻ چاهين ٿا، يا جيڪي جديد سافٽ ويئر ڊولپمينٽ رجحانات ۽ آرڪيٽيڪچر ڊيزائن ۾ دلچسپي رکن ٿا.
ويچاريهي مضمون #GetITConf تي ولاديمير جي پيشڪش جي نقل تي ٻڌل آهي. لاڪ ڊائون کان اڳ، اسان ماسڪو ۽ سينٽ پيٽرسبرگ ۾ ڊولپرز لاءِ باقاعدگي سان ملاقاتون ۽ ڪانفرنسون منعقد ڪندا هئاسين، رجحانن، موجوده ترقي جي مسئلن، مسئلن ۽ حلن تي بحث ڪندا هئاسين. جڏهن ته اسان هاڻي ڪانفرنس منعقد نٿا ڪري سگهون، اهو هڪ سٺو وقت آهي ته اڳئين مان مفيد مواد شيئر ڪيو وڃي.
ان-ميموري ڪير ۽ ڪيئن استعمال ڪندو آهي
ان-ميموري گهڻو ڪري استعمال ڪئي ويندي آهي جتي تيز استعمال ڪندڙ جي رابطي يا وڏي مقدار ۾ ڊيٽا جي پروسيسنگ جي ضرورت هوندي آهي.
- بئنڪون مثال طور، اهي ان-ميموري استعمال ڪندا آهن جڏهن گراهڪ ايپليڪيشن استعمال ڪندا آهن ته دير کي گهٽائڻ لاءِ يا قرض جاري ڪرڻ کان اڳ گراهڪ جو تجزيو ڪرڻ لاءِ.
- فنٽيڪ ڊيٽا پروسيسنگ ۽ تجزيو کي آئوٽ سورس ڪندڙ بينڪن لاءِ خدمتن ۽ ايپليڪيشنن جي ڪارڪردگي کي بهتر بڻائڻ لاءِ ان-ميموري استعمال ڪري ٿو.
- انشورنس ڪمپنيون: خطرن جو حساب ڪرڻ لاءِ، مثال طور، ڪيترن سالن کان ڪلائنٽ ڊيٽا جو تجزيو ڪندي.
- لاجسٽڪ ڪمپنيوناهي تمام گهڻو ڊيٽا پروسيس ڪندا آهن، مثال طور، هزارين پيرا ميٽرز سان مال ۽ مسافرن جي نقل و حمل لاءِ بهترين رستن جو حساب ڪرڻ ۽ ترسيل جي صورتحال کي ٽريڪ ڪرڻ لاءِ.
- پرچونان-ميموري حل توهان کي گراهڪن جي تيزيءَ سان خدمت ڪرڻ ۽ وڏي مقدار ۾ معلومات کي پروسيس ڪرڻ ۾ مدد ڪن ٿا: ترسيل، انوائس، ٽرانزيڪشن، گودامن ۾ هزارين شين جي دستيابي، ۽ تجزياتي رپورٽون تيار ڪرڻ.
- В IoT ان-ميموري روايتي ڊيٽابيس کي تبديل ڪري ٿي.
- دواسازي مثال طور، ڪمپنيون دوا جي مرڪبن جي ميلاپ کي آزمائڻ لاءِ ان-ميموري استعمال ڪنديون آهن.
مان ڪجھ مثال شيئر ڪندس ته اسان جا گراهڪ ان-ميموري حل ڪيئن استعمال ڪن ٿا ۽ توهان انهن کي پنهنجي ماحول ۾ ڪيئن لاڳو ڪري سگهو ٿا.
ان-ميموري بنيادي اسٽوريج جي طور تي
اسان جو هڪ گراهڪ طبي تحقيق جي سامان جو هڪ وڏو آمريڪي سپلائر آهي. اهي پنهنجي بنيادي ڊيٽا گودام جي طور تي هڪ ان-ميموري حل استعمال ڪندا آهن. سڀ ڊيٽا ڊسڪ تي ذخيرو ٿيل آهي، فعال طور تي استعمال ٿيل سب سيٽ رام ۾ رکيل آهي. گودام تائين رسائي جا طريقا معياري آهن: GDBC (عام ڊيٽابيس ڪنيڪٽر) ۽ SQL سوال ٻولي.
مجموعي طور تي، هن کي ان-ميموري ڊيٽابيس (IMDB) يا ميموري-سينٽرڪ اسٽوريج سڏيو ويندو آهي. حلن جي هن طبقي جا ڪيترائي نالا آهن، ۽ اهي واحد نه آهن.
آئي ايم ڊي بي جون خاصيتون:
- ان-ميموري ۾ ذخيرو ٿيل ۽ SQL ذريعي رسائي حاصل ڪيل ڊيٽا ٻين طريقن وانگر ئي آهي. اهو هم وقت سازي ڪئي ويندي آهي؛ صرف پيشڪش ۽ رسائي جا طريقا مختلف آهن. ڊيٽا ٽرانزيڪشن انهن جي وچ ۾ ڪم ڪن ٿا.
- IMDB ريليشنل ڊيٽابيس کان تيز آهي ڇاڪاڻ ته اهو ڊسڪ جي ڀيٽ ۾ RAM مان معلومات حاصل ڪرڻ ۾ تيز آهي.
- اندروني اصلاح جي الگورتھم ۾ گهٽ هدايتون آهن.
- IMDBs ايپليڪيشنن ۾ ڊيٽا، واقعن ۽ ٽرانزيڪشن کي منظم ڪرڻ لاءِ موزون آهن.
IMDB جزوي طور تي ACID کي سپورٽ ڪري ٿو: ايٽميٽي، مستقل مزاجي، ۽ آئسوليشن. بهرحال، اهو پائيداري کي سپورٽ نٿو ڪري - جيڪڏهن بجلي ختم ٿي وڃي ته سڀ ڊيٽا گم ٿي ويندو آهي. ان کي حل ڪرڻ لاءِ، توهان سنيپ شاٽس استعمال ڪري سگهو ٿا - هڪ ڊيٽابيس "سنيپ شاٽ"، جيڪو هارڊ ڊرائيو تي ڊيٽابيس بيڪ اپ وانگر آهي - يا ريبوٽ کان پوءِ ڊيٽا بحال ڪرڻ لاءِ ٽرانزيڪشن (لاگ) لکي سگهو ٿا.
غلطي برداشت ڪندڙ ايپليڪيشنون ٺاهڻ لاءِ
اچو ته هڪ فالٽ-ٽرلرنٽ ويب ايپليڪيشن جي هڪ ڪلاسيڪل آرڪيٽيڪچر جو تصور ڪريون. اهو هن طرح ڪم ڪري ٿو: سڀئي درخواستون ويب لوڊ بيلنسر ذريعي سرورز جي وچ ۾ ورهايون وينديون آهن. هي سسٽم لچڪدار آهي ڇاڪاڻ ته سرور هڪ ٻئي کي نقل ڪندا آهن ۽ واقعن جي صورت ۾ بيڪ اپ فراهم ڪندا آهن.
لوڊ بيلنس ڪندڙ سڀني درخواستن کي هڪ سيشن کان سختي سان هڪ سرور ڏانهن روٽ ڪري ٿو. هي هڪ اسٽڪي سيشن ميڪانيزم آهي: هر سيشن پابند آهي سرور، جنهن ۾ اهو مقامي طور تي ذخيرو ٿيل ۽ پروسيس ٿيل آهي.
جڏهن انهن مان ڪو هڪ ناڪام ٿئي ٿو ته ڇا ٿيندو؟ سرور?
سروس متاثر نه ٿيندي ڇاڪاڻ ته آرڪيٽيڪچر نقل ٿيل آهي. پر اسان ڊيڊ سرور جي سيشن جو هڪ ذيلي سيٽ وڃائي ڇڏينداسين.۽ انهن سيشنن سان ڳنڍيل استعمال ڪندڙ پڻ. مثال طور، هڪ گراهڪ آرڊر ڏئي ٿو ۽ اوچتو ان کي سندس اڪائونٽ مان ڪڍيو وڃي ٿو. جڏهن اهي ٻيهر لاگ ان ٿيندا ۽ دريافت ڪندا ته انهن کي پورو آرڊر ٻيهر مڪمل ڪرڻو پوندو ته اهي مطمئن نه ٿيندا.
هڪ ويب ايپليڪيشن کي وڏي تعداد ۾ استعمال ڪندڙن جي مدد ڪرڻ ۽ هڪ آرامده تجربو فراهم ڪرڻ جي ضرورت آهي. بهرحال، جيڪڏهن ايپليڪيشن ناڪام ٿئي ٿي، ته سيشن اسٽوريج سان رابطو ڪرڻ ۾ خرچ ٿيل وقت هر ايندڙ درخواست سان وڌي ويندو. اهو ٻين استعمال ڪندڙن لاءِ سراسري دير وڌائي ٿو. پر اهي وڌيڪ انتظار نٿا ڪرڻ چاهين جيترو اهي استعمال ڪندا هئا.
هي مسئلو اسان جي ڪنهن ٻئي ڪلائنٽ، آمريڪا ۾ قائم هڪ اهم PASS فراهم ڪندڙ، حل ڪري سگهي ٿو. اهي ويب سيشن کي ڪلسٽر ڪرڻ لاءِ ان-ميموري استعمال ڪندا آهن. اهو ڪرڻ لاءِ، اهي انهن کي مقامي طور تي بدران ان-ميموري ڪلسٽر ۾ مرڪزي طور تي ذخيرو ڪندا آهن. هن طريقي سان، سيشن تمام تيزيءَ سان دستياب آهن ڇاڪاڻ ته اهي اڳ ۾ ئي رام ۾ آهن.
جڏهن ڪو سرور ڪريش ٿئي ٿو، ته لوڊ بيلنس ڪندڙ ڪريش ٿيل سرور جون درخواستون ٻين سرورن ڏانهن موڪلي ٿو، بلڪل ڪلاسيڪل آرڪيٽيڪچر وانگر. بهرحال، هڪ اهم فرق آهي: سيشن هڪ ان-ميموري ڪلسٽر ۾ محفوظ ڪيا ويندا آهن. ۽ سرورز کي ڪريش ٿيل سرور جي سيشن تائين رسائي حاصل آهي.
هي فن تعمير سڄي سسٽم جي غلطي برداشت کي وڌائي ٿو. ان کان علاوه، اسٽڪي سيشن جي ضرورت کي مڪمل طور تي ختم ڪرڻ ممڪن آهي.
هائبرڊ ٽرانزيڪشنل اينالائيٽيڪل پروسيسنگ (HTAP)
ٽرانزيڪشنل ۽ تجزياتي نظام عام طور تي الڳ الڳ رکيا ويندا آهن. جڏهن انهن کي الڳ ڪيو ويندو آهي، ته پرائمري ڊيٽابيس لوڊ جي تابع هوندو آهي. تجزياتي پروسيسنگ لاءِ، ڊيٽا کي نقل ۾ نقل ڪيو ويندو آهي ته جيئن تجزياتي پروسيسنگ ٽرانزيڪشنل عملن ۾ مداخلت نه ڪري. بهرحال، ڪاپي ڪرڻ ۾ دير سان ايندي آهي - دير کان سواءِ نقل ڪرڻ ناممڪن آهي. اهو هم وقت سازي سان ڪرڻ سان پرائمري ڊيٽابيس به سست ٿي ويندو، ۽ ڪو به فائدو نه ٿيندو.
HTAP ۾، شيون مختلف طريقي سان ڪم ڪن ٿيون: ساڳيو ڊيٽا اسٽور ايپليڪيشنن ۽ تجزياتي سوالن مان ٽرانزيڪشنل ورڪ لوڊ ٻنهي لاءِ استعمال ڪيو ويندو آهي، جنهن کي عمل ڪرڻ ۾ گهڻو وقت لڳي سگهي ٿو. جڏهن ڊيٽا RAM ۾ ذخيرو ڪيو ويندو آهي، تجزياتي سوال تيزيءَ سان عمل ڪندا آهن، ۽ ڊيٽابيس سرور گهٽ لوڊ جو تجربو ڪندو آهي (اوسط طور تي).
هائبرڊ طريقو ٽرانزيڪشن پروسيسنگ ۽ اينالائيٽڪس جي وچ ۾ ڀت کي ٽوڙي ٿو. جڏهن ته اسان ساڳئي اسٽوريج تي اينالائيٽڪس ڪندا آهيون، تجزياتي سوال ان-ميموري ڊيٽا تي هلايا ويندا آهن. اهي تمام گهڻو صحيح، تشريح لائق، ۽ لاڳاپيل آهن.
ان-ميموري حل انٽيگريشن
(نسبتا) سادو طريقو آهي شروعات کان هر شيءِ کي ترقي ڏيواسين ڊسڪ تي ڊيٽا ذخيرو ڪندا آهيون ۽ گرم ڊيٽا کي ميموري ۾ رکندا آهيون. هي اسان کي سرور ريبوٽ ۽ بندش کان بچڻ ۾ مدد ڪندو آهي.
جڏهن ڊيٽا ڊسڪ تي ذخيرو ٿيل هوندو آهي ته ٻه مکيه منظرنامو هوندا آهن. پهرين ۾، اسان ڪلسٽر يا ان جي حصن جي ڪريشز يا عام ريبوٽس کان بچڻ چاهيون ٿا - اسان ان کي هڪ سادي ڊيٽابيس جي طور تي استعمال ڪرڻ چاهيون ٿا. ٻئي منظرنامي ۾، جڏهن تمام گهڻو ڊيٽا هوندو آهي، ته ان مان ڪجهه ياداشت ۾ محفوظ ڪيو ويندو آهي.
جيڪڏهن شروعات کان هر شيءِ ٺاهڻ ممڪن نه آهي، ته ان-ميموري کي موجوده سسٽم ۾ ضم ڪرڻ ممڪن آهي. موجوده فن تعميرپر سڀئي ان-ميموري حل هن لاءِ مناسب نه آهن. ٽي لازمي گهرجون آهن. هڪ ان-ميموري حل کي سپورٽ ڪرڻ گهرجي:
- ڊيٽابيس سان ڳنڍڻ جو هڪ معياري طريقو جيڪو ان جي هيٺان هوندو (مثال طور، MySQL)؛
- اسٽوريج سان رابطي جي منطق کي ٻيهر لکڻ ۽ تبديل ڪرڻ کان بچڻ لاءِ هڪ معياري سوال ٻولي؛
- ٽرانزيڪشنلٽي - رابطي جي معنيٰ کي محفوظ ڪريو.
جيڪڏهن سڀئي ٽي شرط پورا ٿين ٿا، ته پوءِ انضمام ممڪن آهي. اسان ايپليڪيشن ۽ ڊيٽابيس جي وچ ۾ هڪ ان-ميموري ڊيٽا گرڊ رکون ٿا. هاڻي، لکڻ جون درخواستون بنيادي ڊيٽابيس ڏانهن تفويض ڪيون وينديون، ۽ جيڪڏهن ڊيٽا ڪيش ۾ نه هجي ته پڙهڻ جون درخواستون بنيادي ڊيٽابيس ڏانهن تفويض ڪيون وينديون.
جيڪڏهن تيز ڊيٽا رسائي ۽ پروسيسنگ توهان لاءِ اهم آهن، مثال طور، ڪاروباري تجزياتي لاءِ، ته توهان ان-ميموري لاڳو ڪرڻ تي غور ڪري سگهو ٿا. لاڳو ڪرڻ لاءِ، توهان نئين آرڪيٽيڪچر کي ڊزائين ڪرڻ وقت ٻئي طريقا استعمال ڪري سگهو ٿا.
جو ذريعو: www.habr.com
