نستمر في تجربة مع أشكال mitaps. في الآونة الأخيرة ، في حلقة الملاكمة ،
اصطدمنا بحافلة بيانات مركزية وشبكة خدمة. هذه المرة ، قررنا تجربة شيء أكثر هدوءًا - StandUp ، أي ميكروفون مفتوح. تم اختيار الموضوع في قاعدة البيانات في الذاكرة.
في أي الحالات يجب أن أتحول إلى الذاكرة؟ كيف ولماذا الحجم؟ وما يستحق الاهتمام؟ الإجابات في خطب المتكلمين ، والتي سنغطيها في هذا المنشور.
لكن أولاً ، تخيل المتحدثين:
- أندريه تروشكين ، رئيس مركز الابتكار والتقنيات المتقدمة في Promsvyazbank
- فلاديسلاف شبيليفا ، مطور تارانتول
- أرتيوم شيتوف ، مهندس حلول GridGain
التبديل إلى في الذاكرة
تفرض الاتجاهات الحالية في السوق المالية متطلبات أكثر صرامة على وقت الاستجابة وتشغيل أتمتة العمليات بشكل عام. بالإضافة إلى ذلك ، تسعى جميع المؤسسات المالية الكبرى تقريبًا اليوم إلى بناء أنظمة بيئية خاصة بها.
في هذا الصدد ، نرى لأنفسنا تطبيقين رئيسيين للحلول في الذاكرة. الأول هو التخزين المؤقت بيانات التكامل. وفقًا للسيناريو الكلاسيكي ، يوجد في الشركات الكبرى العديد من الأنظمة الآلية التي توفر البيانات بناءً على طلب المستخدم. أو نظام خارجي - ولكن في هذه الحالة ، يكون البادئ في معظم الحالات هو المستخدم. تقليديا ، تخزين هذه النظم البيانات منظم بطريقة معينة في قاعدة البيانات ، والوصول إليها عند الطلب.
اليوم ، لم تعد هذه الأنظمة تلبي المتطلبات من حيث الحمل. هنا يجب ألا ننسى المكالمات عن بعد لهذه الأنظمة من قبل أنظمة المستهلكين. وهذا يعني الحاجة إلى مراجعة طرق تخزين البيانات وعرضها - للمستخدمين أو الأنظمة الآلية أو الخدمات الفردية. الإخراج المنطقي - تخزين البيانات ذات الصلة التي تستخدمها الخدمات على مستوى الطبقة في الذاكرة ؛ هناك العديد من الحالات الناجحة المماثلة في السوق.
كانت هذه هي الحالة الأولى. والثاني فعال ، من وجهة نظر تقنية ، إدارة عمليات الأعمال. تقوم أنظمة BPM التقليدية بأتمتة تنفيذ بعض العمليات وفقًا لخوارزمية محددة مسبقًا. وفي العديد من الحالات ، تثار الأسئلة: لماذا لا تكون هذه الأنظمة فعالة بشكل كاف وسريع بما فيه الكفاية؟
عادةً ما تكتب هذه الأنظمة كل خطوة (أو مجموعة صغيرة من الخطوات ، مصممة كصفقة عمل) في قاعدة البيانات. لذلك فهي مرتبطة بوقت الاستجابة والتفاعل مع هذه الأنظمة. الآن أصبح عدد مثيلات العمليات التجارية التي يتم تشغيلها في وقت واحد في الوقت الفعلي أكبر من 10 سنوات. لذلك يجب أن يكون لأنظمة إدارة عمليات الأعمال الحديثة أداء أعلى بكثير وضمان تنفيذ التطبيقات اللامركزية. علاوة على ذلك ، تتحرك جميع الشركات اليوم نحو تكوين بيئة خدمات ميكروية كبيرة. يتمثل التحدي في أن مثيلات مختلفة من العمليات التجارية يمكنها مشاركة البيانات التشغيلية واستخدامها بكفاءة. في إطار التنسيق ، من المنطقي تخزينها في حل داخل الذاكرة.
مشكلة المصالحة
لنفترض أن لدينا عددًا كبيرًا من العقد والخدمات ، وأن يتم تنفيذ عدد من العمليات التجارية ، والتي يتم تنفيذ إجراءاتها في شكل خدمات ميكروية. لتحسين الأداء ، يبدأ كل منهم في كتابة حالته إلى مثيل ذاكرة محلية. نحصل على عدد كبير من الحالات المحلية. كيفية ضمان الأهمية والاتساق للجميع؟
نستخدم تقسيم المناطق في الذاكرة. على سبيل المثال ، حسب مجال العمل. عندما نقطع مجال أعمال ، فإننا نحدد أن بعض خدمات microservices / الأعمال لا تعمل إلا في إطار المنطقة المسؤولة عن المجال المقابل. وبهذه الطريقة يمكننا تسريع تحديث ذاكرة التخزين المؤقت والحل الكامل في الذاكرة.
في الوقت نفسه ، تعمل ذاكرة التخزين المؤقت المسؤولة عن المجال في وضع النسخ المتماثل الكامل - العدد المحدود من العقد بسبب التوزيع عبر المجالات يضمن سرعة وصحة الحل في هذا الوضع. تقسيم المناطق والحد الأقصى للتجزئة يساعد في حل مشاكل المزامنة ، تشغيل الكتلة ، إلخ. على عدد إجمالي كبير من العقد.
غالبًا ما تنشأ أسئلة حول موثوقية حلول الذاكرة. نعم ، لا يمكن وضع كل شيء هناك. من أجل ضمان الموثوقية ، لدينا دائمًا قواعد بيانات بجوار الذاكرة. على سبيل المثال ، بالنسبة للمشكلات المهمة في إعداد التقارير ، يجب تجميعها ، والتي قد تكون صعبة على عدد كبير من العقد. إذن ما هي رؤيتنا اليوم:
تآزر النهجين .
تجدر الإشارة أيضًا إلى أن هذين النهجين غير صحيحين تمامًا فقط على النقيض. وفي الوقت نفسه ، ركز عليها. يوفر المصنعون والمساهمون في أنظمة المحاكاة الافتراضية المتقدمة في حاويات ، مثل Kubernetes ، بالفعل خيارات للتخزين الموثوق به على المدى الطويل. وقد ظهرت بالفعل حالات صناعية جيدة لتنفيذ الحلول ، حيث يتم التخزين في هذا الشكل الافتراضي.
توفر واحدة من أكبر الصحف الأمريكية فرصة لقرائها لتلقي أي قضية على الإنترنت تم نشرها منذ بداية نشر هذه الصحيفة في القرن التاسع عشر. يمكننا أن نتخيل مستوى الحمل. يتم تنفيذ التخزين من خلال منصة Apache Kafka ، المنتشرة في Kubernetes. فيما يلي خيار آخر لتخزين المعلومات وإتاحة الوصول إليها تحت حمولة كبيرة لعدد كبير من العملاء. عند تصميم حلول جديدة ، فإن هذا الخيار يستحق الاهتمام أيضًا.
تحجيم قواعد البيانات في الذاكرة مع Tarantool
لنفترض أن لدينا خادم. يقبل الطلبات ، يخزن البيانات. فجأة هناك المزيد من الطلبات والبيانات ، توقف الخادم عن التعامل مع الحمل. يمكنك تحميل المزيد من الأجهزة إلى الخادم وسيقبل المزيد من الطلبات. ولكن هذا هو طريق مسدود لثلاثة أسباب في وقت واحد: التكلفة العالية ، والقدرات التقنية محدودة ومشاكل التسامح مع الخطأ. بدلاً من ذلك ، هناك تحجيم أفقي: يأتي "الأصدقاء" إلى الخادم لمساعدته على إكمال المهام. النوعان الرئيسيان للقياس الأفقي هما النسخ المتماثل والتقسيم.
يتم النسخ المتماثل عندما يكون هناك العديد من الخوادم ، وكلها تخزن نفس البيانات وتنتشر طلبات العميل عبر جميع هذه الخوادم. هذه هي الطريقة الحوسبة ، وليس البيانات ، والمقاييس. يعمل هذا عندما يتم وضع البيانات على عقدة واحدة ، ولكن هناك الكثير من طلبات العميل التي يتعذر على خادم واحد معالجتها. أيضا ، تم تعزيز التسامح مع الخطأ إلى حد كبير هنا.
يتم استخدام المشاركة لقياس البيانات: يتم إنشاء العديد من الخوادم ، ويقومون بتخزين بيانات مختلفة. لذلك يمكنك قياس كل من الحسابات والبيانات. ولكن التسامح مع الخطأ في هذه الحالة منخفضة. إذا فشل خادم واحد ، سيتم فقد جزء من البيانات.
هناك نهج ثالث - الجمع بينهما. نقسم الكتلة إلى مجموعات فرعية ، نسميها مجموعات النسخ المتماثلة. يخزن كل منهم نفس البيانات ، ولا تتقاطع البيانات بين مجموعات النسخ المتماثلة. والنتيجة هي تحجيم البيانات ، والحوسبة ، والتسامح مع الخطأ.
النسخ المتماثل
يمكن أن يكون النسخ المتماثل من نوعين: غير متزامن ومتزامن. غير متزامن عندما لا تنتظر طلبات العميل حتى تنتشر البيانات عبر النسخ المتماثلة: الكتابة إلى نسخة متماثلة واحدة كافية. بمجرد أن تصل البيانات إلى القرص ، إلى السجل ، تنجح المعاملة ويتم نسخ هذه البيانات في يوم من الأيام. متزامن - عندما تنقسم المعاملة إلى مرحلتين: الاستعداد والالتزام. لن يُرجع الالتزام النجاح حتى يتم نسخ البيانات إلى نصاب من النسخ المتماثلة.
من الواضح أن النسخ المتماثل غير المتزامن أسرع لأنه لا يوجد شيء على الشبكة. سيتم إرسال البيانات إلى الشبكة في الخلفية ، وقد اكتملت المعاملة نفسها ، كما هي مسجلة في السجل. ولكن هناك مشكلة: النسخ المتماثلة يمكن أن تتخلف عن بعضها البعض ، خارج المزامنة تظهر.
النسخ المتماثل متزامن هو أكثر موثوقية ، ولكن أبطأ بكثير وأكثر صعوبة في التنفيذ. هناك بروتوكولات معقدة. في Tarantool ، يمكنك اختيار أي من هذه الأنواع من النسخ المتماثلة ، حسب المهمة.
يؤدي تأخر النسخ المتماثلة إلى عدم التزامن فحسب ، بل إلى مشكلة جهل السيد أيضًا: فهو لا يعرف كيفية تمرير تغييراته إلى النسخة المتماثلة. يتم عادةً تقديم التغييرات بشكل تدريجي - يتم تطبيقها ، وفي نفس الشكل يتم نقلها بعيدًا إلى النسخة المتماثلة. ولكن ماذا تفعل معهم إذا كانت النسخة المتماثلة غير متوفرة؟ على سبيل المثال ، يمكن تكوين كل شيء في Tarantool ، ويصبح المعالج مرنًا جدًا.
تحد آخر: كيفية جعل طوبولوجيا معقدة؟ Mail.ru ، على سبيل المثال ، لديه طوبولوجيا مع مئات Tarantool. يحتوي على نواة tarantool يتم ربط tarantulas النسخة الاحتياطية لها في دائرة. في Tarantool ، يمكنك عمل طبولوجيا تعسفية تمامًا وتكرارها مع هذه الحياة بشكل مثالي.
تقاسم
الآن دعنا ننتقل إلى توسيع نطاق البيانات: التقسيم. يمكن أن يكون من نوعين: النطاقات والتجزئة. يتم مشاركة النطاق عندما يتم فرز جميع البيانات حسب مفتاح مشاركة ، ويتم تقسيم هذا التسلسل الكبير إلى نطاقات بحيث يكون لكل نطاق نفس كمية البيانات تقريبًا. ويتم تخزين كل نطاق بالكامل على أي عقدة مادية واحدة. ولكن عادة لا تكون هناك حاجة إلى مثل هذا التقسيم. علاوة على ذلك ، فهي دائما معقدة للغاية.
هناك أيضا تقاسم مع التجزئة. يتم تقديمه للتو في Tarantool. يعد التنفيذ والاستخدام ومناسبًا دائمًا تقريبًا بدلاً من نطاقات المشاركة أسهل كثيرًا. يعمل مثل هذا: نعتبر أن دالة التجزئة من السجل وتُرجع رقم العقدة الفعلية التي سيتم تخزينها. هناك مشاكل: أولاً ، من الصعب إكمال استعلام معقد بسرعة.
ثانيا ، هناك مشكلة إعادة المشاركة. هناك نوع من دالة shard التي تُرجع عدد الحصة المادية التي يجب حفظ المفتاح فيها. وعندما يتغير عدد العقد ، تتغير وظيفة shard أيضًا. هذا يعني أنه بالنسبة لجميع البيانات الموجودة في الكتلة ، سيتعين إعادة حسابها والتحقق منها مرة أخرى. علاوة على ذلك ، في التقاسم الكلاسيكي ، لن يتم نقل بعض البيانات إلى عقدة جديدة ، ولكن يتم تبديلها ببساطة بين العقد القديمة. لا يمكن تخفيض التحويلات عديمة الفائدة إلى الصفر في التقاسم الكلاسيكي.
يستخدم Tarantool المشاركة الافتراضية: لا يتم توزيع البيانات على العقد الفعلية ، ولكن على العقد الافتراضية. دلو الظاهري في كتلة افتراضية. وتوضع القصص الافتراضية على القصص المادية. وبالفعل هناك يضمن أن كل طابق افتراضي يقع بالكامل على طابق واحد.
كيف يحل هذا مشكلة إعادة البيع؟ الحقيقة هي أن عدد الجرافات ثابت ويتجاوز بشكل خطير عدد العقد المادية. وبالتالي ، بغض النظر عن حجمك الفعلي للمجموعة ، فإن الجرافة ستكون دائمًا كافية لتخزين البيانات وتوزيعها بالتساوي. ونظرًا لحقيقة أن وظيفة shard لم تتغير ، فلن تضطر إلى إعادة حسابها عندما يتغير تكوين الكتلة.
نتيجة لذلك ، حصلنا على
ثلاثة أنواع من التقاسم: النطاقات والتجزئة والدلاء الافتراضية . في حالة النطاقات والجرافات ، توجد مشكلة في البحث الفعلي.
كيفية حلها؟ الطريقة الأولى: فقط حظر إعادة المشاركة. ثم لإعادة المشاركة ، سيتعين عليك إنشاء مجموعة جديدة ونقل كل شيء هناك. الطريقة الثانية: اذهب دائمًا إلى جميع العقد. لكن هذا لا معنى له ، لأنك تحتاج إلى التوسع ، والحسابات لا تتوسع بهذا الشكل. الخيار الثالث: وحدة بروكسي ، والتي تعمل كنوع من الموجه للجرافات. يمكنك بدء تشغيله ، وإرسال طلب هناك ، مع الإشارة إلى عدد المجموعة ، وسوف يرسل طلبك كبديل إلى العقدة المادية المطلوبة.
متقدم في الذاكرة مع مثال منصة GridGain
العمل لديه متطلبات قاعدة بيانات إضافية. إنه يريد أن يكون كل هذا متسامحًا مع الخطأ وكارثية. إنه يريد توفرًا كبيرًا: حتى لا يتم فقد أي شيء على الإطلاق ، بحيث يمكنك التعافي بسرعة. هناك حاجة أيضًا إلى قابلية تطوير سهلة ورخيصة ، ودعم غير معقد ، والثقة في النظام الأساسي وآليات وصول فعالة.
كل هذه الأفكار ليست جديدة. يتم تنفيذ العديد من هذه الأشياء ، بدرجة أو بأخرى ، في قواعد بيانات إدارة قواعد البيانات الكلاسيكية ، ولا سيما النسخ المتماثل بين مراكز البيانات.
لم تعد In-Memory تقنية بدء التشغيل ، بل هي منتجات ناضجة تستخدم في أكبر الشركات حول العالم (باركليز ، سيتي جروب ، مايكروسوفت ، إلخ). من المفترض أن يتم تلبية جميع هذه المتطلبات.
لذلك إذا حدثت كارثة فجأة ، يجب أن تكون هناك فرصة للتعافي من النسخة الاحتياطية. وإذا كنا نتحدث عن مؤسسة مالية ، فمن المهم أن تكون هذه النسخة الاحتياطية متسقة ، وليس مجرد نسخة من جميع محركات الأقراص. بحيث لا يكون هناك موقف حيث تم استعادة البيانات في بعض أجزاء العقد في الوقت X ، وعلى الجانب الآخر في الوقت Y. من المهم للغاية أن يكون لديك "الاسترداد في الوقت المحدد" ، بحيث حتى في حالة تلف البيانات أو حادث شديد بشكل خاص ، تقليل مقدار الخسارة.
من المهم أن تكون قادرًا على دفع البيانات إلى القرص. بحيث لا تقع الكتلة تحت الحمل الزائد وتستمر في العمل بشكل أبطأ. وللارتفاع بسرعة من القرص ، ثم ضخ البيانات بالفعل في الذاكرة.
استجابة في الذاكرة إلى الأعطال مع وبدون مكونات التسامح مع الخطأ GridGainيجب أن كتلة الكتلة تجاوز الفشل أفقياً وعمودياً بسهولة. لا أشعر بالدفع مقابل الخادم الخاص بي وأراقب كيف أن نصف الموارد خاملة. لا أريد الحصول على الجحيم من مئات العمليات التي تحتاج إلى إدارة. أريد نظامًا بسيطًا من وجهة نظر الدعم ، مع سهولة إدخال مخرجات العقد من نظام المجموعة ونظام مراقبة متطور وناضج.
النظر في MongoDB في هذا المنظور. كل من عمل مع MongoDB يدرك عددًا كبيرًا من العمليات. إذا كان لدينا MongoDB مظلل من 5 شظايا ، فسيكون لكل شارب مجموعة متماثلة من ثلاث عمليات (مع نسبة تكرار 3). وهذه 15 عملية فقط على البيانات نفسها. تخزين تكوين نظام المجموعة هو عمليات أخرى زائد 3 ، ويبلغ إجماليها 18 عملية ، وهذا لا يشمل أجهزة التوجيه. إذا كنت تريد 20 سهمًا ، فمرحباً بك في عمليات الجحيم من 63+ (على سبيل المثال ، 8 عمليات أخرى ، إجمالي 71).
قارن مع كاساندرا. إننا نأخذ كل القطع الخمسة نفسها - وهي 5 عمليات و 5 عقد مع نفس نسبة التكرار نفسها وهي 3 ، وهو أبسط بكثير من حيث التحكم. أريد 20 قطعة - هذه 20 عملية. يمكنني توسيع نطاق مجموعتي إلى أي عدد من العقد ، وليس بالضرورة مضاعفات 3 (أو إلى قيمة أخرى لمعامل التكرار). أسهل بكثير وأرخص لتنفيذ وصيانة من مجموعات النسخ المتماثلة.
بالإضافة إلى ذلك ، تحتاج إلى الوثوق في النظام ، لفهم ما يقف الناس وراء كل منتج على حدة. من الناحية المثالية ، يجب أن يكون الترخيص مفتوح المصدر أو مفتوحًا. لذلك في حالة وفاة البائع ، يمكن القيام بشيء ما. من الجيد أيضًا أن يتم إدارة التعليمات البرمجية المصدر بواسطة مجتمع مستقل - نتذكر جميعًا كيف غيرت MongoDB و Redis التراخيص بناءً على طلب شركة الإدارة. كيف فرضت Aerospike قيودًا على إصدار مجتمع "المصدر المفتوح" في بداية العام.
تحتاج الوصول الفعال إلى البيانات. تحتوي جميعها تقريبًا على لغة استعلام منظمة في شكل أو آخر. في أغلب الأحيان يستخدمون SQL ، من الضروري أن يكون التكيف مع هذه اللغة سهلًا قدر الإمكان. سيساعد هذا في تنفيذ الاستعلام الموزع ، عندما لا تحتاج إلى إرسال طلب منفصل إلى كل عقدة ، ولكن يمكنك التواصل مع المجموعة كما هو الحال مع "نافذة واحدة". بدون التفكير من وجهة نظر واجهة برمجة التطبيقات ، هذه مجموعة من العقد (تذكر مدى صعوبة العمل مع Memcache على وحدات التخزين الكبيرة حتى في أبسط مستويات البيع / الاستحواذ ، دون استعلامات SQL المعقدة) ، ضمانات DDL و ACID الموزعة.
وأخيرا ، الدعم. إذا لم ينجح شيء ما فجأة ، فإن الشركة تخسر ببساطة المال. بالنسبة لبعض المناطق ، لا يعد هذا أمرًا بالغ الأهمية ، ولكن من المهم غالبًا أن يتحمل شخص ما المسؤولية عن المنتج وعمله. إمكانية تقديم مطالبة في أي وقت ، وتم حلها بسرعة.
مع هذا المنصب نكمل عام Promsvyazbank على Habré. جمعنا أمنيات العام الجديد لسكان خابروفسك في شريط فيديو قصير: