Здравейте всички! Казвам се Голов Николай. Преди това работих в Avito и управлявах Data Platform в продължение на шест години, тоест работих върху всички бази данни: аналитични (Vertica, ClickHouse), стрийминг и OLTP (Redis, Tarantool, VoltDB, MongoDB, PostgreSQL). През това време се занимавах с голям брой бази данни - много различни и необичайни, и с нестандартни случаи на тяхното използване.
В момента работя в ManyChat. По същество това е стартъп - нов, амбициозен и бързо развиващ се. И когато за първи път се присъединих към компанията, възникна един класически въпрос: „Какво трябва да вземе един млад стартиращ бизнес от пазара на СУБД и бази данни?“
В тази статия, въз основа на моя доклад на , ще отговоря на този въпрос. Видео версия на доклада е достъпна на .
Общоизвестни бази данни 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 контейнера. И внедряването на хардуерни сървъри вече е работа на облачния доставчик. Той е напълно скрит от рамката без сървър. В тази концепция ние плащаме за всяко обаждане. Например, едно обаждане дойде на ден - платихме за едно обаждане, дойде милион на минута - платихме милион. Или след секунда и това се случва.
Концепцията за публикуване на функция без сървър е подходяща за услуга без състояние. И ако имате нужда от (държавна) услуга с пълно състояние, тогава ние добавяме база данни към услугата. В този случай, когато става въпрос за работа със състояние, всяка функция за пълно състояние просто пише и чете от базата данни. Освен това от база данни от всеки от трите типа, описани в началото на статията.
Какво е общото ограничение на всички тези бази данни? Това са разходите за постоянно използван облачен или хардуерен сървър (или няколко сървъра). Няма значение дали използваме класическа или управлявана база данни, дали имаме Devops и администратор или не, ние все още плащаме за хардуер, електричество и наем на център за данни 24/7. Ако имаме класическа база, плащаме за master и slave. Ако това е силно натоварена шардинг база данни, плащаме за 10, 20 или 30 сървъра и плащаме постоянно.
Наличието на постоянно запазени сървъри в структурата на разходите преди това се възприемаше като необходимо зло. Конвенционалните бази данни също имат други трудности, като ограничения за броя на връзките, ограничения за мащабиране, гео-разпределен консенсус - те могат по някакъв начин да бъдат решени в определени бази данни, но не всички наведнъж и не идеално.
База данни без сървър – теория
Въпрос от 2020 г.: възможно ли е да се направи и база данни без сървър? Всеки е чувал за бекенда без сървър... нека опитаме да направим базата данни без сървър?
Това звучи странно, защото базата данни е услуга с пълно състояние, не е много подходяща за инфраструктура без сървър. В същото време състоянието на базата данни е много голямо: гигабайти, терабайти, а в аналитичните бази данни дори петабайти. Не е толкова лесно да го отгледате в леки Docker контейнери.
От друга страна, почти всички съвременни бази данни съдържат огромно количество логика и компоненти: транзакции, координация на целостта, процедури, релационни зависимости и много логика. За доста голяма логика на база данни е достатъчно малко състояние. Гигабайтите и терабайтите се използват директно от само малка част от логиката на базата данни, участваща в директното изпълнение на заявки.
Съответно идеята е: ако част от логиката позволява изпълнение без състояние, защо да не разделим базата на части с състояние и без състояние.
Без сървър за OLAP решения
Нека да видим как може да изглежда разрязването на база данни на части с състояние и без състояние, използвайки практически примери.
Например имаме аналитична база данни: външни данни (червен цилиндър отляво), ETL процес, който зарежда данни в базата данни, и анализатор, който изпраща SQL заявки към базата данни. Това е класическа схема за работа на склад за данни.
В тази схема ETL условно се изпълнява веднъж. След това трябва постоянно да плащате за сървърите, на които базата данни работи с данни, пълни с ETL, така че да има към какво да изпращате заявки.
Нека да разгледаме алтернативен подход, внедрен в AWS Athena Serverless. Няма постоянно специализиран хардуер, на който да се съхраняват изтеглените данни. Вместо това:
- Потребителят изпраща SQL заявка до Athena. Оптимизаторът на Athena анализира SQL заявката и търси в хранилището на метаданни (Metadata) конкретните данни, необходими за изпълнение на заявката.
- Оптимизаторът, въз основа на събраните данни, изтегля необходимите данни от външни източници във временно хранилище (временна база данни).
- SQL заявка от потребителя се изпълнява във временно хранилище и резултатът се връща на потребителя.
- Временното хранилище се изчиства и ресурсите се освобождават.
В тази архитектура ние плащаме само за процеса на изпълнение на заявката. Няма заявки - няма разходи.
Това е работещ подход и се прилага не само в Athena Serverless, но и в Redshift Spectrum (в AWS).
Примерът на Athena показва, че базата данни без сървър работи на реални заявки с десетки и стотици терабайти данни. Стотици терабайти ще изискват стотици сървъри, но ние не трябва да плащаме за тях - ние плащаме за заявките. Скоростта на всяка заявка е (много) ниска в сравнение със специализирани аналитични бази данни като Vertica, но ние не плащаме за периоди на престой.
Такава база данни е приложима за редки аналитични ad hoc заявки. Например, когато спонтанно решим да тестваме хипотеза върху някакво огромно количество данни. Атина е идеална за тези случаи. За редовни заявки такава система е скъпа. В този случай кеширайте данните в някакво специализирано решение.
Без сървър за OLTP решения
Предишният пример разглежда OLAP (аналитични) задачи. Сега нека да разгледаме OLTP задачите.
Нека си представим мащабируем PostgreSQL или MySQL. Нека създадем обикновен управляван екземпляр PostgreSQL или MySQL с минимални ресурси. Когато инстанцията получи повече натоварване, ще свържем допълнителни реплики, към които ще разпределим част от натоварването за четене. Ако няма заявки или натоварване, изключваме репликите. Първият екземпляр е мастер, а останалите са реплики.
Тази идея е реализирана в база данни, наречена Aurora Serverless AWS. Принципът е прост: заявките от външни приложения се приемат от прокси флота. Виждайки увеличаване на натоварването, той разпределя изчислителни ресурси от предварително затоплени минимални инстанции - връзката се осъществява възможно най-бързо. Деактивирането на екземпляри става по същия начин.
В рамките на Aurora съществува концепцията за Aurora Capacity Unit, ACU. Това е (условно) инстанция (сървър). Всеки конкретен ACU може да бъде главен или подчинен. Всяка единица капацитет има собствена RAM памет, процесор и минимален диск. Съответно единият е master, останалите са реплики само за четене.
Броят на тези работещи единици капацитет Aurora е конфигурируем параметър. Минималното количество може да бъде единица или нула (в този случай базата данни не работи, ако няма заявки).
Когато базата получи заявки, прокси флотът повишава Aurora CapacityUnits, увеличавайки ресурсите за производителност на системата. Възможността за увеличаване и намаляване на ресурсите позволява на системата да „жонглира“ с ресурси: автоматично показва отделни ACU (заменяйки ги с нови) и пуска всички текущи актуализации на изтеглените ресурси.
Базата Aurora Serverless може да мащабира натоварването при четене. Но документацията не казва това директно. Може да се почувства, че могат да вдигнат мулти-мастър. Няма магия.
Тази база данни е много подходяща за избягване на харченето на огромни суми пари за системи с непредсказуем достъп. Например, когато създаваме MVP или маркетингови сайтове за визитки, обикновено не очакваме стабилно натоварване. Съответно, ако няма достъп, не плащаме инстанции. Когато възникне неочаквано натоварване, например след конференция или рекламна кампания, тълпи от хора посещават сайта и натоварването се увеличава драстично, Aurora Serverless автоматично поема това натоварване и бързо свързва липсващите ресурси (ACU). Тогава конференцията минава, всички забравят за прототипа, сървърите (ACU) потъмняват и разходите падат до нула - удобно.
Това решение не е подходящо за стабилно високо натоварване, тъй като не мащабира натоварването на запис. Всички тези връзки и прекъсвания на ресурсите се случват в така наречената „точка на мащаба“ - точка във времето, когато базата данни не се поддържа от транзакция или временни таблици. Например, в рамките на една седмица точката на мащаба може да не се случи и базата работи на същите ресурси и просто не може да се разширява или свива.
Няма магия - това е обикновен PostgreSQL. Но процесът на добавяне на машини и изключването им е частично автоматизиран.
Без сървър по дизайн
Aurora Serverless е стара база данни, пренаписана за облака, за да се възползва от някои от предимствата на Serverless. И сега ще ви разкажа за основата, която първоначално беше написана за облака, за безсървърния подход - Serverless-by-design. Беше разработен незабавно без предположението, че ще работи на физически сървъри.
Тази основа се нарича Снежинка. Има три ключови блока.
Първият е блок с метаданни. Това е бърза услуга в паметта, която решава проблеми със сигурността, метаданните, транзакциите и оптимизирането на заявките (показано на илюстрацията вляво).
Вторият блок е набор от виртуални изчислителни клъстери за изчисления (на илюстрацията има набор от сини кръгове).
Третият блок е система за съхранение на данни, базирана на S3. S3 е безразмерно хранилище на обекти в AWS, нещо като безразмерен Dropbox за бизнес.
Нека да видим как работи Snowflake, ако приемем студен старт. Тоест има база данни, данните се зареждат в нея, няма стартирани заявки. Съответно, ако няма заявки към базата данни, тогава сме повдигнали бързата услуга за метаданни в паметта (първи блок). И имаме S3 хранилище, където се съхраняват таблични данни, разделени на така наречените микродялове. За простота: ако таблицата съдържа транзакции, тогава микродяловете са дните на транзакциите. Всеки ден е отделен микродял, отделен файл. И когато базата данни работи в този режим, вие плащате само за мястото, заето от данните. Освен това скоростта на седалка е много ниска (особено като се има предвид значителната компресия). Услугата за метаданни също работи постоянно, но не се нуждаете от много ресурси за оптимизиране на заявките и услугата може да се счита за споделяне.
Сега нека си представим, че потребител дойде в нашата база данни и изпрати SQL заявка. SQL заявката незабавно се изпраща на услугата за метаданни за обработка. Съответно, при получаване на заявка, тази услуга анализира заявката, наличните данни, потребителските права и, ако всичко е наред, изготвя план за обработка на заявката.
След това услугата инициира стартирането на изчислителния клъстер. Компютърният клъстер е клъстер от сървъри, които извършват изчисления. Тоест това е клъстер, който може да съдържа 1 сървър, 2 сървъра, 4, 8, 16, 32 - колкото искате. Изпращате заявка и стартирането на този клъстер веднага започва. Наистина отнема секунди.
След това, след като клъстерът стартира, микродяловете, необходими за обработка на вашата заявка, започват да се копират в клъстера от S3. Тоест, нека си представим, че за да изпълните SQL заявка, имате нужда от два дяла от една таблица и един от втория. В този случай само трите необходими дяла ще бъдат копирани в клъстера, а не всички таблици изцяло. Ето защо и точно защото всичко е разположено в един център за данни и е свързано с много бързи канали, целият процес на трансфер се случва много бързо: за секунди, много рядко за минути, освен ако не говорим за някакви чудовищни заявки. Съответно, микроразделите се копират в изчислителния клъстер и след завършване SQL заявката се изпълнява на този изчислителен клъстер. Резултатът от тази заявка може да бъде един ред, няколко реда или таблица - те се изпращат външно на потребителя, за да може той да го изтегли, да го покаже в своя BI инструмент или да го използва по друг начин.
Всяка SQL заявка може не само да чете агрегати от предварително заредени данни, но и да зарежда/генерира нови данни в базата данни. Тоест, това може да бъде заявка, която например вмъква нови записи в друга таблица, което води до появата на нов дял в изчислителния клъстер, който от своя страна автоматично се записва в едно S3 хранилище.
Сценарият, описан по-горе, от пристигането на потребителя до издигането на клъстера, зареждане на данни, изпълнение на заявки, получаване на резултати, се заплаща по тарифата за минути използване на повдигнатия виртуален изчислителен клъстер, виртуален склад. Тарифата варира в зависимост от AWS зоната и размера на клъстера, но средно е няколко долара на час. Клъстер от четири машини е два пъти по-скъп от клъстер от две машини, а клъстер от осем машини все още е два пъти по-скъп. Предлагат се варианти от 16, 32 машини в зависимост от сложността на заявките. Но вие плащате само за тези минути, когато клъстерът действително работи, защото когато няма заявки, някак си сваляте ръцете и след 5-10 минути чакане (конфигурируем параметър) той ще изгасне сам, освободете ресурси и станете свободни.
Напълно реалистичен сценарий е, когато изпратите заявка, клъстерът изскача, относително казано, след минута, отчита още една минута, след това пет минути за изключване и в крайна сметка плащате за седем минути работа на този клъстер и не за месеци и години.
Първият сценарий описва използването на Snowflake в настройка за един потребител. Сега нека си представим, че има много потребители, което е по-близо до реалния сценарий.
Да кажем, че имаме много анализатори и отчети на Tableau, които постоянно бомбардират нашата база данни с голям брой прости аналитични SQL заявки.
В допълнение, да кажем, че имаме изобретателни специалисти по данни, които се опитват да правят чудовищни неща с данни, оперират с десетки терабайти, анализират милиарди и трилиони редове от данни.
За двата типа натоварване, описани по-горе, Snowflake ви позволява да създадете няколко независими компютърни клъстера с различен капацитет. Освен това тези изчислителни клъстери работят независимо, но с общи последователни данни.
За голям брой леки заявки можете да създадете 2-3 малки клъстера, приблизително 2 машини всеки. Това поведение може да се приложи, наред с други неща, с помощта на автоматични настройки. Така че вие казвате: „Снежинка, отгледай малък грозд. Ако натоварването върху него се увеличи над определен параметър, вдигнете подобен втори, трети. Когато товарът започне да намалява, изгасете излишъка. Така че колкото и анализатори да дойдат и да започнат да гледат отчетите, всеки има достатъчно ресурс.
В същото време, ако анализаторите спят и никой не гледа отчетите, клъстерите може напълно да потъмнеят и вие да спрете да плащате за тях.
В същото време, за тежки заявки (от Data Scientists), можете да създадете един много голям клъстер за 32 машини. Този клъстер също ще бъде платен само за тези минути и часове, когато вашата гигантска заявка се изпълнява там.
Описаната по-горе възможност ви позволява да разделите не само 2, но и повече видове натоварване в клъстери (ETL, мониторинг, материализиране на отчети,...).
Нека обобщим Снежинка. Основата съчетава красива идея и работеща реализация. В ManyChat използваме Snowflake, за да анализираме всички данни, които имаме. Нямаме три клъстера, както в примера, а от 5 до 9, с различни размери. Имаме конвенционални 16-машини, 2-машини, а също и супер-малки 1-машини за някои задачи. Те успешно разпределят товара и ни позволяват да спестим много.
Базата данни успешно мащабира натоварването при четене и запис. Това е огромна разлика и огромен пробив в сравнение със същата „Аврора“, която носеше само натоварването за четене. Snowflake ви позволява да мащабирате работното си натоварване с тези изчислителни клъстери. Тоест, както споменах, ние използваме няколко клъстера в ManyChat, малки и супер-малки клъстери се използват главно за ETL, за зареждане на данни. И анализаторите вече живеят на средни клъстери, които абсолютно не са засегнати от ETL натоварването, така че работят много бързо.
Съответно базата данни е много подходяща за OLAP задачи. Въпреки това, за съжаление, той все още не е приложим за работни натоварвания на OLTP. Първо, тази база данни е колонна, с всички произтичащи от това последствия. Второ, самият подход, когато за всяка заявка, ако е необходимо, повдигате изчислителен клъстер и го наводнявате с данни, за съжаление, все още не е достатъчно бърз за OLTP зареждания. Секунди изчакване за OLAP задачи е нормално, но за OLTP задачи е неприемливо; 100 ms би било по-добре или 10 ms би било още по-добре.
Общо
База данни без сървър е възможна чрез разделяне на базата данни на части без състояние и състояние. Може да сте забелязали, че във всички горепосочени примери Stateful частта, относително казано, съхранява микро-дялове в S3, а Stateless е оптимизаторът, работещ с метаданни, обработвайки проблеми със сигурността, които могат да бъдат повдигнати като независими леки Stateless услуги.
Изпълнението на SQL заявки може също да се възприема като услуги с леко състояние, които могат да изскочат в режим без сървър, като изчислителни клъстери Snowflake, да изтеглят само необходимите данни, да изпълнят заявката и да „излязат“.
Базите данни на производствено ниво без сървър вече са налични за използване, те работят. Тези бази данни без сървър вече са готови да обработват OLAP задачи. За съжаление, за OLTP задачи те се използват... с нюанси, тъй като има ограничения. От една страна, това е минус. Но, от друга страна, това е възможност. Може би някой от читателите ще намери начин да направи OLTP база данни напълно безсървърна, без ограниченията на Aurora.
Надявам се, че ви е било интересно. Без сървър е бъдещето :)
Източник: www.habr.com