مرحبا بالجميع! في الآونة الأخيرة ، تم عقد ندوة مفتوحة على الإنترنت
بعنوان "توفير تخزين يتحمل الأخطاء" . لقد بحثت في المشكلات التي تنشأ في تصميم الهياكل ، ولماذا فشل الخادم ليس عذرًا عن تعطل الخادم وكيفية تقليل وقت التوقف إلى الحد الأدنى. استضاف الندوة
إيفان ريمين ، رئيس قسم تطوير الخوادم في Citimobil ومعلم في الدورة التدريبية
"High Load
Architect" .
لماذا تهتم بمرونة التخزين؟
يجب أن يكون التفكير في مرونة التخزين القابل للتطوير وفهم مشكلات التخزين المؤقت الأساسية
في مرحلة بدء التشغيل . من الواضح أنك عندما تكتب بدء تشغيل ، في البداية تقوم بإعداد الحد الأدنى من إصدار المنتج. ولكن كلما نمت أكثر ، زادت سرعة تشغيلك للإنتاجية ، مما قد يؤدي إلى توقف كامل للعمل. وإذا كنت تحصل على أموال من المستثمرين ، فبالتأكيد ، سوف يحتاجون أيضًا إلى نمو مستمر وميزات أعمال جديدة. لإيجاد التوازن الصحيح ، عليك أن تختار بين السرعة والجودة. في الوقت نفسه ، لا يمكنك التضحية بواحد أو آخر ، وإذا كنت تضحي - بوعي وضمن حدود معينة. ومع ذلك ، لا توجد وصفات عالمية هنا ، بالإضافة إلى حلول مثالية.
نقف ضد قاعدة للقراءة
هذا هو السيناريو الأول. تخيل أن لدينا خادم واحد ، الحمل على المعالج أو محرك الأقراص الصلبة هو 99 ٪. في هذه الحالة:
- تتم قراءة 90 ٪ من الطلبات ؛
- 10 ٪ من الطلبات هي سجل.
أفضل حل في هذا الموقف هو التفكير في النسخ المتماثلة. لماذا؟ هذا هو الحل الأرخص والأسهل.
يتم تصنيف النسخ المتماثل:
1. عن طريق التزامن:
- متزامن.
- غير المتزامن.
- semisynchronous.
2. وفقا للبيانات المحمولة:
- منطقي (قائم على الصف ، قائم على البيان ، مختلط) ؛
- المادية.
3. حسب عدد العقد في السجل:
- السيد / العبد ؛
- سيد / سيد.
4. بواسطة البادئ:
والآن
المهمة هي حول دلو من الماء . تخيل أن لدينا النسخ المتماثل MySQL وغير متزامن السيد والعبد. يجري التنظيف في منطقة العاصمة ، ونتيجة لذلك يتعثر المنظف ويصب دلوًا من الماء على الخادم مع القاعدة الرئيسية. يقوم التنفيذ التلقائي بتبديل أحد أحدث الرقيق إلى الوضع الرئيسي. وكل شيء مستمر في العمل. أين هو الصيد؟
الجواب بسيط - نفقد المعاملات التي لم نتمكن من تكرارها. وبالتالي ، يتم انتهاك الخاصية D من ACID.
الآن دعنا نتحدث عن كيفية عمل النسخ المتماثل غير المتزامن (MySQL):
- تسجيل معاملة على محرك التخزين (InnoDB) ؛
- تسجيل معاملة في سجل ثنائي ؛
- إكمال المعاملة في محرك التخزين ؛
- تأكيد التأكيد للعميل ؛
- نقل جزء من السجل إلى النسخة المتماثلة ؛
- تنفيذ معاملة على نسخة طبق الأصل (ص 1-3).
والسؤال المطروح الآن هو ، ما الذي يجب تغييره في الفقرات أعلاه حتى لا ينتهي بنا المطاف إلى النسخ المتماثل؟
ولا يلزم تبديل سوى نقطتين: الرابعة والخامسة ("نقل جزء من السجل إلى النسخة المتماثلة" و "إعادة التأكيد إلى العميل"). وبالتالي ، إذا تطورت العقدة الرئيسية ، سيكون لدينا دائمًا سجل معاملات في مكان ما (البند 2). وإذا تم تسجيل المعاملة في السجل الثنائي ، فستحدث المعاملة أيضًا في وقت ما.
نتيجة لذلك ، نحصل على النسخ المتماثل شبه المتزامن (MySQL) ، والذي يعمل على النحو التالي:
- تسجيل معاملة على محرك التخزين (InnoDB) ؛
- تسجيل معاملة في سجل ثنائي ؛
- إكمال المعاملة في محرك التخزين ؛
- نقل جزء من السجل إلى النسخة المتماثلة ؛
- تأكيد التأكيد للعميل ؛
- تنفيذ معاملة على نسخة طبق الأصل (ص 1-3).
المزامنة مقابل شبه المزامنة و المزامنة مقابل شبه المزامنة
لسبب ما ، في روسيا ، لم يسمع معظم الناس عن النسخ المتماثل شبه المتزامن. بالمناسبة ، يتم تنفيذها بشكل جيد في PostgreSQL وليس في MySQL. قراءة المزيد عن هذا
هنا ، ولكن يمكن صياغة أطروحة على النحو التالي:
- النسخ المتماثل شبه متزامن لا يزال خلف (ولكن ليس بالقدر) غير متزامن؛
- نحن لا نفقد المعاملات ؛
- يكفي إحضار البيانات إلى عبد واحد فقط.
بالمناسبة ، يتم استخدام النسخ المتماثل شبه المتزامن على Facebook.
نقف ضد قاعدة قياسية
لنتحدث عن مشكلة معاكسة تمامًا عندما يكون لدينا:
- 90 ٪ من الطلبات - سجل ؛
- تتم قراءة 10 ٪ من الطلبات ؛
- خادم واحد
- تحميل - 99 ٪ (المعالج أو القرص الصلب).
تأتي الحوارات المعروفة إلى الإنقاذ هنا. ولكن الآن دعنا نتحدث عن شيء آخر:
في كثير من الأحيان في مثل هذه الحالات ، فإنها تبدأ في استخدام سيد. ومع ذلك ،
فإنه لا يساعد في هذا الموقف . لماذا؟ الأمر بسيط: السجل على الخادم لا يصبح أصغر. بعد كل شيء ، يعني النسخ المتماثل أن هناك بيانات على كافة العقد. مع النسخ المتماثل المستندة إلى بيان ، في الواقع ، سيتم تشغيل SQL على ALL العقد. C الصف القائم هو أسهل قليلا ، ولكن لا تزال باهظة الثمن. وأيضا سيد لديه مشاكل مع الصراعات.
في الواقع ، من المنطقي استخدام برنامج الماجستير في المواقف التالية:
- الكتابة من خلال التسامح مع الخطأ (الفكرة هي أن تكتب دائمًا إلى رئيسي واحد فقط). يمكنك تنفيذ باستخدام عنوان IP الظاهري .
- النظم الجغرافية الموزعة.
ومع ذلك ، تذكر أن النسخ المتماثل الرئيسي من الصعب دائمًا. وغالبًا ما يجلب السيد-ماستر مشاكل أكثر مما يحل.
عملية التجزئة
لقد ذكرنا بالفعل التقسيم. باختصار ، فإن التقسيم هو وسيلة مؤكدة لإطلاق النار. الفكرة هي أننا نقوم بتوزيع البيانات عبر خوادم مستقلة (ولكن ليس دائمًا). كل قشرة يمكن تكرارها بشكل مستقل.
القاعدة الأولى للتقاسم هي أن البيانات المستخدمة معًا يجب أن تكون في نفس الحالة. sharding_key -> shard_id تعمل
sharding_key -> shard_id . وفقًا لذلك ، يجب أن يتطابق
sharding_key مع البيانات المستخدمة معًا. الصعوبة الأولى هي أنه إذا اخترت
sharding_key الخطأ ، فسيكون من الصعب عليك إعادة خلط كل شيء. ثانياً ، إذا كان لديك نوع من
sharding_key ، فسيكون من الصعب للغاية تنفيذ بعض الطلبات. على سبيل المثال ، لا يمكنك العثور على متوسط القيمة.
لإثبات ذلك ، دعنا نتخيل أن لدينا شحذتين لهما ثلاث قيم في كل منهما: (1 ؛ 2 ؛ 3) (0 ؛ 0 ؛ 500). ستكون القيمة المتوسطة مساوية (1 + 2 + 3 + 500) / 6 = 84.33333.
الآن تخيل أن لدينا خادمين مستقلين. وإعادة حساب متوسط القيمة بشكل منفصل لكل قشرة. في الأول منهم نحصل على 2 ، في الثاني - 166.66667. وحتى إذا قمنا بعد ذلك بتقييم هذه القيم ، فسنظل نحصل على رقم يختلف عن الرقم الصحيح: (2 + 166.66667) / 2 = 86.33334.
وهذا يعني أن
متوسط الوسائل لا يساوي متوسط كل شيء: avg(a, b, c, d) != avg(avg(a, b) + (avg(c, d))
الرياضيات بسيطة ، ولكن من المهم أن نتذكر.
مهمة المشاركة
لنفترض أن لدينا نظام حوار في شبكة اجتماعية. يمكن أن يكون هناك شخصان فقط في حوار. جميع الرسائل موجودة في جدول واحد ، حيث يوجد:
- معرف الرسالة
- معرف المرسل
- معرف المستلم
- نص الرسالة
- تاريخ إرسال الرسالة ؛
- بعض الأعلام.
ما هو مفتاح المشاركة الذي يجب اختياره استنادًا إلى حقيقة أن لدينا قاعدة المشاركة الأولى الموضحة أعلاه؟
هناك العديد من الخيارات لحل هذه المشكلة الكلاسيكية:
- crc32 (id_src // id_dst) ؛
- crc32 (1 // 2)! = crc32 (2 // 1) ؛
- crc32 (من + إلى)٪ n ؛
- crc32 (دقيقة (من ، إلى). كحد أقصى (من ، إلى))٪ n.
كيشي
وبعض الكلمات عن المخابئ. يمكننا أن نقول أن
المخابئ هي أداة مضادة ، على الرغم من أنه يمكن للمرء أن
يناقش هذا البيان (كثير من الناس
يفضلون استخدام ذاكرة التخزين المؤقت). ولكن إلى حد كبير ، هناك حاجة فقط إلى ذاكرة التخزين المؤقت لزيادة معدل الاستجابة. ولا يمكن تعيينها لعقد الحمل.
الاستنتاج بسيط - يجب أن نعيش بهدوء دون مخابئ. السبب الوحيد الذي قد تكون هناك حاجة إليه هو بالضبط نفس السبب الذي تدعو الحاجة إليه في المعالج: زيادة سرعة الاستجابة. إذا كانت قاعدة البيانات لا تصمد أمام التحميل كنتيجة لتختفي ذاكرة التخزين المؤقت ، فهذا أمر سيء. هذا هو النمط المعماري غير الناجح للغاية ، لذلك لا ينبغي أن يكون هذا. ومهما كانت الموارد التي لديك ، فسوف تسقط ذاكرة التخزين المؤقت الخاصة بك في يوم من الأيام ، مهما فعلت.
مشاكل ذاكرة التخزين المؤقت هي الأطروحة:- تبدأ مع ذاكرة التخزين المؤقت الباردة.
- مشكلة إبطال ذاكرة التخزين المؤقت ؛
- مخبأ الاتساق.
إذا كنت لا تزال تستخدم ذاكرة التخزين المؤقت ، فإن التجزئة المتناسق يساعدك. هذه طريقة لإنشاء جداول التجزئة الموزعة ، والتي لا يؤدي فيها فشل خادم تخزين واحد أو أكثر إلى الحاجة إلى نقل كامل لجميع المفاتيح والقيم المخزنة. ومع ذلك ، يمكنك قراءة المزيد عن هذا
هنا .
حسنا ، شكرا لمشاهدة! حتى لا تفوت أي شيء من المحاضرة الأخيرة ، من الأفضل
مشاهدة الندوة عبر الإنترنت بأكملها .