HighLoad ++ ، Mikhail Tyulenev (MongoDB): الاتساق السببي: من النظرية إلى الممارسة

سيعقد مؤتمر HighLoad ++ التالي يومي 6 و 7 أبريل 2020 في سان بطرسبرغ.
التفاصيل والتذاكر هنا . HighLoad ++ سيبيريا 2019. قاعة "كراسنويارسك". 25 يونيو ، 12:00. الملخصات والعرض .



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

Mikhail Tyulenev (فيما يلي - MT): - سأتحدث عن الاتساق السببي - هذه ميزة عملنا عليها في MongoDB. أنا أعمل في مجموعة من الأنظمة الموزعة ، وقد قمنا بذلك منذ عامين تقريبًا.



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

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

الاتساق السببي. دعونا نحدد المفاهيم


بادئ ذي بدء ، أريد أن أوضح بشكل عام ماهية الاتساق السببي. هناك شخصان - ليونارد وبيني (سلسلة "نظرية الانفجار الكبير"):



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

في الواقع ، هذه خصائص غير تافهة تمامًا لقاعدة البيانات - عدد قليل جدًا من الأشخاص يدعمونها. دعنا ننتقل إلى النماذج.

نماذج الاتساق


ما هو نموذج الاتساق في قواعد البيانات بشكل عام؟ هذه هي بعض الضمانات التي يوفرها النظام الموزع فيما يتعلق بالبيانات والتسلسل الذي يمكن للعميل الحصول عليه.

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

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

نموذج قوي


في الواقع ، النموذج الأول قوي (أو خط القدرة على الارتفاع ، كما يطلق عليه غالبًا). هذا هو نموذج الاتساق الذي يضمن أن كل تغيير ، بمجرد استلام تأكيد حدوثه ، مرئي لجميع مستخدمي النظام.

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

هناك خاصية أخرى أقوى مدعومة في "Spanner" - تسمى التناسق الخارجي. سنتحدث عنه بعد ذلك بقليل.

السببي


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

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

في نهاية المطاف


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

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

أريد أن أعطي بعض الأمثلة المقارنة:



ماذا تعني هذه الأسهم؟

  • Latency. : , , , . Eventual Consistency , , , memory .
  • Availability. , partitions, - – , , - . Eventual Consistency – , .
  • Anomalies. , , . Strong Consistency , Eventual Consistency . : Eventual Consistency, ? , Eventual Consistency- , , , ; - ; . , .

CAP


عندما ترى الكلمات الاتساق والتوافر - ما الذي يتبادر إلى الذهن؟ حق - نظرية CAP! الآن أريد تبديد الأسطورة ... لست أنا - هناك مارتن كليبمان ، الذي كتب مقالة رائعة ، كتابًا رائعًا.



نظرية CAP هي مبدأ تمت صياغته في العقد الأول من القرن الحادي والعشرين وهو الاتساق والتوافر والأقسام: خذ أي اثنين ، ولا يمكنك اختيار ثلاثة. كان مبدأ معين. وقد ثبت أنها نظرية بعد ذلك ببضع سنوات بواسطة جيلبرت ولينش. ثم أصبحت تستخدم كمقولة - بدأ تقسيم الأنظمة إلى CA و CP و AP وما إلى ذلك.

لقد تم إثبات هذه النظرية بالفعل للأسباب التالية ... أولاً ، لم يتم اعتبار التوفر كقيمة مستمرة من صفر إلى مئات (0 - النظام "ميت" ، 100 - الإجابة بسرعة ؛ نحن معتادون على النظر فيه) ، ولكن كخاصية الخوارزمية ، مما يضمن أنه مع جميع عمليات التنفيذ الخاصة به ، فإنه يعيد البيانات.

