بنية الذاكرة لخدمات الويب: أساسيات ومبادئ التكنولوجيا

In-Memory عبارة عن مجموعة من المفاهيم لتخزين البيانات عندما يتم تخزينها في ذاكرة الوصول العشوائي (RAM) الخاصة بالتطبيق، ويتم استخدام القرص للنسخ الاحتياطي. في الأساليب الكلاسيكية، يتم تخزين البيانات على القرص ويتم تخزين الذاكرة في ذاكرة التخزين المؤقت. على سبيل المثال، يطلب تطبيق ويب ذو واجهة خلفية لمعالجة البيانات تخزينها: فهو يستقبلها، ويحولها، ويتم نقل الكثير من البيانات عبر الشبكة. في الذاكرة الداخلية، يتم إرسال الحسابات إلى البيانات - إلى وحدة التخزين، حيث تتم معالجتها ويكون تحميل الشبكة أقل.

بفضل بنيتها، تعمل 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:

• البيانات المخزنة في الذاكرة الداخلية والتي يتم الوصول إليها من خلال SQL هي نفسها كما في الطرق الأخرى. إنها متزامنة، فقط طريقة العرض وطريقة معالجتها مختلفة. المعاملات تعمل بين البيانات.

• يعد IMDB أسرع من قواعد البيانات العلائقية لأنه أسرع في استرداد المعلومات من ذاكرة الوصول العشوائي (RAM) مقارنة بالقرص. 
• تحتوي خوارزميات التحسين الداخلي على تعليمات أقل.
• IMDBs مناسبة لإدارة البيانات والأحداث والمعاملات في التطبيقات.

IMDBs تدعم جزئيًا ACID: الذرية والاتساق والعزلة. لكنها لا تدعم "المتانة" - عند إيقاف تشغيل الطاقة، يتم فقدان جميع البيانات. لحل المشكلة، يمكنك استخدام اللقطات - "لقطة" لقاعدة البيانات، مماثلة للنسخ الاحتياطي لقاعدة البيانات على القرص الصلب، أو تسجيل المعاملات (السجلات) لاستعادة البيانات بعد إعادة التشغيل.

لإنشاء تطبيقات متسامحة مع الخطأ

دعونا نتخيل البنية الكلاسيكية لتطبيق ويب متسامح مع الأخطاء. يعمل الأمر على النحو التالي: يتم توزيع جميع الطلبات بواسطة موازن الويب بين الخوادم. هذا النظام مستقر لأن الخوادم تنسخ بعضها البعض وتقوم بعمل نسخة احتياطية في حالة وقوع حوادث.

يقوم الموازن بتوجيه جميع الطلبات من جلسة واحدة بدقة إلى خادم واحد. هذه آلية جلسة ثابتة: ترتبط كل جلسة بخادم حيث يتم تخزينها ومعالجتها محليًا. 

ماذا يحدث عندما يفشل أحد الخوادم؟

لن تتأثر الخدمة لأن البنية مكررة. لكننا سنفقد مجموعة فرعية من جلسات الخادم الميت. وفي الوقت نفسه، المستخدمون المرتبطون بهذه الجلسات. على سبيل المثال، يقدم العميل طلبًا ويطرده فجأة من المكتب. سيكون غير سعيد عندما يقوم بتسجيل الدخول مرة أخرى ويجد أنه يجب القيام بكل شيء مرة أخرى.

يلزم وجود تطبيق ويب لدعم عدد كبير من المستخدمين وعدم إبطاء سرعتهم حتى يتمكنوا من العمل بشكل مريح. ولكن إذا تم رفضه، مع كل طلب لاحق، سيزداد الوقت المستغرق للتواصل مع مخزن الجلسة. يؤدي هذا إلى زيادة متوسط ​​زمن الوصول للمستخدمين الآخرين. لكنهم لا يريدون الانتظار لفترة أطول مما اعتادوا عليه.

يمكن حل هذه المشكلة مثل عميلنا الآخر، وهو مزود كبير لخدمات PASS من الولايات المتحدة الأمريكية. يستخدم In-Memory لتجميع جلسات الويب. للقيام بذلك، يقوم بتخزينها ليس محليًا، ولكن مركزيًا - في مجموعة داخل الذاكرة. في هذه الحالة، تكون الجلسات متاحة بشكل أسرع لأنها موجودة بالفعل في ذاكرة الوصول العشوائي (RAM).

