company_banner

На пути к бессерверным базам данных — как и зачем

    Всем привет! Меня зовут Голов Николай. Раньше я работал в Авито и шесть лет руководил Data Platform, то есть занимался всеми базами: аналитическими (Vertica, ClickHouse), потоковыми и OLTP (Redis, Tarantool, VoltDB, MongoDB, PostgreSQL). За это время я разобрался с большим количеством баз данных — самых разных и необычных, и с нестандартными кейсами их использования.

    Сейчас я работаю в 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 будущее :)
    Конференции Олега Бунина (Онтико)
    Конференции Олега Бунина

    Комментарии 88

      +27

      Бесит термин serverless, ожидаешь нечто true p2p, а видишь тот же сервер, но где-то в облаке.
      Полнейшее торжество булшита.

        +2
        В случае p2p сервер тоже, получается, есть, им является одна из клиентских машин :)… Или обе.
        Здесь можно говорить об «эффективном» отсутствии сервера. Т.е. к серверу нельзя подключится по SSH, нельзя писать код в предположении, что под разными
        функциями лежит общий диск, оперативка, или хоть что-то общее.
          +2
          То есть вместо одного сервера выдерживающего 10К запросов, нам нужны уже 10 серверов, каждый из которых выдерживает лишь 1000 запросов, а всё остальное время занимается эмуляцией эффективного отсутствия сервера.
            0
            Оно примерно так и обстоит, в контексте Aurora Serverless, только коэффициент не 10, а скорее 3. И поэтому к этой базе много вопросов.
            Но по прежнему актуален вопрос — а что если запросов стало 100к? Или 0, на несколько часов?
              0
              Этот вопрос эффективно закрывается виртуализацией серверов без превращения в PHP.
          +4
          Serverless это просто очередной уровень абстракции. Вы снимаете с себя головняки железной и софтовой инфраструктуры, проблемы с покупкой и с лицензированием всего этого добра, обслуживанием, обновлением, поддержкой. Просто пишете свой код, который работает и приносит деньги. Очень хорошо для старта.

          Но ваш код должен приносить деньги.
          И вам не доступен тонкий тюнинг на уровне БД.
          И данные лежат не у вас.
          И код тоже не только ваш в контексте доступа.
            +9
            А самое главное — код гвоздями прибит к конкретному провайдеру.
              +1
              Это безусловно верно, и было верно еще в рамках предыдущей парадигмы, managed баз и сервисов :)… Практически все западные стартапы живут  в AWS или Azure, это уже данность, все привыкли.
                +1
                Практически все западные стартапы живут в AWS или Azure, это уже данность, все привыкли.
                потому что это OPEX))) Ни один нормальный инвестор не даст стартапу наращивать CAPEX в виде собственных серверов. Serverless дополнительно к стандартным «облачным плюшкам» переводит DBA и им подобных из зарплатной ведомости в OPEX, что еще более управляемо для инвесторов. Но не все стартапы хотят существовать как стартапы, некоторые становятся регулярным бизнесом, а 1 из 1000 выходит на биржу (и не умирает после выхода). Хотя и в таких топ-менеджмент, сменяющийся каждый год, предпочитает заниматься оптимизацией CAPEX, что отражается на годовых бонусах. Никто не любит думать на 10 лет вперед, т.к. не он будет пожинать плоды инвестиций, которые еще надо протащить через инвестиционный комитет.

                Лично мне, как разработчику, конечно же приятно иметь небольшую «железную» избыточность ресурсов под рукой в рамках 200Тб кластера Vertica и специальных людей занимающихся обслуживанием DWH. А не думать о том как ETL-запросом не съесть бюджет Либерии. При этом Serverless, как и условные микро-сервисы, не станет серебряной пулей, а найдет свое место, если пройдет проверку временем.

                Николай, рад возвращению на Хабр! Большинство Ваших постулатов (жесткий Anchor Modeling и пр.) не разделяю, но доклады на конференциях по Vertica и статьи здесь — всегда были проработанными и вызывали живой отклик. Удачи!

                PS: думал Вы ушли из Avito в mail.ru…
                  +1
                  Привет-привет :)
                  В mail.ru я заглянул совсем ненадолго, понял, что мне важнее дух стартапа, и продолжил путь. Там норм, но перевести аналитику на бессерверное облачное решение вроде Snowflake там я бы не смог.
                  PS. В течении 2-3 месяцев выйдет еще одна статья от моей команды про нашу архитектуру. Anchor Modeling и бессерверная облачная база — далеко не единственный компонент нашего решения, который ранее в такой роли не применялся, но на удивление хорошо себя показал.
                    0
                    Адская смесь: AM + S. Учитывая избыточное количество джоинов в AM, было бы интересно глянуть экономику решения в сравнении с более часто встречающимися моделями данных (вот если бы для статьи замутить serverless стенд не на AM рядышком). Вангую, что ad-hoc запросы Anchor Modeling x2/x3 или на порядок дороже. Жду статью)
                      0
                      Выбор такого решения был чисто экономический. AM как раз здорово позволило управлять костами Snowflake, за счет мелкой автоматической декомпозиции каждой операции. В итоге огромная доля расчетов и сервисных операций идет на XS и S кластерах. Кластера, сравнимы по костам с полноценной аналитической инсталляцией (L, XL, ...) работают только несколько минут в день.
                0
                И данные лежат не у вас
                Как вкусно. Успехов с GDPR, 152-ФЗ и прочими.
                  +3
                  Вы действительно считаете, что все американские и европейские компании, живущие в AWS, имеют проблемы с GDPR, который, к слову, более строг чем 152 ФЗ?
                    0
                    То что проблем нет сейчас ничего не значит, проблемы могут появиться в любой, как правило самый не удобный, момент. Например когда у вас появился конкурент :)
                      0
                      Какие проблемы, и как они связаны с облачными провайдерами?
                      Компания, работающая в Европе и не соблюдающая GDPR, нарывается на неприятности. Работающая, живущая в AWS и соблюдающая — что ей конкурент сделает?
                        +1
                        Справедливости ради, замечу, что если у Меня появился конкурент с господдержкой, то уж лучше пусть меня топят по 152-ФЗ, чем уголовкой по экономической части.
                        Честно говоря, все эти законы по защите данных всего лишь инструменты политической и экономической борьбы, а не инструменты защиты пользователей, для примера, сколько утечек за последние годы было из гос органов РФ? Хоть кого-то оштрафовали? Кого-то посадили?
                          0

                          Здесь в Германии у AWS есть местный region, eu-central-1, знакомые мне сервисы S3, EBS, ElastiCache, RDS/Aurora, да и думаю, что и другие тоже, поддерживают шифрование данных, как при хранении, так и при передаче, есть сертификация по GDPR, BSI, FIPS, ISO 27001.


                          AWS, которая при этом гребет прибыль экскаваторами, больше делать нечего, как таскать и перепродавать чужие данные.

                            +1
                            AWS Frankfurt :)… Отличное место. Все описанные в статье базы там доступны, и Snowflake тоже. 100% GDPR Compliance.
                              0

                              На сколько я знаю дела у AWS в Европе так себе. Собственно это хорошо видно по дисбалансу количества ЦОДов в США и Европе.

                                0

                                AWS в Европе процветает, особенно, с введением GDPR.

                            0

                            Мы действительно считаем, что надзорные органы, живущие в России, никогда не читали GDPR, не сравнивали его с 152-ФЗ и плевать хотели на все эти тонкости.

                              0
                              И вы не читайте :)… И будет вам каждый год сюприз.
                              Год за годом видно, как в плане толкований и правоприменения 152ФЗ сближается с GDPR. И решения, принятые по GDPR (где 152 еще не давал однозначного ответа) отлично готовят к новым толкованиям.
                            +1

                            У амазона даже gov cloud есть с более строгой сертификацией чисто для гос компаний сша.

                              0
                              По 152-ому можно иметь за границей, главное наличие копии в РФ.
                                0
                                Небольшое уточнение — копии в РФ с приоритетной записью, предшествующей сохранению соответствующих персональных данных за границей, для граждан РФ.
                                В целом, вполне реализуемо, никакого рокет-сайнса. Благо облака у нас уже и на территории страны есть :)
                            +4
                            Бессерверная — это когда сервером владеет кто-то другой ;)
                            PS Были ведь бессерверные БД — файловые. Как вспомню — так вздрогну.
                              0

                              SqLite и сейчас есть и он на небольших объемах (лендосики клепать) и сейчас хорош.
                              Многие его даже для всяких android приложений используют для каталогизации чего-нибудь.

                                0
                                и hive и сноуфлейк и прочие спарки — они и есть файловые субд
                                  –1
                                  В этой терминологии вообще все базы данных — файловые субд, без исключений. т.к без файлов на диске нигде не обошлись.
                                0

                                Когда читаю про серверлесс, всегда думаю о CGI из 90-х, ну или о PHP — пришёл запрос, развернули стэк, обработали, умерли.

                                  0
                                  Второй вариант — это именно оно. Но в 2020 году — уже с тяжелым State, нужным для работы базы данных.
                                  0

                                  Увы, слова сейчас значат совсем не то, что они значат...

                                  +1
                                  Не пойму в чем смысл от этих облачных СУБД. Кто вообще использует их? Хранить данные у дяди, платить за это деньги каждый месяц… Какой профит?
                                  Чтобы свой сервер не держать? Но свой дешевле
                                  Чтобы легко масштабироваться? Но когда большая нагрузка, то цена огромная
                                    +4

                                    Разница иметь 4 своих админов по базам или иметь ноль очень большая. Особенно если надо платить зарплату калифорнийским работникам :)

                                      +3

                                      А свой это где, дома под кроватью?
                                      В чем разница междую облачным и впс, если и там и там он тебе не принадлежит, но облачный не надо настраивать и менеджить?

                                        0
                                        Обычный впс стоит существенно дешевле, а менеджерить сейчас, с приходом докера, не сильно то и нужно
                                          +3

                                          Как оно, оказывается, всё просто: docker run mysql и готово, можно увольнять DBA. Тут тебе и прозрачный failover, и multi-master при желании, и read/write split, и автоскалирование числа реплик и snapshots, и maintenance и всё-всё-всё. Докер же :))

                                            +1
                                            А завтра ты платишь дешифровальщикам
                                              0
                                              Вы прямо глубоко копнули… Мультимастер это уже высшая математика.
                                              Я не уверен, что без DBA даже простейший мастер+пару слейвов получится восстановить после физического сгорания одной из машин… Если машины именно физические, как в посте выше. Покупка нового сервера, настройка, введение его в кластер…
                                                0

                                                Да, это я преувеличил.

                                                +1
                                                можно увольнять DBA

                                                а как база данных в облаке заменяет DBA, тебе базу проэктируют и запросы пишут сотрудники провайдера?
                                                Ну и в крайности тоже впадать не следует.
                                                docker run mysql и готово

                                                Ну и будем честны, чаще оно так чем не так=)

                                                например на яндексе виртуалка 2ядра(100%) 8 гигов стоит в 2.5 раза больше хетснера — 2800 против 1500 за 2 ядра(выделененные, теже 100%), 8 гигов
                                                за постгрес яндекс просит еще 700р в месяц сверху к 2800. 700р в месяц за инстанс, ок, могу принять, но откуда берется 2800 за саму виртуалку?
                                                А если не страшно железо, то на хетснере i7 6700, 32гига, 2 по 500 ssd стоит теже 3500, там можно 4 виртуалки поднять по 2 выделенных ядра и почти по 8 гигов памяти.

                                                сторонники облаков говорят «Вам не нужен админ девопс», но как-тослабо себе представляю
                                                  +3
                                                  тебе базу проэктируют и запросы пишут сотрудники провайдера

                                                  бэкендеры справляются… Последние годы в современных компаниях позиция DBA исчезает, по моим наблюдениям.
                                                    0

                                                    DBA всегда нужен. Но с облачной базой у него будет больше времени на сон и на, собственно, базу.
                                                    Взять нашего DBA: с дедиками ему нужно было ещё и следить за железом, ОС и сетью вокруг, IPMI глючил, ECC RAM-модули умирали каждые 3 месяца, бондинг-интерфейсы выпадали. Сейчас у нас ещё даже не Aurora/RDS, а просто EC2. Вместо серверов у него небольшой Terraform-проект. Все.

                                                      0
                                                      А почему этим ДБА занимался?
                                                      Интересно кстати услышать разницу, как в деньгах, так и удобстве.
                                                      Еще один ньюанс, когда речь заходит о том что современное ПО требует непомерное кол-во ресурсов и работает так же как и ПО которое было 20 лет назад, обычно люди отвечают «Труд программистов слишком дорог» и конечно час программиста дороже чем планка памяти которую покупает пользователь, ведь платит за нее пользователь.
                                                      Возвращаясь к облакам. За говнокод программиста уже платит его работодатель в виде оплаты лишних ресурсов.
                                                        +1
                                                        А почему этим ДБА занимался?
                                                        Интересно кстати услышать разницу, как в деньгах, так и удобстве.

                                                        Потому что больше некому. У нас не стартап, но и не энтерпрайз, средних размеров контора. Можно было либо нанять кого-то ещё одного, а то и нескольких сотрудников, которые бы занимались железом. После миграции в облако эта необходимость почти сошла на нет. Почти — потому что мы ещё не везде на RDS/Aurora. Центральная база пока на EC2, но миграция в процессе. По деньгам точно не скажу, помню, что по нашим расчётам нанять нового сотрудника вышло бы дороже.


                                                        Проблемы качества ПО стали более заметны, т.к. напрямую коррелируют с нашими расходами на облако. В результате повысился приоритет рефакторингов и оптимизаций.


                                                        Кроме того, разработчики в восторге от того, что могут легко и запросто подключать и интегрировать другие облачные сервисы: SQS, Lambda, S3, CloudFront и т.д.


                                                        Короче, куча плюсов, как прямых, так и косвенных.

                                                  +1
                                                  Обычный ВПС дешевле когда у вас блог на 1000 чел, в статье ведется речь про хайлоад и балансировку нагрузки, и вот там я очень сомневаюсь что обычный ВПС дешевле.

                                                  А еще обычный ВПС не принадлежит вам также как и облачный, потому что у вас нет гарантий что кто-то в датацентре не сливает ваши данные. Вам тогда свой ДЦ строить надо
                                                +2
                                                Не вполне понятен вопрос… 2020 год на дворе. Большинство новых компаний на американском и европейском рынке держат все свои базы в облаках.
                                                Свои ДЦ держат только отдельные старые консервативные компании, вроде не очень крупных банков, которым нужно все переделывать для перехода на облачную инфраструктуру.
                                                Переход в облака (оправданность) можно было обсуждать 5 лет назад, но сейчас то зачем, поезд уехал…
                                                  +2
                                                  «Мыши плакали, кололись…» всё зависит от размеров и нагрузки, те кто успели сильно подсесть страдают и переезжают на свои дата центры.
                                                    +1
                                                    :)… Т.е. пользование облаками падает, компании оттуда уходят, облачные провайдеры разоряются?
                                                      0

                                                      Хм, или наоборот. Дата центр не свернёшь при падении нагрузки и не расширишь при росте. Нужно всегда брать с запасом под пики нагрузки. Всё зависит от проектов.

                                                        0
                                                        Дата центр делают свой когда примерно известны нагрузки и есть постоянные большие, а с гибридным решением когда часть у себя часть у облачного провайдера, можно и пики пережить без проблем. Да и что за проблема со сворачиванием? В большой компании всегда найдётся способ как использовать ресурсы, обычно проблема что их не хватает, а не то что их слишком много.
                                                          0
                                                          Амазон так к идее AWS и пришёл, когда понял, что ресурсы в своём ДЦ простаивают и надо их как-то в работу включать.
                                                      0
                                                      Т.е. Bank of NY, например, держит свои данные у дяди, вызывает процедуры обработки данных написанные васянами и уволил всех админов и дба? Что за новые компании — стартапы-однодневки?
                                                        +1
                                                        Bank of New York Mellon? Они в Azure, да. В 2017 начали переход.
                                                        0

                                                        Богатые, наверное, компании.


                                                        Давеча считал альтернативы размещения относительно простого приложения — PHP, mysql, redis, elastic, файло. AWS во Франкфурте — под 2000 (без трафика и балансеров) долларов в месяц, дедики — 500 сложно выбрать на плюс минус то же CPU и RAM.


                                                        Разочаровал меня AWS, GC и т. п. Годами читал "платишь за то, что потребляешь" и завидовал, глядя на top, когда за минуту на 4-8 ядрах то вообще нагрузки нет, то LA 5-10.А оказывается нужно заранее выбирать сколько ядер и памяти. И платить, даже если нагрузки нет.

                                                          0
                                                          Serverless концепция как раз про то, чтобы не платить, пока нагрузки нет :)… Не все типы нагрузки так можно обрабатывать, по состоянию на 2020, но технологии не стоят на месте.
                                                          Что касается озвученных костов — т.к. 24к.$ в год… За эти деньги альтернативно можно купить… один? два сервера? + аренда ДЦ.
                                                            +1
                                                            В год.

                                                            В итоге облака выгодны тем, кто больше года прожить и не рассчитывает.
                                                              +2
                                                              Или тот, кто планирует каждый год удваиваться.
                                                              Экономия на долгосрочном использовании сервера — это звучит реальным для компании, которая уверена, что перспектив роста на 2-3 года у нее нет никаких… По мне звучит достаточно депрессивно… И риск сгорания 1-2 серверов, замена которым будет ехать 90 дней, но бизнес подождет…
                                                              0

                                                              Поднимать инстанс для обработки запроса больше секунды означает, что постоянно надо держать его. Сколько одновременных запросов планируешь — столько инстансов и держать горячими.


                                                              За эти деньги можно арендовать в 4 раза больше железа, даже не VDS, а DS

                                                                0

                                                                Как ни крути, но у нас всё упирается в реляционную БД. Она скалируется только вертикально и должна быть всё время наготове, потому жрёт бОльшую часть бюджета.


                                                                А веб-воркеры требуют не так уж и много, в контейнерах было бы даже ещё меньше. Ну и ещё есть т.н. serverless (в AWS API Gateway + Lambda). У нас он используется на проекте с резкими скачками нагрузки: 95% времени — 5% нагрузки и 5% времени — 95% нагрузки. Проблем с масштабированием с 0 до 1000 запросов в сек. не было никаких, расходы — минимальные.

                                                                  0
                                                                  А представьте, что и базу можно было бы делать serverless? :)… Про это и статья.
                                                                    0

                                                                    Ага. Мы завязаны на MySQL, поэтому осторожно посматриваем в сторону Aurora Serverless. Про Snowflake было интересно, повтыкаю на досуге.

                                                                      0
                                                                      К сожалению да, serverless OLTP база на замену MySQL пока недостижимая мечта… Тем лучше будет позиция тех, кто первым создаст или эмулирует такое решение.
                                                          +1
                                                          я последние лет 6 не видел СУБД на своем железе, все проекты в aws или gcp. сон кстати улучшился — последний раз репликацию чинил среди ночи еще на железе. В этом и смысл — много операционного головняка снимается.
                                                            0

                                                            У нас была (и вроде, еще жива) своя база. Ну как своя — в EC2, при том, что остальные бд в RDS. Потому что еще пару-тройку лет назад к базе в RDS нельзя было прикрутить Debezium — а нам надо. Сейчас, вроде, уже можно.

                                                            +2

                                                            БД разворачивается по темплейту терраформа, автоматически бэкапится, поднимаются реплики. Чтобы всё это настроить руками нужно изучить много материалов или найти специального человека, а так разработчики могут быстро поднять базу и начать писать код.
                                                            Но для домашнего проекта цены облака, увы, кусаются.

                                                            +3
                                                            There ain't no such thing as a free lunch.
                                                            если вьі не хотите заниматься серверами — кто-то будет за деньги заниматься за вас.
                                                            но дороже.
                                                            для системьі типа proof-of-concept — подет… но как только начнется нагрузка — стоимость оутсорса бд будет космической.
                                                              +2
                                                              Космической это сколько в $ :)?
                                                              Нагрузка началась, расходы не выходят за планируемые.
                                                              Описываемые риски были актуальны 5-10 лет назад. Сейчас аргумент за выбор облаков прежде всего финансовый, если расход на команду поддержки не исключать.
                                                                0

                                                                2000 за AWS + 4000 за "девопса" или 500 за дедики и 2000 за админа.

                                                                  +1

                                                                  Странно как-то, почему девопс стоит дороже админа? По-моему опыту девопсить с дедиками намного муторнее, а значит, и дороже.

                                                                    0

                                                                    Так рынок порешал. Видимо, знаний для облаков нужно больше. Или с дедиками всё уже давно стандартизировано, а с облаками постоянно надо адаптироваться к изменениям.

                                                                    +1
                                                                    Скажем так, для того чтобы админить то, на что хватает 2000$ в AWS,  достаточно недельного курса для любого разработчика (или техдиректора? пусть пользу приносит). Главная проблема, чтобы знания как-то повторять, т.к. за месяцы неиспользования легко все забыть.
                                                                      0

                                                                      Не согласен, что достаточно. Ну и зп техдира может быть гораздо выше "девопса", на начальном этапе, когда сетапом фуллтайм заниматься надо. А от "девопса" и другая польза должна быть.

                                                                +2

                                                                Мне всегда так нравилось про "раз — и результат. ни ETL, ни баз данных. Афина или Спектр все за тебя сделают". А потом "Афина — только для спонтанных запросов, иначе слишком дорого"…
                                                                Может все-таки следует упоминать экономику serverless решений?

                                                                  +1

                                                                  У афина тарификация идёт за размер прочитанных запросом данных. Т.е. 100 запросов читающих 10 Мб и 1 читающий 1000 Мб стоят одинаково. Минимум для запроса 10 Мб, цена: $5 за 1 Тб.
                                                                  Но сколько что стоить будет в итоге нужно считать под конкретный проект и задачу, иначе всё очень туманно.

                                                                    0
                                                                    Статья и так огромная получилась :)… Выше супер-коммент, где разобран именно прайсинг Афины.
                                                                    Это глубокая тема, если интересно, можно в привате обсудить.
                                                                    Все аспекты, связанные с деньгами, страшно в публичных статьях обсуждать, можно случайно посчитать не по публичному прайсингу, а по… особым условиям.
                                                                    0
                                                                    Доступны варианты из 16, 32 машин, в зависимости от сложности запросов. Но вы платите только за те минуты, когда кластер реально работает, потому что, когда запросов нет, вы как бы убираете руки, и после 5-10 минут ожидания (настраиваемый параметр) он сам погаснет, освободит ресурсы и станет бесплатным.

                                                                    Звучит, как мерзкое убожество по сравнению с Google Big Query…
                                                                      0
                                                                      Google Big Query тоже отличный пример реализации аналитической бессерверной базы :)
                                                                      К сожалению, достаточно старый и дорогой, иначе у аналитических баз платформы AWS не было никаких шансов в честной конкуренции.
                                                                      +1

                                                                      Интересно, вы пишите, что бессерверные базы новинка 2020 года, тогда как DynamoDB существует с 2012 года и спроектирована именно как бессерверная: там нет ни кластеров, ни инстансов. Всё, чем мы можем управлять и масштабировать — число записей и чтений (и регионы репликации, конечно).
                                                                      Да та же Athena с Presto под капотом, запущенная в 2016: пользователь вообще не видит никаких кластеров, как в Snowflake...

                                                                        +3
                                                                        Кстати да, DynamoDB с on-demand прайсингом тоже вполне может рассматриваться как бессерверная, не подумал. При этом она может быть поднята и в provisioned режиме, с выделенными серверами.
                                                                        Про 2020 год — я описываю уровень зрелости этих баз, а не год появления. Athena стартовала в 2016, Snowflake начал писаться в 2012, в 2015 уже мог что-то делать. В 2020 можно без страха рекомендовать ими пользоваться.
                                                                        0
                                                                        При этом, к сожалению, для OLTP-нагрузок она еще не применима. Во-первых, эта база колоночная, со всеми вытекающими последствиями.

                                                                        Строго говоря поколоночное inmemory хранение не является препятствием для создания OLTP решений. Пример СУБД SAP HANA и SAP ERP S/4 HANA.
                                                                          +1
                                                                          Кстати да, колоночность не является препятствием для OLTP. Она просто порождают меньшую эффективность обработки нагрузки, которую можно компенсировать железом.
                                                                          В SAP Hana, и в одной из новых баз, MemSQL, насколько я знаю, применяется фокус с двойным хранением — данные хранятся дважды, в колонках, и в строках. Строчное хранение держит OLTP нагрузку, колоночное — OLAP нагрузку. Это в некотором роде передний край технологий.
                                                                          0

                                                                          Отличная вводная статья, но я бы выделил Snowflake в отдельную статью. SF не называют свой продукт serverless, по сути — это managed analytical db, т.к. вы указываете какие вычислительные ресурсы использовать. При этом есть serverless фичи, например — Snowpipe. Вот, например, они сравнивают SF с serverless аналогами:
                                                                          https://www.snowflake.com/blog/snowflake-versus-query-engines/


                                                                          А вот Google BigQuery является serverless analytical db, в ней вы вычислительными ресурсами не управляете.

                                                                            0
                                                                            … А вы с кем с команде разработки Snowflake общаетесь, чтоб привет передать?…
                                                                            Просто есть маркетинг, и есть технические нюансы. В описанной вами статье речь идет не о сравнении с serverless databases, а с serverless query engines, вычленяемых ими, прежде всего, по ценообразованию.
                                                                            В Snowflake вы не можете «управлять» вычислительными ресурсами, как в managed databases вроде RDS. Вы можете указывать тип вычислительных ресурсов, рекомендовать конкретный ресурс, но без жесткого контроля.
                                                                            Простейший пример — вы создаете кластер размера M, задаете ему коэффициент скалирования 0-3, и направляете в него, например, 5 последовательных однотипных тяжелых запросов (работающих с идентичными исходными данными, но по разному).
                                                                            Первый запрос из 5, очевидно, будет сильно медленней, т.к. он упадет в «непрогретый» кластер, и потребует перекачки исходных данных из S3.
                                                                            Но означает ли это, что остальные 4 выполнятся быстрее, сравнимо быстро? Нет, т.к. возможен, например, следующий сценарий:
                                                                            1 запрос: старт кластера M1 (Размер Medium, первая копия), наполнение данными из S3, выполнение запроса.
                                                                            2 запрос: уже поднятый кластер M1, данные уже загружены, только выполнение запросов.
                                                                            3 запрос: оптимизатор принимает решение, что M1 перегружен. Старт кластера M2 (Размер Medium, вторая копия), наполнение данными из S3, выполнение запроса.
                                                                            4 запрос: оптимизатор принимает решение, что M1 и M2 перегружены. Старт кластера M3 (Размер Medium, третья копия), наполнение данными из S3, выполнение запроса.
                                                                            5 запрос: кластер M1 потерян (сбой, перезагрузка), M2 и M3 перегружены. Старт кластера M1 (Размер Medium, первая копия), наполнение данными из S3, выполнение запроса.

                                                                            В итоге, управление ресурсами — очень опосредованное.
                                                                              0
                                                                              Так это как хинты оптимизатора в Постгресе. Они-то как бы есть, только ты ими не управляешь.
                                                                              p.s. Хочу тоже пощупать сноуфлейк. Кажется очень перспективным
                                                                                0
                                                                                К сожалению, это еще не хинты, это примерно на один уровень контроля слабее.
                                                                                Раскрытие хинтов Вертики позволило нам выйти на новый уровень использования этой базы в Авито.
                                                                                Сейчас мы очень плотно работаем с поддержкой Snowflake, чтобы получить хоть немного больше контроля, хотя бы на уровне хинтов.
                                                                                Но пока доступный контроль минимален.

                                                                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                          Самое читаемое