لا توجد كلمة عن وقت الاستجابة! هناك خوارزمية تقوم بإرجاع البيانات بعد 100 عام - خوارزمية متاحة تمامًا ، وهي جزء من نظرية CAP.
ثانيًا: تم إثبات نظرية للتغيرات في قيم المفتاح نفسه ، على الرغم من حقيقة أن هذه التغييرات هي خط يمكن تغيير حجمه. هذا يعني أنه في الواقع لا يتم استخدامها عمليًا ، لأن النماذج مختلفة الاتساق النهائي ، والاتساق القوي (ربما).

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

الاتساق السببي - أقوى نموذج


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



أولاً ، يبسط عمل مطوري التطبيقات. على وجه الخصوص ، هناك الكثير من الدعم من الخادم: عندما يتم ضمان وصول جميع السجلات التي تحدث داخل عميل واحد في هذا الطلب على العميل الآخر. ثانيًا ، يقاوم الأقسام.

مطبخ داخلي MongoDB


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





MongoDB (المشار إليها فيما يلي باسم "MongoBD") هو نظام موزع يدعم التحجيم الأفقي ، أي تقسيم ؛ وداخل كل جزء ، يدعم أيضًا تكرار البيانات ، أي التكرار.

تؤدي المشاركة في "MongoBD" (قاعدة بيانات غير علائقية) إلى إجراء موازنة تلقائية ، أي أن كل مجموعة من المستندات (أو "جدول" من حيث البيانات العلائقية) إلى أجزاء ، ويقوم الخادم بالفعل بنقلها تلقائيًا بين الأجزاء.

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

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

أطلقنا الإصدار 4.2 - ظهرت أشياء جديدة مثيرة للاهتمام هناك. على وجه الخصوص ، أدخلوا Lucene - البحث - كان جافا قابل للتنفيذ مباشرة في "Mongo" ، وأصبح من الممكن البحث من خلال Lucene ، كما هو الحال في "Elastic".

وقاموا بعمل منتج جديد - الرسوم البيانية ، وهو متاح أيضًا على Atlas (سحابة Mongo الخاصة). لديهم طبقة مجانية - يمكنك اللعب مع هذا. لقد أحببت الرسوم البيانية حقًا - تصور البيانات بديهي للغاية.

مكونات الاتساق السببي


أحصيت حوالي 230 مقالة تم نشرها حول هذا الموضوع - من ليزلي لامبرت. الآن من ذاكرتي سأحضر لك بعض أجزاء من هذه المواد.



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

محددات


ما هي القيود؟ هذه في الواقع واحدة من النقاط الرئيسية ، لأن القيود التي تفرضها أنظمة الإنتاج تختلف تمامًا عن القيود الموجودة في المقالات الأكاديمية. غالبًا ما تكون مصطنعة تمامًا.



  • أولاً ، "MongoDB" هو سيد واحد ، كما قلت بالفعل (وهذا يبسط إلى حد كبير).
  • , 10 . - , .
  • , , , binary, , .
  • , Research : . «» – . , , – . , .
  • , – : , performance degradation .
  • هناك نقطة أخرى عمومًا مناهضة للأكاديمية: توافق الإصدارات السابقة والمستقبلية. يجب أن تدعم برامج التشغيل القديمة التحديثات الجديدة ، ويجب أن تدعم قاعدة البيانات برامج التشغيل القديمة.

بشكل عام ، كل هذا يفرض قيودًا.

مكونات الاتساق السببي


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



تتبع التبعية الكاملة


لماذا هو مطلوب؟ من أجل أنه عندما يتم نسخ البيانات - كل سجل ، يحتوي كل تغيير في البيانات على معلومات حول التغييرات التي تعتمد عليها. التغيير الأول والساذج هو عندما تحتوي كل رسالة تحتوي على سجل على معلومات حول الرسائل السابقة:



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

لماذا قررنا عدم استخدام هذا النهج (التتبع الكامل)؟ من الواضح ، لأن هذا النهج غير عملي: أي تغيير في الشبكة الاجتماعية يعتمد على جميع التغييرات السابقة في هذه الشبكة الاجتماعية ، حيث ينقل ، على سبيل المثال ، Facebook أو Vkontakte في كل تحديث. ومع ذلك ، هناك الكثير من الأبحاث وهي تتبع الاعتماد الكامل - فهذه شبكات اجتماعية ، وفي بعض المواقف تعمل حقًا.

