جميع الشركات الناشئة الجيدة إما تموت بسرعة أو تنمو لتتوسع. سنقوم بتصميم نموذج بدء التشغيل هذا ، والذي يتعلق أولاً بالميزات ، ثم حول الأداء. سنحسن الأداء من خلال MongoDB ، وهو حل تخزين بيانات NoSQL الشهير. من السهل البدء في تطبيق MongoDB ، والعديد من المشاكل لها حلول خارج الصندوق. ومع ذلك ، عندما يزداد الحمل ، يخرج أشعل النار أنه لم يحذرك أحد من قبل ... حتى اليوم!
يتم تنفيذ النمذجة بواسطة
سيرجي زاجورسكي ، المسؤول عن البنية التحتية الخلفية بشكل عام ، و MongoDB بشكل خاص ، في
Joom . شوهد أيضًا في جانب الخادم لتطوير MMORPG Skyforge. كما يصف سيرجي نفسه ، فهو "صانع مخروط محترف بجبهته وأشعل النار". تحت المجهر ، وهو مشروع يستخدم استراتيجية التراكم لإدارة الديون الفنية. في هذا النص النصي
للتقرير في HighLoad ++ ، سننتقل بترتيب زمني من حدوث المشكلة إلى الحل باستخدام MongoDB.
الصعوبات الأولى
نحن نمثل نموذجًا لبدء التشغيل الذي يحطم المطبات. المرحلة الأولى من الحياة - يتم إطلاق الميزات في بدء التشغيل لدينا ، وبشكل غير متوقع ، يأتي المستخدمون. يحتوي خادم MongoDB الصغير الخاص بنا على حمولة لم نحلم بها أبدًا. لكننا في السحابة ، نحن بدء التشغيل! نحن نقوم بأبسط الأشياء الممكنة: انظر إلى الطلبات - أوه ، وهنا يتم طرح التصحيح بالكامل لكل مستخدم ، وسنقوم هنا ببناء المؤشرات ، وسنضيف الأجهزة هناك ، وسنقوم هنا بالتخزين المؤقت.
كل شيء - نحن نعيش على!
إذا كان من الممكن حل المشكلات بهذه الوسائل البسيطة ، فيجب حلها بهذه الطريقة.
لكن المسار المستقبلي لبدء التشغيل الناجح هو تأخير بطيء مؤلم للحظة التوسع الأفقي. سأحاول تقديم المشورة بشأن كيفية البقاء على قيد الحياة في هذه الفترة ، والتوسع وليس خطوة على أشعل النار.
تسجيل بطيء
هذه هي واحدة من المشاكل التي قد تواجهها. ماذا تفعل إذا قابلتها ، والطرق المذكورة أعلاه لا تساعد؟ الإجابة:
وضع ضمان المتانة في MongoDB بشكل افتراضي . في ثلاث كلمات يعمل مثل هذا:
- وصلنا إلى السطر الأساسي وقلنا: "اكتب!".
- النسخة المتماثلة الأساسية المسجلة.
- بعد ذلك ، تم قراءة النسخ المتماثلة الثانوية منها وقالوا الابتدائية: "سجلنا!"
في الوقت الذي فعلت فيه معظم النسخ المتماثلة الثانوية ذلك ، يعتبر الطلب كاملاً ويعود التحكم إلى برنامج التشغيل في التطبيق. تتيح لنا هذه الضمانات التأكد من أنه عند عودة التحكم إلى التطبيق ، لن تذهب المتانة إلى أي مكان ، حتى لو كان MongoDB مستلقياً ، باستثناء الكوارث الفظيعة للغاية.
لحسن الحظ ، MongoDB هي قاعدة بيانات تسمح لك بتقليل ضمانات المتانة لكل طلب فردي.
بالنسبة للطلبات المهمة ، يمكننا ترك الحد الأقصى من ضمانات المتانة بشكل افتراضي ، وبالنسبة لبعض الطلبات ، يمكننا تقليلها.
طلب الطبقات
الطبقة الأولى من الضمانات التي يمكننا إزالتها هي
عدم انتظار تأكيد السجل بواسطة معظم النسخ المتماثلة . هذا يوفر الكمون ، ولكن لا يضيف عرض النطاق الترددي. لكن في بعض الأحيان يكون الكمون هو ما تحتاجه ، خاصةً إذا كانت الكتلة محملة بقليل ولم تعمل النسخ المتماثلة الثانوية بالسرعة التي نرغب فيها.
{w:1, j:true}
إذا كتبنا سجلات بمثل هذه الضمانات ، فعندما نتحكم في التطبيق ، لم نعد نعرف ما إذا كان السجل سيبقى حياً بعد نوع من الحوادث. لكن في العادة ، ما زالت حية.
الضمان التالي ، الذي يؤثر على النطاق الترددي والكمون أيضًا ، هو
تعطيل تأكيد التسجيل . يتم كتابة إدخال دفتر اليومية على أي حال. المجلة هي واحدة من الآليات الأساسية. إذا
أوقفنا تأكيد الكتابة إليها ، فلن نفعل شيئين:
fsync على السجل ولا ننتظر نهايته . يمكن أن
يوفر هذا الكثير من موارد القرص ويحصل على
زيادة متعددة في الإنتاجية من خلال تغيير متانة الضمان.
{w:1, j:false}
ضمانات المتانة الأكثر صرامة هي
تعطيل أي اعترافات . سوف نتلقى تأكيدًا فقط بأن الطلب وصل إلى النسخة المتماثلة الأساسية. هذا سيوفر الكمون وليس زيادة الإنتاجية بأي شكل من الأشكال.
{w:0, j:false} — .
سوف نتلقى أيضًا أشياء أخرى مختلفة ، على سبيل المثال ، فشل التسجيل بسبب تعارض مع مفتاح فريد.
ما العمليات التي ينطبق عليها هذا؟
سأخبرك عن التطبيق الخاص بالإعداد في Joom. بالإضافة إلى التحميل من المستخدمين ، حيث لا توجد تنازلات متانة ، هناك حمولة يمكن وصفها بأنها تحميل دُفعة خلفية: التحديث ، إعادة فرز التقييمات ، تجميع بيانات التحليلات.
قد تستغرق عمليات الخلفية هذه ساعات ، ولكنها مصممة بحيث إذا تعطلت ، على سبيل المثال ، تعطل الواجهة الخلفية ، فلن تفقد نتيجة كل أعمالها ، ولكنها ستستأنف من النقطة الأخيرة في الماضي. يعد تقليل ضمان المتانة مفيدًا لمثل هذه المهام ، خاصة وأن fsync في السجل ، مثل أي عمليات أخرى ، سيزيد من زمن الوصول أيضًا للقراءة.
قراءة التحجيم
المشكلة التالية هي
عدم كفاية قراءة عرض النطاق الترددي . تذكر أنه في مجموعتنا لا توجد نسخ متماثلة أساسية فقط ، ولكن أيضًا نسخ ثانوية
يمكنك من خلالها القراءة . دعونا نفعل ذلك.
يمكنك أن تقرأ ، ولكن هناك فروق دقيقة. ستأتي البيانات القديمة قليلاً من النسخ المتماثلة الثانوية - بمقدار 0.5 إلى 1 ثانية. في معظم الحالات ، يكون هذا أمرًا طبيعيًا ، لكن سلوك النسخة المتماثلة الثانوية يختلف عن سلوك النسخ المتماثلة الأساسية.
في المرحلة الثانوية ، هناك عملية استخدام oplog ، وهي ليست على النسخة المتماثلة الأساسية. هذه العملية ليست مصممة للكمون المنخفض - فقط مطورو MongoDB لم يكلفوا عناء هذا. في ظل ظروف معينة ، يمكن أن تتسبب عملية استخدام oplog من الأساسي إلى الثانوي في تأخير يصل إلى 10 ثوان.
النسخ المتماثلة الثانوية ليست مناسبة لاستعلامات المستخدم - تأخذ تجارب المستخدم خطوة سريعة في الحاوية.
في المجموعات غير المظللة ، تكون هذه الطفرات أقل وضوحًا ، لكنها لا تزال موجودة. تتعثر مجموعات Shard لأن oplog يتأثر بشكل خاص بالحذف ،
والحذف جزء من وظيفة الموازن . يقوم الموازن بحذف المستندات بدقة من قبل عشرات الآلاف في فترة زمنية قصيرة.
عدد الاتصالات
العامل التالي الذي يجب مراعاته هو
الحد من عدد الاتصالات على مثيلات MongoDB . افتراضيًا ، لا توجد قيود ،
باستثناء موارد نظام التشغيل - يمكنك الاتصال أثناء السماح.
ومع ذلك ، فإن الطلبات المتزامنة أكثر المتزامنة ، أبطأ تشغيلها.
الأداء يحط من دون خطية . لذلك ، إذا وصلت إلينا زيادة كبيرة في الطلبات ، فمن الأفضل أن تخدم 80 ٪ من عدم الخدمة 100 ٪. يجب أن يقتصر عدد الاتصالات مباشرة على MongoDB.
ولكن هناك أخطاء يمكن أن تسبب مشكلة بسبب هذا. على وجه الخصوص ، يعتبر
تجمع الاتصال على جانب MongoDB شائعًا لكل من اتصالات المستخدم والخدمات intracluster . إذا كان التطبيق "أكل" جميع الاتصالات من هذا التجمع ، ثم قد يتم انتهاك سلامة في الكتلة.
لقد تعلمنا حول هذا عندما كنا بصدد إعادة بناء الفهرس ، وبما أننا كنا بحاجة لإزالة التفرد من الفهرس ، فقد مر الإجراء بعدة مراحل. في MongoDB ، لا يمكنك البناء بجوار الفهرس نفسه ، ولكن دون تفرد. لذلك ، أردنا:
- بناء مؤشر مماثل دون التفرد
- إزالة الفهرس مع التفرد ؛
- بناء فهرس دون التفرد بدلاً من البعيد ؛
- حذف مؤقت.
عندما كان الفهرس المؤقت لا يزال قيد الاكتمال في المرحلة الثانوية ، بدأنا في حذف الفهرس الفريد. عند هذه النقطة ، أعلنت MongoDB الثانوية قفله. تم حظر بعض البيانات التعريفية ، وفي معظمها توقفت جميع السجلات: لقد علقت في
تجمع الاتصال وانتظرت منهم للتأكد من مرور السجل. توقفت جميع القراءات على الثانوية أيضًا لأنه تم التقاط السجل العام.
الكتلة في مثل هذه الحالة المثيرة للاهتمام فقدت أيضا اتصالها. في بعض الأحيان بدا ذلك وعندما ربطت ملاحظتان ببعضهما البعض ، حاولوا اتخاذ قرار في دولتهم لا يمكنهم القيام به ، لأن لديهم قفلًا عالميًا.
معنويات القصة: يجب مراقبة عدد الاتصالات.
هناك أشعل النار MongoDB المعروفة ، والتي لا تزال تتعرض للهجوم في كثير من الأحيان لدرجة أنني قررت أن المشي لفترة قصيرة على ذلك.
لا تفقد الوثائق
إذا قمت بإرسال طلب بالفهرس إلى MongoDB ،
فقد لا يُرجع
الطلب جميع المستندات التي تفي بالشرط ، وفي الحالات غير المتوقعة تمامًا. هذا يرجع إلى حقيقة أنه عندما نذهب إلى بداية الفهرس ، فإن الوثيقة ، التي في النهاية ، تنتقل إلى بداية تلك الوثائق التي مررنا بها. هذا يرجع فقط
إلى قابلية تغير المؤشر . للتكرار الموثوق ، استخدم
الفهارس في الحقول غير المستقرة ولن تكون هناك صعوبات.
MongoDB لها وجهات نظرها الخاصة حول الفهارس التي يجب استخدامها. الحل بسيط -
بمساعدة تلميح $ ، نجبر MongoDB على استخدام الفهرس الذي حددناه .
جمع الأحجام
الشركة الناشئة قيد التطوير ، وهناك الكثير من البيانات ، لكنني لا أريد إضافة أقراص - لقد أضفنا بالفعل ثلاث مرات في الشهر الماضي. دعونا نرى ما يتم تخزينه في بياناتنا ، انظر إلى حجم المستندات. كيف نفهم أين يمكنك أن تقلل من الحجم في المجموعة؟ وفقا لاثنين من المعلمات.
- حجم مستندات معينة للعب بطولها:
Object.bsonsize() ؛
- وفقًا لمتوسط حجم المستند في المجموعة :
db.c.stats().avgObjectSize .
كيف تؤثر على حجم الوثيقة؟
لدي إجابات غير محددة على هذا السؤال. أولاً ،
يزيد اسم الحقل الطويل من حجم المستند. في كل وثيقة ، يتم نسخ جميع أسماء الحقول ، لذلك إذا كان للوثيقة اسم حقل طويل ، فيجب إضافة حجم الاسم إلى حجم كل وثيقة. إذا كان لديك مجموعة بها عدد كبير من المستندات الصغيرة في عدة حقول ، فعليك تسمية الحقول بأسماء قصيرة: "A" ، "B" ، "CD" - بحد أقصى حرفين.
على القرص ، يتم تعويض هذا عن طريق الضغط ، ولكن يتم تخزين كل شيء في ذاكرة التخزين المؤقت كما هي.
النصيحة الثانية هي أنه في
بعض الأحيان
يمكن وضع بعض الحقول ذات الأهمية المنخفضة في اسم المجموعة . على سبيل المثال ، قد يكون هذا الحقل لغة. إذا كانت لدينا مجموعة بها ترجمات إلى الروسية والإنجليزية والفرنسية وحقل يحتوي على معلومات حول اللغة المخزنة ، فيمكن وضع قيمة هذا الحقل باسم المجموعة. لذلك سوف نقوم
بتقليل حجم المستندات ويمكننا
تقليل عدد وحجم الفهارس - وفورات كبيرة! لا يمكن القيام بذلك دائمًا ، لأنه في بعض الأحيان توجد فهارس داخل المستند لن تعمل إذا تم تقسيم المجموعة إلى مجموعات مختلفة.
آخر نصيحة حول حجم المستند -
استخدم الحقل _id . إذا كانت بياناتك تحتوي على مفتاح فريد طبيعي ، فضعها مباشرةً في id_field. حتى لو كان المفتاح مركبًا - استخدم معرف مركب. انها مفهرسة تماما. لا يوجد سوى مجموعة صغيرة واحدة - إذا غيّر منظم الأحداث ترتيب الحقول في بعض الأحيان ، فسيتم اعتبار المعرّف بنفس قيم الحقول ، ولكن بترتيب مختلف معرف مختلف من حيث فهرس فريد في MongoDB. في بعض الحالات ، يمكن أن يحدث هذا في Go.
أحجام الفهرس
يخزن الفهرس نسخة من الحقول التي تم تضمينها فيه . يتكون حجم الفهرس من البيانات المفهرسة. إذا كنا نحاول فهرسة الحقول الكبيرة ، فاستعد لحجم الفهرس ليكون كبيرًا.
تقوم اللحظة الثانية بتضخيم الفهارس بشدة:
تضرب حقول الصفيف في الفهرس الحقول الأخرى من المستند في هذا الفهرس . كن حذرًا من الصفائف الكبيرة في المستندات: إما لا تقوم بفهرسة شيء آخر للصفيف ، أو قم بالالتفاف بالترتيب الذي يتم به سرد الحقول في الفهرس.
يعد ترتيب الحقول مهمًا ،
خاصةً إذا كان أحد حقول الفهرس عبارة عن صفيف . إذا اختلفت الحقول في الأصل ، وفي عدد من الحقول يختلف عدد القيم المحتملة اختلافًا كبيرًا عن عدد القيم الممكنة في حقل آخر ، فمن المنطقي بناء هذه القيم عن طريق زيادة القيم الأساسية.
يمكنك بسهولة حفظ 50٪ من حجم الفهرس إذا قمت بتبديل الحقول باستخدام أصل مختلف. يمكن أن يؤدي التقليب في الحقول إلى تقليل أكبر في الحجم.
في بعض الأحيان ، عندما يحتوي الحقل على قيمة كبيرة ، لا نحتاج إلى مقارنة هذه القيمة أكثر أو أقل ، ولكننا بحاجة إلى مقارنة واضحة للمساواة. ثم يمكن
استبدال الفهرس الموجود في الحقل ذي المحتوى الثقيل بالفهرس على التجزئة من هذا الحقل . سيتم تخزين نسخ من التجزئة في الفهرس ، وليس نسخًا من هذه الحقول.
حذف المستندات
لقد ذكرت بالفعل أن حذف المستندات هو عملية غير سارة ومن
الأفضل عدم حذفها إن أمكن. عند تصميم مخطط بيانات ، حاول التفكير في تقليل إزالة البيانات الفردية أو حذف المجموعات بأكملها. يمكن حذفها مع مجموعات كاملة. تعتبر إزالة المجموعات عملية رخيصة ، وحذف آلاف المستندات الفردية عملية صعبة.
إذا كنت لا تزال بحاجة إلى حذف الكثير من المستندات ، فتأكد من
القيام بالاختناق ، وإلا فإن الحذف الشامل للوثائق سيؤثر على زمن القراءة وسيكون غير سارة. هذا أمر سيء بشكل خاص عن الكمون في المرحلة الثانوية.
من الجدير صنع نوع من "القلم" لتحويل الخانق - من الصعب للغاية رفع المستوى في المرة الأولى. مررنا بها مرات عديدة لدرجة أن خنقها خمن من المرة الثالثة والرابعة. في البداية ، النظر في إمكانية تشديده.
إذا قمت بحذف أكثر من 30٪ من مجموعة كبيرة ، فقم بنقل المستندات المباشرة إلى المجموعة المجاورة وحذف المجموعة القديمة ككل. من الواضح أن هناك فروق دقيقة ، لأن الحمل يتم تبديله من المجموعة القديمة إلى المجموعة الجديدة ، ولكن يتم التحويل إن أمكن.
هناك طريقة أخرى لحذف المستندات وهي فهرس
TTL ، وهو فهرس يفهرس الحقل الذي يحتوي على الطابع الزمني لمونغو ، والذي يحتوي على تاريخ وفات الوثيقة. عندما يأتي هذا الوقت ، سوف يقوم MongoDB بحذف هذا المستند تلقائيًا.
مؤشر TTL مناسب ، ولكن
لا يوجد اختناق في التنفيذ. MongoDB لا يهتم بكيفية إزالة هذه الحذف. إذا حاولت حذف مليون مستند في نفس الوقت ، فلديك بضع دقائق مجموعة غير صالحة للعمل لا تتعامل إلا مع الحذف وليس أكثر. لمنع حدوث ذلك ، أضف بعض
العشوائية ،
وانشر TTL بقدر ما يسمح به منطق عملك والمؤثرات الخاصة على الكمون. يعد تلطيخ TTL أمرًا ضروريًا إذا كان لديك أسباب منطقية للعمل التجاري تركز على الحذف في وقت واحد.
Shardirovanie
لقد حاولنا تأجيل هذه اللحظة ، لكنها جاءت - لا يزال يتعين علينا التوسع بشكل أفقي. بالنسبة لـ MongoDB ، هذا أمر شاق.
إذا كنت تشك في أنك بحاجة إلى التقسيم ، فأنت لا تحتاج إليه.
تؤدي المشاركة إلى تعقيد حياة أحد المطورين والمطورين بطرق متنوعة. في الشركة ، نسميها ضريبة المشاركة. عندما نشارك مجموعة ،
ينخفض الأداء المحدد للمجموعة : يتطلب MongoDB فهرسًا منفصلًا للمشاركة ، ويجب تمرير معلمات إضافية إلى الطلب حتى يمكن تنفيذه بشكل أكثر كفاءة.
بعض الأشياء المبهمة لا تعمل بشكل جيد. على سبيل المثال ، من المستحسن استخدام الاستعلامات مع
skip ، خاصةً إذا كان لديك الكثير من المستندات. أنت تعطي الأمر: "تخطي 100000 وثيقة."
يعتقد MongoDB بهذه الطريقة: "أولاً ، ثانياً ، ثالثاً ... مائة ألف ، دعنا نذهب أبعد من ذلك. وسوف نعود إلى المستخدم ".
في مجموعة غير مشتركة ، سيقوم MongoDB بإجراء عملية في مكان ما داخل نفسه. في شكل شبيه - تقرأ وترسل حقًا جميع المستندات البالغ عددها 100000 إلى وكيل مشاركة - في
المانجو ، والتي
ستقوم بالفعل بالفعل إلى جانبها بترشيح وتجاهل أول 100000. وهي ميزة غير سارة يجب وضعها في الاعتبار.
بالتأكيد سوف تصبح الشفرة أكثر تعقيدًا مع التقسيم - سيتعين عليك سحب مفتاح المشاركة إلى العديد من الأماكن. هذا ليس مريحًا دائمًا ، وليس ممكنًا دائمًا. ستذهب بعض الاستعلامات إما للبث أو البث المتعدد ، مما لا يضيف أيضًا قابلية التوسع. تعال إلى اختيار المفتاح الذي ستكون فيه عملية الدق أكثر دقة.
في مجموعات القطع ، تتوقف عملية count . تبدأ في إرجاع رقم أكثر مما هو في الواقع - يمكنها أن تكذب مرتين. يكمن السبب في عملية الموازنة ، عندما يتم سكب المستندات من قطعة إلى أخرى. عندما يتم سكب المستندات على القشرة المجاورة ، ولكن لم يتم حذفها بعد على اللوح الأصلي ،
count على أي حال. مطورو MongoDB لا يسمون هذا خطأ - إنها مثل هذه الميزة. لا أعرف ما إذا كان سيتم إصلاحها أم لا.
من الصعب إدارة الكتلة المختلطة . سيتوقف Devops عن تحياتك ، لأن عملية إزالة نسخة احتياطية تصبح أكثر تعقيدًا بشكل جذري. عند المشاركة ، تومض الحاجة إلى أتمتة البنية الأساسية كإنذار بالحريق - وهو ما كان يمكنك القيام به من قبل.
كيف يعمل التقسيم في MongoDB
هناك مجموعة ، نريد أن نوزعها بطريقة أو بأخرى حول القطع. للقيام بذلك ،
يقسم MongoDB المجموعة إلى مجموعات باستخدام مفتاح shard ، في محاولة لتقسيمها إلى أجزاء متساوية في مساحة مفتاح shard. يأتي بعد ذلك الموازن ، الذي
يحدد بجدية
هذه القطع وفقًا للأجزاء الموجودة في المجموعة . علاوة على ذلك ، لا يهتم الموازن بوزن هذه القطع وعدد الوثائق الموجودة فيها ، حيث أن الموازنة تتم على شكل قطع.
مفتاح المشاركة
هل ما زلت تقرر ما لشارد؟ حسنًا ، السؤال الأول هو كيفية اختيار مفتاح المشاركة. يحتوي المفتاح الجيد على العديد من المعلمات:
ارتفاع معدل عدم الاستقرار وهو
مناسب تمامًا للطلبات المتكررة .
الاختيار الطبيعي لمفتاح المشاركة هو المفتاح الأساسي - حقل المعرف. إذا كان حقل المعرف مناسبًا للتقاسم ، فمن الأفضل أن تتقاسمه مباشرةً. يعد هذا اختيارًا ممتازًا - فهو يتمتع بأهمية أساسية جيدة ، وهو غير مستقر ، ولكن مدى خصوصية عملك هو مدى ملاءمته للطلبات المتكررة. بناء على وضعك.
سأقدم مثالاً على مفتاح مشاركة فاشل. لقد ذكرت بالفعل مجموعة الترجمات - الترجمات. يحتوي على حقل لغة يخزن اللغة. على سبيل المثال ، المجموعة تدعم 100 لغة ونحن نشارك اللغة. هذا سيء - الأصل ، عدد القيم المحتملة 100 قطعة فقط ، وهي صغيرة. لكن هذا ليس هو الأسوأ - ربما تكون العلاقة الأساسية كافية لهذه الأغراض. والأسوأ من ذلك ، بمجرد أن نجحنا في التحدث حول اللغة ، اكتشفنا على الفور أن عدد المستخدمين الناطقين باللغة الإنجليزية يزيد ثلاثة أضعاف عن باقي المستخدمين. تأتي ثلاثة أضعاف الطلبات إلى المجموعة المؤسفة التي توجد بها اللغة الإنجليزية مقارنة بالطلبات الأخرى مجتمعة.
لذلك ، يجب أن يؤخذ في الاعتبار أنه في بعض الأحيان يميل مفتاح القشرة بشكل طبيعي إلى توزيع تحميل غير متساوٍ.
موازنة
لقد وصلنا إلى نقطة الانهيار عندما تنضج الحاجة بالنسبة إلينا - صانعي مجموعات MongoDB ، وننقر بأقراصها ومعالجها - بكل ما نستطيع. إلى أين تذهب؟ في أي مكان ، ونحن خلط البطولات في أعقاب المجموعات. نحن نشارك ونطلق ونكتشف فجأة أن
الموازنة ليست مجانية .
التوازن يمر عبر عدة مراحل. يختار الموازن القطع والشظايا ، من أين وأين سينقل. يستمر العمل الإضافي على مرحلتين: أولاً ،
يتم نسخ المستندات من المصدر إلى الهدف ، ثم
يتم حذف المستندات التي تم نسخها.
إن قشرتنا محملة بأكثر من طاقتها ، وهي تحتوي على جميع المجموعات ، ولكن الجزء الأول من العملية سهل بالنسبة له. لكن الثانية - إزالة - غير سارة للغاية ، لأنه سيضع حادة على شفرات الكتف ويعاني بالفعل تحت الحمل.
تتفاقم المشكلة بحقيقة أننا إذا قمنا بموازنة الكثير من القطع ، على سبيل المثال ، الآلاف ، ثم مع الإعدادات الافتراضية يتم نسخ كل هذه القطع أولاً ، ثم يأتي مزيل ويبدأ في حذفها بكميات كبيرة. في هذه المرحلة ، لم يعد الإجراء متأثرًا وعليك فقط مشاهدة ما يحدث بحزن.
لذلك ، إذا كنت تقترب من حشد مجموعة مثقلة ، فأنت بحاجة إلى التخطيط ، حيث إن
الموازنة تستغرق وقتًا. من المستحسن أن تأخذ هذا الوقت ليس في وقت الذروة ، ولكن في فترات الحمل المنخفض. موازن - قطع غيار منفصلة. يمكنك التعامل مع الموازنة الأساسية في الوضع اليدوي ، وإيقاف تشغيل الموازن في وقت الذروة ، وتشغيله عند انخفاض الحمل للسماح لنفسك أكثر.
إذا كانت قدرات السحابة لا تزال تسمح لك بالتدرج عموديًا ، فمن الأفضل تحسين مصدر القطع مسبقًا لتقليل كل هذه التأثيرات الخاصة قليلاً.
يجب أن تكون مستعدة بعناية.سيأتي HighLoad ++ سيبيريا 2019 في نوفوسيبيرسك يومي 24 و 25 يونيو. HighLoad ++ Siberia هي فرصة للمطورين من سيبيريا للاستماع إلى التقارير ، والتحدث عن الموضوعات المثقلة والغطس في البيئة "حيث يكون لكل شخص ملكه" ، دون أن يطير أكثر من ثلاثة آلاف كيلومتر إلى موسكو أو سان بطرسبرغ. من بين 80 طلبًا ، وافقت لجنة البرنامج على 25 طلبًا ، ونخبرنا عن جميع التغييرات الأخرى في البرنامج ، وإعلانات التقارير والأخبار الأخرى في قائمتنا البريدية. اشترك لتبقى على اطلاع