Всем привет! Меня зовут Голов Николай. Раньше я работал в Авито и шесть лет руководил Data Platform, то есть занимался всеми базами: аналитическими (Vertica, ClickHouse), потоковыми и OLTP (Redis, Tarantool, VoltDB, MongoDB, PostgreSQL). За это время я разобрался с большим количеством баз данных — самых разных и необычных, и с нестандартными кейсами их использования.
Сейчас я работаю в ManyChat. По сути это стартап — новый, амбициозный и быстро растущий. И когда я только вышел в компанию, возник классический вопрос: «А что сейчас стоит брать молодому стартапу с рынка СУБД и баз данных?».
В этой статье, основанной на моем докладе на онлайн-фестивале РИТ++2020, отвечу на этот вопрос. Видеоверсия доклада доступна на YouTube.
На дворе 2020 год, я огляделся и увидел три типа БД.
Первый тип — классические OLTP базы: PostgreSQL, SQL Server, Oracle, MySQL. Они написаны давным-давно, но по-прежнему актуальны, потому что хорошо знакомы сообществу разработчиков.
Второй тип — базы из «нулевых». Они пытались уйти от классических шаблонов путем отказа от SQL, традиционных структур и ACID, за счёт добавления встроенного шардирования и других привлекательных фич. Например, это Cassandra, MongoDB, Redis или Tarantool. Все эти решения хотели предложить рынку что-то принципиально новое и заняли свою нишу, потому что в определенных задачах оказались крайне удобными. Эти базы обозначу зонтичным термином NOSQL.
«Нулевые» закончились, к NOSQL базам привыкли, и мир, с моей точки зрения, сделал следующий шаг — к managed базам. У этих баз ядро то же, что и у классических OLTP баз или новых NoSQL. Но у них нет потребности в DBA и DevOps и они крутятся на управляемом железе в облаках. Для разработчика это «просто база», которая где-то работает, а как она установлена на сервере, кто настроил сервер и кто его обновляет, никого не волнует.
Примеры таких баз:
В основе это старые базы, но поднятые в managed среде, без необходимости работы с железом.
Примечание. Примеры взяты для среды AWS, но их аналоги существуют также в Microsoft Azure, Google Cloud, или Яндекс.Облаке.
Что же из этого нового? В 2020 году ничего из этого.
Действительно новое на рынке в 2020 году — это serverless или бессерверные решения.
Попытаюсь объяснить, что это значит, на примере обычного сервиса или бэкенд-приложения.
Чтобы развернуть обычное бэкенд-приложение, покупаем или арендуем сервер, копируем на него код, опубликовываем наружу endpoint и регулярно платим за аренду, электричество и услуги дата-центра. Это стандартная схема.
Можно ли как-то иначе? C бессерверными сервисами можно.
В чем фокус этого подхода: нет сервера, нет даже аренды виртуального instance в облаке. Для развертывания сервиса копируем код (функции) в репозиторий и опубликовываем наружу endpoint. Дальше просто платим за каждый вызов этой функции, полностью игнорируя аппаратное обеспечение, где она выполняется.
Попытаюсь проиллюстрировать этот подход на картинках.
Классический деплой. У нас есть сервис с определенной нагрузкой. Поднимаем два инстанса: физические серверы или инстансы в AWS. На эти инстансы направляются внешние запросы, которые там обрабатываются.
Как видно на картинке, серверы утилизированы неодинаково. Один утилизирован на 100%, там два запроса, а один только на 50% — частично простаивает. Если придет не три запроса, а 30, то вся система не справится с нагрузкой и начнет тормозить.
Бессерверный деплой. В бессерверном окружении у подобного сервиса нет инстансов и серверов. Есть некоторый пул разогретых ресурсов — маленьких подготовленных Docker-контейнеров с развернутым кодом функции. Система получает внешние запросы и на каждый из них бессерверный фреймворк поднимает маленький контейнер с кодом: обрабатывает именно этот запрос и убивает контейнер.
Один запрос — один поднятый контейнер, 1000 запросов — 1000 контейнеров. А развертывание на железных серверах — это уже работа облачного провайдера. Она полностью скрыта бессерверным фреймворком. В этой концепции мы платим за каждый вызов. Например, пришел один вызов в день — мы заплатили за один вызов, пришел миллион в минуту — заплатили за миллион. Или в секунду, такое тоже бывает.
Концепция публикации бессерверной функции подходит для stateless сервиса. А если вам нужен (state) statefull сервис, то к сервису добавляем базу данных. В этом случае, когда доходит до работы со state, с состоянием, каждая statefull функция просто пишет и читает из базы данных. Причем из базы данных любого из трех типов, описанных в начале статьи.
Какое общее ограничение у всех этих баз? Это расходы на постоянно используемый облачный или железный сервер (или несколько серверов). Неважно, используем классическую базу или managed, есть Devops и админ или нет, всё равно 24 на 7 платим за железо, электричество и аренду дата-центра. Если у нас классическая база, мы платим за master и slave. Если высоконагруженная шардированная база — платим за 10, 20 или 30 серверов, и платим постоянно.
Наличие в структуре расходов постоянно зарезервированных серверов раньше воспринималось как неизбежное зло. Есть у обычных баз и другие сложности, такие как лимиты на количество подключений, ограничение масштабирования, геораспределенный консенсус — их как-то можно решить в определенных базах, но не все сразу и не идеально.
Вопрос 2020 года: можно ли базу данных тоже сделать serverless? Все слышали про serverless бэкенд… а давайте и базу данных попробуем сделать serverless?
Это звучит странно, потому что база данных — это же statefull сервис, не очень подходящий для serverless инфраструктуры. При этом, и state у базы данных очень большой: гигабайты, Терабайты, а в аналитических базах даже петабайты. Его так просто в легковесных Docker-контейнерах не поднять.
С другой стороны, практически все современные базы — это огромное количество логики и компонентов: транзакции, согласование целостности, процедуры, реляционные зависимости и много логики. Довольно большой части логики базы данных достаточно небольшого state. Гигабайты и Терабайты непосредственно используются только небольшой частью логики базы данных, связанной с непосредственным выполнением запросов.
Соответственно, идея: если часть логики допускает stateless исполнение, почему бы не распилить базу на Stateful и Stateless части.
Давайте посмотрим, как может выглядеть распилка базы данных на Stateful и Stateless части на практических примерах.
Например, у нас есть аналитическая база данных: внешние данные (красный цилиндр слева), ETL-процесс, который загружает данные в базу, и аналитик, который отправляет к базе SQL-запросы. Это классическая схема работы хранилища данных.
В этой схеме, условно, один раз выполняется ETL. Дальше нужно все время платить за серверы, на которых работает база с данными, залитыми ETL, чтобы было к чему кидать запросы.
Рассмотрим альтернативный подход, реализованный в базе AWS Athena Serverless. Здесь нет постоянно выделенного железа, на котором хранятся загруженные данные. Вместо этого:
В этой архитектуре мы платим только за процесс выполнение запроса. Нет запросов — нет расходов.
Это рабочий подход и он реализуется не только в Athena Serverless, но и в Redshift Spectrum (в AWS).
На примере Athena видно, что Serverless база данных работает на реальных запросах с десятками и сотнями Терабайт данных. Для сотен Терабайт понадобятся сотни серверов, но нам не нужно за них платить — мы платим за запросы. Скорость каждого запроса (очень) низка по сравнению со специализированными аналитическими базами типа Vertica, но зато мы не оплачиваем периоды простоя.
Такая база данных применима для редких аналитических ad-hoc запросов. Например, когда мы спонтанно решим проверить гипотезу на каком-то гигантском объеме данных. Для этих кейсов Athena подходит идеально. Для регулярных запросов такая система выходит дорого. В этом случае кешируйте данные в каком-то специализированном решении.
В предыдущем примере рассматривались 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. Но процесс добавления машин и отключения частично автоматизирован.
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 будущее :)
Сейчас я работаю в ManyChat. По сути это стартап — новый, амбициозный и быстро растущий. И когда я только вышел в компанию, возник классический вопрос: «А что сейчас стоит брать молодому стартапу с рынка СУБД и баз данных?».
В этой статье, основанной на моем докладе на онлайн-фестивале РИТ++2020, отвечу на этот вопрос. Видеоверсия доклада доступна на YouTube.
Общеизвестные базы данных 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 и регулярно платим за аренду, электричество и услуги дата-центра. Это стандартная схема.
Можно ли как-то иначе? C бессерверными сервисами можно.
В чем фокус этого подхода: нет сервера, нет даже аренды виртуального 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 будущее :)
Gorthauer87
Бесит термин serverless, ожидаешь нечто true p2p, а видишь тот же сервер, но где-то в облаке.
Полнейшее торжество булшита.
azathot Автор
В случае p2p сервер тоже, получается, есть, им является одна из клиентских машин :)… Или обе.
Здесь можно говорить об «эффективном» отсутствии сервера. Т.е. к серверу нельзя подключится по SSH, нельзя писать код в предположении, что под разными
функциями лежит общий диск, оперативка, или хоть что-то общее.
nin-jin
То есть вместо одного сервера выдерживающего 10К запросов, нам нужны уже 10 серверов, каждый из которых выдерживает лишь 1000 запросов, а всё остальное время занимается эмуляцией эффективного отсутствия сервера.
azathot Автор
Оно примерно так и обстоит, в контексте Aurora Serverless, только коэффициент не 10, а скорее 3. И поэтому к этой базе много вопросов.
Но по прежнему актуален вопрос — а что если запросов стало 100к? Или 0, на несколько часов?
nin-jin
Этот вопрос эффективно закрывается виртуализацией серверов без превращения в PHP.
Sergey-S-Kovalev
Serverless это просто очередной уровень абстракции. Вы снимаете с себя головняки железной и софтовой инфраструктуры, проблемы с покупкой и с лицензированием всего этого добра, обслуживанием, обновлением, поддержкой. Просто пишете свой код, который работает и приносит деньги. Очень хорошо для старта.
Но ваш код должен приносить деньги.
И вам не доступен тонкий тюнинг на уровне БД.
И данные лежат не у вас.
И код тоже не только ваш в контексте доступа.
nin-jin
А самое главное — код гвоздями прибит к конкретному провайдеру.
azathot Автор
Это безусловно верно, и было верно еще в рамках предыдущей парадигмы, managed баз и сервисов :)… Практически все западные стартапы живут в AWS или Azure, это уже данность, все привыкли.
McKinseyBA
Лично мне, как разработчику, конечно же приятно иметь небольшую «железную» избыточность ресурсов под рукой в рамках 200Тб кластера Vertica и специальных людей занимающихся обслуживанием DWH. А не думать о том как ETL-запросом не съесть бюджет Либерии. При этом Serverless, как и условные микро-сервисы, не станет серебряной пулей, а найдет свое место, если пройдет проверку временем.
Николай, рад возвращению на Хабр! Большинство Ваших постулатов (жесткий Anchor Modeling и пр.) не разделяю, но доклады на конференциях по Vertica и статьи здесь — всегда были проработанными и вызывали живой отклик. Удачи!
PS: думал Вы ушли из Avito в mail.ru…
azathot Автор
Привет-привет :)
В mail.ru я заглянул совсем ненадолго, понял, что мне важнее дух стартапа, и продолжил путь. Там норм, но перевести аналитику на бессерверное облачное решение вроде Snowflake там я бы не смог.
PS. В течении 2-3 месяцев выйдет еще одна статья от моей команды про нашу архитектуру. Anchor Modeling и бессерверная облачная база — далеко не единственный компонент нашего решения, который ранее в такой роли не применялся, но на удивление хорошо себя показал.
McKinseyBA
Адская смесь: AM + S. Учитывая избыточное количество джоинов в AM, было бы интересно глянуть экономику решения в сравнении с более часто встречающимися моделями данных (вот если бы для статьи замутить serverless стенд не на AM рядышком). Вангую, что ad-hoc запросы Anchor Modeling x2/x3 или на порядок дороже. Жду статью)
azathot Автор
Выбор такого решения был чисто экономический. AM как раз здорово позволило управлять костами Snowflake, за счет мелкой автоматической декомпозиции каждой операции. В итоге огромная доля расчетов и сервисных операций идет на XS и S кластерах. Кластера, сравнимы по костам с полноценной аналитической инсталляцией (L, XL, ...) работают только несколько минут в день.
erty
azathot Автор
Вы действительно считаете, что все американские и европейские компании, живущие в AWS, имеют проблемы с GDPR, который, к слову, более строг чем 152 ФЗ?
akabrr
То что проблем нет сейчас ничего не значит, проблемы могут появиться в любой, как правило самый не удобный, момент. Например когда у вас появился конкурент :)
azathot Автор
Какие проблемы, и как они связаны с облачными провайдерами?
Компания, работающая в Европе и не соблюдающая GDPR, нарывается на неприятности. Работающая, живущая в AWS и соблюдающая — что ей конкурент сделает?
uldashev
Справедливости ради, замечу, что если у Меня появился конкурент с господдержкой, то уж лучше пусть меня топят по 152-ФЗ, чем уголовкой по экономической части.
Честно говоря, все эти законы по защите данных всего лишь инструменты политической и экономической борьбы, а не инструменты защиты пользователей, для примера, сколько утечек за последние годы было из гос органов РФ? Хоть кого-то оштрафовали? Кого-то посадили?
tagirb
Здесь в Германии у AWS есть местный region, eu-central-1, знакомые мне сервисы S3, EBS, ElastiCache, RDS/Aurora, да и думаю, что и другие тоже, поддерживают шифрование данных, как при хранении, так и при передаче, есть сертификация по GDPR, BSI, FIPS, ISO 27001.
AWS, которая при этом гребет прибыль экскаваторами, больше делать нечего, как таскать и перепродавать чужие данные.
azathot Автор
AWS Frankfurt :)… Отличное место. Все описанные в статье базы там доступны, и Snowflake тоже. 100% GDPR Compliance.
acmnu
На сколько я знаю дела у AWS в Европе так себе. Собственно это хорошо видно по дисбалансу количества ЦОДов в США и Европе.
tagirb
AWS в Европе процветает, особенно, с введением GDPR.
gluck59
Мы действительно считаем, что надзорные органы, живущие в России, никогда не читали GDPR, не сравнивали его с 152-ФЗ и плевать хотели на все эти тонкости.
azathot Автор
И вы не читайте :)… И будет вам каждый год сюприз.
Год за годом видно, как в плане толкований и правоприменения 152ФЗ сближается с GDPR. И решения, принятые по GDPR (где 152 еще не давал однозначного ответа) отлично готовят к новым толкованиям.
tmin10
У амазона даже gov cloud есть с более строгой сертификацией чисто для гос компаний сша.
alekciy
По 152-ому можно иметь за границей, главное наличие копии в РФ.
azathot Автор
Небольшое уточнение — копии в РФ с приоритетной записью, предшествующей сохранению соответствующих персональных данных за границей, для граждан РФ.
В целом, вполне реализуемо, никакого рокет-сайнса. Благо облака у нас уже и на территории страны есть :)
nerudo
Бессерверная — это когда сервером владеет кто-то другой ;)
PS Были ведь бессерверные БД — файловые. Как вспомню — так вздрогну.
iit
SqLite и сейчас есть и он на небольших объемах (лендосики клепать) и сейчас хорош.
Многие его даже для всяких android приложений используют для каталогизации чего-нибудь.
VolCh
Когда читаю про серверлесс, всегда думаю о CGI из 90-х, ну или о PHP — пришёл запрос, развернули стэк, обработали, умерли.
azathot Автор
Второй вариант — это именно оно. Но в 2020 году — уже с тяжелым State, нужным для работы базы данных.
gluck59
Увы, слова сейчас значат совсем не то, что они значат...