لینک کوتاه مطلب : https://hsgar.com/?p=5430

مقاله DynamoDB – وبلاگ مارک

پایگاه داده دیگر به نام Dynamo

این هفته در USENIX ATC’22، گروهی از همکارانم1 از تیم AWS DynamoDB قرار است مقاله خود را ارائه دهند Amazon DynamoDB: یک سرویس پایگاه داده NoSQL مقیاس پذیر، قابل پیش بینی و کاملاً مدیریت شده. این مقاله نگاهی نادر به یک سیستم توزیع شده در دنیای واقعی است که در مقیاس عظیم اجرا می شود.

از روی کاغذ:

در سال 2021، در طول رویداد خرید 66 ساعته Amazon Prime Day، سیستم های آمازون … تریلیون ها تماس API را با DynamoDB انجام دادند که به 89.2 میلیون درخواست در ثانیه رسید.

89 میلیون درخواست در ثانیه یک پایگاه داده بزرگ با هر استانداردی است (و این فقط استفاده آمازون از DynamoDB است)!

چیزی که در مورد این مقاله برای من هیجان انگیز است این است که سفر DynamoDB را پوشش می دهد و اینکه چگونه در طول زمان تغییر کرده است تا نیازهای مشتریان را برآورده کند. مقالات نسبتا کمی وجود دارد که این نوع تغییر را در طول زمان پوشش دهد. مثلا:

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

این یک نوع فرض در طراحی سیستم است – که تقسیم کردن باعث بهتر شدن عملکرد می شود – که هنگام طراحی یک سیستم واقعاً نادیده گرفته می شود، و به طور بالقوه رفع آن در زمان تولید مشکل است. بسیاری از مواردی که سیستم‌هایی مانند DynamoDB را بسیار مفید می‌سازد این است که آنها این درس‌ها را آماده می‌کنند، و افرادی که از آنها استفاده می‌کنند نیازی به یادگیری همان درس ندارند.

کمی کلیدی از تاریخ2:

این بحث‌های معماری در آمازون DynamoDB، یک سرویس عمومی که در سال 2012 راه‌اندازی شد و بیشتر نام سیستم قبلی Dynamo را داشت، اما کمی از معماری آن را به اشتراک می‌گذاشت، به اوج خود رسید.

با خواندن بقیه مقاله DynamoDB می توانید تأثیر Dynamo را مشاهده کنید، اما همچنین برخی از تفاوت های عمده در معماری را مشاهده می کنید. قابل توجه ترین، احتمالا، این است که DynamoDB از Multi Paxos استفاده می کند3 برای همگام نگه داشتن کپی ها:

کپی های یک پارتیشن یک گروه تکرار را تشکیل می دهند. گروه تکرار از Multi-Paxos برای انتخاب رهبر و اجماع استفاده می کند.

و یک مدل نسبتاً ساده انتخاب رهبر برای خواندن و نوشتن مداوم:

فقط ماکت رهبر می‌تواند درخواست‌های خواندنی نوشتاری و کاملاً سازگار را ارائه کند. به محض دریافت درخواست نوشتن، رهبر گروه تکرار برای کلید در حال نوشتن یک رکورد ثبت پیش از نوشتن تولید می کند و آن را برای همتای خود (مثنی ها) ارسال می کند. … هر کپی از گروه تکرار می تواند در نهایت قرائت های ثابتی ارائه دهد.

مانند بسیاری از سیستم‌های بزرگ در AWS، تیم DynamoDB از روش‌های رسمی (مخصوصا TLA+) برای تعیین و مدل‌سازی قسمت‌های اصلی سیستم خود استفاده می‌کند:

ما از روش های رسمی به طور گسترده برای اطمینان از صحت پروتکل های تکرار خود استفاده می کنیم. پروتکل تکرار هسته با استفاده از TLA+ مشخص شد.

حافظه پنهان و فراپایداری

یکی دیگر از درس های عالی از مقاله یادآوری در مورد خطرات حافظه پنهان است (نگاه کنید به کش ها، حالت ها و سیستم های ناپایدار):

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

چه چیزی در مورد نرخ ضربه 99.75 درصد حافظه پنهان را دوست ندارید؟ حالت های شکست!

نکته منفی این است که ذخیره سازی رفتار دووجهی را معرفی می کند. در مورد شروع سرد که در آن روترهای درخواست دارای حافظه پنهان خالی هستند، هر درخواست DynamoDB منجر به جستجوی ابرداده می‌شود و بنابراین سرویس باید برای ارائه درخواست‌ها با همان سرعت DynamoDB مقیاس می‌شد.

بنابراین این جدول فراداده باید از رسیدگی به 0.25 درصد درخواست ها تا رسیدگی به 100 درصد درخواست ها مقیاس شود. افزایش بالقوه 400 برابری در ترافیک! طراحی و نگهداری چیزی که بتواند با افزایش نادر 400 برابری ترافیک مقابله کند، بسیار سخت است. برای رفع این مشکل، تیم DynamoDB یک کش توزیع شده به نام MemDS معرفی کرد.

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

که منجر به کار پس زمینه بیشتر، اما تقویت کمتر در موارد شکست می شود.

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

این خرابی‌های آبشاری می‌توانند منجر به حالت‌های شکست غیرپایدار شوند و بنابراین از نظر معماری و نزدیک‌تر شدن آنها به کار مداوم مهم است. باز هم، این همان بینشی است که از اجرای سیستم‌های بزرگ برای مدت طولانی و بخش بزرگی از ارزشی است که در DynamoDB ایجاد می‌شود.

مقاله را بررسی کنید. اگر به پایگاه‌های داده، سیستم‌های توزیع‌شده یا واقعیت‌های اجرای سیستم‌های در مقیاس علاقه‌مند هستید، ارزش وقت شما را دارد!

پانویسها و منابع

  1. مصطفی الهیملی، نایل گالاگر، نیکلاس گوردون، جوزف یدزیورک، ریچارد کروگ، کالین لازیر، اربن مو، آخیلش مریتونجی، سومو پریانایاگام، تیم راث، سوامی سیواسوبرامانیان، جیمز کریستوفر سورنسون سوم، سرواج سوسوتیکول، داگ تری، و آکاشات تری اغلب در AWS انجام دهید، این لیست به ترتیب حروف الفبا است، نه به ترتیب معمول دانشگاهی “نویسنده اول” که ممکن است بیشتر با آن آشنا باشید).
  2. با اشاره به سیستمی که در De Candia و همکارانش توضیح داده شده است، Dynamo: فروشگاه با ارزش کلیدی بسیار در دسترس آمازون. آن مقاله به حق بسیار مشهور و تأثیرگذار است.
  3. Paxos، طبق معمول، به عنوان لاک پشت پایین ظاهر می شود، یک سیستم مقیاس کردن.

لینک منبع

ارسال یک پاسخ

آدرس ایمیل شما منتشر نخواهد شد.