HighLoad++، میخائیل تیولنف (MongoDB): سازگاری علی: از تئوری تا عمل

کنفرانس بعدی HighLoad++ در تاریخ 6 و 7 آوریل 2020 در سن پترزبورگ برگزار خواهد شد.
جزئیات و بلیط по ссылке. HighLoad++ Siberia 2019. سالن "کراسنویارسک". 25 ژوئن ساعت 12:00. پایان نامه ها و ارائه.

این اتفاق می افتد که الزامات عملی با تئوری در تضاد است، جایی که جنبه های مهم برای یک محصول تجاری در نظر گرفته نمی شود. این گفتار فرآیندی را برای انتخاب و ترکیب رویکردهای مختلف برای ایجاد مؤلفه‌های سازگاری علی بر اساس تحقیقات دانشگاهی بر اساس الزامات یک محصول تجاری ارائه می‌کند. شنوندگان در مورد رویکردهای نظری موجود در مورد ساعت های منطقی، ردیابی وابستگی، امنیت سیستم، همگام سازی ساعت، و اینکه چرا MongoDB بر روی راه حل های خاص مستقر شده است، یاد خواهند گرفت.

میخائیل تیولنف (از این پس MT نامیده می شود): - من در مورد سازگاری علی صحبت خواهم کرد - این یک ویژگی است که ما در MongoDB روی آن کار کردیم. من در یک گروه از سیستم های توزیع شده کار می کنم، ما این کار را حدود دو سال پیش انجام دادیم.

در این فرآیند، مجبور شدم با بسیاری از تحقیقات دانشگاهی آشنا شوم، زیرا این ویژگی به خوبی مورد مطالعه قرار گرفته است. مشخص شد که به دلیل الزامات بسیار خاصی که احتمالاً در هر برنامه تولیدی وجود دارد، حتی یک مقاله با آنچه در پایگاه داده تولید مورد نیاز است، نمی گنجد.

من در مورد این صحبت خواهم کرد که چگونه ما، به عنوان مصرف کنندگان تحقیقات دانشگاهی، چیزی از آن تهیه می کنیم که سپس می توانیم به عنوان یک غذای آماده و راحت و ایمن برای استفاده به کاربران خود ارائه دهیم.

سازگاری علّی. بیایید مفاهیم را تعریف کنیم

برای شروع، می خواهم به طور کلی بگویم سازگاری علی چیست. دو شخصیت وجود دارد - لئونارد و پنی (سریال تلویزیونی "The Big Bang Theory"):

فرض کنید پنی در اروپا است و لئونارد می خواهد برای او یک مهمانی سورپرایز برگزار کند. و او نمی تواند به چیزی بهتر از حذف او از لیست دوستانش فکر کند، و برای همه دوستانش یک به روز رسانی در فید بفرستد: "بیایید پنی را خوشحال کنیم!" (او در اروپا است، در حالی که می خوابد، همه اینها را نمی بیند و نمی تواند ببیند، زیرا او آنجا نیست). در نهایت، او این پست را حذف می کند، آن را از فید پاک می کند و دسترسی را بازیابی می کند تا متوجه چیزی نشود و رسوایی به وجود نیاید.
همه اینها خوب و خوب است، اما بیایید فرض کنیم که سیستم توزیع شده است و همه چیز کمی اشتباه پیش رفته است. برای مثال، ممکن است این اتفاق بیفتد که محدودیت دسترسی پنی پس از ظاهر شدن این پست رخ دهد، در صورتی که رویدادها با علت و معلول مرتبط نباشند. در واقع، این نمونه‌ای از زمانی است که برای انجام یک عملکرد تجاری (در این مورد) به سازگاری علّی نیاز است.

در واقع، اینها ویژگی های کاملاً بی اهمیت پایگاه داده هستند - افراد بسیار کمی از آنها پشتیبانی می کنند. بیایید به سراغ مدل ها برویم.

مدل های سازگاری

مدل سازگاری در پایگاه داده دقیقا چیست؟ اینها برخی از تضمین هایی است که یک سیستم توزیع شده در مورد اینکه مشتری چه داده هایی را می تواند دریافت کند و در چه ترتیبی می دهد.

در اصل، همه مدل‌های سازگاری به این موضوع مربوط می‌شوند که یک سیستم توزیع‌شده چقدر شبیه به سیستمی است که مثلاً روی یک گره در لپ‌تاپ اجرا می‌شود. و این همان چیزی است که سیستمی که بر روی هزاران "گره" توزیع شده جغرافیایی اجرا می شود به یک لپ تاپ شباهت دارد که در آن همه این ویژگی ها اصولاً به طور خودکار انجام می شوند.

بنابراین، مدل‌های سازگاری فقط برای سیستم‌های توزیع شده اعمال می‌شوند. تمام سیستم هایی که قبلا وجود داشتند و با مقیاس عمودی یکسان کار می کردند، چنین مشکلاتی را تجربه نکردند. یک بافر کش وجود داشت و همه چیز همیشه از روی آن خوانده می شد.

مدل قوی

در واقع، اولین مدل قوی است (یا خط توانایی افزایش، همانطور که اغلب به آن گفته می شود). این یک مدل سازگاری است که تضمین می‌کند هر تغییری، پس از تأیید وقوع آن، برای همه کاربران سیستم قابل مشاهده است.

این یک نظم جهانی از همه رویدادها در پایگاه داده ایجاد می کند. این خاصیت قوام بسیار قوی است و به طور کلی بسیار گران است. با این حال، بسیار خوب پشتیبانی می شود. این فقط بسیار گران و کند است - فقط به ندرت استفاده می شود. به این توانایی افزایش می گویند.

یکی دیگر از ویژگی های قوی تر وجود دارد که در Spanner پشتیبانی می شود - به نام External Consistency. کمی بعد در مورد آن صحبت خواهیم کرد.

علت

مورد بعدی Causal است که دقیقاً همان چیزی است که من در مورد آن صحبت می کردم. چندین سطح فرعی دیگر بین Strong و Causal وجود دارد که من در مورد آنها صحبت نمی کنم، اما همه آنها به Causal خلاصه می شوند. این یک مدل مهم است زیرا قوی‌ترین مدل‌ها، قوی‌ترین سازگاری در حضور یک شبکه یا پارتیشن‌ها است.

علت ها در واقع وضعیتی هستند که در آن رویدادها با یک رابطه علت و معلولی به هم مرتبط می شوند. اغلب آنها از دیدگاه مشتری به عنوان حقوق خوانده شده در نظر گرفته می شوند. اگر مشتری مقادیری را رعایت کرده باشد، نمی تواند مقادیری را که در گذشته بوده است ببیند. او در حال حاضر شروع به دیدن خواندن پیشوندها کرده است. همه چیز به یک چیز ختم می شود.
Causals به عنوان یک مدل سازگاری، نظم بخشی از رویدادها در سرور است که در آن رویدادها از همه مشتریان در یک توالی مشاهده می شوند. در این مورد، لئونارد و پنی.

