در راه پایگاه های داده بدون سرور - چگونه و چرا

سلام به همه! نام من گولوف نیکولای است. قبلاً در Avito کار می کردم و به مدت شش سال پایگاه داده را مدیریت می کردم، یعنی روی همه پایگاه های داده کار می کردم: تحلیلی (Vertica، ClickHouse)، جریان و OLTP (Redis، Tarantool، VoltDB، MongoDB، PostgreSQL). در طول این مدت، من با تعداد زیادی پایگاه داده - بسیار متفاوت و غیر معمول و با موارد غیر استاندارد استفاده از آنها سروکار داشتم.

من در حال حاضر در ManyChat کار می کنم. در اصل، این یک استارت آپ است - جدید، جاه طلب و به سرعت در حال رشد. و زمانی که من برای اولین بار به شرکت پیوستم، یک سوال کلاسیک مطرح شد: "یک استارتاپ جوان اکنون چه چیزی باید از بازار DBMS و پایگاه داده بگیرد؟"

در این مقاله، بر اساس گزارش من در جشنواره آنلاین RIT++2020، من به این سوال پاسخ خواهم داد. نسخه تصویری گزارش در این آدرس موجود است یوتیوب.

پایگاه های داده رایج 2020

سال 2020 است، من به اطراف نگاه کردم و سه نوع پایگاه داده را دیدم.

نوع اول - پایگاه داده های کلاسیک OLTP: PostgreSQL، SQL Server، Oracle، MySQL. آنها مدت ها پیش نوشته شده اند، اما هنوز هم مرتبط هستند زیرا برای جامعه توسعه دهندگان بسیار آشنا هستند.

نوع دوم است پایه از "صفر". آنها سعی کردند با کنار گذاشتن SQL، ساختارهای سنتی و ACID، با افزودن شاردینگ داخلی و سایر ویژگی های جذاب، از الگوهای کلاسیک دور شوند. به عنوان مثال، این Cassandra، MongoDB، Redis یا Tarantool است. همه این راه‌حل‌ها می‌خواستند چیزی اساساً جدید به بازار ارائه دهند و جایگاه آنها را اشغال کردند زیرا معلوم شد برای کارهای خاص بسیار راحت هستند. من این پایگاه های داده را با عبارت چتر NOSQL نشان خواهم داد.

"صفرها" به پایان رسید، ما به پایگاه های داده NOSQL عادت کردیم، و جهان، از دیدگاه من، قدم بعدی را برداشت. پایگاه های داده مدیریت شده. این پایگاه‌های اطلاعاتی هسته‌ای مشابه پایگاه‌های داده OLTP کلاسیک یا پایگاه‌های جدید NoSQL دارند. اما آنها نیازی به DBA و DevOps ندارند و روی سخت افزار مدیریت شده در فضای ابری اجرا می شوند. برای یک توسعه دهنده، این فقط یک پایه است که در جایی کار می کند، اما هیچ کس اهمیت نمی دهد که چگونه روی سرور نصب می شود، چه کسی سرور را پیکربندی کرده و چه کسی آن را به روز می کند.

نمونه هایی از این پایگاه های داده:

• AWS RDS یک پوشش مدیریت شده برای PostgreSQL/MySQL است.
• DynamoDB یک آنالوگ AWS از یک پایگاه داده مبتنی بر سند است، شبیه به Redis و MongoDB.
• Amazon Redshift یک پایگاه داده تحلیلی مدیریت شده است.

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

توجه داشته باشید. مثال‌ها برای محیط AWS گرفته شده‌اند، اما مشابه‌های آن‌ها در Microsoft Azure، Google Cloud یا Yandex.Cloud نیز وجود دارد.

چه خبر در این مورد؟ در سال 2020، هیچ کدام از اینها.

مفهوم بدون سرور

آنچه واقعاً در سال 2020 در بازار وجود دارد راه حل های بدون سرور یا بدون سرور است.

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

آیا راه دیگری وجود دارد؟ با خدمات بدون سرور می توانید.

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

من سعی خواهم کرد این رویکرد را با تصاویر نشان دهم.


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

