Сегодня бо́льшая часть production-решений продолжает резервировать собственные мощности под базы данных. Да, это надёжно и привычно, но тем не менее всё больше проектов обращается к бессерверным инструментам, в том числе и к базам данных. Создатели находят этим инструментам применение в распределённых приложениях и микросервисах, где важна скорость разработки и возможность масштабирования.
Бессерверные базы данных развивались последние несколько лет параллельно с бессерверными вычислениями, и сейчас можно условно выделить два типа СУБД: адаптирующие популярные базы данных под бессерверное использование и разработанные под бессерверный режим. В этой статье я расскажу об их особенностях и дам примеры применения.
Простота в обслуживании. На просторах интернета можно встретить такие заявления, что облачная архитектура — NoOps-решение. Отчасти это так, облачный провайдер берёт на себя львиную долю работы по обслуживанию. В части бессерверных СУБД вы даже не выбираете оборудование, потому что не нужно резервировать мощности. Для компаний с администраторами баз данных можно говорить, что появляется возможность заниматься бизнес-логикой. Важно понимать: кроме обслуживания, есть ещё непосредственная работа с базой, и в зависимости от класса СУБД (SQL, NewSQL, NoSQL) сложность будет разная. Последний требует опытного специалиста в NoSQL, который поможет не собрать на пути все грабли.
Масштабируемость. Про бессерверные СУБД ещё добавляют — бесконечная. Возможно, это немного преувеличено. Хотя даже SQL-решения имеют в несколько раз превосходящую пропускную способность в сравнении с обычными SQL СУБД, все классы СУБД ограничены пропускной способностью и размером контейнеров. Но архитектура самих бессерверных СУБД разная, поэтому упереться в предельные значения при резервируемых квотах и грамотном проектировании первичного ключа становится невозможным. Тем более что вы опять же не выбираете мощность оборудования.
Отказоустойчивость. Стандартный набор от облачного провайдера: минимум три зоны доступности, резервное копирование и автоматическое восстановление. В бессерверном режиме вы определённо будете платить за дополнительные резервные копии. У некоторых провайдеров и автоматические резервные копии выделены отдельно из стоимости услуг. В таком случае главное — не забыть оформить эту услугу.
Отличительной особенностью бессерверных баз данных является экономическая эффективность перед Managed-сервисами. В бессерверной архитектуре клиент платит не за резервируемые мощности, а за операции чтения, записи, удаления и (или) время активной работы. Такой подход позволяет более точно рассчитать экономику проекта в условиях невозможности спрогнозировать масштабы. Снимается боль бизнеса — оплата мощностей за время простоя. Но на первое место выходит сложность операций, выполняемых с данными. И здесь важны сразу два аспекта: время обработки запроса и рост стоимости от сложности.
При этом в бессерверном режиме остаётся оплата за хранение данных, восстановление из резервной копии и исходящий трафик. Но это не противоречит пункту об экономии, расчёт будет по фактическим ГБ.
Получается, что привычный Stateful-сервис в бессерверных СУБД разделён на хранение данных, что всё ещё относится к Stateful-части, и обработку. Последнее — Stateless: запрос пришёл — запрос обработан — ответ получен — всё уничтожено.
Отсутствие у команды опыта с классом СУБД или конкретной реализацией — основная причина неверного выбора бессерверной базы данных. Осознанный выбор даже между реляционными базами может дать дополнительные преимущества для приложения.
Поэтому при выборе бессерверной СУБД я бы рекомендовал обратить внимание на класс СУБД и порог входа в работу с ней, оценить ограничения в масштабировании и возможность построения всей архитектуры у одного вендора.
В сухом остатке Aurora не совсем полноценная бессерверная СУБД. Это всё та же MySQL или PostgreSQL с повышенной пропускной способностью и возможностью выбора бессерверной оплаты за объём хранилища, ресурсы БД и операции ввода/вывода, которые база данных использует во время активной работы.
Несмотря на отличную масштабируемость и производительность, отсутствие SQL и есть главный минус DynamoDB. В остальном эта СУБД занимает лидирующее положение, отчасти из-за удобства построения всей архитектуры приложения в AWS.
Есть ряд ограничений, касающихся длительности транзакций и партиционирования данных, но это не скрытые сюрпризы, при подробном изучении СУБД перед выбором описанные недостатки лежат на поверхности.
СУБД разработана в качестве замены Realtime Database с возможностью быстрых запросов и масштабированием. Вкупе с нативными SDK и легко прокручиваемой разработчиком аутентификацией, вариант занимает свою нишу для мобильных приложений, которые планируют не выходить за лимиты масштабирования.
Вариант ограничен тем, что это только Data API, для развёртывания полноценного бессерверного приложения понадобится интеграция с решениями одного из облачных провайдеров. По умолчанию заявлена интеграция с основными западными облаками.
Для запросов можно использовать CQL или написанный DataStax API GraphQL, последний предполагает увеличение производительности базы данных.
Эти кейсы — положительный опыт компаний, с одной стороны, в облачной инфраструктуре, с другой — в переходе на бессерверные СУБД. Успех был определён тем, что команды не бездумно шли за трендами, а понимали свой проект и учли: все ли аспекты позволяют работать в облаках и хранить там данные, будет ли решение экономически выгодным.
habr.com
Бессерверные базы данных развивались последние несколько лет параллельно с бессерверными вычислениями, и сейчас можно условно выделить два типа СУБД: адаптирующие популярные базы данных под бессерверное использование и разработанные под бессерверный режим. В этой статье я расскажу об их особенностях и дам примеры применения.
Ключевые особенности бессерверных СУБД
Бессерверные СУБД — Managed-сервисы для баз данных с выбором бессерверного режима и всеми наследуемыми характеристиками: простота в обслуживании, масштабируемость, отказоустойчивость. При этом по каждому пункту бессерверные базы данных имеют преимущества. Рассмотрим подробно.Простота в обслуживании. На просторах интернета можно встретить такие заявления, что облачная архитектура — NoOps-решение. Отчасти это так, облачный провайдер берёт на себя львиную долю работы по обслуживанию. В части бессерверных СУБД вы даже не выбираете оборудование, потому что не нужно резервировать мощности. Для компаний с администраторами баз данных можно говорить, что появляется возможность заниматься бизнес-логикой. Важно понимать: кроме обслуживания, есть ещё непосредственная работа с базой, и в зависимости от класса СУБД (SQL, NewSQL, NoSQL) сложность будет разная. Последний требует опытного специалиста в NoSQL, который поможет не собрать на пути все грабли.
Масштабируемость. Про бессерверные СУБД ещё добавляют — бесконечная. Возможно, это немного преувеличено. Хотя даже SQL-решения имеют в несколько раз превосходящую пропускную способность в сравнении с обычными SQL СУБД, все классы СУБД ограничены пропускной способностью и размером контейнеров. Но архитектура самих бессерверных СУБД разная, поэтому упереться в предельные значения при резервируемых квотах и грамотном проектировании первичного ключа становится невозможным. Тем более что вы опять же не выбираете мощность оборудования.
Отказоустойчивость. Стандартный набор от облачного провайдера: минимум три зоны доступности, резервное копирование и автоматическое восстановление. В бессерверном режиме вы определённо будете платить за дополнительные резервные копии. У некоторых провайдеров и автоматические резервные копии выделены отдельно из стоимости услуг. В таком случае главное — не забыть оформить эту услугу.
Отличительной особенностью бессерверных баз данных является экономическая эффективность перед Managed-сервисами. В бессерверной архитектуре клиент платит не за резервируемые мощности, а за операции чтения, записи, удаления и (или) время активной работы. Такой подход позволяет более точно рассчитать экономику проекта в условиях невозможности спрогнозировать масштабы. Снимается боль бизнеса — оплата мощностей за время простоя. Но на первое место выходит сложность операций, выполняемых с данными. И здесь важны сразу два аспекта: время обработки запроса и рост стоимости от сложности.
При этом в бессерверном режиме остаётся оплата за хранение данных, восстановление из резервной копии и исходящий трафик. Но это не противоречит пункту об экономии, расчёт будет по фактическим ГБ.
Получается, что привычный Stateful-сервис в бессерверных СУБД разделён на хранение данных, что всё ещё относится к Stateful-части, и обработку. Последнее — Stateless: запрос пришёл — запрос обработан — ответ получен — всё уничтожено.
Базы данных: сравнение основных решений
При проектировании и создании приложения один из ключевых аспектов — какую базу данных использовать. Неверное решение приведёт к тому, что придётся выбирать между сменой СУБД и принятием проблем, поиском нестандартных решений. Это в конечном итоге — затраты денег и ресурсов, и этих затрат можно было избежать.Отсутствие у команды опыта с классом СУБД или конкретной реализацией — основная причина неверного выбора бессерверной базы данных. Осознанный выбор даже между реляционными базами может дать дополнительные преимущества для приложения.
Поэтому при выборе бессерверной СУБД я бы рекомендовал обратить внимание на класс СУБД и порог входа в работу с ней, оценить ограничения в масштабировании и возможность построения всей архитектуры у одного вендора.
Amazon Aurora Serverless
Aurora Serverless — это изначально реляционная база данных, которую переписали под облака, затем доработали бессерверную версию со всеми вытекающими плюшками. Ключевой особенностью представляется совместимость с MySQL и PostgreSQL. Выделены две версии, на выбор. Amazon Aurora является частью сервиса Amazon Relational Database Service (RDS), поэтому есть интеграции с MariaDB, Oracle и SQL Server.В сухом остатке Aurora не совсем полноценная бессерверная СУБД. Это всё та же MySQL или PostgreSQL с повышенной пропускной способностью и возможностью выбора бессерверной оплаты за объём хранилища, ресурсы БД и операции ввода/вывода, которые база данных использует во время активной работы.
Amazon DynamoDB
DynamoDB уже 4 года назад была интересна для разработчиков бессерверных приложений за счёт интерфейса, минимальной настройки на старте и NoSQL. Аргумент по части NoSQL такой, что бессерверные приложения по большей части в стартапах, когда нет истории, нет понимания будущей модели данных, прогнозов трафика. Но мнения формировались неоднозначные, совсем без понимания разработчиками NoSQL нельзя.Несмотря на отличную масштабируемость и производительность, отсутствие SQL и есть главный минус DynamoDB. В остальном эта СУБД занимает лидирующее положение, отчасти из-за удобства построения всей архитектуры приложения в AWS.
Azure Cosmos DB
Cosmos DB — NoSQL база данных Microsoft с документ-ориентированным API. С одной стороны, есть интерфейсы API с открытым кодом для MongoDB и Cassandra, с другой — SQL API. Это не позволяет делать SQL-запросы в чистом виде, есть некоторые отличия языка, но то, что есть возможность работать с разными моделями данных в едином сервисе, без мучений выбора и сомнений «подойдёт ли для нас», — сильное преимущество. Притом что Cosmos не теряет в производительности, масштабируемости и доступности.Есть ряд ограничений, касающихся длительности транзакций и партиционирования данных, но это не скрытые сюрпризы, при подробном изучении СУБД перед выбором описанные недостатки лежат на поверхности.
Yandex Database
YDB — распределённая NewSQL СУБД. YDB поддерживает реляционную модель данных и оперирует таблицами с предопределённой схемой. При этом поддерживается строгая консистентность и распределённые ACID-транзакции. Важно отметить, что поддерживается язык запросов YQL (Yandex Query Language), диалект SQL и API сервиса в режиме бессерверных вычислений совместим с API Amazon DynamoDB, с помощью этого API можно выполнять операции над документными таблицами.Google Firestore
Cloud Firestore — это база данных NoSQL от Google Cloud Platform, основанная на Firebase, которая разработана в первую очередь для веб-приложений и мобильных приложений, но при этом подходит для общего использования на стороне сервера.СУБД разработана в качестве замены Realtime Database с возможностью быстрых запросов и масштабированием. Вкупе с нативными SDK и легко прокручиваемой разработчиком аутентификацией, вариант занимает свою нишу для мобильных приложений, которые планируют не выходить за лимиты масштабирования.
FaunaDB
FaunaDB — транзакционная СУБД от Twitter, она не является частью существующего крупного поставщика облачных услуг. Для запросов создан FQL — это функциональный язык запросов, созданный для расширенной обработки данных.Вариант ограничен тем, что это только Data API, для развёртывания полноценного бессерверного приложения понадобится интеграция с решениями одного из облачных провайдеров. По умолчанию заявлена интеграция с основными западными облаками.
Astra DB
СУБД от DataStax, в основе Apache Cassandra — NoSQL-база данных с открытым исходным кодом. DataStax предоставляют базу данных в качестве услуги, при этом есть возможность развёртывания в AWS, GCP или Azure.Для запросов можно использовать CQL или написанный DataStax API GraphQL, последний предполагает увеличение производительности базы данных.
Что можно сделать с бессерверными СУБД
Бо́льшая часть примеров привязана к определённым вендорам, но это не помешает рассмотреть причины перехода на бессерверную архитектуру. Любой из примеров может быть реализован практически в каждом облаке.Масштабирование при пиковых нагрузках в e-commerce
Стартап из Индонезии The Shonet, социальная сеть и e-commerce, вырос до 3 млн пользователей и перед внедрением в проект e-commerce перешёл на беcсерверный подход в архитектуре. Решение было связано с пиковыми периодами покупок.Экономия на отсутствии резервируемых мощностей в периоды падения трафика
Clive, надстройка к Cascade CMS, — приложение, позволяющее пользователям CMS создавать формы без программирования и персонализировать контент. Объём трафика Clive варьируется в 10 раз в течение суток.Сокращение времени простоя и потери производительности до нуля
Компания Pokémon Company первоначально выбрала NoSQL и столкнулась со сложностью поддержки бесперебойной работы узлов. Выбор SQL-решения позволил сократить узлы с 300 до 30 и свести к нулю время простоя и снижения производительности.Освобождение ресурсов эксплуатации баз данных для работы с бизнес-логикой
Перед FINN.no, крупнейшим сайтом объявлений в Норвегии, стояла задача перенести приложение с базой данных Apache Cassandra в облако, чтобы сосредоточиться на разработке, а не управлении инфраструктурой. Приложение поддерживает около двадцати процентов трафика на сайт, это порядка 10 млн посещений в месяц.Решение проблемы масштабируемости без роста стоимости услуги
Dropbox в 2018 году столкнулся с нехваткой ёмкости в своём локальном хранилище метаданных. Одним из решений было найти легко масштабируемый вариант, не увеличив расходы. Выбор пал на хранилище данных S3 и NoSQL СУБД. Интересный итог: сокращение стоимости одного гигабайта пользователя в 5,5 раза.Эти кейсы — положительный опыт компаний, с одной стороны, в облачной инфраструктуре, с другой — в переходе на бессерверные СУБД. Успех был определён тем, что команды не бездумно шли за трендами, а понимали свой проект и учли: все ли аспекты позволяют работать в облаках и хранить там данные, будет ли решение экономически выгодным.
П.С. Про коммьюнити
Сама сфера serverless достаточно бурно развивается и у нас есть активно растущее serverless-коммьюнити Yandex Serverless Ecosystem в Telegram, где можно задавать вопросы, возникающие в процессе создания serverless-приложений и получать ответы от единомышленников и коллег.
Бессерверные БД: зачем переводить Stateful-сервис в Serverless
Сегодня бо́льшая часть production-решений продолжает резервировать собственные мощности под базы данных. Да, это надёжно и привычно, но тем не менее всё больше проектов обращается к бессерверным...
habr.com