سرانجام

مدل سوم، سازگاری نهایی است. این چیزی است که کاملاً همه سیستم های توزیع شده پشتیبانی می کنند، مدل حداقلی که اصلاً منطقی است. به این معنی است که: وقتی تغییراتی در داده ها داشته باشیم، در نقطه ای یکسان می شوند.

در چنین لحظه ای او چیزی نمی گوید، در غیر این صورت به سازگاری خارجی تبدیل می شود - داستان کاملاً متفاوتی خواهد بود. با این وجود، این یک مدل بسیار محبوب و رایج ترین است. به طور پیش فرض، همه کاربران سیستم های توزیع شده از سازگاری رویدادی استفاده می کنند.

می خواهم چند مثال مقایسه ای بزنم:

معنی این فلش ها چیست؟

• تاخیر. با افزایش قدرت سازگاری، به دلایل واضح بزرگتر می شود: باید رکوردهای بیشتری ایجاد کنید، از همه میزبان ها و گره هایی که در خوشه شرکت می کنند تأیید کنید که داده ها از قبل وجود دارد. بر این اساس، Eventual Consistency سریعترین پاسخ را دارد، زیرا در آنجا، به عنوان یک قاعده، شما حتی می توانید آن را به حافظه اختصاص دهید و این در اصل کافی است.
• دسترسی. اگر این را به‌عنوان توانایی سیستم برای پاسخ‌دهی در حضور قطع‌های شبکه، پارتیشن‌ها یا نوعی خرابی درک کنیم، با کاهش مدل سازگاری، تحمل خطا افزایش می‌یابد، زیرا برای ما کافی است که یک میزبان در همان زمان زندگی کند. زمان مقداری داده تولید می کند. سازگاری نهایی هیچ چیزی را در مورد داده ها تضمین نمی کند - می تواند هر چیزی باشد.
• ناهنجاری ها در عین حال، البته تعداد ناهنجاری ها افزایش می یابد. در Strong Consistency تقریباً اصلاً نباید وجود داشته باشند، اما در Eventual Consistency می توانند هر چیزی باشند. این سوال مطرح می شود: چرا اگر افراد سازگاری رویدادی حاوی ناهنجاری است، آن را انتخاب می کنند؟ پاسخ این است که مدل‌های سازگاری احتمالی قابل اجرا هستند و ناهنجاری‌ها، برای مثال، در یک دوره زمانی کوتاه وجود دارند. می توان از جادوگر برای خواندن و خواندن کم و بیش داده های سازگار استفاده کرد. اغلب می توان از مدل های سازگاری قوی استفاده کرد. در عمل این کار می کند و اغلب تعداد ناهنجاری ها در زمان محدود است.

قضیه CAP

وقتی کلمات سازگاری، در دسترس بودن را می بینید - چه چیزی به ذهن شما می رسد؟ درست است - قضیه CAP! حالا می‌خواهم این افسانه را از بین ببرم... این من نیستم - این مارتین کلپمن است که یک مقاله فوق‌العاده نوشت، یک کتاب فوق‌العاده.

قضیه CAP یک اصل است که در دهه 2000 فرموله شده است که سازگاری، در دسترس بودن، پارتیشن ها: هر دو را انتخاب کنید، و شما نمی توانید سه مورد را انتخاب کنید. این یک اصل مشخص بود. چند سال بعد توسط گیلبرت و لینچ به عنوان یک قضیه ثابت شد. سپس از این به عنوان یک مانترا استفاده شد - سیستم ها به CA، CP، AP و غیره تقسیم شدند.

این قضیه در واقع برای موارد زیر اثبات شد... اولاً، در دسترس بودن به عنوان یک مقدار پیوسته از صفر تا صدها در نظر گرفته شد (0 - سیستم "مرده است"، 100 - به سرعت پاسخ می دهد؛ ما عادت کرده ایم آن را به این صورت در نظر بگیریم) ، اما به عنوان یک ویژگی از الگوریتم، که تضمین می کند که برای تمام اجرای خود داده ها را برمی گرداند.

در مورد زمان پاسخگویی اصلا حرفی نیست! الگوریتمی وجود دارد که داده‌ها را پس از 100 سال برمی‌گرداند - یک الگوریتم فوق‌العاده در دسترس، که بخشی از قضیه CAP است.
دوم: قضیه برای تغییرات مقادیر یک کلید ثابت شد، علیرغم اینکه این تغییرات قابل تغییر اندازه هستند. این بدان معنی است که در واقعیت آنها عملاً مورد استفاده قرار نمی گیرند، زیرا مدل های مختلف سازگاری رویدادی، سازگاری قوی (شاید) هستند.

این همه برای چیست؟ علاوه بر این، قضیه CAP دقیقاً به شکلی که در آن ثابت شد عملاً قابل اجرا نیست و به ندرت مورد استفاده قرار می گیرد. در شکل نظری، به نوعی همه چیز را محدود می کند. به نظر می رسد یک اصل مشخص است که به طور شهودی صحیح است، اما به طور کلی ثابت نشده است.

سازگاری علی قوی ترین مدل است

آنچه در حال حاضر اتفاق می افتد این است که می توانید هر سه چیز را دریافت کنید: سازگاری، در دسترس بودن با استفاده از پارتیشن ها. به طور خاص، سازگاری علّی قوی‌ترین مدل سازگاری است که هنوز در حضور پارتیشن‌ها (شکست‌های شبکه) کار می‌کند. به همین دلیل است که بسیار مورد توجه است و به همین دلیل است که ما آن را انتخاب کردیم.

اولا، کار توسعه دهندگان برنامه را ساده می کند. به طور خاص، وجود پشتیبانی عالی از طرف سرور: زمانی که تمام رکوردهایی که در یک کلاینت اتفاق می‌افتند تضمین می‌شوند که در یک دنباله روی مشتری دیگر می‌رسند. دوم اینکه پارتیشن ها را تحمل می کند.

آشپزخانه داخلی MongoDB

با یادآوری اینکه ناهار است، به سمت آشپزخانه حرکت می کنیم. من در مورد مدل سیستم به شما خواهم گفت، یعنی MongoDB برای کسانی که برای اولین بار در مورد چنین پایگاه داده ای می شنوند چیست.

MongoDB (از این پس "MongoDB" نامیده می شود) یک سیستم توزیع شده است که از مقیاس بندی افقی، یعنی به اشتراک گذاری، پشتیبانی می کند. و در داخل هر قطعه از افزونگی داده، یعنی تکرار، نیز پشتیبانی می کند.