همانطور که در تصویر مشاهده می کنید، سرورها به طور یکسان دفع نمی شوند. یکی 100٪ استفاده شده است، دو درخواست وجود دارد، و یکی فقط 50٪ - تا حدی بیکار است. اگر نه سه درخواست، بلکه 30 درخواست وارد شود، کل سیستم قادر به مقابله با بار نخواهد بود و شروع به کاهش سرعت می کند.

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

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

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

محدودیت مشترک همه این پایگاه های داده چیست؟ اینها هزینه های یک سرور ابری یا سخت افزاری (یا چندین سرور) است که دائماً استفاده می شود. فرقی نمی‌کند از پایگاه داده کلاسیک یا مدیریت‌شده استفاده می‌کنیم، Devops و ادمین داریم یا نه، ما همچنان هزینه سخت‌افزار، برق و اجاره مرکز داده را 24/7 پرداخت می‌کنیم. اگر پایه کلاسیک داشته باشیم برای ارباب و برده پول می دهیم. اگر یک پایگاه داده خرد شده با بارگذاری بالا باشد، ما برای 10، 20 یا 30 سرور پرداخت می کنیم و دائماً پرداخت می کنیم.

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

پایگاه داده بدون سرور - تئوری

سوال 2020: آیا می توان پایگاه داده را بدون سرور نیز ساخت؟ همه در مورد بک اند بدون سرور شنیده اند ... بیایید سعی کنیم پایگاه داده را بدون سرور کنیم؟

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

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

بر این اساس، ایده این است: اگر بخشی از منطق اجازه اجرای بدون دولت را می دهد، چرا پایگاه را به دو بخش Stateful و Stateless تقسیم نکنیم.

بدون سرور برای راه حل های OLAP

بیایید ببینیم با استفاده از مثال‌های عملی، برش یک پایگاه داده به بخش‌های Stateful و Stateless چگونه است.

مثلا ما یک پایگاه داده تحلیلی داریم: داده های خارجی (سیلندر قرمز در سمت چپ)، یک فرآیند ETL که داده ها را در پایگاه داده بارگذاری می کند، و یک تحلیلگر که پرس و جوهای SQL را به پایگاه داده ارسال می کند. این یک طرح عملیاتی انبار داده کلاسیک است.

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

بیایید به یک رویکرد جایگزین پیاده سازی شده در AWS Athena Serverless نگاه کنیم. هیچ سخت افزار اختصاصی دائمی وجود ندارد که داده های دانلود شده روی آن ذخیره شود. به جای این:

• کاربر یک پرس و جوی SQL را به آتنا ارسال می کند. بهینه ساز Athena پرس و جوی SQL را تجزیه و تحلیل می کند و ذخیره ابرداده (Metadata) را برای داده های خاص مورد نیاز برای اجرای پرس و جو جستجو می کند.
• بهینه ساز، بر اساس داده های جمع آوری شده، داده های لازم را از منابع خارجی به ذخیره سازی موقت (پایگاه داده موقت) دانلود می کند.
• پرس و جوی SQL از کاربر در فضای ذخیره سازی موقت اجرا می شود و نتیجه به کاربر بازگردانده می شود.
• حافظه موقت پاک شده و منابع آزاد می شوند.

در این معماری ما فقط هزینه فرآیند اجرای درخواست را پرداخت می کنیم. بدون درخواست - بدون هزینه.

این یک رویکرد کاری است و نه تنها در Athena Serverless، بلکه در Redshift Spectrum (در AWS) نیز پیاده سازی شده است.

مثال آتنا نشان می دهد که پایگاه داده بدون سرور بر روی پرس و جوهای واقعی با ده ها و صدها ترابایت داده کار می کند. صدها ترابایت به صدها سرور نیاز دارند، اما ما مجبور نیستیم برای آنها هزینه ای بپردازیم - ما برای درخواست ها هزینه می کنیم. سرعت هر درخواست در مقایسه با پایگاه داده های تخصصی تحلیلی مانند Vertica (بسیار) پایین است، اما ما برای دوره های خرابی هزینه ای پرداخت نمی کنیم.

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