تتبع التبعية الصريحة


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



ترى أن السجل 5 يعتمد على السجلات 1 ، 2 ، 3 ، 4 - على التوالي ، تنتظر قبل أن يحصل العميل على إمكانية الوصول إلى التغييرات التي تم إجراؤها بموجب مرسوم وصول بيني عندما تمر جميع التغييرات السابقة بالفعل إلى قاعدة البيانات.

هذا أيضًا لا يناسبنا ، لأنه على أي حال هناك الكثير من المعلومات ، وهذا سيتباطأ. هناك نهج مختلف ...

ساعة لامبورت


إنهم كبار في السن. تعني ساعة Lamport أن هذه التبعية قد انهارت في دالة عددية تسمى Lamport Clock.

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

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

سترى كيف يزيد وقت العداد المنطقي على الخلاصة:



وبالتالي ، فإن الخاصية الرئيسية لساعة Lamport هذه والاتساق السببي (الموضحة من خلال Lamport Clock) هي كما يلي: إذا كان لدينا حدثان A و B ، والحدث B يعتمد على الحدث A * ، فإن ذلك يعني أن LogicalTime من الحدث A أقل من LogicalTime من الحدث B.

* أحيانًا يقولون حتى أن A حدث قبل B ، أي حدث A قبل B - هذا نوع من العلاقة التي تطلب جزئيًا مجموعة كاملة من الأحداث التي حدثت بشكل عام.

العكس خطأ. هذا هو في الواقع أحد العيوب الرئيسية لساعة Lamport - الترتيب الجزئي. هناك مفهوم للأحداث المتزامنة ، أي الأحداث التي لم يحدث فيها (أ حدث قبل ب) ولا (أ حدث قبل ب). مثال على ذلك هو الإضافة الموازية التي كتبها ليونارد لأصدقاء شخص آخر (ولا حتى ليونارد ، ولكن شيلدون ، على سبيل المثال).
هذه هي الخاصية التي يتم استخدامها غالبًا عند العمل مع ساعات Lamport: فهم ينظرون إلى الوظيفة تمامًا ويخلصون إلى نتيجة من ذلك - ربما تعتمد هذه الأحداث. لأن هذا صحيح في اتجاه واحد: إذا كان LogicalTime A أقل من LogicalTime B ، فلا يمكن أن يحدث B قبل A ؛ وإذا كان الأمر كذلك ، فربما.

ساعة متجهة


التطور المنطقي لساعات لامبورت هو ساعة المتجه. تختلف في أن كل عقدة موجودة هنا تحتوي على ساعتها المنفصلة الخاصة بها ، ويتم إرسالها كمتجه.
في هذه الحالة ، سترى أن الفهرس الصفري للمتجه مسؤول عن الخلاصة ، والفهرس الأول للمتجه هو للأصدقاء (كل من هذه العقد). والآن سيزيدون: يزداد المؤشر الصفري لـ "الخلاصة" عند التسجيل - 1 ، 2 ، 3:



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

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

Spanner TrueTime. ساعة ذرية


قلت أنه ستكون هناك قصة عن Spanner. هذا شيء رائع ، في القرن الحادي والعشرين: الساعات الذرية ، مزامنة GPS.

فكرة ماذا؟ Spanner هو نظام Google أصبح متاحًا مؤخرًا للأشخاص (لقد أرفقوا به SQL). كل معاملة هناك بعض الطابع الزمني. نظرًا لتزامن الوقت * ، يمكن تعيين وقت محدد لكل حدث - فالساعة الذرية لها وقت انتظار ، وبعد ذلك يتم ضمان حدوث وقت آخر.



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

* هذه هي المشكلة الرئيسية لساعات لامبارت - فهي ليست متزامنة على الأنظمة الموزعة. يمكن أن تتباعد ، حتى مع NTP ، فإنها لا تزال لا تعمل بشكل جيد للغاية. يحتوي "Spanner" على ساعة ذرية ويبدو أن التزامن هو ثم ميكروثانية.

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

