سيُعقد مؤتمر HighLoad++ القادم يومي 6 و7 أبريل 2020 في سانت بطرسبرغ.
التفاصيل والتذاكر . HighLoad++ سيبيريا 2019. قاعة "كراسنويارسك". 25 يونيو، الساعة 12:00. الأطروحات و .
ويحدث أن تتعارض المتطلبات العملية مع النظرية، حيث لا تؤخذ في الاعتبار الجوانب المهمة للمنتج التجاري. يقدم هذا الحديث عملية اختيار ودمج الأساليب المختلفة لإنشاء مكونات الاتساق السببي بناءً على البحث الأكاديمي القائم على متطلبات المنتج التجاري. سوف يتعرف المستمعون على الأساليب النظرية الحالية للساعات المنطقية، وتتبع التبعية، وأمن النظام، ومزامنة الساعة، ولماذا استقر MongoDB على حلول معينة.
ميخائيل تيولينيف (المشار إليه فيما يلي باسم MT): – سأتحدث عن الاتساق السببي – وهي ميزة عملنا عليها في MongoDB. أنا أعمل في مجموعة من الأنظمة الموزعة، قمنا بذلك منذ عامين تقريبًا.
في هذه العملية، كان علي أن أتعرف على الكثير من الأبحاث الأكاديمية، لأن هذه الميزة تمت دراستها جيدًا. اتضح أنه لا توجد مقالة واحدة تناسب ما هو مطلوب في قاعدة بيانات الإنتاج نظرًا لمتطلبات محددة للغاية ربما تكون موجودة في أي تطبيق إنتاج.
سأتحدث عن كيف نقوم، كمستهلكين للأبحاث الأكاديمية، بإعداد شيء منه يمكننا بعد ذلك تقديمه لمستخدمينا كطبق جاهز ومريح وآمن للاستخدام.
الاتساق السببي. دعونا نحدد المفاهيم
في البداية، أريد أن أقول بشكل عام ما هو الاتساق السببي. هناك شخصيتان - ليونارد وبيني (المسلسل التلفزيوني "The Big Bang Theory"):
لنفترض أن بيني في أوروبا ويريد ليونارد أن يقيم لها حفلًا مفاجئًا. ولا يمكنه التفكير في أي شيء أفضل من حذفها من قائمة أصدقائه، وإرسال تحديث إلى جميع أصدقائه على الموجز: "دعونا نجعل بيني سعيدة!" (هي في أوروبا، وهي نائمة، لا ترى كل هذا ولا تستطيع رؤيته، لأنها ليست هناك). في النهاية، تقوم بحذف هذا المنشور، ومسحه من الخلاصة واستعادة الوصول إليه حتى لا تلاحظ أي شيء ولا تكون هناك فضيحة.
كل هذا جيد وجيد، ولكن لنفترض أن النظام موزع وأن الأمور سارت بشكل خاطئ قليلاً. قد يحدث، على سبيل المثال، أن تقييد الوصول إلى Penny حدث بعد ظهور هذا المنشور، إذا لم تكن الأحداث مرتبطة بالسبب والنتيجة. في الواقع، هذا مثال على الحالات التي يكون فيها الاتساق السببي مطلوبًا من أجل أداء وظيفة عمل (في هذه الحالة).
في الواقع، هذه خصائص غير تافهة لقاعدة البيانات - عدد قليل جدًا من الأشخاص يدعمونها. دعنا ننتقل إلى النماذج.
نماذج الاتساق
ما هو بالضبط نموذج الاتساق في قواعد البيانات؟ هذه بعض الضمانات التي يقدمها النظام الموزع بشأن البيانات التي يمكن للعميل الحصول عليها وبأي تسلسل.
من حيث المبدأ، تتلخص جميع نماذج الاتساق في مدى تشابه النظام الموزع مع النظام الذي يعمل، على سبيل المثال، على عقدة واحدة على جهاز كمبيوتر محمول. وهذا هو مدى تشابه النظام الذي يعمل على آلاف "العقد" الموزعة جغرافيًا مع جهاز كمبيوتر محمول، حيث يتم تنفيذ جميع هذه الخصائص تلقائيًا من حيث المبدأ.
ولذلك، يتم تطبيق نماذج الاتساق فقط على الأنظمة الموزعة. جميع الأنظمة التي كانت موجودة سابقًا وتعمل بنفس المقياس الرأسي لم تواجه مثل هذه المشكلات. كانت هناك ذاكرة تخزين مؤقت واحدة، وكان يتم قراءة كل شيء منها دائمًا.
نموذج قوي
في الواقع، النموذج الأول قوي (أو خط القدرة الصاعد، كما يطلق عليه غالبًا). هذا نموذج اتساق يضمن أن كل تغيير، بمجرد التأكد من حدوثه، يكون مرئيًا لجميع مستخدمي النظام.
يؤدي هذا إلى إنشاء ترتيب عالمي لجميع الأحداث في قاعدة البيانات. هذه خاصية اتساق قوية جدًا، وهي مكلفة جدًا بشكل عام. ومع ذلك، فهو مدعوم بشكل جيد للغاية. إنها مكلفة للغاية وبطيئة - ونادرًا ما يتم استخدامها. وهذا ما يسمى القدرة على الارتفاع.
هناك خاصية أخرى أقوى مدعومة في Spanner - تسمى الاتساق الخارجي. سنتحدث عن ذلك بعد قليل.
سببي
التالي هو السببية، وهو بالضبط ما كنت أتحدث عنه. هناك العديد من المستويات الفرعية بين القوي والسببي التي لن أتحدث عنها، لكنها جميعها تتلخص في السببية. وهذا نموذج مهم لأنه الأقوى بين جميع النماذج، والأقوى تماسكا في حالة وجود شبكة أو أقسام.
السببية هي في الواقع حالة ترتبط فيها الأحداث بعلاقة السبب والنتيجة. في كثير من الأحيان يُنظر إليهم على أنهم اقرأ حقوقك من وجهة نظر العميل. إذا لاحظ العميل بعض القيم، فلن يتمكن من رؤية القيم التي كانت في الماضي. لقد بدأ بالفعل في رؤية قراءات البادئة. كل ذلك يأتي إلى نفس الشيء.
السببية كنموذج اتساق هي ترتيب جزئي للأحداث على الخادم، حيث تتم ملاحظة الأحداث من جميع العملاء بنفس التسلسل. في هذه الحالة، ليونارد وبيني.
في نهاية المطاف
النموذج الثالث هو الاتساق النهائي. هذا هو ما تدعمه جميع الأنظمة الموزعة تمامًا، وهو النموذج البسيط المنطقي على الإطلاق. وهذا يعني ما يلي: عندما يكون لدينا بعض التغييرات في البيانات، فإنها تصبح متسقة في مرحلة ما.
في مثل هذه اللحظة، لا تقول أي شيء، وإلا فإنها ستتحول إلى الاتساق الخارجي - ستكون قصة مختلفة تماما. ومع ذلك، هذا نموذج شائع جدًا، وهو الأكثر شيوعًا. افتراضيًا، يستخدم كافة مستخدمي الأنظمة الموزعة التناسق النهائي.
أريد أن أعطي بعض الأمثلة المقارنة:
ماذا تعني هذه الأسهم؟
- وقت الإستجابة. مع زيادة قوة الاتساق، تصبح أكبر لأسباب واضحة: تحتاج إلى إنشاء المزيد من السجلات، والحصول على تأكيد من جميع المضيفين والعقد المشاركة في المجموعة بأن البيانات موجودة بالفعل. وفقًا لذلك، فإن الاتساق النهائي لديه أسرع إجابة، لأنه هناك، كقاعدة عامة، يمكنك حفظه في الذاكرة وسيكون هذا كافيًا من حيث المبدأ.
- توفر. إذا فهمنا ذلك على أنه قدرة النظام على الاستجابة في حالة وجود فواصل في الشبكة أو أقسام أو نوع من الفشل، فإن التسامح مع الخطأ يزداد مع انخفاض نموذج الاتساق، لأنه يكفي بالنسبة لنا أن يعيش مضيف واحد وفي نفس الوقت الوقت ينتج بعض البيانات. لا يضمن الاتساق النهائي أي شيء يتعلق بالبيانات على الإطلاق - يمكن أن يكون أي شيء.
- الشذوذ. وفي الوقت نفسه، بالطبع، يزداد عدد الحالات الشاذة. في حالة الاتساق القوي لا ينبغي أن تكون موجودة على الإطلاق، ولكن في حالة الاتساق النهائي يمكن أن تكون أي شيء. السؤال الذي يطرح نفسه: لماذا يختار الناس الاتساق النهائي إذا كان يحتوي على حالات شاذة؟ الجواب هو أن نماذج الاتساق النهائي قابلة للتطبيق وتوجد حالات شاذة، على سبيل المثال، في فترة زمنية قصيرة؛ من الممكن استخدام المعالج لقراءة البيانات المتسقة وقراءتها بشكل أو بآخر؛ غالبًا ما يكون من الممكن استخدام نماذج اتساق قوية. من الناحية العملية، ينجح هذا الأمر، وغالبًا ما يكون عدد الحالات الشاذة محدودًا بمرور الوقت.
نظرية CAP
عندما ترى الكلمات الاتساق والتوافر – ما الذي يتبادر إلى ذهنك؟ هذا صحيح - نظرية CAP! الآن أريد تبديد الأسطورة... لست أنا، بل مارتن كليبمان، الذي كتب مقالًا رائعًا، كتابًا رائعًا.
نظرية CAP هي مبدأ تمت صياغته في العقد الأول من القرن الحادي والعشرين وهو أن الاتساق والتوافر والأقسام: خذ أي اثنين، ولا يمكنك اختيار ثلاثة. لقد كان مبدأ معينًا. وقد تم إثباتها كنظرية بعد سنوات قليلة من قبل جيلبرت ولينش. ثم بدأ استخدامه كشعار - بدأ تقسيم الأنظمة إلى CA و CP و AP وما إلى ذلك.
تم إثبات هذه النظرية فعليًا في الحالات التالية... أولاً، لم يتم اعتبار التوفر كقيمة مستمرة من صفر إلى مئات (0 - النظام "ميت"، 100 - يستجيب بسرعة؛ لقد اعتدنا على اعتباره بهذه الطريقة) ، ولكن كخاصية للخوارزمية، والتي تضمن أنها تقوم بإرجاع البيانات لجميع عمليات التنفيذ.
ليس هناك كلمة عن وقت الاستجابة على الإطلاق! هناك خوارزمية تقوم بإرجاع البيانات بعد 100 عام - وهي خوارزمية رائعة للغاية متاحة، وهي جزء من نظرية CAP.
ثانياً: تم إثبات نظرية التغيرات في قيم نفس المفتاح، على الرغم من أن هذه التغيرات قابلة للتغيير. هذا يعني أنه في الواقع لا يتم استخدامها عمليا، لأن النماذج مختلفة الاتساق النهائي، الاتساق القوي (ربما).
لماذا كل هذا؟ علاوة على ذلك، فإن نظرية CAP بالشكل الذي تم إثباتها فيه غير قابلة للتطبيق عمليا ونادرا ما يتم استخدامها. في الشكل النظري، فإنه يحد بطريقة أو بأخرى من كل شيء. لقد اتضح أن هناك مبدأ معينًا صحيحًا بشكل بديهي، ولكن بشكل عام لم يتم إثباته.
الاتساق السببي هو النموذج الأقوى
ما يحدث الآن هو أنه يمكنك الحصول على الأشياء الثلاثة: الاتساق والتوافر باستخدام الأقسام. على وجه الخصوص، يعد الاتساق السببي أقوى نموذج اتساق، والذي لا يزال يعمل في حالة وجود أقسام (فواصل في الشبكة). ولهذا السبب فهو ذو أهمية كبيرة، ولهذا السبب تناولناه.
أولاً، فهو يبسط عمل مطوري التطبيقات. على وجه الخصوص، وجود دعم كبير من الخادم: عندما يتم ضمان وصول جميع السجلات التي تحدث داخل عميل واحد بنفس التسلسل إلى عميل آخر. ثانيا، فإنه يقاوم الأقسام.
مطبخ MongoDB الداخلي
تذكر أنه الغداء، ننتقل إلى المطبخ. سأخبرك عن نموذج النظام، أي ما هو MongoDB لأولئك الذين يسمعون عن قاعدة البيانات هذه لأول مرة.
MongoDB (المشار إليه فيما يلي باسم "MongoDB") هو نظام موزع يدعم القياس الأفقي، أي التجزئة؛ وداخل كل جزء يدعم أيضًا تكرار البيانات، أي النسخ المتماثل.
تؤدي المشاركة في MongoDB (وليست قاعدة بيانات علائقية) إلى تحقيق موازنة تلقائية، أي أن كل مجموعة من المستندات (أو "جدول" من حيث البيانات العلائقية) مقسمة إلى أجزاء، ويقوم الخادم تلقائيًا بنقلها بين الأجزاء.
جهاز توجيه الاستعلام، الذي يوزع الطلبات للعميل، هو عميل يعمل من خلاله. إنه يعرف بالفعل أين وما هي البيانات الموجودة ويوجه جميع الطلبات إلى الجزء الصحيح.
نقطة أخرى مهمة: MongoDB هو سيد واحد. يوجد ملف أساسي واحد - يمكنه أخذ السجلات التي تدعم المفاتيح التي يحتوي عليها. لا يمكنك القيام بالكتابة متعددة الماجستير.
لقد أصدرنا الإصدار 4.2 - ظهرت أشياء جديدة مثيرة للاهتمام هناك. على وجه الخصوص، قاموا بإدراج Lucene - البحث - أي Java القابل للتنفيذ مباشرة في Mongo، وهناك أصبح من الممكن إجراء عمليات بحث من خلال Lucene، كما هو الحال في Elastica.
وقد صنعوا منتجًا جديدًا - الرسوم البيانية، وهو متاح أيضًا على Atlas (سحابة Mongo الخاصة). لديهم طبقة مجانية - يمكنك اللعب بها. لقد أحببت الرسوم البيانية حقًا - تصور البيانات، بديهي جدًا.
المكونات الاتساق السببي
لقد أحصيت حوالي 230 مقالاً تم نشرها حول هذا الموضوع - بقلم ليزلي لامبرت. والآن من ذاكرتي سأنقل لكم بعض أجزاء هذه المواد.
بدأ كل شيء بمقالة كتبها ليزلي لامبرت في السبعينيات. كما ترون، لا تزال بعض الأبحاث حول هذا الموضوع مستمرة. الآن أصبح الاتساق السببي موضع اهتمام فيما يتعلق بتطوير الأنظمة الموزعة.
القيود
ما هي القيود هناك؟ هذه في الواقع إحدى النقاط الرئيسية، لأن القيود التي يفرضها نظام الإنتاج تختلف تمامًا عن القيود الموجودة في المقالات الأكاديمية. غالبًا ما تكون مصطنعة تمامًا.
- أولا، "MongoDB" هو سيد واحد، كما قلت بالفعل (وهذا يبسط إلى حد كبير).
- نعتقد أن النظام يجب أن يدعم حوالي 10 آلاف قطعة. لا يمكننا اتخاذ أي قرارات معمارية من شأنها أن تحد بشكل صريح من هذه القيمة.
- لدينا سحابة، ولكننا نفترض أنه لا يزال يتعين على الشخص أن يحظى بالفرصة عندما يقوم بتنزيل البرنامج الثنائي، وتشغيله على جهاز الكمبيوتر المحمول الخاص به، وكل شيء يعمل بشكل رائع.
- نحن نفترض شيئًا نادرًا ما تفترضه الأبحاث: يمكن للعملاء الخارجيين أن يفعلوا ما يريدون. MongoDB مفتوح المصدر. وبناء على ذلك، يمكن أن يكون العملاء أذكياء وغاضبين للغاية - فقد يرغبون في كسر كل شيء. نحن نتكهن بأن الفيلور البيزنطي قد ينشأ.
- بالنسبة للعملاء الخارجيين الموجودين خارج المحيط، هناك قيد مهم: إذا تم تعطيل هذه الميزة، فلا ينبغي ملاحظة أي تدهور في الأداء.
- هناك نقطة أخرى مناهضة للأكاديمية بشكل عام: توافق الإصدارات السابقة والإصدارات المستقبلية. يجب أن تدعم برامج التشغيل القديمة التحديثات الجديدة، ويجب أن تدعم قاعدة البيانات برامج التشغيل القديمة.
بشكل عام، كل هذا يفرض قيودا.
مكونات الاتساق السببي
سأتحدث الآن عن بعض المكونات. إذا أخذنا في الاعتبار الاتساق السببي بشكل عام، فيمكننا اختيار الكتل. اخترنا من بين الأعمال التي تنتمي إلى كتلة معينة: تتبع التبعية، واختيار الساعات، وكيف يمكن مزامنة هذه الساعات مع بعضها البعض، وكيف نضمن الأمان - وهذا مخطط تقريبي لما سأتحدث عنه:
تتبع التبعية الكاملة
لماذا هو مطلوب؟ لذلك، عند نسخ البيانات، يحتوي كل سجل وكل تغيير في البيانات على معلومات حول التغييرات التي يعتمد عليها. التغيير الأول والساذج هو عندما تحتوي كل رسالة تحتوي على سجل على معلومات حول الرسائل السابقة:
في هذا المثال، الرقم الموجود بين قوسين متعرجين هو أرقام السجلات. في بعض الأحيان يتم نقل هذه السجلات ذات القيم بالكامل، وأحيانًا يتم نقل بعض الإصدارات. خلاصة القول هي أن كل تغيير يحتوي على معلومات حول التغيير السابق (من الواضح أنه يحمل كل هذا في حد ذاته).
لماذا قررنا عدم استخدام هذا النهج (التتبع الكامل)؟ من الواضح أن هذا النهج غير عملي: أي تغيير في شبكة اجتماعية يعتمد على جميع التغييرات السابقة على تلك الشبكة الاجتماعية، ونقل، على سبيل المثال، Facebook أو VKontakte في كل تحديث. ومع ذلك، هناك الكثير من الأبحاث حول تتبع التبعية الكاملة، وهي شبكات ما قبل التواصل الاجتماعي، وهي تعمل بالفعل في بعض المواقف.
تتبع التبعية الصريحة
القادم هو أكثر محدودية. يتم أيضًا أخذ نقل المعلومات هنا بعين الاعتبار، ولكن فقط تلك التي تعتمد بشكل واضح. ما يعتمد على ما، كقاعدة عامة، يحدده التطبيق. عند نسخ البيانات، يقوم الاستعلام بإرجاع الاستجابات فقط عند استيفاء التبعيات السابقة، أي عند عرضها. هذا هو جوهر كيفية عمل الاتساق السببي.
وترى أن السجل 5 يعتمد على السجلات 1، 2، 3، 4 - وبالتالي، تنتظر قبل أن يتمكن العميل من الوصول إلى التغييرات التي تم إجراؤها بواسطة قرار الوصول الخاص بـ Penny، عندما تكون جميع التغييرات السابقة قد مرت بالفعل عبر قاعدة البيانات.
وهذا لا يناسبنا أيضًا، لأنه لا يزال هناك الكثير من المعلومات، وسيؤدي إلى إبطاء الأمور. وهناك نهج آخر..
ساعة لامبورت
إنهم قديمون جدًا. تعني ساعة Lamport أن هذه التبعيات مدمجة في دالة عددية تسمى Lamport Clock.
الدالة العددية هي بعض الأرقام المجردة. وغالبا ما يطلق عليه الوقت المنطقي. مع كل حدث، يزيد هذا العداد. يقوم العداد المعروف حاليًا للعملية بإرسال كل رسالة. من الواضح أن العمليات يمكن أن تكون غير متزامنة، ويمكن أن يكون لها أوقات مختلفة تمامًا. ومع ذلك، يقوم النظام بطريقة أو بأخرى بموازنة الساعة مع مثل هذه الرسائل. ما يحدث في هذه الحالة؟
لقد قمت بتقسيم هذه القطعة الكبيرة إلى قسمين لتوضيح الأمر: يمكن للأصدقاء العيش في عقدة واحدة، والتي تحتوي على جزء من المجموعة، ويمكن أن يعيش الخلاصة في عقدة أخرى، والتي تحتوي على جزء من هذه المجموعة. هل من الواضح كيف يمكنهم الخروج عن الخط؟ سيقول الخلاصة الأولى: "مكرر"، ثم الأصدقاء. إذا لم يوفر النظام نوعًا من الضمان بأن الخلاصة لن تظهر حتى يتم تسليم تبعيات الأصدقاء في مجموعة الأصدقاء أيضًا، فسنواجه الموقف الذي ذكرته بالضبط.
ترى كيف يزيد وقت العداد في الخلاصة بشكل منطقي:
لذا فإن الخاصية الرئيسية لساعة لامبورت والاتساق السببي (الموضحة من خلال ساعة لامبورت) هي كما يلي: إذا كان لدينا الحدثان A وB، وكان الحدث B يعتمد على الحدث A*، فإنه يتبع ذلك أن الزمن المنطقي للحدث A أقل من LogicalTime من الحدث B.
* في بعض الأحيان يقولون أيضًا أن A حدث قبل B، أي أن A حدث قبل B - وهذه علاقة معينة تنظم جزئيًا مجموعة الأحداث الكاملة التي حدثت بشكل عام.
والعكس غير صحيح. يعد هذا في الواقع أحد العيوب الرئيسية لساعة Lamport - النظام الجزئي. هناك مفهوم حول الأحداث المتزامنة، أي الأحداث التي لم يحدث فيها (أ حدث قبل ب) ولا (أ حدث قبل ب). ومن الأمثلة على ذلك إضافة ليونارد الموازية لشخص آخر كصديق (وليس حتى ليونارد، ولكن شيلدون، على سبيل المثال).
هذه هي الخاصية التي يتم استخدامها غالبًا عند العمل مع ساعات لامبورت: فهم ينظرون على وجه التحديد إلى الوظيفة ومن هذا يستنتجون أنه ربما تكون هذه الأحداث تابعة. لأن هناك طريقة واحدة صحيحة: إذا كان LogicalTime A أقل من LogicalTime B، فلا يمكن أن يحدث B قبل A؛ وإذا كان أكثر، فربما.
ساعة المتجهات
التطور المنطقي لساعة لامبورت هو ساعة المتجهات. وهي تختلف في أن كل عقدة موجودة هنا تحتوي على ساعتها المنفصلة الخاصة بها، ويتم إرسالها كمتجه.
في هذه الحالة، ترى أن الفهرس الصفري للمتجه هو المسؤول عن التغذية، والفهرس الأول للمتجه هو المسؤول عن الأصدقاء (كل من هذه العقد). والآن سيزدادون: يزداد مؤشر "الخلاصة" الصفري عند الكتابة – 1، 2، 3:
لماذا تعتبر ساعة Vector أفضل؟ لأنها تسمح لك بمعرفة الأحداث المتزامنة ومتى تحدث على عقد مختلفة. هذا مهم جدًا لنظام المشاركة مثل MongoDB. لكننا لم نختر هذا، رغم أنه شيء رائع، ويعمل بشكل رائع، وربما يناسبنا...
إذا كان لدينا 10 آلاف شظايا، فلا يمكننا نقل 10 آلاف مكون، حتى لو قمنا بضغطها أو التوصل إلى شيء آخر - ستظل الحمولة أصغر بعدة مرات من حجم هذا المتجه بأكمله. ولذلك، ونحن نصر على قلوبنا وأسناننا، تخلينا عن هذا النهج وانتقلنا إلى نهج آخر.
مفتاح البراغي ترو تايم. ساعة ذرية
قلت أنه ستكون هناك قصة عن سبانر. هذا شيء رائع، خرج مباشرة من القرن الحادي والعشرين: الساعات الذرية، ومزامنة نظام تحديد المواقع العالمي (GPS).
ما هي الفكرة؟ "Spanner" هو نظام Google الذي أصبح متاحًا مؤخرًا للأشخاص (لقد أضافوا SQL إليه). كل معاملة هناك لها بعض الطابع الزمني. بما أن الوقت متزامن*، يمكن تخصيص وقت محدد لكل حدث - الساعات الذرية لها وقت انتظار، وبعد ذلك يتم ضمان "حدوث" وقت مختلف.
وبالتالي، بمجرد الكتابة إلى قاعدة البيانات والانتظار لفترة من الوقت، يتم ضمان إمكانية تسلسل الحدث تلقائيًا. لديهم أقوى نموذج اتساق يمكن تخيله من حيث المبدأ - إنه الاتساق الخارجي.
* هذه هي المشكلة الرئيسية في ساعات لامبارت - فهي غير متزامنة أبدًا على الأنظمة الموزعة. من الممكن أن تتباعد، حتى مع NTP، فإنها لا تزال لا تعمل بشكل جيد. يحتوي "Spanner" على ساعة ذرية ويبدو أن المزامنة تستغرق ميكروثانية.
لماذا لم نختار؟ نحن لا نفترض أن مستخدمينا لديهم ساعة ذرية مدمجة. عندما تظهر، وهي مدمجة في كل كمبيوتر محمول، سيكون هناك نوع من مزامنة نظام تحديد المواقع العالمي (GPS) الرائعة للغاية - إذن نعم... ولكن في الوقت الحالي، أفضل ما هو ممكن هو Amazon، Base Stations - للمتعصبين... لذلك استخدمنا ساعات أخرى .
الساعة الهجينة
هذا هو في الواقع ما يميز MongoDB عند ضمان الاتساق السببي. كيف هم الهجين؟ الهجين هو قيمة عددية، ولكن لديه مكونين:
- الأول هو عصر يونكس (كم ثانية مرت منذ "بداية عالم الكمبيوتر").
- والثاني هو بعض الزيادة، وهو أيضًا عدد صحيح غير موقع 32 بت.
هذا كل شيء، في الواقع. هناك هذا النهج: الجزء المسؤول عن الوقت متزامن مع الساعة طوال الوقت؛ في كل مرة يحدث فيها تحديث، تتم مزامنة هذا الجزء مع الساعة ويتبين أن الوقت دائمًا أكثر أو أقل صحة، وتسمح لك الزيادة بالتمييز بين الأحداث التي حدثت في نفس النقطة الزمنية.
لماذا يعد هذا مهمًا لـ MongoDB؟ لأنه يسمح لك بعمل نوع من المطاعم الاحتياطية في وقت معين، أي أنه يتم فهرسة الحدث حسب الوقت. وهذا مهم عندما تكون هناك حاجة إلى أحداث معينة؛ بالنسبة لقاعدة البيانات، الأحداث هي التغييرات في قاعدة البيانات التي حدثت على فترات زمنية معينة.
سأخبرك بالسبب الأهم لك وحدك (من فضلك لا تخبر أحدا)! لقد فعلنا ذلك لأن هذا هو الشكل الذي تبدو عليه البيانات المنظمة والمفهرسة في MongoDB OpLog. OpLog عبارة عن بنية بيانات تحتوي على جميع التغييرات في قاعدة البيانات تمامًا: فهي تنتقل أولاً إلى OpLog، ثم يتم تطبيقها على التخزين نفسه في حالة وجود تاريخ أو جزء منسوخ.
وكان هذا هو السبب الرئيسي. ومع ذلك، هناك أيضًا متطلبات عملية لتطوير قاعدة بيانات، مما يعني أنها يجب أن تكون بسيطة - القليل من التعليمات البرمجية، وأقل عدد ممكن من الأشياء المعطلة التي تحتاج إلى إعادة كتابتها واختبارها. لقد ساعدت حقيقة أن مدوناتنا الإلكترونية مفهرسة بواسطة ساعات هجينة كثيرًا وسمحت لنا باتخاذ القرار الصحيح. لقد أتت ثمارها حقًا وعملت بطريقة سحرية على النموذج الأولي الأول. كان باردا جدا!
مزامنة الساعة
هناك العديد من طرق المزامنة الموضحة في الأدبيات العلمية. أنا أتحدث عن المزامنة عندما يكون لدينا شظيتين مختلفتين. إذا كانت هناك مجموعة نسخ متماثلة واحدة، ليست هناك حاجة لأية مزامنة: هذه "نسخة رئيسية واحدة"؛ لدينا OpLog، حيث تقع جميع التغييرات - في هذه الحالة، يتم ترتيب كل شيء بالتسلسل بالفعل في "Oplog" نفسه. ولكن إذا كان لدينا شظيتين مختلفتين، فإن مزامنة الوقت مهمة هنا. هذا هو المكان الذي ساعدت فيه ساعة المتجهات أكثر! ولكن ليس لدينا لهم.
والثاني مناسب - هذا هو "نبضات القلب". ومن الممكن تبادل بعض الإشارات التي تحدث في كل وحدة زمنية. لكن نبضات القلب بطيئة للغاية، ولا يمكننا توفير زمن الاستجابة لعملائنا.
الوقت الحقيقي، بالطبع، شيء رائع. ولكن، مرة أخرى، ربما يكون هذا هو المستقبل... على الرغم من أنه يمكن القيام بذلك بالفعل في نظام أطلس، إلا أن هناك بالفعل أدوات مزامنة سريعة للوقت من نوع "أمازون". لكنها لن تكون متاحة للجميع.
النميمة هي عندما تشمل جميع الرسائل الوقت. هذا هو تقريبا ما نستخدمه. كل رسالة بين العقد، وبرنامج التشغيل، وجهاز توجيه عقدة البيانات، وكل شيء على الإطلاق بالنسبة لـ MongoDB هو نوع من العناصر، وهو مكون قاعدة بيانات يحتوي على ساعة تعمل. لديهم معنى الوقت الهجين في كل مكان، وينتقل. 64 بت؟ هذا يسمح، وهذا ممكن.
كيف يعمل كل ذلك معًا؟
أنا هنا ألقي نظرة على مجموعة نسخ متماثلة واحدة لتسهيل الأمر قليلاً. هناك الابتدائي والثانوي. يقوم الثانوي بالنسخ المتماثل ولا تتم مزامنته دائمًا بشكل كامل مع الأساسي.
يحدث الإدراج في "Primery" بقيمة زمنية معينة. يؤدي هذا الإدخال إلى زيادة العدد الداخلي بمقدار 11، إذا كان هذا هو الحد الأقصى. أو سيتم التحقق من قيم الساعة ومزامنتها مع الساعة إذا كانت قيم الساعة أكبر. هذا يسمح لك بالتنظيم حسب الوقت.
بعد أن يقوم بالتسجيل، تحدث لحظة مهمة. الساعة موجودة في "MongoDB" ولا تتم زيادتها إلا في حالة الكتابة إلى "Oplog". هذا هو الحدث الذي يغير حالة النظام. في جميع المقالات الكلاسيكية تمامًا، يتم اعتبار الحدث هو عندما تصل الرسالة إلى العقدة: لقد وصلت الرسالة، مما يعني أن النظام قد غيّر حالته.
ويرجع ذلك إلى حقيقة أنه أثناء البحث ليس من الواضح تمامًا كيف سيتم تفسير هذه الرسالة. نحن نعلم يقينًا أنه إذا لم ينعكس في "Oplog"، فلن يتم تفسيره بأي شكل من الأشكال، والتغيير في حالة النظام ليس سوى إدخال في "Oplog". وهذا يبسط لنا كل شيء: النموذج يبسطه، ويسمح لنا بتنظيمه ضمن مجموعة متماثلة واحدة، والعديد من الأشياء المفيدة الأخرى.
يتم إرجاع القيمة المكتوبة بالفعل إلى "Oplog" - نعلم أن "Oplog" يحتوي بالفعل على هذه القيمة، ووقتها هو 12. الآن، على سبيل المثال، تبدأ القراءة من عقدة أخرى (ثانوية)، وترسل afterClusterTime في الرسالة. يقول: "أحتاج إلى كل ما حدث بعد الساعة 12 أو خلال الساعة الثانية عشرة على الأقل" (انظر الصورة أعلاه).
وهذا ما يسمى السببية متسقة (CAT). هناك مفهوم من الناحية النظرية مفاده أن هذه شريحة من الوقت، وهي متسقة في حد ذاتها. في هذه الحالة، يمكننا القول أن هذه هي حالة النظام التي تمت ملاحظتها في الوقت 12.
الآن لا يوجد شيء هنا حتى الآن، لأن هذا النوع يحاكي الموقف عندما تحتاج إلى البيانات الثانوية لنسخ البيانات من البيانات الأساسية. إنه ينتظر... والآن وصلت البيانات - يقوم بإرجاع هذه القيم مرة أخرى.
هذا إلى حد كبير كيف يعمل كل شيء. بالكاد.
ماذا يعني "تقريبا"؟ لنفترض أن هناك شخصًا قرأ وفهم كيف يعمل كل هذا. أدركت أنه في كل مرة يحدث فيها ClusterTime، يقوم بتحديث الساعة المنطقية الداخلية، ثم يزيد الإدخال التالي بمقدار واحد. تستغرق هذه الوظيفة 20 سطرًا. لنفترض أن هذا الشخص يرسل أكبر رقم 64 بت، ناقص واحد.
لماذا "ناقص واحد"؟ لأنه سيتم استبدال الساعة الداخلية بهذه القيمة (من الواضح أن هذا أكبر ما يمكن وأكبر من الوقت الحالي)، فسيحدث إدخال في "Oplog"، وستتم زيادة الساعة بوحدة أخرى - وسيكون هناك بالفعل تكون القيمة القصوى (توجد ببساطة جميع الوحدات، ولا يوجد مكان آخر للذهاب إليه)، وغير مقدسة).
من الواضح أنه بعد ذلك يصبح النظام غير قابل للوصول على الإطلاق لأي شيء. لا يمكن تفريغها وتنظيفها إلا - وهو عمل يدوي كثير. التوفر الكامل:
علاوة على ذلك، إذا تم تكرار ذلك في مكان آخر، فستسقط المجموعة بأكملها ببساطة. وضع غير مقبول على الإطلاق ويمكن لأي شخص تنظيمه بسرعة وسهولة! لذلك اعتبرنا هذه اللحظة من أهم اللحظات. كيفية منع ذلك؟
طريقتنا هي التوقيع علىclusterTime
هذه هي الطريقة التي يتم بها نقلها في الرسالة (قبل النص الأزرق). لكننا بدأنا أيضًا في إنشاء توقيع (نص أزرق):
يتم إنشاء التوقيع بواسطة مفتاح يتم تخزينه داخل قاعدة البيانات، داخل محيط آمن؛ يتم إنشاء وتحديث نفسه (لا يرى المستخدمون أي شيء عنه). يتم إنشاء تجزئة، ويتم توقيع كل رسالة عند إنشائها والتحقق من صحتها عند استلامها.
ربما يطرح السؤال في أذهان الناس: "إلى أي مدى يؤدي هذا إلى إبطاء الأمور؟" لقد أخبرتك أنه يجب أن يعمل بسرعة، خاصة في ظل عدم وجود هذه الميزة.
ماذا يعني استخدام الاتساق السببي في هذه الحالة؟ هذا لإظهار المعلمة afterClusterTime. بدون هذا، فإنه ببساطة سوف يمرر القيم على أي حال. النميمة، بدءًا من الإصدار 3.6، تعمل دائمًا.
إذا تركنا التوليد المستمر للتوقيعات، فسيؤدي ذلك إلى إبطاء النظام حتى في حالة عدم وجود ميزة لا تلبي مناهجنا ومتطلباتنا. إذا، مالذي فعلناه؟
افعل هذا بسرعه!
إنه أمر بسيط إلى حد ما، ولكن الحيلة مثيرة للاهتمام – سأشاركها، ربما سيكون شخص ما مهتمًا بها.
لدينا تجزئة تقوم بتخزين البيانات الموقعة. جميع البيانات تمر عبر ذاكرة التخزين المؤقت. لا تسجل ذاكرة التخزين المؤقت وقتًا محددًا، بل النطاق. عندما تصل بعض القيمة، نقوم بإنشاء نطاق، وإخفاء آخر 16 بت، ونوقع هذه القيمة:
ومن خلال تلقي مثل هذا التوقيع، نقوم بتسريع النظام (نسبيًا) 65 ألف مرة. إنه يعمل بشكل رائع: عندما أجرينا التجارب، انخفض الوقت فعليًا بمقدار 10 آلاف مرة عندما أجرينا تحديثًا تسلسليًا. ومن الواضح أنه عندما يكونون على خلاف، فإن هذا لا ينجح. ولكن في معظم الحالات العملية يعمل. أدى الجمع بين توقيع النطاق والتوقيع إلى حل مشكلة الأمان.
ماذا تعلمنا؟
الدروس التي تعلمناها من هذا:
- نحن بحاجة إلى قراءة المواد والقصص والمقالات، لأن لدينا الكثير من الأشياء المثيرة للاهتمام. عندما نعمل على بعض الميزات (خاصة الآن، عندما نقوم بالمعاملات، وما إلى ذلك)، نحتاج إلى القراءة والفهم. يستغرق الأمر وقتًا، لكنه في الواقع مفيد جدًا لأنه يوضح أين نحن. لا يبدو أننا توصلنا إلى أي شيء جديد، لقد أخذنا المكونات فقط.
بشكل عام، هناك اختلاف معين في التفكير عندما يكون هناك مؤتمر أكاديمي (سيجمون، على سبيل المثال) - يركز الجميع على الأفكار الجديدة. ما الجديد في خوارزميتنا؟ لا يوجد شيء جديد بشكل خاص هنا. لكن الحداثة تكمن في الطريقة التي مزجنا بها النهج الحالي معًا. لذلك، أول شيء هو قراءة الكلاسيكيات، بدءا من لامبارت.
- في الإنتاج، المتطلبات مختلفة تماما. أنا متأكد من أن الكثير منكم لا يواجه قواعد بيانات "كروية" في فراغ مجرد، بل يواجه أشياء عادية وحقيقية تعاني من مشاكل تتعلق بالتوفر وزمن الوصول والتسامح مع الأخطاء.
- آخر شيء هو أنه كان علينا أن ننظر إلى أفكار مختلفة ونجمع عدة مقالات مختلفة تمامًا في نهج واحد معًا. فكرة التوقيع، على سبيل المثال، جاءت بشكل عام من مقال تناول بروتوكول باكسوس، والذي بالنسبة للفاشلين غير البيزنطيين يقع داخل بروتوكول التفويض، وبالنسبة للبيزنطيين - خارج بروتوكول التفويض... بشكل عام، هذا هو بالضبط ما نحن عليه انتهى به الأمر.
لا يوجد شيء جديد على الإطلاق هنا! ولكن بمجرد أن نخلط كل ذلك معًا... إنه نفس القول بأن وصفة سلطة أوليفييه محض هراء، لأن البيض والمايونيز والخيار قد تم اختراعهم بالفعل... إنها نفس القصة تقريبًا.
سأنتهي من هذا. شكرًا لك!
الأسئلة
سؤال من الجمهور (المشار إليه فيما بعد بـ): - شكرا ميخائيل على التقرير! الموضوع عن الوقت مثير للاهتمام. أنت تستخدم النميمة. قالوا إن لكل شخص وقته الخاص، والجميع يعرف توقيته المحلي. كما أفهمها، لدينا سائق - يمكن أن يكون هناك العديد من العملاء الذين لديهم برامج تشغيل، ومخططو الاستعلامات أيضًا، والأجزاء أيضًا... وما الذي سيؤول إليه النظام إذا كان لدينا فجأة تناقض: يقرر شخص ما أنه من أجل دقيقة للأمام، شخص متأخر بدقيقة؟ أين سننتهي؟
طن متري: - سؤال عظيم حقا! أردت فقط أن أتحدث عن الشظايا. إذا فهمت السؤال بشكل صحيح، لدينا الوضع التالي: هناك قطعة 1 وقطعة 2، تحدث القراءة من هاتين القطعتين - لديهما تناقض، ولا يتفاعلان مع بعضهما البعض، لأن الوقت الذي يعرفانه مختلف، وخاصة الوقت الذي كانوا موجودين في oplogs.
لنفترض أن الجزء 1 قام بإنشاء مليون سجل، والجزء 2 لم يفعل شيئًا على الإطلاق، وجاء الطلب إلى قسمين. والأول يحتوي على afterClusterTime لأكثر من مليون. في مثل هذه الحالة، كما شرحت، لن تستجيب Shard 2 مطلقًا.
В: – أردت أن أعرف كيف يتم المزامنة واختيار وقت منطقي واحد؟
طن متري: - من السهل جدًا المزامنة. Shard، عندما يأتي إليه afterClusterTime ولا يجد وقتًا في "Oplog"، لا يبدأ أي موافقة. أي أنه يرفع وقته بيديه إلى هذه القيمة. وهذا يعني أنه لا يوجد لديه أحداث مطابقة لهذا الطلب. إنه يخلق هذا الحدث بشكل مصطنع، وبالتالي يصبح سببيًا متسقًا.
В: – وماذا لو جاءته بعد ذلك بعض الأحداث الأخرى التي ضاعت في مكان ما في الشبكة؟
طن متري: – تم تصميم Shard بحيث لن يعودوا مرة أخرى، لأنه سيد واحد. إذا قام بالتسجيل بالفعل، فلن يأتوا، لكنهم سيأتون لاحقًا. لا يمكن أن يحدث أن يعلق شيء ما في مكان ما، ثم لا يكتب، ثم تصل هذه الأحداث - وينكسر الاتساق السببي. عندما لا يكتب، يجب أن يأتيوا جميعًا بعد ذلك (سينتظرهم).
В: – لدي عدة أسئلة بخصوص قوائم الانتظار. يفترض الاتساق السببي وجود قائمة انتظار محددة من الإجراءات التي يجب تنفيذها. ماذا يحدث إذا اختفت إحدى طرودنا؟ هنا يأتي اليوم العاشر والحادي عشر... وقد اختفى اليوم الثاني عشر، والجميع ينتظر أن يتحقق. وفجأة ماتت سيارتنا، ولا نستطيع أن نفعل أي شيء. هل هناك حد أقصى لطول قائمة الانتظار التي تتراكم قبل تنفيذها؟ ما هو الفشل القاتل الذي يحدث عند فقدان أي دولة؟ علاوة على ذلك، إذا كتبنا أن هناك حالة سابقة ما، فهل يجب أن نبدأ منها بطريقة أو بأخرى؟ لكنهم لم يطردوه!
طن متري: - سؤال عظيم أيضا! ماذا نفعل؟ لدى MongoDB مفهوم كتابة النصاب وقراءة النصاب. في أي الحالات يمكن أن تضيع الرسالة؟ عندما لا يكون النصاب القانوني للكتابة أو عندما لا تكون القراءة نصابًا قانونيًا (قد يلتصق أيضًا نوع من البيانات المهملة).
وفيما يتعلق بالاتساق السببي، تم إجراء اختبار تجريبي كبير، وكانت نتيجته أنه في حالة عدم اكتمال النصاب الكتابي والقراءة، تحدث انتهاكات للاتساق السببي. بالضبط ما تقوله!
نصيحتنا: استخدم قراءة النصاب القانوني على الأقل عند استخدام الاتساق السببي. في هذه الحالة، لن يتم فقدان أي شيء، حتى لو تم فقدان سجل النصاب... هذا موقف متعامد: إذا كان المستخدم لا يريد فقدان البيانات، فهو بحاجة إلى استخدام سجل النصاب. الاتساق السببي لا يضمن المتانة. يتم ضمان المتانة من خلال النسخ المتماثل والآلات المرتبطة بالنسخ المتماثل.
В: - عندما نقوم بإنشاء مثيل يقوم بالتقسيم لنا (ليس السيد، ولكن العبد، على التوالي)، فإنه يعتمد على وقت يونكس لجهازه الخاص أو على وقت "السيد"؛ هل تتم المزامنة لأول مرة أم بشكل دوري؟
طن متري: - سأوضح الآن. Shard (أي قسم أفقي) - يوجد دائمًا قسم أساسي هناك. ويمكن أن تحتوي القطعة على "سيد" ويمكن أن تكون هناك نسخ متماثلة. لكن الجزء يدعم التسجيل دائمًا، لأنه يجب أن يدعم بعض النطاقات (الجزء لديه أساسي).
В: - إذن كل شيء يعتمد بشكل كامل على "السيد"؟ هل يستخدم الوقت الرئيسي دائمًا؟
طن متري: - نعم. يمكنك أن تقول مجازيًا: الساعة تدق عند حدوث دخول إلى "السيد" إلى "Oplog".
В: – لدينا عميل يتصل ولا يحتاج إلى معرفة أي شيء عن الوقت؟
طن متري: - لا تحتاج إلى معرفة أي شيء على الإطلاق! إذا تحدثنا عن كيفية عمل ذلك على العميل: عندما يريد العميل استخدام الاتساق السببي، فإنه يحتاج إلى فتح جلسة. الآن كل شيء موجود: المعاملات في الجلسة، واسترداد الحقوق... الجلسة هي ترتيب الأحداث المنطقية التي تحدث مع العميل.
إذا فتح هذه الجلسة وقال هناك إنه يريد الاتساق السببي (إذا كانت الجلسة تدعم الاتساق السببي افتراضيًا)، فسيعمل كل شيء تلقائيًا. يتذكر السائق هذه المرة ويزيدها عندما يتلقى رسالة جديدة. يتذكر الاستجابة التي أعادها الرد السابق من الخادم الذي أعاد البيانات. سيحتوي الطلب التالي على afterCluster("الوقت أكبر من هذا").
لا يحتاج العميل إلى معرفة أي شيء على الإطلاق! وهذا غير واضح تماما بالنسبة له. إذا استخدم الأشخاص هذه الميزات، فماذا يمكنهم أن يفعلوا؟ أولاً، يمكنك قراءة المرتبات الثانوية بأمان: يمكنك الكتابة إلى المجلد الأساسي والقراءة من المرتبات الثانوية المنسوخة جغرافيًا والتأكد من أنها تعمل. في الوقت نفسه، يمكن حتى نقل الجلسات التي تم تسجيلها على "الابتدائية" إلى "الثانوية"، أي لا يمكنك استخدام جلسة واحدة، ولكن عدة جلسات.
В: - طبقة جديدة من علوم الحساب - أنواع بيانات CRDT (أنواع البيانات المكررة الخالية من التعارضات) - ترتبط ارتباطًا وثيقًا بموضوع الاتساق النهائي. هل فكرت في دمج هذه الأنواع من البيانات في قاعدة البيانات وماذا يمكنك أن تقول عنها؟
طن متري: - سؤال جيد! يعد CRDT منطقيًا لتعارضات الكتابة: في MongoDB، سيد واحد.
В: - لدي سؤال من المطورين. في العالم الحقيقي، هناك مثل هذه المواقف اليسوعية عندما يحدث الفشل البيزنطي، ويبدأ الأشرار داخل المحيط المحمي في اختراق البروتوكول، وإرسال الطرود الحرفية بطريقة خاصة؟
طن متري: - الأشرار داخل المحيط يشبهون حصان طروادة! يمكن للأشخاص الأشرار داخل المحيط أن يفعلوا الكثير من الأشياء السيئة.
В: - من الواضح أن ترك، بشكل تقريبي، ثغرة في الخادم يمكنك من خلالها دفع حديقة حيوانات الأفيال وانهيار المجموعة بأكملها إلى الأبد... سيستغرق الاسترداد اليدوي وقتًا طويلاً... وهذا، بعبارة ملطفة، هو خطأ. من ناحية أخرى، فمن المثير للاهتمام: في الحياة الحقيقية، في الممارسة العملية، هناك مواقف تحدث فيها هجمات داخلية مماثلة بشكل طبيعي؟
طن متري: – نظرًا لأنني نادرًا ما أواجه خروقات أمنية في الحياة الواقعية، فلا أستطيع أن أقول ما إذا كانت قد حدثت أم لا. لكن إذا تحدثنا عن فلسفة التنمية، فإننا نفكر على النحو التالي: لدينا محيط يوفر للأشخاص الذين يقومون بالأمن - هذه قلعة، جدار؛ وداخل المحيط يمكنك أن تفعل ما تريد. من الواضح أن هناك مستخدمين لديهم القدرة على العرض فقط، وهناك مستخدمون لديهم القدرة على مسح الدليل.
اعتمادًا على الحقوق، يمكن أن يكون الضرر الذي يمكن أن يحدثه المستخدمون هو الفأرة، أو يمكن أن يكون فيلًا. من الواضح أن المستخدم الذي يتمتع بالحقوق الكاملة يمكنه فعل أي شيء على الإطلاق. يمكن للمستخدم ذو الحقوق المحدودة أن يتسبب في ضرر أقل بكثير. على وجه الخصوص، لا يمكن كسر النظام.
В: - في المحيط المحمي، حاول شخص ما إنشاء بروتوكولات غير متوقعة للخادم من أجل تدمير الخادم بالكامل، وإذا كنت محظوظًا، المجموعة بأكملها... هل حصلت على هذا "الجيد" من قبل؟
طن متري: "لم أسمع قط عن مثل هذه الأشياء." حقيقة أنه يمكنك تعطل الخادم بهذه الطريقة ليست سرا. فشل في الداخل، كونه من البروتوكول، كونه مستخدمًا معتمدًا يمكنه كتابة شيء كهذا في الرسالة... في الواقع، هذا مستحيل، لأنه سيتم التحقق منه. من الممكن تعطيل هذه المصادقة للمستخدمين الذين لا يريدونها - فهذه مشكلتهم؛ لقد دمروا الجدران بأنفسهم، تقريبًا، ويمكنك دفع فيل إلى هناك، والذي سوف يدوس... ولكن بشكل عام، يمكنك ارتداء ملابس مصلح، تعال واسحبه!
В: - شكرا على التقرير. سيرجي (ياندكس). يوجد ثابت في Mong يحد من عدد الأعضاء المصوتين في مجموعة النسخ المتماثلة، وهذا الثابت هو 7 (سبعة). لماذا هذا ثابت؟ لماذا لا يعد هذا نوعًا من المعلمة؟
طن متري: – لدينا مجموعات متماثلة تحتوي على 40 عقدة. هناك دائما أغلبية. لا أعرف أي إصدار...
В: - في مجموعة النسخ المتماثلة، يمكنك تشغيل الأعضاء الذين لا يحق لهم التصويت، ولكن هناك 7 أعضاء مصوتين كحد أقصى. كيف يمكننا النجاة من إيقاف التشغيل في هذه الحالة إذا كانت مجموعة النسخ المتماثلة الخاصة بنا منتشرة عبر 3 مراكز بيانات؟ يمكن أن يتم إيقاف تشغيل أحد مراكز البيانات بسهولة، ويمكن أن يسقط جهاز آخر.
طن متري: - وهذا بالفعل خارج نطاق التقرير قليلاً. هذا سؤال عام. ربما يمكنني أن أخبرك بذلك لاحقًا.
بعض الاعلانات 🙂
أشكركم على البقاء معنا. هل تحب مقالاتنا؟ تريد أن ترى المزيد من المحتوى المثير للاهتمام؟ ادعمنا عن طريق تقديم طلب أو التوصية للأصدقاء ، , تناظرية فريدة من خوادم المستوى المبتدئ ، اخترعناها من أجلك: (متوفر مع RAID1 و RAID10 ، حتى 24 مركزًا وحتى 40 جيجا بايت DDR4).
Dell R730xd أرخص مرتين في مركز بيانات Equinix Tier IV في أمستردام؟ هنا فقط في هولندا! Dell R420 - 2x E5-2430 2.2 جيجا هرتز 6C 128 جيجا بايت DDR3 2x960 جيجا بايت SSD 1 جيجا بايت في الثانية 100 تيرا بايت - من 99 دولارًا! أقرأ عن
المصدر: www.habr.com