بدون سرور برای راه حل های OLTP

مثال قبلی به وظایف OLAP (تحلیلی) نگاه کرد. حالا بیایید به وظایف OLTP نگاه کنیم.

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

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

درون شفق قطبی مفهوم واحد ظرفیت Aurora، ACU وجود دارد. این (مشروط) یک نمونه (سرور) است. هر ACU خاص می تواند یک Master یا Slave باشد. هر واحد ظرفیت دارای رم، پردازنده و حداقل دیسک مخصوص به خود است. بر این اساس، یکی استاد است، بقیه فقط کپی خواندنی هستند.

تعداد این واحدهای ظرفیت Aurora در حال اجرا یک پارامتر قابل تنظیم است. حداقل مقدار می تواند یک یا صفر باشد (در این مورد، اگر درخواستی وجود نداشته باشد، پایگاه داده کار نمی کند).

هنگامی که پایگاه درخواست ها را دریافت می کند، ناوگان پراکسی واحد ظرفیت Aurora را افزایش می دهد و منابع عملکرد سیستم را افزایش می دهد. توانایی افزایش و کاهش منابع به سیستم اجازه می‌دهد تا منابع را «جلوگیری» کند: به‌طور خودکار ACU‌های جداگانه را نمایش می‌دهد (آنها را با موارد جدید جایگزین می‌کند) و همه به‌روزرسانی‌های فعلی را برای منابع برداشت‌شده منتشر می‌کند.

پایگاه بدون سرور Aurora می تواند بار خواندن را مقیاس کند. اما مستندات این را مستقیماً نمی گوید. ممکن است به نظر برسد که آنها می توانند یک مولتی مستر را بلند کنند. هیچ جادویی وجود ندارد.

این پایگاه داده برای جلوگیری از صرف مبالغ هنگفت پول برای سیستم هایی با دسترسی غیرقابل پیش بینی مناسب است. به عنوان مثال، هنگام ایجاد سایت های کارت ویزیت MVP یا بازاریابی، معمولاً انتظار یک بار پایدار را نداریم. بر این اساس، در صورت عدم دسترسی، ما هزینه ای برای نمونه ها پرداخت نمی کنیم. هنگامی که بار غیرمنتظره رخ می دهد، به عنوان مثال پس از یک کنفرانس یا کمپین تبلیغاتی، جمعیت زیادی از سایت بازدید می کنند و بار به طور چشمگیری افزایش می یابد، Aurora Serverless به طور خودکار این بار را می گیرد و به سرعت منابع از دست رفته (ACU) را به هم متصل می کند. سپس کنفرانس می گذرد، همه نمونه اولیه را فراموش می کنند، سرورها (ACU) تاریک می شوند و هزینه ها به صفر می رسد - راحت است.

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

هیچ جادوی وجود ندارد - PostgreSQL معمولی است. اما روند اضافه کردن ماشین آلات و قطع آنها تا حدی خودکار است.

بدون سرور از نظر طراحی

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

این پایه Snowflake نام دارد. دارای سه بلوک کلیدی است.

اولی بلوک فراداده است. این یک سرویس سریع در حافظه است که مشکلات مربوط به امنیت، ابرداده، تراکنش ها و بهینه سازی پرس و جو را حل می کند (در تصویر سمت چپ نشان داده شده است).

بلوک دوم مجموعه ای از خوشه های محاسبات مجازی برای محاسبات است (در تصویر مجموعه ای از دایره های آبی وجود دارد).

بلوک سوم یک سیستم ذخیره سازی داده مبتنی بر S3 است. S3 ذخیره سازی اشیاء بدون بعد در AWS است، به نوعی مانند Dropbox بدون بعد برای تجارت.