Sharding در MongoDB (نه یک پایگاه داده رابطه ای) تعادل خودکار را انجام می دهد، یعنی هر مجموعه ای از اسناد (یا "جدول" از نظر داده های رابطه ای) به قطعات تقسیم می شود و سرور به طور خودکار آنها را بین خرده ها جابجا می کند.

کوئری روتر، که درخواست ها را توزیع می کند، برای یک کلاینت، کلاینت هایی است که از طریق آن کار می کند. از قبل می‌داند کجا و چه داده‌هایی قرار دارند و همه درخواست‌ها را به قطعه درست هدایت می‌کند.

نکته مهم دیگر: MongoDB یک استاد واحد است. یک Primary وجود دارد - می تواند رکوردهایی را بگیرد که از کلیدهای موجود در آن پشتیبانی می کند. شما نمی توانید Multi-Master رایت کنید.

ما نسخه 4.2 را منتشر کردیم - چیزهای جالب جدیدی در آنجا ظاهر شد. به طور خاص، آنها Lucene - جستجو - یعنی جاوا قابل اجرا را مستقیماً در Mongo قرار دادند و در آنجا امکان انجام جستجوها از طریق Lucene، مانند الاستیکا، فراهم شد.

و آنها یک محصول جدید ساختند - نمودارها، همچنین در اطلس (ابر خود مونگو) موجود است. آنها یک ردیف رایگان دارند - می توانید با آن بازی کنید. نمودارها را خیلی دوست داشتم - تجسم داده ها، بسیار شهودی.

مواد تشکیل دهنده قوام علت

من حدود 230 مقاله در این موضوع - از لزلی لمپرت - منتشر کردم. اکنون از خاطراتم بخشهایی از این مطالب را به شما می رسانم.

همه چیز با مقاله ای از لزلی لمپرت شروع شد که در دهه 1970 نوشته شد. همانطور که می بینید، برخی تحقیقات در مورد این موضوع هنوز ادامه دارد. در حال حاضر سازگاری علّی در ارتباط با توسعه سیستم‌های توزیع شده مورد توجه قرار گرفته است.

محدودیت

چه محدودیت هایی وجود دارد؟ این در واقع یکی از نکات اصلی است، زیرا محدودیت هایی که یک سیستم تولیدی ایجاد می کند با محدودیت هایی که در مقالات دانشگاهی وجود دارد بسیار متفاوت است. آنها اغلب کاملا مصنوعی هستند.

• در مرحله اول، همانطور که قبلاً گفتم، "MongoDB" یک استاد واحد است (این امر بسیار ساده می کند).
• ما معتقدیم که این سیستم باید حدود 10 هزار شارد را پشتیبانی کند. ما نمی توانیم هیچ تصمیمی در زمینه معماری بگیریم که به صراحت این ارزش را محدود کند.
• ما یک ابر داریم، اما فرض می‌کنیم زمانی که یک نفر باینری را دانلود می‌کند، آن را روی لپ‌تاپ خود اجرا می‌کند، هنوز هم باید فرصت داشته باشد، و همه چیز عالی کار می‌کند.
• ما چیزی را فرض می کنیم که پژوهش به ندرت آن را فرض می کند: مشتریان خارجی می توانند هر کاری که می خواهند انجام دهند. MongoDB منبع باز است. بر این اساس، مشتریان می توانند بسیار باهوش و عصبانی باشند - آنها می توانند بخواهند همه چیز را بشکنند. ما حدس می زنیم که فیلورهای بیزانسی ممکن است منشأ داشته باشند.
• برای کلاینت‌های خارجی که خارج از محیط هستند، یک محدودیت مهم وجود دارد: اگر این ویژگی غیرفعال باشد، نباید کاهش عملکرد مشاهده شود.
• نکته دیگر به طور کلی ضد آکادمیک است: سازگاری نسخه های قبلی و نسخه های آینده. درایورهای قدیمی باید از به روز رسانی های جدید پشتیبانی کنند و پایگاه داده باید از درایورهای قدیمی پشتیبانی کند.

به طور کلی، همه اینها محدودیت هایی ایجاد می کند.

مولفه های سازگاری علّی

اکنون در مورد برخی از مؤلفه ها صحبت خواهم کرد. اگر سازگاری علی را به طور کلی در نظر بگیریم، می‌توانیم بلوک‌ها را انتخاب کنیم. ما از میان کارهایی که به یک بلوک خاص تعلق دارند انتخاب کردیم: ردیابی وابستگی، انتخاب ساعت، نحوه هماهنگ سازی این ساعت ها با یکدیگر، و نحوه تضمین امنیت - این یک طرح کلی از چیزی است که در مورد آن صحبت خواهم کرد:

ردیابی وابستگی کامل

چرا نیاز است؟ به طوری که وقتی داده ها تکرار می شوند، هر رکورد، هر تغییر داده حاوی اطلاعاتی در مورد تغییراتی است که به آن بستگی دارد. اولین و ساده‌ترین تغییر زمانی است که هر پیام حاوی رکورد حاوی اطلاعاتی درباره پیام‌های قبلی باشد:

در این مثال، عدد در پرانتزهای فرفری اعداد رکورد هستند. گاهی اوقات این رکوردها با مقادیر حتی به طور کامل منتقل می شوند، گاهی اوقات برخی از نسخه ها منتقل می شوند. نکته اصلی این است که هر تغییر حاوی اطلاعاتی در مورد قبلی است (بدیهی است که همه اینها را در خود حمل می کند).

چرا تصمیم گرفتیم از این رویکرد (ردیابی کامل) استفاده نکنیم؟ بدیهی است، زیرا این رویکرد غیر عملی است: هر تغییری در یک شبکه اجتماعی به تمام تغییرات قبلی در آن شبکه اجتماعی بستگی دارد، مثلاً فیس بوک یا VKontakte را در هر به روز رسانی منتقل می کند. با این وجود، تحقیقات زیادی در مورد ردیابی وابستگی کامل وجود دارد - اینها شبکه های پیش اجتماعی هستند؛ برای برخی موقعیت ها واقعاً کار می کند.

ردیابی وابستگی صریح

بعدی محدودتر است. انتقال اطلاعات نیز در اینجا در نظر گرفته می شود، اما فقط آن چیزی که به وضوح وابسته است. چه چیزی بستگی به آنچه، به عنوان یک قاعده، توسط برنامه تعیین می شود. هنگامی که داده ها تکرار می شوند، پرس و جو فقط زمانی پاسخ ها را برمی گرداند که وابستگی های قبلی برآورده شده باشند، یعنی نشان داده شده باشند. این جوهر چگونگی کارکرد سازگاری علی است.