ساعة هجينة


هذا في الواقع ما يميز "MongoBD" مع ضمان الاتساق السببي. ما هي الهجين؟ الهجين هو قيمة قياسية ، لكنه يتكون من مكونين:



  • الأول هو عصر يونكس (كم ثانية مرت منذ "بداية عالم الكمبيوتر").
  • والثاني هو بعض الزيادة ، وكذلك int int 32 بت غير موقعة.

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

لماذا هذا مهم لـ MongoBD؟ لأنه يسمح لك بعمل نوع من أنواع الترميم الاحتياطي في وقت معين ، أي أن الحدث يتم فهرسته حسب الوقت. هذا مهم عند الحاجة إلى بعض الأحداث ؛ بالنسبة لقاعدة البيانات ، فإن الأحداث هي تغييرات في قاعدة البيانات تحدث في أوقات معينة من الزمن.

سأقول لك فقط أهم سبب (من فضلك ، لا تخبر أحدا)! لقد فعلنا ذلك لأن البيانات المفهرسة المرتبة في MongoDB OpLog تبدو هكذا. OpLog هو هيكل بيانات يحتوي على جميع التغييرات في قاعدة البيانات تمامًا: يذهبون أولاً إلى OpLog ، ثم يتم تطبيقهم بالفعل على التخزين نفسه في الحالة عندما يكون تاريخًا متكررًا أو جزءًا.

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

تزامن الساعة


هناك العديد من طرق التزامن الموضحة في المؤلفات العلمية. أنا أتحدث عن المزامنة عندما يكون لدينا شطرتان مختلفتان. إذا كان هناك مجموعة متماثلة واحدة ، فلا حاجة للتزامن هناك: إنها "سيد واحد" ؛ لدينا OpLog تدخل فيه جميع التغييرات - في هذه الحالة يتم ترتيب كل شيء بالفعل بالتسلسل في "Oplog" نفسه. ولكن إذا كان لدينا شطرتان مختلفتان ، فإن مزامنة الوقت مهمة هنا. هنا ساعدت ساعات ناقلات أكثر! لكن ليس لدينا منهم.



والثاني هو نبضات القلب. يمكنك تبادل بعض الإشارات التي تحدث في كل وحدة زمنية. لكن Hartbits بطيئة جدًا ، ولا يمكننا توفير وقت استجابة لعملائنا.

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

القيل والقال هو عندما تتضمن جميع الرسائل الوقت. هذا هو تقريبا ما نستخدمه. كل رسالة بين العقد ، برنامج تشغيل ، جهاز توجيه لعقد البيانات ، كل شيء على الإطلاق لـ MongoDB هي بعض العناصر ، مكونات قاعدة البيانات التي تحتوي على ساعات تتدفق. في كل مكان لديهم معنى الوقت الهجين ، يتم نقله. 64 بت؟ هذا ممكن.

كيف يعمل كل ذلك معًا؟


هنا ألقي نظرة على نسخة متماثلة واحدة لجعلها أسهل قليلاً. هناك الابتدائية والثانوية. الثانوية تقوم بالنسخ المتماثل ولا تتم مزامنتها دائمًا بشكل أساسي مع Primary.

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

بعد أن يسجل رقما قياسيا ، تحدث لحظة مهمة. الساعات في "MongoDB" ولا يتم زيادتها إلا إذا تم تسجيلها في "Oplog". هذا حدث يغير حالة النظام. تمامًا في جميع المقالات الكلاسيكية ، يعتبر الحدث رسالة تدخل عقدة: وصلت رسالة - وهذا يعني أن النظام قد غيّر حالته.

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