بیایید ببینیم Snowflake چگونه کار می کند، با فرض شروع سرد. یعنی یک پایگاه داده وجود دارد، داده ها در آن بارگذاری می شوند، هیچ کوئری در حال اجرا وجود ندارد. بر این اساس، اگر هیچ درخواستی برای پایگاه داده وجود نداشته باشد، ما سرویس Metadata سریع در حافظه (بلوک اول) را افزایش داده ایم. و ما فضای ذخیره سازی S3 را داریم که در آن داده های جدول ذخیره می شود و به اصطلاح به میکروپارتیشن تقسیم می شود. برای سادگی: اگر جدول شامل تراکنش‌ها باشد، ریزپارتیشن‌ها روزهای تراکنش هستند. هر روز یک میکروپارتیشن جداگانه، یک فایل جداگانه است. و زمانی که پایگاه داده در این حالت کار می کند، شما فقط هزینه فضای اشغال شده توسط داده ها را پرداخت می کنید. علاوه بر این، نرخ هر صندلی بسیار پایین است (به ویژه با در نظر گرفتن فشرده سازی قابل توجه). سرویس ابرداده نیز به طور مداوم کار می کند، اما برای بهینه سازی پرس و جوها به منابع زیادی نیاز ندارید و این سرویس را می توان به عنوان Shareware در نظر گرفت.

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

در مرحله بعد، سرویس راه اندازی خوشه محاسباتی را آغاز می کند. خوشه محاسباتی مجموعه ای از سرورهایی است که محاسبات را انجام می دهند. یعنی این خوشه ای است که می تواند شامل 1 سرور، 2 سرور، 4، 8، 16، 32 باشد - به تعداد دلخواه. شما یک درخواست پرتاب می کنید و راه اندازی این خوشه بلافاصله شروع می شود. واقعا چند ثانیه طول میکشه

در مرحله بعد، پس از شروع کلاستر، ریزپارتیشن های مورد نیاز برای پردازش درخواست شما شروع به کپی شدن در خوشه از S3 می کنند. یعنی بیایید تصور کنیم که برای اجرای یک کوئری SQL به دو پارتیشن از یک جدول و یکی از جدول دوم نیاز دارید. در این حالت، فقط سه پارتیشن ضروری در خوشه کپی می شوند و نه همه جداول به طور کامل. به همین دلیل است، و دقیقاً به این دلیل که همه چیز در یک مرکز داده قرار دارد و توسط کانال‌های بسیار سریع به هم متصل می‌شود، کل فرآیند انتقال بسیار سریع اتفاق می‌افتد: در چند ثانیه، به ندرت در چند دقیقه، مگر اینکه در مورد درخواست‌های هیولایی صحبت کنیم. بر این اساس، ریزپارتیشن‌ها در خوشه محاسباتی کپی می‌شوند و پس از تکمیل، کوئری SQL روی این خوشه محاسباتی اجرا می‌شود. نتیجه این درخواست می تواند یک خط، چندین خط یا یک جدول باشد - آنها به صورت خارجی برای کاربر ارسال می شوند تا بتواند آن را دانلود کند، آن را در ابزار BI خود نمایش دهد یا به روش دیگری از آن استفاده کند.

هر پرس و جوی SQL نه تنها می تواند انبوه ها را از داده های بارگذاری شده قبلی بخواند، بلکه می تواند داده های جدیدی را در پایگاه داده بارگذاری/تولید کند. یعنی می‌تواند کوئری باشد که برای مثال رکوردهای جدیدی را در جدول دیگری وارد می‌کند که منجر به ظاهر شدن یک پارتیشن جدید در خوشه محاسباتی می‌شود که به نوبه خود به‌طور خودکار در یک حافظه S3 ذخیره می‌شود.

سناریویی که در بالا توضیح داده شد، از ورود کاربر تا بالا بردن خوشه، بارگذاری داده ها، اجرای پرس و جوها، به دست آوردن نتایج، با نرخ چند دقیقه استفاده از خوشه محاسبات مجازی افزایش یافته، انبار مجازی پرداخت می شود. نرخ بسته به منطقه AWS و اندازه خوشه متفاوت است، اما به طور متوسط ​​چند دلار در ساعت است. یک خوشه از چهار ماشین دو برابر گرانتر از یک خوشه از دو ماشین است و یک خوشه از هشت ماشین هنوز دو برابر گران است. بسته به پیچیدگی درخواست ها، گزینه های 16، 32 دستگاه موجود است. اما شما فقط برای دقایقی که کلاستر در حال اجرا است پرداخت می کنید، زیرا وقتی هیچ درخواستی وجود ندارد، به نوعی دست خود را بردارید و بعد از 5-10 دقیقه انتظار (یک پارامتر قابل تنظیم) خود به خود خاموش می شود. منابع را آزاد کنید و رایگان شوید.

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