او می بیند که رکورد 5 به رکوردهای 1، 2، 3، 4 بستگی دارد - بر این اساس، او منتظر می ماند تا مشتری به تغییرات ایجاد شده توسط تصمیم دسترسی Penny دسترسی پیدا کند، زمانی که همه تغییرات قبلی قبلاً از پایگاه داده عبور کرده باشند.

این برای ما هم مناسب نیست، زیرا هنوز اطلاعات زیادی وجود دارد و باعث کندی کار می شود. رویکرد دیگری نیز وجود دارد ...

ساعت لامپورت

آنها بسیار پیر هستند. ساعت Lamport به این معنی است که این وابستگی ها در یک تابع اسکالر جمع می شوند که به آن ساعت Lamport گفته می شود.

یک تابع اسکالر یک عدد انتزاعی است. اغلب به آن زمان منطقی می گویند. با هر رویداد، این شمارنده افزایش می یابد. شمارنده، که در حال حاضر برای فرآیند شناخته شده است، هر پیام را ارسال می کند. واضح است که فرآیندها می توانند ناهماهنگ باشند، آنها می توانند زمان های کاملاً متفاوتی داشته باشند. با این وجود، سیستم به نوعی ساعت را با چنین پیام‌هایی متعادل می‌کند. در این مورد چه اتفاقی می افتد؟

من آن قطعه بزرگ را به دو قسمت تقسیم کردم تا مشخص شود: دوستان می توانند در یک گره زندگی کنند که شامل قطعه ای از مجموعه است و Feed می تواند در گره دیگری زندگی کند که شامل قطعه ای از این مجموعه است. آیا مشخص است که چگونه می توانند از خط خارج شوند؟ ابتدا فید می گوید: "Replicated" و سپس Friends. اگر تا زمانی که وابستگی های Friends در مجموعه Friends تحویل داده نشود، سیستم به نوعی تضمین نمی کند که Feed نشان داده نخواهد شد، دقیقاً وضعیتی را خواهیم داشت که گفتم.

می بینید که چگونه زمان شمارشگر در فید به طور منطقی افزایش می یابد:

بنابراین ویژگی اصلی این ساعت Lamport و سازگاری علّی (که از طریق ساعت Lamport توضیح داده شده است) این است: اگر رویدادهای A و B را داشته باشیم و رویداد B به رویداد A* بستگی داشته باشد، نتیجه آن این است که زمان منطقی رویداد A کمتر از LogicalTime از رویداد B.

* گاهی اوقات آنها همچنین می گویند که A قبل از B اتفاق افتاده است، یعنی A قبل از B اتفاق افتاده است - این یک رابطه خاص است که تا حدی کل مجموعه رویدادهایی را که به طور کلی اتفاق افتاده است سفارش می دهد.

برعکس آن نادرست است. این در واقع یکی از معایب اصلی ساعت لامپورت است - نظم جزئی. مفهومی در مورد رویدادهای همزمان وجود دارد، یعنی رویدادهایی که نه (الف قبل از ب اتفاق افتاده است) و نه (الف قبل از ب اتفاق افتاده است). یک مثال می‌تواند اضافه کردن موازی لئونارد از شخص دیگری به عنوان دوست باشد (مثلاً نه لئونارد، بلکه شلدون).
این خاصیتی است که اغلب هنگام کار با ساعت های Lamport استفاده می شود: آنها به طور خاص به عملکرد نگاه می کنند و از آن نتیجه می گیرند که شاید این رویدادها وابسته باشند. زیرا یک راه درست است: اگر LogicalTime A کمتر از LogicalTime B باشد، B نمی تواند قبل از A اتفاق بیفتد. و اگر بیشتر، پس شاید.

ساعت وکتور

توسعه منطقی ساعت لامپورت، ساعت برداری است. تفاوت آنها در این است که هر گره ای که در اینجا وجود دارد حاوی ساعت جداگانه خود است و آنها به عنوان یک بردار منتقل می شوند.
در این حالت می بینید که اندیس صفر بردار مسئول Feed است و اولین اندیس بردار مربوط به Friends (هر کدام از این گره ها) است. و اکنون آنها افزایش خواهند یافت: شاخص صفر "Feed" هنگام نوشتن افزایش می یابد - 1، 2، 3:

چرا ساعت برداری بهتر است؟ زیرا آنها به شما امکان می دهند بفهمید کدام رویدادها همزمان هستند و چه زمانی روی گره های مختلف رخ می دهند. این برای سیستم اشتراک گذاری مانند MongoDB بسیار مهم است. با این حال، ما این را انتخاب نکردیم، اگرچه چیز فوق العاده ای است و عالی کار می کند و احتمالاً برای ما مناسب است ...

اگر 10 هزار قطعه داشته باشیم، نمی توانیم 10 هزار جزء را انتقال دهیم، حتی اگر آن را فشرده کنیم یا چیز دیگری به دست آوریم - بار بار هنوز چندین برابر حجم کل این بردار کوچکتر خواهد بود. بنابراین، با دندان قروچه، این رویکرد را کنار گذاشتیم و به سراغ دیگری رفتیم.

آچار TrueTime. ساعت اتمی

گفتم داستانی در مورد اسپنر خواهد بود. این یک چیز جالب است، مستقیماً از قرن بیست و یکم: ساعت های اتمی، همگام سازی GPS.

ایده چیست؟ "Spanner" یک سیستم گوگل است که اخیرا حتی در دسترس مردم قرار گرفته است (آنها SQL را به آن اضافه کردند). هر تراکنش در آنجا دارای مهر زمانی است. از آنجایی که زمان هماهنگ است*، به هر رویداد می توان زمان خاصی را اختصاص داد - ساعت های اتمی یک زمان انتظار دارند، پس از آن زمان متفاوتی برای "اتفاق" تضمین می شود.

بنابراین، صرفاً با نوشتن در پایگاه داده و انتظار برای مدتی، سریال پذیری رویداد به طور خودکار تضمین می شود. آنها قوی ترین مدل سازگاری را دارند که در اصل می توان تصور کرد - این سازگاری خارجی است.

* این مشکل اصلی ساعت های Lampart است - آنها هرگز در سیستم های توزیع شده همزمان نیستند. آنها می توانند واگرا شوند؛ حتی با NTP، آنها هنوز خیلی خوب کار نمی کنند. "Spanner" یک ساعت اتمی دارد و به نظر می رسد هماهنگ سازی میکروثانیه است.

