Ўсім прывітанне! Мяне клічуць Галоў Мікалай. Раней я працаваў у Авіта і шэсць гадоў кіраваў 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 баз абвыклі, і мір, з майго пункта гледжання, зрабіў наступны крок - да managed баз. У гэтых баз ядро тое ж, што і ў класічных OLTP баз ці новых NoSQL. Але ў іх няма патрэбнасці ў DBA і DevOps і яны круцяцца на кіраваным жалезе ў аблоках. Для распрацоўніка гэта "проста база", якая дзесьці працуе, а як яна ўсталявана на серверы, хто наладзіў сервер і хто яго абнаўляе, нікога не хвалюе.
Прыклады такіх баз:
- AWS RDS - managed абгортка над PostgreSQL/MySQL.
- DynamoDB - AWS аналаг document based базы, падобна на Redis і MongoDB.
- Amazon Redshift – managed аналітычная база.
У аснове гэта старыя базы, але паднятыя ў managed асяроддзі, без неабходнасці працы з жалезам.
Заўвага. Прыклады ўзяты для асяроддзя AWS, але іх аналагі існуюць таксама ў Microsoft Azure, Google Cloud, або Яндэкс.Аблокі.
Што ж з гэтага новага? У 2020 годзе нічога з гэтага.
Канцэпцыя Serverless
Сапраўды новае на рынку ў 2020 годзе - гэта serverless або бессерверныя рашэнні.
Паспрабую растлумачыць, што гэта значыць, на прыкладзе звычайнага сэрвісу ці бэкэнд-прыкладанні.
Каб разгарнуць звычайнае бэкэнд-дадатак, купляем ці арандуем сервер, які капіюецца на яго код, апублікоўваем вонкі endpoint і рэгулярна які плаціцца за арэнду, электрычнасць і паслугі дата-цэнтра. Гэта стандартная схема.
Ці можна неяк інакш? З бессервернымі сэрвісамі можна.
У чым фокус гэтага падыходу: няма сервера, няма нават арэнды віртуальнага instance у воблаку. Для разгортвання сэрвісу які капіюецца код (функцыі) у рэпазітар і апублікоўваем вонкі endpoint. Далей проста які плаціцца за кожны выклік гэтай функцыі, цалкам ігнаруючы апаратнае забеспячэнне, дзе яна выконваецца.
Паспрабую праілюстраваць гэты падыход на карцінках.
Класічны дэплой. У нас ёсьць сэрвіс з пэўнай нагрузкай. Падымаем два інстансы: фізічныя серверы або інстансы ў AWS. На гэтыя інстансы накіроўваюцца вонкавыя запыты, якія там апрацоўваюцца.
Як відаць на малюнку, серверы утылізаваны неаднолькава. Адзін утылізаваны на 100%, там два запыты, а адзін толькі на 50% - часткова прастойвае. Калі прыйдзе не тры запыты, а 30, то ўся сістэма не зладзіцца з нагрузкай і пачне тармазіць.
Бессерверны дэплой. У бессерверным асяроддзі ў падобнага сэрвісу няма інстансаў і сервераў. Ёсць некаторы пул разагрэтых рэсурсаў - маленькіх падрыхтаваных Docker-кантэйнераў з разгорнутым кодам функцыі. Сістэма атрымлівае вонкавыя запыты і на кожны з іх бессерверны фрэймворк паднімае маленькі кантэйнер з кодам: апрацоўвае менавіта гэты запыт і забівае кантэйнер.
Адзін запыт - адзін падняты кантэйнер, 1000 запытаў - 1000 кантэйнераў. А разгортванне на жалезных серверах - гэта ўжо праца хмарнага правайдэра. Яна цалкам утоена бессерверным фрэймворкам. У гэтай канцэпцыі мы плацім за кожны выклік. Напрыклад, прыйшоў адзін выклік у дзень - мы заплацілі за адзін выклік, прыйшоў мільён у хвіліну - заплацілі за мільён. Або за секунду, такое таксама бывае.
Канцэпцыя публікацыі бессервернай функцыі падыходзіць для stateless сэрвісу. А калі вам патрэбен (state) statefull сэрвіс, то да сэрвісу дадаем базу дадзеных. У гэтым выпадку, калі даходзіць да працы са state, са станам, кожная statefull функцыя проста піша і чытае з базы дадзеных. Прычым з базы даных любога з трох тыпаў, апісаных у пачатку артыкула.
Якое агульнае абмежаванне ва ўсіх гэтых базах? Гэта выдаткі на ўвесь час выкарыстоўваны хмарны або жалезны сервер (ці некалькі сервераў). Усё роўна, выкарыстоўваем класічную базу або managed, ёсць Devops і адмін ці не, усё роўна 24 на 7 які плаціцца за жалеза, электрычнасць і арэнду дата-цэнтра. Калі ў нас класічная база, мы плацім за master і slave. Калі высоканагружаная шардыраваная база — плацім за 10, 20 ці 30 сервераў, і плацім увесь час.
Наяўнасць у структуры выдаткаў стала зарэзерваваных сервераў раней успрымалася як непазбежнае зло. Ёсць у звычайных баз і іншыя складанасці, такія як ліміты на колькасць падлучэнняў, абмежаванне маштабавання, геаразмеркаваны кансэнсус - іх неяк можна вырашыць у пэўных базах, але не ўсё адразу і не ідэальна.
Serverless база дадзеных - тэорыя
Пытанне 2020 гады: ці можна базу дадзеных таксама зрабіць serverless? Усе чулі пра serverless бэкэнд… а давайце і базу дадзеных паспрабуем зрабіць serverless?
Гэта гучыць дзіўна, таму што база дадзеных - гэта ж statefull сэрвіс, не вельмі прыдатны для serverless інфраструктуры. Пры гэтым, і state у базы дадзеных вельмі вялікі: гігабайты, Тэрабайты, а ў аналітычных базах нават петабайты. Яго так проста ў легкаважных Docker-кантэйнерах не падняць.
З іншага боку, практычна ўсе сучасныя базы - гэта вялікая колькасць логікі і кампанентаў: транзакцыі, узгадненне цэласнасці, працэдуры, рэляцыйныя залежнасці і шмат логікі. Даволі вялікай часткі логікі базы дадзеных дастаткова невялікага state. Гігабайты і Тэрабайты непасрэдна выкарыстоўваюцца толькі невялікай часткай логікі базы дадзеных, звязанай з непасрэдным выкананнем запытаў.
Адпаведна, ідэя: калі частка логікі дапускае stateless выкананне, чаму б не распілаваць базу на Stateful і Stateless часткі.
Serverless для OLAP рашэнняў
Давайце паглядзім, як можа выглядаць распілоўка базы дадзеных на Stateful і Stateless часткі на практычных прыкладах.
Напрыклад, у нас ёсць аналітычная база даных: вонкавыя дадзеныя (чырвоны цыліндр злева), ETL-працэс, які загружае дадзеныя ў базу, і аналітык, які адпраўляе да базы SQL-запыты. Гэта класічная схема працы сховішча дадзеных.
У гэтай схеме, умоўна, адзін раз выконваецца ETL. Далей трэба ўвесь час плаціць за серверы, на якіх працуе база з дадзенымі, залітымі ETL, каб было да чаго кідаць запыты.
Разгледзім альтэрнатыўны падыход, рэалізаваны ў базе AWS Athena Serverless. Тут няма стала вылучанага жалеза, на якім захоўваюцца загружаныя дадзеныя. Замест гэтага:
- Карыстальнік адпраўляе SQL-запыт да Athena. Аптымізатар Athena аналізуе SQL-запыт і шукае ў сховішчы метададзеных (Metadata) пэўныя дадзеныя, патрэбныя для выканання запыту.
- Аптымізатар, на аснове сабраных дадзеных, выгружае патрэбныя дадзеныя са знешніх крыніц у часовае сховішча (часовую базу дадзеных).
- У часовым сховішчы выконваецца SQL-запыт ад карыстача, вынік вяртаецца карыстачу.
- Часовае сховішча чысціцца, рэсурсы вызваляюцца.
У гэтай архітэктуры мы плацім толькі за працэс выканання запыту. Няма запытаў - няма выдаткаў.
Гэта працоўны падыход і ён рэалізуецца не толькі ў Athena Serverless, але і ў Redshift Spectrum (у AWS).
На прыкладзе Athena відаць, што Serverless база дадзеных працуе на рэальных запытах з дзясяткамі і сотнямі Тэрабайт дадзеных. Для сотняў Тэрабайт спатрэбяцца сотні сервераў, але нам не трэба за іх плаціць - мы плацім за запыты. Хуткасць кожнага запыту (вельмі) нізкая ў параўнанні са спецыялізаванымі аналітычнымі базамі тыпу Vertica, але затое мы не аплачваем перыяды прастою.
Такая база даных прымяняецца для рэдкіх аналітычных ad-hoc запытаў. Напрыклад, калі мы спантанна вырашым праверыць гіпотэзу на нейкім гіганцкім аб'ёме дадзеных. Для гэтых кейсаў Athena падыходзіць ідэальна. Для рэгулярных запытаў такая сістэма выходзіць дорага. У гэтым выпадку кэшуйце дадзеныя ў нейкім спецыялізаваным рашэнні.
Serverless для OLTP рашэнняў
У папярэднім прыкладзе разглядаліся OLAP-задачы (аналітычныя). Цяпер разгледзім OLTP-задачы.
Прадстаўляльны які маштабуецца PostgreSQL або MySQL. Давайце паднімем звычайны managed instance PostgreSQL ці MySQL на мінімальных рэсурсах. Калі на інстанс будзе прыходзіць больш нагрузкі, мы будзем падлучаць дадатковыя рэплікі, на якія размяркуем частка якая чытае нагрузкі. Калі запытаў і нагрузкі няма - адключаем рэплікі. Першы інстанс - гэта майстар, а астатнія - рэплікі.
Гэта ідэя рэалізавана ў базе пад назовам Aurora Serverless AWS. Прынцып просты: запыты ад вонкавых прыкладанняў прымае proxy fleet. Бачачы рост нагрузкі, ён вылучае вылічальныя рэсурсы з папярэдне прагрэтых мінімальных інстансаў - падлучэнне выконваецца максімальна хутка. Адключэнне інстансаў адбываецца гэтак жа.
У рамках Aurora ёсць паняцце Aurora Capacity Unit, ACU. Гэта (умоўна) - інстанс (сервер). Кожны канкрэтны ACU можа быць master ці slave. Кожны Capacity Unit валодае сваёй аператыўнай памяццю, працэсарам і мінімальнай кружэлкай. Адпаведна, адзін master, астатнія read only рэплікі.
Колькасць гэтых якія працуюць Aurora Capacity Units – гэта наладжвальны параметр. Мінімальная колькасць можа быць адзін ці нуль (у такім выпадку база не працуе, калі няма запытаў).
Калі база атрымлівае запыты, proxy fleet паднімае Aurora CapacityUnits, павялічваючы прадукцыйныя рэсурсы сістэмы. Магчымасць павялічваць і памяншаць рэсурсы дазваляе сістэме «жангляваць» рэсурсамі: аўтаматычна выводзіць асобныя ACU (падмяняючы іх новымі) і накатваць на выведзеныя рэсурсы ўсе актуальныя абнаўленні.
База Aurora Serverless можа маштабаваць якая чытае нагрузку. Але ў дакументацыі аб гэтым не сказанае наўпрост. Можа ўзнікнуць адчуванне, што яны могуць паднімаць multi-master. Чараўніцтва ж ніякага няма.
Гэтая база добра падыходзіць, каб не марнаваць вялізныя грошы на сістэмы з непрадказальным доступам. Напрыклад, пры стварэнні MVP ці маркетынгавых сайтаў-візітак, мы звычайна не чакаем стабільнай нагрузкі. Адпаведна, пры адсутнасці доступу, мы не плацім за інстансы. Калі нечакана ўзнікае нагрузка, напрыклад, пасля канферэнцыі ці рэкламнай кампаніі, натоўпы людзей заходзяць на сайт і нагрузка рэзка расце, Aurora Serverless аўтаматычна прымае гэтую нагрузку і хутка падлучае адсутнічаюць рэсурсы (ACU). Далей канферэнцыя праходзіць, усё забываюць пра прататып, сервера (ACU) згасаюць, і выдаткі падаюць да нуля – зручна.
Гэтае рашэнне не падыходзіць для стабільнага высокага highload, таму што яно не ўмее маштабаваць пішучую нагрузку. Усе гэтыя падключэнні і адключэнні рэсурсаў адбываюцца ў момант так званага "scale point" - моманту часу, калі базу не трымае транзакцыя, не трымаюць часовыя табліцы. Напрыклад, на працягу тыдня scale point можа і не здарыцца, і база працуе на адных рэсурсах і проста не можа ні пашырэць, ні сціснуцца.
Чараўніцтва няма - гэта звычайны PostgreSQL. Але працэс дадання машын і адключэнні часткова аўтаматызаваны.
Serverless by design
Aurora Serverless гэта старая база, перапісаная пад аблокі, каб выкарыстоўваць асобныя перавагі Serverless. А зараз распавяду аб базе, якая першапачаткова напісана пад аблокі, пад serverless падыход - Serverless-by-design. Яе адразу распрацоўвалі без дапушчэння аб тым, што яна працуе на фізічных серверах.
Гэтая база называецца Snowflake. У ёй тры ключавыя блокі.
Першы - гэта блок метададзеных. Гэта хуткі in-memory сэрвіс, які вырашае пытанні з бяспекай, метададзенымі, транзакцыямі, аптымізацыяй запыту (на ілюстрацыі злева).
Другі блок - гэта мноства віртуальных вылічальных кластараў для разлікаў (на ілюстрацыі - набор сініх гурткоў).
Трэці блок - сістэма захоўвання дадзеных на базе S3. S3 – гэта непамернае аб'ектнае сховішча ў AWS, нешта накшталт непамернага Dropbox для бізнэсу.
Давайце паглядзім, як Snowflake працуе, у здагадцы аб халодным старце. Гэта значыць база ёсць, дадзеныя ў яе загружаныя, якія працуюць запытаў няма. Адпаведна, калі да базы няма запытаў, то ў нас падняты хуткі in-memory Metadata сэрвіс (першы блок). І ў нас ёсць сховішча S3, дзе ляжаць дадзеныя табліц, разбітыя на так званыя мікрапартыцыі. Для прастаты: калі ў табліцы ляжаць здзелкі, то мікрапартыцыі - гэта дні здзелак. Кожны дзень - гэта асобная мікрапартыцыя, асобны файлік. І калі база працуе ў такім рэжыме, вы плаціце толькі за месца, якое займае дадзенымі. Прычым тарыф за месца вельмі нізкі (асабліва з улікам значнага сціску). Сэрвіс метададзеных таксама працуе ўвесь час, але для аптымізацыі запытаў шмат рэсурсаў не трэба, і сэрвіс можна лічыць умоўна-бясплатным.
Зараз уявім, што да нашай базы прыйшоў карыстач і кінуў SQL-запыт. SQL-запыт адразу паступае на апрацоўку ў Metadata сэрвіс. Адпаведна, атрымаўшы запыт, гэты сэрвіс аналізуе запыт, даступныя дадзеныя, паўнамоцтвы карыстальніка і, калі ўсё добра, складае план апрацоўкі запыту.
Далей сэрвіс ініцыюе запуск вылічальнага кластара. Вылічальны кластар - гэта кластар з сервераў, якія выконваюць вылічэнні. Гэта значыць гэта кластар, які можа ўтрымліваць 1 сервер, 2 поўначы, 4, 8, 16, 32 - колькі захочаце. Вы кідаеце запыт і пад яго імгненна пачынаецца запуск гэтага кластара. Гэта рэальна займае секунды.
Далей, пасля таго, як кластар стартаваў, у кластар з S3 пачынаюць капіявацца мікрапартыцыі, патрэбныя для апрацоўкі менавіта вашага запыту. Гэта значыць, уявім, што для выканання SQL-запыту трэба дзве партіціі з адной табліцы і адна з другой. У такім выпадку ў кластар будуць скапіяваныя толькі тры патрэбныя партіціі, а не ўсе табліцы цалкам. Менавіта таму і менавіта з-за таго, што ўсё знаходзіцца ў рамках аднаго дата-цэнтра і злучана вельмі хуткімі каналамі, увесь працэс перапампоўкі адбываецца вельмі хутка: за секунды, вельмі рэдка - за хвіліны, калі гаворка не ідзе пра нейкія жахлівыя запыты . Адпаведна, мікрапартыцыі капіююцца на вылічальны кластар, і, па завяршэнні, на гэтым вылічальным кластары выконваецца SQL запыт. Вынікам гэтага запыту можа быць адзін радок, некалькі радкоў ці табліца - яны адпраўляюцца вонкі карыстачу, каб ён выгрузіў, адлюстраваў у сябе ў BI інструменце, ці яшчэ як-небудзь выкарыстаў.
Кожны SQL запыт можа не толькі лічыць агрэгаты з раней загружаных дадзеных, але і загружаць / фармаваць новыя дадзеныя ў базе. Гэта можа быць запыт, які, напрыклад, ажыццяўляе ўстаўку ў іншую табліцу новых запісаў, што прыводзіць да з'яўлення новай партыцыі на вылічальным кластары, якая, у сваю чаргу, аўтаматычна захоўваецца ў адзіным S3 сховішча.
Апісаны вышэй сцэнар, ад прыходу карыстальніка да ўзняцця кластара, загрузка дадзеных, выкананне запытаў, атрыманне вынікаў, аплачваецца па тарыфе за хвіліны выкарыстання паднятага віртуальнага вылічальнага кластара, віртуальнага warehouse. Тарыф вар'іруецца ў залежнасці ад зоны AWS і памеру кластара, але, у сярэднім, гэта некалькі долараў за гадзіну. Кластар з чатырох машын у два разы даражэйшы, чым з дзвюх машын, з васьмі машын яшчэ ў два разы даражэй. Даступныя варыянты з 16, 32 машын, у залежнасці ад складанасці запытаў. Але вы плаціце толькі за тыя хвіліны, калі кластар рэальна працуе, таму што, калі запытаў няма, вы як бы прыбіраеце рукі, і пасля 5-10 хвілін чакання (наладжвальны параметр) ён сам згасне, вызваліць рэсурсы і стане бясплатным.
Цалкам рэальны сцэнар, калі вы кідаеце запыт, кластар усплывае, умоўна кажучы, за хвіліну, яшчэ хвіліну ён лічыць, далей за пяць хвілін на выключэнне, і вы плаціце ў выніку за сем хвілін працы гэтага кластара, а не за месяцы і гады.
Першы сцэнар апісваў выкарыстанне Snowflake у аднакарыстальніцкім варыянце. Цяпер давайце ўявім, што карыстальнікаў шмат, што ўжо бліжэй да рэальнага сцэнара.
Выкажам здагадку, у нас ёсць шмат аналітыкаў і Tableau справаздач, якія ўвесь час бамбуюць нашу базу вялікай колькасцю нескладаных аналітычных SQL-запытаў.
Акрамя гэтага, дапусцім, што ў нас ёсць вынаходлівыя Data Scientists, якія спрабуюць рабіць з дадзенымі жахлівыя рэчы, апераваць дзясяткамі Тэрабайт, аналізаваць мільярды і трыльёны радкоў дадзеных.
Для апісаных вышэй двух тыпаў нагрузкі Snowflake дазваляе паднімаць некалькі незалежных вылічальных кластараў рознай магутнасці. Прычым гэтыя вылічальныя кластары працуюць незалежна, але з агульнымі ўзгодненымі дадзенымі.
Для вялікай колькасці лёгкіх запытаў можна падняць 2-3 невялікія кластары, памерам, умоўна, 2 машыны кожны. Гэтыя паводзіны рэалізуема, у тым ліку, з дапамогай аўтаматычных налад. Гэта значыць, вы кажаце: «Snowflake, падымі маленькі кластар. Калі нагрузка на яго вырасце больш вызначанага параметра, падымі аналагічны другі, трэці. Калі нагрузка пачне спадаць - гасі лішнія». Каб незалежна ад таго, колькі аналітыкаў прыходзіць і пачынае глядзець справаздачы, усім хапала рэсурсаў.
Пры гэтым, калі аналітыкі спяць, і справаздачы ніхто не глядзіць - кластара могуць цалкам згаснуць, і плаціць за іх вы перастаеце.
Пры гэтым, для цяжкіх запытаў (ад Data Scientists), вы можаце падняць адзін вельмі вялікі кластар на ўмоўныя 32 машыны. Гэты кластар таксама будзе аплачвацца толькі за тыя хвіліны і гадзіны, калі там працуе ваш гіганцкі запыт.
Апісаная вышэй магчымасць дазваляе падзяляць па кластарах не толькі 2, але і больш відаў нагрузкі (ETL, маніторынг, матэрыялізацыя справаздач, ...).
Падвядзем вынік па Snowflake. База спалучае прыгожую ідэю і працаздольную рэалізацыю. У ManyChat мы выкарыстоўваем Snowflake для аналітыкі ўсіх наяўных дадзеных. Кластараў у нас не тры, як у прыкладзе, а ад 5 да 9, розных памераў. У нас ёсць умоўныя 16-машынныя, 2-машынныя, ёсць і супер-маленькія 1-машынныя для некаторых задач. Яны паспяхова размяркоўваюць нагрузку і дазваляюць нам выдатна эканоміць.
База паспяхова маштабуе якая чытае і пішучую нагрузку. Гэта велізарнае адрозненне і велізарны прарыў у параўнанні з той жа «Аўрорай», якая цягнула толькі якая чытае нагрузку. Snowflake дазваляе маштабаваць гэтымі вылічальнымі кластарамі і пішучую нагрузку. Гэта значыць, як я згадаў, у нас у ManyChat выкарыстоўваецца некалькі кластараў, маленькія і супермаленькія кластары ў асноўным выкарыстоўваюцца для ETL, для загрузкі дадзеных. А аналітыкі жывуць ужо на сярэдніх кластарах, якія абсалютна не закрануты ETL-нагрузкай, таму працуюць вельмі хутка.
Адпаведна, база добра падыходзіць для OLAP-задач. Пры гэтым, нажаль, для OLTP-нагрузак яна яшчэ не дастасавальная. Па-першае, гэтая база калоначная, з усімі вынікаючымі наступствамі. Па-другое, сам падыход, калі на кожны запыт па неабходнасці вы паднімаеце вылічальны кластар і праліваеце яго дадзенымі, нажаль, для OLTP-нагрузак яшчэ нядосыць хуткі. Секунды чакання для OLAP-задач - гэта нармальна, а для OLTP-задач - непрымальна, лепш бы 100 мс, а яшчэ лепш - 10 мс.
Вынік
Serverless база дадзеных магчыма за кошт падзелу базы дадзеных на Stateless і Stateful часткі. Вы, павінна быць, звярнулі ўвагу, што ва ўсіх прыведзеных прыкладах, Stateful частка – гэта, умоўна кажучы, захоўванне мікрапартыцый у S3, а Stateless – гэта аптымізатар, праца з мета-дадзеныя, апрацоўка пытанняў бяспекі, якія могуць быць паднятыя як незалежныя легкаважныя Stateless сэрвісы.
Выкананне SQL-запытаў таксама можна ўспрыняць як сэрвісы з лёгкім state, якія могуць усплыць у бессерверным рэжыме, як вылічальныя кластара Snowflake, спампаваць толькі патрэбныя дадзеныя, выканаць запыт і "згаснуць".
Serverless базы прадакшэн ўзроўню ўжо даступныя для выкарыстання, яны працуюць. Гэтыя serverless базы ўжо гатовыя спраўляцца з OLAP-задачамі. Нажаль, для OLTP-задач яны ўжываюцца… з нюансамі, бо ёсць абмежаванні. З аднаго боку, гэта мінус. Але, з іншага боку, гэта магчымасць. Магчыма, нехта з чытачоў знойдзе спосаб, як OLTP-базу зрабіць цалкам serverless, без абмежаванняў Aurora.
Спадзяюся, вам было цікава. За Serverless будучыню 🙂
Крыніца: habr.com