In-Memory مجموعه ای از مفاهیم برای ذخیره سازی داده ها زمانی است که در رم برنامه ذخیره می شود و دیسک برای پشتیبان گیری استفاده می شود. در رویکردهای کلاسیک، داده ها روی دیسک و حافظه در حافظه پنهان ذخیره می شود. به عنوان مثال، یک برنامه وب با یک Backend برای پردازش داده ها، آن را به ذخیره سازی درخواست می کند: آن را دریافت می کند، آن را تبدیل می کند و داده های زیادی از طریق شبکه منتقل می شود. در In-Memory، محاسبات به داده ها ارسال می شود - به ذخیره سازی، جایی که آنها پردازش می شوند و شبکه کمتر بارگذاری می شود.
چه امکانات دیگری با In-Memory در دسترس است و این چه نوع رویکردی است؟ ولادیمیر پلگین - مهندس در GridGain. این مطالب مروری برای توسعه دهندگان برنامه های کاربردی وب که با In-Memory کار نکرده اند و می خواهند امتحان کنند یا علاقه مند به روندهای مدرن در توسعه نرم افزار و طراحی معماری هستند مفید خواهد بود.
یادداشت. این مقاله بر اساس متن گزارش ولادیمیر در #GetIT Conf است. قبل از معرفی خود انزوا، ما به طور منظم جلسات و کنفرانس هایی را برای توسعه دهندگان در مسکو و سن پترزبورگ برگزار می کردیم: در مورد روندها، مسائل توسعه فعلی، مشکلات و راه حل های آنها بحث می کردیم. اکنون امکان برگزاری یک کنفرانس وجود ندارد، اما زمان آن رسیده است که مطالب مفیدی را از گذشته به اشتراک بگذارید.
چه کسی و چگونه از In-Memory استفاده می کند
In-Memory اغلب در مواردی استفاده می شود که تعامل سریع کاربر یا پردازش مقادیر زیادی داده مورد نیاز است.
- بانک از In-Memory استفاده کنید، به عنوان مثال، برای کاهش تاخیر زمانی که مشتریان از برنامه ها استفاده می کنند یا برای تجزیه و تحلیل مشتری قبل از صدور وام.
- فین تک از In-Memory برای بهبود عملکرد خدمات و برنامه های کاربردی برای بانک هایی که پردازش و تجزیه و تحلیل داده ها را برون سپاری می کنند، استفاده می کند.
- شرکت های بیمه: برای محاسبه ریسک ها، به عنوان مثال، با تجزیه و تحلیل داده های مشتری در طول چندین سال.
- شرکت های لجستیک. آنها داده های زیادی را پردازش می کنند، به عنوان مثال، برای محاسبه مسیرهای بهینه برای حمل و نقل بار و مسافر با هزاران پارامتر، و ردیابی وضعیت محموله ها.
- خرده فروشی. راه حل های درون حافظه به خدمات رسانی سریعتر به مشتریان کمک می کند و حجم زیادی از اطلاعات را پردازش می کند: محموله ها، فاکتورها، تراکنش ها، وجود هزاران کالا در انبارها و تهیه گزارش های تحلیلی.
- В IOT In-Memory جایگزین پایگاه داده های سنتی می شود.
- دارویی برای مثال، شرکت‌ها از In-Memory برای مرتب‌سازی ترکیبی از ترکیبات دارویی استفاده می‌کنند.
من به شما چند مثال می گویم که چگونه مشتریان ما از راه حل های In-Memory استفاده می کنند و چگونه می توانید خودتان آنها را پیاده سازی کنید.
حافظه داخلی به عنوان حافظه اصلی
یکی از مشتریان ما تامین کننده بزرگ تجهیزات علمی پزشکی از ایالات متحده آمریکا است. آنها از یک راه حل In-Memory به عنوان ذخیره اصلی داده خود استفاده می کنند. تمام داده ها روی دیسک ذخیره می شوند و زیر مجموعه داده هایی که به طور فعال استفاده می شوند در RAM نگهداری می شوند. روش های دسترسی به ذخیره سازی استاندارد هستند - GDBC (اتصال دهنده پایگاه داده عمومی) و زبان پرس و جو SQL.
در مجموع به این پایگاه داده درون حافظه (IMDB) یا حافظه محوری می گویند. این دسته از راه حل ها نام های زیادی دارند، این ها تنها نیستند.
ویژگی های IMDB:
- داده هایی که در In-Memory ذخیره می شوند و از طریق SQL به آنها دسترسی پیدا می کنند مانند سایر روش ها هستند. آنها هماهنگ هستند، فقط نحوه ارائه، نحوه پرداختن به آنها متفاوت است. تراکنش بین داده ها کار می کند.
- IMDB سریعتر از پایگاه داده های رابطه ای است زیرا بازیابی اطلاعات از RAM سریعتر از دیسک است.
- الگوریتم های بهینه سازی داخلی دستورالعمل های کمتری دارند.
- IMDB ها برای مدیریت داده ها، رویدادها و تراکنش ها در برنامه ها مناسب هستند.
IMDB ها تا حدی از ACID: Atomicity، Consistency و Isolation پشتیبانی می کنند. اما آنها از "دوام" پشتیبانی نمی کنند - وقتی برق خاموش می شود، تمام داده ها از بین می روند. برای حل این مشکل، می توانید از عکس های فوری استفاده کنید - یک "عکس فوری" از پایگاه داده، مشابه یک نسخه پشتیبان از پایگاه داده در هارد دیسک، یا ثبت تراکنش ها (log) برای بازیابی داده ها پس از راه اندازی مجدد.
برای ایجاد برنامه های کاربردی مقاوم در برابر خطا
بیایید معماری کلاسیک یک برنامه وب مقاوم در برابر خطا را تصور کنیم. این کار به این صورت است: همه درخواست ها توسط یک متعادل کننده وب بین سرورها توزیع می شوند. این سیستم پایدار است زیرا سرورها از یکدیگر کپی می کنند و در صورت بروز حوادث پشتیبان تهیه می کنند.
متعادل کننده تمام درخواست ها را از یک جلسه به طور دقیق به یک سرور هدایت می کند. این یک مکانیسم جلسه استیک است: هر جلسه با یک سرور مرتبط است که در آن به صورت محلی ذخیره و پردازش می شود.
وقتی یکی از سرورها از کار بیفتد چه اتفاقی می افتد؟
سرویس تحت تأثیر قرار نخواهد گرفت زیرا معماری تکراری است. اما ما زیر مجموعه ای از جلسات سرور مرده را از دست خواهیم داد. و در عین حال کاربرانی که به این جلسات گره خورده اند. مثلاً مشتری سفارشی می دهد و ناگهان او را از دفتر بیرون می اندازد. وقتی دوباره وارد سیستم شود و متوجه شود که همه چیز باید دوباره انجام شود، ناراضی خواهد بود.
یک برنامه وب برای پشتیبانی از تعداد زیادی از کاربران و کاهش سرعت آنها لازم است تا بتوانند راحت کار کنند. اما در صورت رد شدن، با هر درخواست بعدی مدت زمان برقراری ارتباط با فروشگاه جلسه افزایش می یابد. این باعث افزایش میانگین تاخیر برای سایر کاربران می شود. اما آنها نمی خواهند بیشتر از آنچه که عادت کرده اند صبر کنند.
این مشکل را می توان مانند مشتری دیگر ما، یک ارائه دهنده PASS بزرگ از ایالات متحده، حل کرد. از In-Memory برای خوشه بندی جلسات وب استفاده می کند. برای انجام این کار، آنها را نه به صورت محلی، بلکه به صورت مرکزی - در یک کلاستر در حافظه ذخیره می کند. در این مورد، جلسات بسیار سریعتر در دسترس هستند زیرا آنها قبلاً در RAM هستند.
هنگامی که یک سرور خراب می شود، متعادل کننده درخواست ها را از سرور خراب شده به سرورهای دیگر ارسال می کند، مانند معماری کلاسیک. اما یک تفاوت مهم وجود دارد: جلسات در یک کلاستر در حافظه ذخیره می شوند و سرورها به جلسات سرور سقوط کرده دسترسی دارند.
این معماری تحمل خطای کل سیستم را افزایش می دهد. علاوه بر این، می توان مکانیسم نشست چوب را به طور کلی کنار گذاشت.
پردازش تحلیلی تراکنش ترکیبی (HTAP)
به طور معمول، سیستم های تراکنشی و تحلیلی جدا نگه داشته می شوند. وقتی جدا می شوند، پایه اصلی تحت بار قرار می گیرد. برای پردازش تحلیلی، داده ها در یک ماکت کپی می شوند تا پردازش تحلیلی با فرآیندهای تراکنش تداخلی نداشته باشد. اما کپی کردن با تاخیر اتفاق می‌افتد - تکرار بدون تاخیر غیرممکن است. اگر این کار را به صورت همزمان انجام دهیم، سرعت پایه اصلی را نیز کاهش می دهد و هیچ برنده ای نمی گیریم.
در HTAP، همه چیز متفاوت عمل می کند - از همان ذخیره داده برای بارگذاری تراکنش ها از برنامه ها و برای پرس و جوهای تحلیلی استفاده می شود که تکمیل آنها ممکن است زمان زیادی طول بکشد. هنگامی که داده ها در RAM هستند، کوئری های تحلیلی سریعتر اجرا می شوند و سرور با پایگاه داده کمتر بارگذاری می شود (به طور متوسط).
یک رویکرد ترکیبی دیوار بین پردازش تراکنش و تجزیه و تحلیل را می شکند. اگر تجزیه و تحلیل را روی یک حافظه مشابه انجام دهیم، پرس و جوهای تحلیلی بر روی داده های RAM راه اندازی می شوند. آنها بسیار دقیق تر، قابل تفسیرتر و کافی هستند.
ادغام راه حل های درون حافظه
یک راه (نسبتا) ساده - همه چیز را از ابتدا توسعه دهید. ما داده ها را روی دیسک نگه می داریم و داده های داغ را در حافظه ذخیره می کنیم. این کمک می کند تا از راه اندازی مجدد یا قطع شدن سرور جان سالم به در ببرید.
هنگامی که داده ها روی دیسک ذخیره می شوند، دو سناریو اصلی در کار است. در مرحله اول، ما می خواهیم از خرابی ها یا راه اندازی مجدد منظم خوشه یا قطعات جان سالم به در ببریم - می خواهیم از آن به عنوان یک پایگاه داده ساده استفاده کنیم. در سناریوی دوم، زمانی که داده های زیادی وجود دارد، مقداری از آن در حافظه است.
اگر ساختن همه چیز از ابتدا امکان پذیر نباشد، می توان In-Memory را در یک حافظه قبلی ادغام کرد. معماری موجود. اما همه راه حل های In-Memory برای این کار مناسب نیستند. سه شرط اجباری وجود دارد. راه حل In-Memory باید پشتیبانی کند:
- راه استاندارد برای اتصال به پایگاه داده ای که در زیر آن قرار دارد (به عنوان مثال، MySQL).
- یک زبان پرس و جو استاندارد، به طوری که منطق تعامل با ذخیره سازی را بازنویسی و تغییر ندهد.
- تراکنشی - حفظ معناشناسی تعامل.
اگر هر سه شرط برآورده شود، ادغام امکان پذیر است. ما شبکه داده های درون حافظه را بین برنامه و پایگاه داده قرار می دهیم. اکنون درخواست‌های نوشتن به پایگاه داده اصلی و درخواست‌های خواندن در صورتی که داده‌ها در حافظه پنهان نباشند به پایگاه داده اصلی واگذار می‌شوند.
اگر دسترسی سریع به داده ها و پردازش آن برای شما مهم است، مثلاً برای تجزیه و تحلیل تجاری، می توانید به پیاده سازی In-Memory فکر کنید. و برای پیاده سازی می توانید در طراحی معماری جدید از هر دو روش استفاده کنید.
منبع: www.habr.com