چرا انتخاب نکردیم؟ ما تصور نمی کنیم که کاربران ما یک ساعت اتمی داخلی دارند. هنگامی که آنها ظاهر می شوند و در هر لپ تاپ تعبیه شده اند، نوعی همگام سازی GPS فوق العاده جالب وجود خواهد داشت - پس بله... اما در حال حاضر بهترین چیزی که ممکن است آمازون است، ایستگاه های پایه - برای افراد متعصب... بنابراین ما از ساعت های دیگر استفاده کردیم. .

ساعت هیبریدی

این در واقع همان چیزی است که در MongoDB هنگام اطمینان از سازگاری Causal مشخص می شود. هیبریدشون چطوره؟ Hybrid یک مقدار اسکالر است، اما دارای دو جزء است:

• اولی دوره یونیکس است (چند ثانیه از "آغاز دنیای کامپیوتر" گذشته است).
• دومی مقداری افزایش است، همچنین یک int بدون علامت 32 بیتی.

این همه، در واقع. این رویکرد وجود دارد: بخشی که مسئول زمان است همیشه با ساعت هماهنگ می شود. هر بار که یک به روز رسانی رخ می دهد، این قسمت با ساعت همگام می شود و معلوم می شود که زمان همیشه کم و بیش درست است و افزایش به شما امکان می دهد بین رویدادهایی که در همان نقطه از زمان رخ داده اند تمایز قائل شوید.

چرا این برای MongoDB مهم است؟ زیرا این امکان را به شما می دهد تا در یک نقطه خاص از زمان، نوعی رستوران پشتیبان ایجاد کنید، یعنی رویداد بر اساس زمان ایندکس می شود. این مهم زمانی است که رویدادهای خاصی مورد نیاز است. برای یک پایگاه داده، رویدادها تغییراتی در پایگاه داده هستند که در بازه های زمانی معینی رخ می دهند.

مهم ترین دلیل را فقط به شما می گویم (لطفاً به کسی نگویید)! ما این کار را انجام دادیم زیرا این همان چیزی است که داده های سازمان یافته و فهرست شده در MongoDB OpLog به نظر می رسد. OpLog یک ساختار داده ای است که مطلقاً شامل تمام تغییرات در پایگاه داده است: آنها ابتدا به OpLog می روند و در مواردی که تاریخ یا خرده ای تکرار شده باشد به خود Storage اعمال می شوند.

این دلیل اصلی بود. با این حال، الزامات عملی نیز برای توسعه یک پایگاه داده وجود دارد، به این معنی که باید ساده باشد - کد کمی، تا حد امکان تعداد کمی چیزهای شکسته که نیاز به بازنویسی و آزمایش دارند. این واقعیت که آپلوگ های ما توسط ساعت های هیبریدی ایندکس می شدند کمک زیادی کرد و به ما اجازه داد تا انتخاب درستی داشته باشیم. واقعاً نتیجه داد و به نحوی جادویی روی اولین نمونه اولیه کار کرد. خیلی باحال بود!

همگام سازی ساعت

چندین روش همگام سازی در مقالات علمی شرح داده شده است. من در مورد همگام سازی صحبت می کنم زمانی که ما دو قطعه مختلف داریم. اگر یک مجموعه ماکت وجود داشته باشد، نیازی به هماهنگی نیست: این یک "مستر تک" است. ما یک OpLog داریم که همه تغییرات در آن قرار می گیرند - در این مورد، همه چیز به طور متوالی در خود "Oplog" مرتب شده است. اما اگر دو قطعه متفاوت داشته باشیم، هماهنگ سازی زمان در اینجا مهم است. اینجاست که ساعت برداری کمک بیشتری کرد! اما ما آنها را نداریم.

مورد دوم مناسب است - این "ضربان قلب" است. ممکن است برخی از سیگنال ها را که در هر واحد زمان رخ می دهد، مبادله کرد. اما ضربان قلب بسیار کند است، ما نمی توانیم تاخیری را برای مشتری خود فراهم کنیم.

البته زمان واقعی چیز شگفت انگیزی است. اما، دوباره، احتمالاً این آینده است... اگرچه می‌توان آن را در اطلس انجام داد، هم‌زمان‌کننده‌های سریع «آمازون» از قبل وجود دارد. اما برای همه در دسترس نخواهد بود.

شایعه سازی زمانی است که همه پیام ها شامل زمان می شود. این تقریباً همان چیزی است که ما استفاده می کنیم. هر پیامی بین گره ها، یک درایور، یک روتر گره داده، مطلقاً همه چیز برای MongoDB نوعی عنصر است، یک مؤلفه پایگاه داده که حاوی ساعتی است که اجرا می شود. معنی زمان هیبریدی را در همه جا دارند، منتقل می شود. 64 بیت؟ این اجازه می دهد، این امکان پذیر است.

چگونه همه با هم کار می کنند؟

در اینجا من به یک مجموعه ماکت نگاه می کنم تا کمی ساده تر شود. اولیه و ثانویه وجود دارد. ثانویه همانند سازی انجام می دهد و همیشه به طور کامل با Primary همگام نیست.

یک درج در "Primery" با مقدار زمانی مشخص رخ می دهد. این درج تعداد داخلی را 11 افزایش می دهد، اگر این حداکثر باشد. یا اگر مقادیر ساعت بیشتر باشد، مقادیر ساعت را بررسی می کند و با ساعت همگام می شود. این به شما امکان می دهد تا بر اساس زمان سازماندهی کنید.

پس از اینکه او ضبط را انجام داد، لحظه مهمی رخ می دهد. ساعت در "MongoDB" است و فقط در صورت نوشتن روی "Oplog" افزایش می یابد. این رویدادی است که وضعیت سیستم را تغییر می دهد. در تمام مقالات کلاسیک، یک رویداد زمانی در نظر گرفته می شود که یک پیام به یک گره برخورد کند: پیام رسیده است، به این معنی که سیستم حالت خود را تغییر داده است.

این به این دلیل است که در طول تحقیق کاملاً مشخص نیست که این پیام چگونه تفسیر می شود. ما با اطمینان می دانیم که اگر در "Oplog" منعکس نشود، به هیچ وجه تفسیر نخواهد شد و تغییر در وضعیت سیستم فقط یک ورودی در "Oplog" است. این همه چیز را برای ما ساده می کند: مدل آن را ساده می کند و به ما امکان می دهد آن را در یک مجموعه ماکت سازماندهی کنیم، و بسیاری چیزهای مفید دیگر.

مقداری که قبلاً در "Oplog" نوشته شده است برگردانده می شود - ما می دانیم که "Oplog" قبلاً حاوی این مقدار است و زمان آن 12 است. اکنون، مثلاً، خواندن از یک گره دیگر (ثانویه) شروع می شود و پس از ClusterTime در آن ارسال می شود. پیام. او می گوید: "من به هر چیزی که حداقل بعد از 12 یا در طول دوازده اتفاق افتاده است نیاز دارم" (تصویر بالا را ببینید).