اولین سناریوی استفاده از Snowflake در یک تنظیمات تک کاربره را توصیف کرد. حالا بیایید تصور کنیم که کاربران زیادی وجود دارد که به سناریوی واقعی نزدیکتر است.

بیایید بگوییم که ما تحلیلگران و گزارش های Tableau زیادی داریم که دائما پایگاه داده ما را با تعداد زیادی پرس و جوی ساده تحلیلی SQL بمباران می کنند.

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

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

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

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

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

فرصتی که در بالا توضیح داده شد به شما این امکان را می دهد که نه تنها 2، بلکه انواع بیشتری از حجم کار را به خوشه ها تقسیم کنید (ETL، نظارت، تحقق گزارش،...).

بیایید Snowflake را خلاصه کنیم. پایه ترکیبی از یک ایده زیبا و یک پیاده سازی قابل اجرا است. در ManyChat، ما از Snowflake برای تجزیه و تحلیل تمام داده هایی که در اختیار داریم استفاده می کنیم. ما مانند مثال سه خوشه نداریم، اما از 5 تا 9، با اندازه های مختلف. ما 16 ماشین معمولی، 2 ماشین و همچنین 1 ماشین فوق العاده کوچک برای برخی کارها داریم. آنها با موفقیت بار را توزیع می کنند و به ما اجازه می دهند تا مقدار زیادی صرفه جویی کنیم.

پایگاه داده با موفقیت بار خواندن و نوشتن را مقیاس می کند. این یک تفاوت بزرگ و یک پیشرفت بزرگ در مقایسه با همان "آرورا" است که فقط بار خواندن را تحمل می کند. Snowflake به شما این امکان را می دهد که حجم کار نوشتن خود را با این خوشه های محاسباتی افزایش دهید. یعنی همانطور که اشاره کردم، ما در ManyChat از چندین کلاستر استفاده می کنیم، خوشه های کوچک و فوق کوچک عمدتاً برای ETL، برای بارگذاری داده ها استفاده می شوند. و تحلیلگران در حال حاضر روی خوشه های متوسط ​​زندگی می کنند، که مطلقاً تحت تأثیر بار ETL قرار نمی گیرند، بنابراین خیلی سریع کار می کنند.

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

مجموع

یک پایگاه داده بدون سرور با تقسیم پایگاه داده به بخش های Stateless و Stateful امکان پذیر است. ممکن است متوجه شده باشید که در تمام مثال‌های بالا، بخش Stateful، به طور نسبی، میکرو پارتیشن‌ها را در S3 ذخیره می‌کند، و Stateless بهینه‌ساز است، با متادیتا کار می‌کند، و مسائل امنیتی را مدیریت می‌کند که می‌توان آن‌ها را به‌عنوان سرویس‌های سبک‌وزن مستقل بدون وضعیت مطرح کرد.

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

پایگاه داده های سطح تولید بدون سرور در حال حاضر برای استفاده در دسترس هستند، آنها کار می کنند. این پایگاه‌های داده بدون سرور از قبل آماده انجام وظایف OLAP هستند. متأسفانه، برای وظایف OLTP از آنها استفاده می شود ... با تفاوت های ظریف، زیرا محدودیت هایی وجود دارد. از یک طرف، این یک منفی است. اما، از سوی دیگر، این یک فرصت است. شاید یکی از خوانندگان راهی برای ایجاد یک پایگاه داده OLTP کاملاً بدون سرور، بدون محدودیت های Aurora پیدا کند.

امیدوارم براتون جالب بوده باشه بدون سرور آینده است :)

منبع: www.habr.com