عندما يتعطل الخادم، يرسل الموازن طلبات من الخادم المتعطل إلى خوادم أخرى، كما هو الحال في البنية الكلاسيكية. و لكن هناك فرق مهم: يتم تخزين الجلسات في مجموعة في الذاكرة ويمكن للخوادم الوصول إلى جلسات الخادم الساقط.

تعمل هذه البنية على زيادة التسامح مع الخطأ للنظام بأكمله. علاوة على ذلك، من الممكن التخلي عن آلية جلسة العصا تمامًا.

المعالجة التحليلية للمعاملات الهجينة (HTAP)

عادة، يتم الاحتفاظ بأنظمة المعاملات والتحليلات بشكل منفصل. عندما ينفصلان، تقع القاعدة الرئيسية تحت الحمل. بالنسبة للمعالجة التحليلية، يتم نسخ البيانات إلى نسخة متماثلة بحيث لا تتداخل المعالجة التحليلية مع عمليات المعاملات. لكن النسخ يحدث بتأخر، فمن المستحيل التكرار دون تأخير. إذا قمنا بذلك بشكل متزامن، فسيؤدي ذلك أيضًا إلى إبطاء القاعدة الرئيسية ولن نحصل على أي مكاسب.

في HTAP، يعمل كل شيء بشكل مختلف - يتم استخدام نفس مخزن البيانات لتحميل المعاملات من التطبيقات، وللاستعلامات التحليلية التي قد يستغرق إكمالها وقتًا طويلاً. عندما تكون البيانات في ذاكرة الوصول العشوائي (RAM)، يتم تنفيذ الاستعلامات التحليلية بشكل أسرع، ويكون تحميل الخادم الذي يحتوي على قاعدة البيانات أقل (في المتوسط).

يعمل النهج المختلط على كسر الحاجز بين معالجة المعاملات والتحليلات. إذا قمنا بإجراء تحليلات على نفس وحدة التخزين، فسيتم إطلاق الاستعلامات التحليلية على البيانات من ذاكرة الوصول العشوائي. فهي أكثر دقة وأكثر قابلية للتفسير وكفاية.

تكامل الحلول في الذاكرة

طريقة بسيطة (نسبيا) - تطوير كل شيء من الصفر. نحتفظ بالبيانات على القرص ونخزن البيانات الساخنة في الذاكرة. يساعد هذا على النجاة من عمليات إعادة تشغيل الخادم أو انقطاعه.

هناك سيناريوهان رئيسيان في العمل هنا عندما يتم تخزين البيانات على القرص. في البداية، نريد النجاة من الأعطال أو عمليات إعادة التشغيل المنتظمة للمجموعة أو الأجزاء - نريد استخدامها كقاعدة بيانات بسيطة. في السيناريو الثاني، عندما يكون هناك الكثير من البيانات، يكون بعضها في الذاكرة.

إذا لم يكن من الممكن بناء كل شيء من الصفر، فمن الممكن دمج الذاكرة الداخلية في الذاكرة الداخلية بالفعل الهندسة المعمارية القائمة. ولكن ليست كل الحلول داخل الذاكرة مناسبة لهذا الغرض. هناك ثلاثة شروط إلزامية. يجب أن يدعم حل In-Memory ما يلي:

• الطريقة القياسية للاتصال بقاعدة البيانات التي ستكون موجودة أسفلها (على سبيل المثال، MySQL)؛
• لغة استعلام قياسية، حتى لا يتم إعادة كتابة وتغيير منطق التفاعل مع التخزين؛
• المعاملات - الحفاظ على دلالات التفاعل.

فإذا توفرت الشروط الثلاثة كان التكامل ممكنا. نضع شبكة البيانات في الذاكرة بين التطبيق وقاعدة البيانات. سيتم الآن تفويض طلبات الكتابة إلى قاعدة البيانات الأساسية، وسيتم تفويض طلبات القراءة إلى قاعدة البيانات الأساسية إذا لم تكن البيانات موجودة في ذاكرة التخزين المؤقت.

إذا كان الوصول السريع إلى البيانات ومعالجتها أمرًا مهمًا بالنسبة لك، على سبيل المثال، لتحليلات الأعمال، فيمكنك التفكير في تطبيق In-Memory. وبالنسبة للتنفيذ، يمكنك استخدام كلا الطريقتين عند تصميم بنية جديدة.

المصدر: www.habr.com