این چیزی است که Causal a Consent (CAT) نامیده می شود. در تئوری چنین مفهومی وجود دارد که این برشی از زمان است که به خودی خود سازگار است. در این حالت می توان گفت که این حالت سیستمی است که در زمان 12 مشاهده شد.

اکنون هیچ چیزی در اینجا وجود ندارد، زیرا این نوع موقعیت زمانی را شبیه سازی می کند که شما به Secondary برای تکرار داده ها از Primary نیاز دارید. او صبر می کند ... و اکنون داده ها رسیده است - او این مقادیر را برمی گرداند.

تقریباً همه چیز اینگونه است. تقریبا.

"تقریبا" به چه معناست؟ بیایید فرض کنیم شخصی وجود دارد که خوانده است و درک کرده است که همه اینها چگونه کار می کند. متوجه شدم که هر بار ClusterTime رخ می دهد، ساعت منطقی داخلی را به روز می کند و سپس ورودی بعدی یک عدد افزایش می یابد. این تابع 20 خط می گیرد. فرض کنید این شخص بزرگترین عدد 64 بیتی منهای یک را ارسال می کند.

چرا "منهای یک"؟ از آنجایی که ساعت داخلی با این مقدار جایگزین می شود (بدیهی است که این بزرگترین زمان ممکن و بزرگتر از زمان فعلی است)، سپس یک ورودی در "Oplog" رخ می دهد، و ساعت توسط واحد دیگری افزایش می یابد - و قبلا وجود خواهد داشت. یک مقدار حداکثر باشد (به سادگی همه واحدها وجود دارند، جای دیگری برای رفتن وجود ندارد)، ints unsaint).

واضح است که پس از این سیستم برای هیچ چیز کاملاً غیر قابل دسترس می شود. فقط می توان آن را تخلیه و تمیز کرد - کارهای دستی زیادی. در دسترس بودن کامل:

علاوه بر این، اگر این در جای دیگری تکرار شود، کل خوشه به سادگی سقوط می کند. یک موقعیت کاملا غیرقابل قبول که هر کسی می تواند خیلی سریع و آسان آن را سازماندهی کند! بنابراین، ما این لحظه را یکی از مهمترین آنها در نظر گرفتیم. چگونه از آن جلوگیری کنیم؟

راه ما امضای clusterTime است

به این ترتیب در پیام (قبل از متن آبی) منتقل می شود. اما ما همچنین شروع به تولید یک امضا (متن آبی) کردیم:

امضا توسط کلیدی تولید می شود که در داخل پایگاه داده، در یک محیط امن ذخیره می شود. خود تولید و به روز می شود (کاربران چیزی در مورد آن نمی بینند). یک هش تولید می‌شود و هر پیام هنگام ایجاد امضا و پس از دریافت اعتبار تأیید می‌شود.
احتمالاً این سؤال در ذهن مردم ایجاد می شود: "این کار چقدر سرعت را کاهش می دهد؟" من به شما گفتم که باید سریع کار کند، مخصوصاً در صورت نبود این ویژگی.

استفاده از سازگاری علّی در این مورد به چه معناست؟ این برای نشان دادن پارامتر afterClusterTime است. بدون این، به هر حال به سادگی مقادیر را منتقل می کند. Gossiping، با شروع از نسخه 3.6، همیشه کار می کند.

اگر نسل ثابت امضاها را رها کنیم، حتی در صورت عدم وجود ویژگی، که رویکردها و الزامات ما را برآورده نمی کند، سیستم را کند می کند. پس چیکار کردیم؟

سریع انجامش بده!

این یک چیز نسبتاً ساده است، اما ترفند جالب است - من آن را به اشتراک خواهم گذاشت، شاید کسی علاقه مند شود.
ما یک هش داریم که داده های امضا شده را ذخیره می کند. تمام داده ها از طریق کش عبور می کنند. حافظه نهان زمان خاصی را نشان نمی دهد، بلکه محدوده را نشان می دهد. وقتی مقداری رسید، یک محدوده تولید می کنیم، 16 بیت آخر را پنهان می کنیم و این مقدار را امضا می کنیم:

با دریافت چنین امضایی، سرعت سیستم را (نسبتا) 65 هزار بار افزایش می دهیم. عالی کار می کند: وقتی آزمایش هایی را انجام دادیم، زمانی که یک به روز رسانی متوالی داشتیم، زمان در واقع 10 هزار بار کاهش می یابد. واضح است که وقتی آنها در تضاد هستند، این کار نمی کند. اما در بیشتر موارد عملی کار می کند. ترکیب امضای Range به همراه امضا مشکل امنیتی را حل کرد.

ما چه آموخته ایم؟

درس هایی که از این موضوع گرفتیم:

• ما باید مطالب، داستان ها، مقالات را بخوانیم، زیرا چیزهای جالب زیادی داریم. وقتی روی برخی از ویژگی‌ها کار می‌کنیم (مخصوصاً اکنون، زمانی که تراکنش‌ها و غیره انجام می‌دادیم)، باید بخوانیم و بفهمیم. زمان می برد، اما در واقع بسیار مفید است زیرا مشخص می کند که کجا هستیم. به نظر نمی رسید چیز جدیدی به ذهنمان برسد - ما فقط مواد تشکیل دهنده را مصرف کردیم.

  به طور کلی، در هنگام برگزاری یک کنفرانس آکادمیک (برای مثال سیگمون) تفاوت خاصی در تفکر وجود دارد - همه بر ایده های جدید تمرکز می کنند. چه چیز جدیدی در مورد الگوریتم ما وجود دارد؟ در اینجا هیچ چیز جدیدی وجود ندارد. تازگی بیشتر در روشی است که ما رویکردهای موجود را با هم ترکیب کردیم. بنابراین، اولین چیز خواندن کلاسیک است، با Lampart شروع کنید.

• در تولید، الزامات کاملاً متفاوت است. من مطمئن هستم که بسیاری از شما با پایگاه‌های داده «کروی» در خلأ انتزاعی مواجه نیستید، بلکه با چیزهای عادی و واقعی مواجه هستید که مشکلات در دسترس بودن، تأخیر و تحمل خطا دارند.
• آخرین مورد این است که ما باید به ایده های مختلف نگاه می کردیم و چندین مقاله کاملاً متفاوت را با هم در یک رویکرد ترکیب می کردیم. به عنوان مثال، ایده امضا، عموماً از مقاله ای ناشی شد که پروتکل Paxos را در نظر گرفت، که برای شکست خوردگان غیر بیزانسی داخل پروتکل مجوز است، برای بیزانسی ها - خارج از پروتکل مجوز... به طور کلی، این دقیقاً همان چیزی است که ما داریم. در نهایت انجام داد.

  هیچ چیز جدیدی در اینجا وجود ندارد! اما به محض این که همه را با هم مخلوط کردیم... مثل این است که بگوییم دستور سالاد اولیویه مزخرف است، زیرا تخم مرغ، سس مایونز و خیار قبلاً اختراع شده اند... درباره همان داستان است.