تقوم بإرجاع القيمة التي تم تسجيلها بالفعل في "Oplog" - نحن نعلم أنه في "Oplog" تكمن هذه القيمة بالفعل ، ووقتها هو 12. والآن ، على سبيل المثال ، تبدأ القراءة من عقدة أخرى (ثانوية) ، وهي تنتقل بالفعل بعد ClusterTime نفسها رسالة. يقول: "أحتاج إلى كل ما حدث بعد 12 أو على الأقل اثني عشر" (انظر الشكل أعلاه).

هذا هو ما يسمى السببية (CAT). هناك مثل هذا المفهوم من الناحية النظرية أنه جزء من الوقت ، وهو ثابت في حد ذاته. في هذه الحالة ، يمكننا القول أن هذه هي حالة النظام التي تمت ملاحظتها في الوقت 12.

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



هكذا يعمل كل شيء. تقريبيا.

ماذا يعني "تقريبا"؟ لنفترض أن هناك شخصًا قرأ وفهم كيف يعمل كل هذا. أدركت أنه في كل مرة يحدث فيها ClusterTime ، فإنه يقوم بتحديث الساعة المنطقية الداخلية ، ثم يزيد السجل التالي بمقدار واحد. تأخذ هذه الوظيفة 20 خطًا. افترض أن هذا الشخص يرسل أكبر عدد ممكن من 64 بت ، ناقص واحد.

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

من الواضح أنه بعد ذلك يصبح النظام غير قابل للوصول إلى أي شيء. يمكن تفريغها وتنظيفها فقط - الكثير من العمل اليدوي. التوافر الكامل:



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

طريقنا هو التوقيع على الكتلة


لذلك يتم إرسالها في الرسالة (قبل النص الأزرق). ولكننا بدأنا أيضًا في إنشاء توقيع (نص أزرق):



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

ماذا يعني استخدام التناسق السببي في هذه الحالة؟ سيؤدي هذا إلى إظهار المعلمة afterClusterTime. وبدونه ، سيمرر ببساطة القيم على أي حال. النميمة ، منذ الإصدار 3.6 ، تعمل دائمًا.

إذا تركنا الجيل المستمر من التوقيعات ، فسيؤدي ذلك إلى إبطاء النظام حتى في غياب الميزات ، والتي لا تلبي مناهجنا ومتطلباتنا. وماذا فعلنا؟

افعلها بسرعة!


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



خلال تلقي مثل هذا التوقيع ، نقوم بتسريع النظام (بشكل مشروط) بمقدار 65 ألف مرة. إنه يعمل بشكل رائع: عندما أجروا التجارب ، تم تقليل الوقت الذي كان لدينا فيه تحديث ثابت هناك بالفعل 10 آلاف مرة. من الواضح أنه عندما تكون على خلاف ، فإن هذا لا يعمل. ولكن في معظم الحالات العملية يعمل هذا. أدى الجمع بين توقيع النطاق والتوقيع إلى حل مشكلة الأمان.

ماذا تعلمنا؟


الدروس التي تعلمناها من هذا:

  • , , , . - ( , . .), , . , , , . – .

    , , («», ) – . ? . , . – , .
  • . , «» , , , availability, latency .
  • والأخير هو أنه كان علينا أن نفكر في أفكار مختلفة ودمج عدة مقالات مختلفة بشكل عام في نهج واحد معًا. جاءت فكرة التوقيع ، على سبيل المثال ، من مقال فحص بروتوكول Paxos ، والذي بالنسبة لغير البيزنطيين داخل بروتوكول الترخيص ، بالنسبة إلى البيزنطيين خارج بروتوكول الترخيص ... بشكل عام ، هذا بالضبط ما فعلناه في النهاية.

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



على هذا سوف تنتهي. شكرا!

الأسئلة


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

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

س: - أردت معرفة كيفية المزامنة واختيار وقت منطقي واحد؟

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

سؤال: - وبعد ذلك إذا ما زالت هناك بعض الأحداث الأخرى التي ضاعت في مكان ما على الشبكة؟