من با این تمام می کنم. متشکرم!

پرسش

سوال از حضار (از این پس B نامیده می شود): - متشکرم، میخائیل، برای گزارش! موضوع زمان جالب است. شما از Gossiping استفاده می کنید. گفتند هرکس وقت خودش را دارد، هرکس ساعت محلی خودش را می داند. همانطور که من متوجه شدم، ما یک درایور داریم - می‌تواند مشتریان زیادی با درایورها، برنامه‌ریزان جستجو، خرده‌ها نیز وجود داشته باشد. یک دقیقه جلوتر، کسی یک دقیقه عقب تر؟ به کجا خواهیم رسید؟

MT: - واقعاً سوال بزرگی است! من فقط می خواستم در مورد خرده ها صحبت کنم. اگر سوال را درست متوجه شده باشم، وضعیت زیر را داریم: خرده 1 و خرده 2 وجود دارد، خواندن از این دو خرده اتفاق می افتد - آنها اختلاف دارند، با یکدیگر تعامل ندارند، زیرا زمانی که آنها می دانند متفاوت است. به خصوص زمانی که آنها در آپلوگ ها وجود دارند.
فرض کنید که شارد 1 یک میلیون رکورد ایجاد کرد، شارد 2 اصلاً هیچ کاری انجام نداد و درخواست به دو قطعه رسید. و اولین مورد دارای afterClusterTime بیش از یک میلیون است. در چنین شرایطی همانطور که توضیح دادم شارد 2 اصلا جواب نمی دهد.

که در: - می خواستم بدانم چگونه آنها یک زمان منطقی را همگام می کنند و انتخاب می کنند؟

MT: - همگام سازی بسیار آسان شارد، وقتی afterClusterTime به سراغش می آید و زمانی را در "Oplog" پیدا نمی کند، هیچ تاییدی را آغاز نمی کند. یعنی وقتش را با دستانش به این ارزش می برد. این بدان معنی است که هیچ رویدادی مطابق با این درخواست ندارد. او این رویداد را به طور تصنعی ایجاد می کند و در نتیجه به سازگاری علّی تبدیل می شود.

که در: - اگر بعد از این اتفاقات دیگری برای او بیفتد که در جایی از شبکه گم شده است؟

MT: – شارد به گونه ای طراحی شده است که دیگر نیایند، چون تک استاد است. اگر قبلا ثبت نام کرده باشد، نمی آیند، اما بعدا می آیند. این اتفاق نمی افتد که چیزی در جایی گیر کند، سپس او چیزی ننویسد، و سپس این رویدادها از راه می رسد - و سازگاری علّی به هم می خورد. وقتی او هیچ نوشتنی نمی کند، همه آنها باید در مرحله بعدی بیایند (او منتظر آنها خواهد بود).

که در: - چند سوال در مورد صف ها دارم. سازگاری علّی فرض می کند که صف خاصی از اقداماتی وجود دارد که باید انجام شوند. اگر یکی از بسته های ما ناپدید شود چه اتفاقی می افتد؟ اینجا 10، 11 می آید... دوازدهم ناپدید شده است و بقیه منتظرند تا به حقیقت بپیوندد. و ناگهان ماشین ما مرد، ما نمی توانیم کاری انجام دهیم. آیا حداکثر طول صفی که قبل از اجرا جمع می شود وجود دارد؟ چه شکست مهلکی زمانی رخ می دهد که یک حالت از بین برود؟ علاوه بر این، اگر بنویسیم که حالت قبلی وجود دارد، باید به نحوی از آن شروع کنیم؟ اما او را از خود دور نکردند!

MT: - همچنین یک سوال عالی! ما چه کار می کنیم؟ MongoDB مفهوم حد نصاب نوشتن، حد نصاب خواندن را دارد. در چه مواردی ممکن است یک پیام گم شود؟ وقتی نوشتن حد نصاب نیست یا زمانی که خواندن در حد نصاب نیست (ممکن است نوعی زباله نیز بچسبد).
در مورد همسانی علّی، یک آزمون آزمایشی بزرگ انجام شد که نتیجه آن این بود که در مواردی که نوشتن و خواندن در حد نصاب نباشد، نقض قوام علی رخ می دهد. دقیقا همونی که میگی!

توصیه ما: هنگام استفاده از سازگاری علّی، حداقل از حد نصاب خواندن استفاده کنید. در این صورت، هیچ چیز از بین نمی رود، حتی اگر رکورد حد نصاب از بین برود... این یک وضعیت متعامد است: اگر کاربر نمی خواهد داده ها از بین برود، باید از یک رکورد حد نصاب استفاده کند. قوام علت دوام را تضمین نمی کند. دوام توسط تکرار و ماشین آلات مرتبط با تکرار تضمین می شود.

که در: – وقتی نمونه‌ای را ایجاد می‌کنیم که برای ما شاردینگ را انجام می‌دهد (به ترتیب نه master، بلکه slave)، به زمان یونیکس ماشین خودش یا به زمان «master» متکی است. آیا برای اولین بار همگام می شود یا دوره ای؟

MT: -الان توضیح میدم Shard (یعنی پارتیشن افقی) - همیشه یک Primary وجود دارد. و یک خرده می تواند یک "استاد" داشته باشد و می تواند نسخه های مشابهی داشته باشد. اما شارد همیشه از ضبط پشتیبانی می کند، زیرا باید دامنه ای را پشتیبانی کند (شارد دارای Primary است).

که در: - پس همه چیز صرفاً به "استاد" بستگی دارد؟ آیا همیشه از زمان استاد استفاده می شود؟

MT: - آره. شما می توانید به صورت مجازی بگویید: زمانی که ورود به "master" به "Oplog" رخ می دهد، ساعت در حال تیک تیک است.

که در: - ما مشتری داریم که متصل است و نیازی به دانستن چیزی در مورد زمان ندارد؟

MT: - اصلاً لازم نیست چیزی بدانی! اگر در مورد نحوه عملکرد آن بر روی مشتری صحبت کنیم: وقتی مشتری می خواهد از سازگاری علّی استفاده کند، باید یک جلسه باز کند. اکنون همه چیز وجود دارد: تراکنش‌ها در جلسه، و بازیابی حقوق... یک جلسه ترتیب رویدادهای منطقی است که با مشتری اتفاق می‌افتد.