MT:- يتم ترتيب القشرة لدرجة أنها لن تأتي بعد الآن ، لأنها سيد واحد. إذا كان قد سجل بالفعل ، فلن يأتوا ، ولكن سيتبعون. لا يمكن أن يحدث أنه في مكان ما عالق شيء ما ، فلن يكتب بعد ذلك ، ثم وصلت هذه الأحداث - وتم انتهاك الاتساق السببي. عندما لا يكتب ، يجب أن يأتي جميعهم بعد ذلك (سوف ينتظرهم).



في:- لدي بعض الأسئلة بخصوص الخطوط. يفترض الاتساق السببي أن هناك طابورًا معينًا من الإجراءات التي يجب تنفيذها. ماذا يحدث إذا فقدنا عبوة واحدة؟ لذلك ذهبت العاشرة ، ال 11 ... اختفت ال 12 ، والجميع ينتظرون أن يتم تحقيقه. وفجأة ماتت سيارتنا ، لا يمكننا فعل أي شيء. هل هناك حد أقصى لطول الانتظار يتراكم قبل تنفيذه؟ ما الفشل المميت الذي يحدث عندما تضيع دولة واحدة؟ علاوة على ذلك ، إذا كتبنا أن هناك نوعًا من الدولة السابقة ، فهل علينا أن نبدأ من ذلك بطريقة أو بأخرى؟ ولم يدفعوا منه!

MT:- أيضا سؤال رائع! ماذا نفعل؟ MongoDB لديه مفهوم سجلات النصاب القانوني ، يقرأ النصاب القانوني. متى يمكن أن تختفي الرسالة؟ عندما لا يكون النصاب القانوني أو عندما لا يكون النصاب القانوني (يمكن لبعض القمامة أن تلتصق).
فيما يتعلق بالاتساق السببي ، أجرينا اختبارًا تجريبيًا كبيرًا ، مما أدى إلى حقيقة أنه عندما لا يكون النصاب القانوني للتسجيل والقراءة ، تحدث انتهاكات الاتساق السببي. بالضبط ما تقوله!

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

س: - عندما ننشئ مثالًا يفعله التجزئة بالنسبة لنا (وليس سيدًا ، ولكن تابعًا على التوالي) ، فإنه يعتمد على وقت يونيكس الخاص بآلته الخاصة أو على وقت "السيد" ؛ متزامن لأول مرة أو بشكل دوري؟

MT:- الآن سأوضح. Shard (أي قسم أفقي) - هناك دائمًا أساسي. وفي جزء قد يكون هناك "سيد" وقد يكون هناك نسخ طبق الأصل. لكن الجزء دائمًا يدعم الكتابة ، لأنه يجب أن يدعم مجالًا معينًا (الأساسي موجود في الجزء).

سؤال: أي أن كل شيء يعتمد بحتة على "السيد"؟ دائما استخدام الوقت "سيد"؟

MT: - نعم. يمكن القول المجازي: الساعة تدق عندما يكون هناك تسجيل في "سيد" في "Oplog".

س: - لدينا عميل متصل ولا يحتاج لمعرفة أي شيء عن الوقت؟

MT:- بشكل عام ، لا تحتاج إلى معرفة أي شيء! إذا تحدثنا عن كيفية عملها على العميل: في العميل ، عندما يريد استخدام الاتساق السببي ، يحتاج إلى فتح جلسة. كل شيء موجود الآن: كلتا المعاملات في الجلسة واسترداد الحقوق ... الجلسة هي ترتيب للأحداث المنطقية التي تحدث مع العميل.

إذا قام بفتح هذه الجلسة وقال هناك إنه يريد الاتساق السببي (إذا كانت الجلسة تدعم الاتساق السببي افتراضيًا) ، فسيعمل كل شيء تلقائيًا. يتذكر السائق هذه المرة ويزيدها عندما يتلقى رسالة جديدة. يتذكر الإجابة التي أعادت الإجابة السابقة من الخادم الذي أعاد البيانات. سيحتوي الطلب التالي على afterCluster ("الوقت أكبر من هذا").

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

س: - يرتبط موضوع الاتساق النهائي ارتباطًا وثيقًا بطبقة علوم الحوسبة الجديدة - أنواع البيانات CRDT (أنواع البيانات المكررة الخالية من التعارضات). هل فكرت في دمج هذه الأنواع من البيانات في قاعدة البيانات وماذا يمكن أن تقوله عنه؟

MT: - سؤال جيد! CRDT منطقي لتعارضات الكتابة: في MongoDB - سيد واحد.

في:- لدي سؤال من devops. في العالم الحقيقي ، هناك مثل هذه الحالات اليسوعية عندما يحدث الفشل البيزنطي ، ويبدأ الأشرار داخل المحيط المحمي بالالتزام بالبروتوكول ، وإرسال الحزم الحرفية بطريقة خاصة؟



MT: - الناس الشر داخل المحيط مثل حصان طروادة! يمكن لأناس الشر داخل المحيط القيام بأشياء سيئة كثيرة.

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

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

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

في:- في محيط آمن ، صعد شخص ما لتشكيل بروتوكولات غير متوقعة للخادم من أجل إعداد الخادم مع السرطان ، وإذا كنت محظوظًا ، فإن المجموعة بأكملها ... هل يحدث ذلك "جيدًا"؟

MT: - لم يسبق لي أن سمعت عن مثل هذه الأشياء. حقيقة أنه بهذه الطريقة يمكنك ملء الخادم ليس سرا. لملء الداخل ، كونه من البروتوكول ، كونه مستخدمًا مفوضًا يمكنه كتابة شيء من هذا القبيل في رسالة ... في الواقع ، هذا مستحيل ، لأنه سيتم التحقق منه على أي حال. من الممكن تعطيل هذه المصادقة للمستخدمين الذين لا يريدون - هذه هي مشكلتهم ؛ بشكل تقريبي ، هم أنفسهم دمروا الجدران ويمكنك حشر الفيل هناك ، والذي سوف يدوس ... بشكل عام ، يمكنك ارتداء الملابس كالمصلح ، تعال واحصل عليه!

في:- شكرا على التقرير. سيرجي (ياندكس). في "مونغ" يوجد ثابت يحد من عدد الأعضاء المصوتين في مجموعة النسخ المتماثلة وهذا الثابت هو 7 (سبعة). لماذا هذا ثابت؟ لماذا هذا ليس نوع من المعلمة؟

MT: - مجموعة النسخ المتماثلة لدينا أيضا 40 عقدة. هناك دائما أغلبية. لا أعرف أي إصدار ...

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

MT: - هذا بالفعل خارج نطاق التقرير. هذا سؤال شائع. ربما بعد ذلك يمكنني إخباره.




القليل من الدعاية :)


أشكركم على البقاء معنا. هل تحب مقالاتنا؟ هل تريد رؤية مواد أكثر إثارة للاهتمام؟ ادعمنا عن طريق تقديم طلب أو التوصية لأصدقائك VPS القائم على السحابة للمطورين من $ 4.99 ، وهو نظير فريد من نوعه لخوادم مستوى الدخول التي اخترعناها لك: الحقيقة الكاملة عن VPS (KVM) E5-2697 v3 (6 نوى) 10GB DDR4 480GB SSD 1Gbps من $ 19 أو كيفية تقسيم الخادم؟ (تتوفر الخيارات مع RAID1 و RAID10 ، حتى 24 مركزًا و 40 جيجابايت DDR4).

Dell R730xd أرخص مرتين في مركز بيانات Equinix Tier IV في أمستردام؟ فقط لدينا 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV من 199 دولارًا في هولندا!Dell R420 - 2x E5-2430 2.2 جيجا هرتز 6C 128 جيجا بايت DDR3 2x960GB SSD 1Gbps 100TB - من 99 دولار! اقرأ عن كيفية بناء مبنى البنية التحتية الفئة c باستخدام خوادم Dell R730xd E5-2650 v4 بتكلفة 9000 يورو مقابل سنت واحد؟

Source: https://habr.com/ru/post/undefined/


All Articles