اگر این جلسه را باز کند و آنجا بگوید که سازگاری علت و معلولی را می‌خواهد (اگر جلسه به طور پیش‌فرض از سازگاری علی پشتیبانی می‌کند)، همه چیز به طور خودکار کار می‌کند. راننده این زمان را به خاطر می آورد و با دریافت پیام جدید آن را افزایش می دهد. به یاد می‌آورد که پاسخ قبلی از سروری که داده‌ها را برگردانده است، داده است. درخواست بعدی حاوی afterCluster ("زمان بیشتر از این") خواهد بود.

مشتری نیازی به دانستن مطلق چیزی ندارد! این برای او کاملا مبهم است. اگر مردم از این ویژگی ها استفاده کنند، چه کاری می توانند انجام دهند؟ اول، شما می توانید با خیال راحت ثانویه ها را بخوانید: می توانید به Primary بنویسید و از ثانویه های جغرافیایی تکرار شده بخوانید و مطمئن شوید که کار می کند. در عین حال، جلساتی که در Primary ضبط شده اند حتی می توانند به Secondary منتقل شوند، یعنی می توانید از یک جلسه استفاده نکنید، بلکه از چندین جلسه استفاده کنید.

که در: - لایه جدیدی از علوم محاسباتی - انواع داده های CRDT (انواع داده های تکراری بدون تضاد) - به شدت با موضوع سازگاری نهایی مرتبط است. آیا به ادغام این نوع داده ها در پایگاه داده فکر کرده اید و در مورد آن چه می توانید بگویید؟

MT: - سؤال خوبی بود! CRDT برای تضادهای نوشتن منطقی است: در MongoDB، تک استاد.

که در: - من یک سوال از توسعه دهندگان دارم. در دنیای واقعی، چنین موقعیت های یسوعی وجود دارد که شکست بیزانسی رخ می دهد، و افراد شرور در داخل محیط محافظت شده شروع به هجوم به پروتکل می کنند، بسته های صنایع دستی را به روش خاصی ارسال می کنند؟

MT: - افراد شرور داخل محیط مانند اسب تروا هستند! افراد شرور داخل محیط می توانند کارهای بد زیادی انجام دهند.

که در: – واضح است که به طور کلی، سوراخی در سرور باقی می‌ماند که می‌توانید از طریق آن باغ وحشی از فیل‌ها را قرار دهید و کل خوشه را برای همیشه از بین ببرید... بازیابی دستی زمان می‌برد... این، به بیان ساده، اشتباه. از سوی دیگر، این جالب است: در زندگی واقعی، در عمل، موقعیت هایی وجود دارد که به طور طبیعی حملات داخلی مشابهی رخ می دهد؟

MT: - از آنجایی که من به ندرت با نقض های امنیتی در زندگی واقعی مواجه می شوم، نمی توانم بگویم که این موارد رخ می دهند یا خیر. اما اگر در مورد فلسفه توسعه صحبت کنیم، اینگونه فکر می کنیم: ما محیطی داریم که برای افرادی که امنیت را انجام می دهند، فراهم می کند - این یک قلعه است، یک دیوار. و در داخل محیط می توانید هر کاری که می خواهید انجام دهید. واضح است که کاربرانی وجود دارند که فقط قابلیت مشاهده دارند و کاربرانی هستند که امکان پاک کردن دایرکتوری را دارند.

بسته به حقوق، آسیبی که کاربران می توانند انجام دهند می تواند یک موش یا یک فیل باشد. واضح است که کاربر با حقوق کامل می تواند هر کاری انجام دهد. کاربر با حقوق محدود می تواند آسیب قابل توجهی کمتری ایجاد کند. به ویژه، نمی تواند سیستم را بشکند.

که در: – در محیط محافظت شده، شخصی سعی کرد پروتکل‌های غیرمنتظره‌ای را برای سرور ایجاد کند تا سرور را کاملاً از بین ببرد، و اگر خوش شانس باشید، کل خوشه... آیا هرگز به این «خوب» می‌رسد؟

MT: "من هرگز در مورد چنین چیزهایی نشنیده ام." این واقعیت که شما می توانید سرور را از این طریق خراب کنید، هیچ رازی نیست. Fail inside، از پروتکل بودن، کاربر مجاز بودن که می تواند چیزی شبیه به این را در پیام بنویسد... در واقع غیرممکن است، زیرا هنوز تایید خواهد شد. غیرفعال کردن این احراز هویت برای کاربرانی که آن را نمی‌خواهند ممکن است - پس مشکل آنها این است. به طور تقریبی دیوارها را خودشان خراب کردند و می توانی یک فیل را به داخل هل بدهی که زیر پا می گذارد... اما در کل می توانی لباس تعمیرکار بپوشی، بیا بیرونش!

که در: - ممنون از گزارش سرگئی (Yandex). ثابتی در Mong وجود دارد که تعداد اعضای رای دهنده در Replica Set را محدود می کند و این ثابت 7 (هفت) است. چرا این ثابت است؟ چرا این یک نوع پارامتر نیست؟

MT: - ما Replica Sets با 40 گره داریم. همیشه اکثریت وجود دارد. نمیدونم کدوم نسخه...

که در: – در Replica Set می‌توانید اعضایی را اجرا کنید که حق رای ندارند، اما حداکثر 7 عضو رای‌دهنده وجود دارد. اگر مجموعه Replica ما در 3 مرکز داده پخش شده باشد، چگونه می‌توانیم از خاموش شدن جان سالم به در ببریم؟ یک مرکز داده می تواند به راحتی خاموش شود و دستگاه دیگری می تواند سقوط کند.

MT: - این در حال حاضر کمی فراتر از محدوده گزارش است. این یک سوال کلی است. شاید بتوانم بعداً در مورد آن به شما بگویم.

چند تبلیغ 🙂

از اینکه با ما ماندید متشکرم آیا مقالات ما را دوست دارید؟ آیا می خواهید مطالب جالب تری ببینید؟ با ثبت سفارش یا معرفی به دوستان از ما حمایت کنید ابر VPS برای توسعه دهندگان از 4.99 دلار, یک آنالوگ منحصر به فرد از سرورهای سطح ورودی که توسط ما برای شما اختراع شده است: تمام حقیقت در مورد VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps از 19 دلار یا چگونه سرور را به اشتراک بگذاریم؟ (در دسترس با RAID1 و RAID10، حداکثر 24 هسته و حداکثر 40 گیگابایت DDR4).

Dell R730xd 2 برابر ارزان تر در مرکز داده 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.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - از 99 دلار! در مورد بخوانید نحوه ساخت شرکت زیرساخت کلاس با استفاده از سرورهای Dell R730xd E5-2650 v4 به ارزش 9000 یورو برای یک پنی؟

منبع: www.habr.com