Режимы работы Serverless и Dedicated
Вы можете создать и использовать множество баз данных YDB. Для каждой БД при создании выбирается один из двух режимов работы: Serverless или Dedicated. В дальнейшем он не может быть изменен.
- Serverless — БД, не требующая от вас какого-либо конфигурирования, администрирования, отслеживания загрузки и управления ресурсами. Для ее создания достаточно указать имя, и вы получите URL для соединения. Оплата берется за исполнение запросов и фактический объем хранимых данных.
- Dedicated — вы определяете вычислительные ресурсы, которые будут зарезервированы под БД: CPU и RAM на узлах, количество узлов и объем хранилища данных. Вам необходимо отслеживать достаточность ресурсов для успешной обработки нагрузки и добавлять новые по мере необходимости. Оплата берется за выделенные ресурсы по часам, вне зависимости от их фактического использования.
Дополнительная информация о тарификации и ценах Yandex Cloud:
- Для Serverless БД.
- Для Dedicated БД.
В Yandex Cloud БД в режиме Serverless поддерживает работу с данными не только с помощью YDB API, но и с помощью Document API — HTTP API, совместимого с Amazon DynamoDB. С помощью этого API можно выполнять операции над документными таблицами.
Параметры Serverless базы данных
Ограничения — пропускная способность, RU/с
При исполнении запроса к Serverless БД данных вычисляется показатель, отражающий величину ресурсов разного вида, затраченных на исполнение этого запроса. Данный показатель измеряется в специальных единицах — Request Units (RU). От суммарного потребления RU зависит стоимость использования Serverless БД.
Так как ресурсы Serverless БД неопределенно большие, то и максимальное потребление Request Units за промежуток времени также может составить любое значение, приведя к нежелательным начислениям. Например, такое может произойти в результате ошибки в коде, приводящей к запросам в бесконечном цикле.
При облачном развертывании YDB на уровне облачных квот существует ограничение на общее количество Request Units в секунду. Но данное ограничение носит технический характер и достаточно велико, чтобы возможная сумма счета оказалась заметно выше ожиданий. Изменение этого параметра возможно только в сторону увеличения через обращение в техническую поддержку.
Ограничение Пропускная способность на Serverless БД позволяет вам установить максимальную скорость потребления RU в секунду. С учетом 5 минутного накопления неиспользованных RU, небольшие величины этого ограничения (10 RU/с — значение по умолчанию при создании БД) позволяют успешно осуществлять широкий круг задач разработки и тестирования, а также эксплуатировать приложения с небольшой нагрузкой. При этом величина возможных начислений будет ограничена верхней границей в 2572000 секунд в месяц (30 дней), умноженной на цену за 1 миллион RU. По тарифу, актуальному на момент написания этой документации (13.36 ₽), максимально возможная сумма начислений в месяц составит около 340 ₽.
Ограничение Пропускная способность может быть изменено в интерактивном режиме в любой момент, как в сторону увеличения, так и в сторону уменьшения, без ограничений. Это позволяет вам оперативно менять его по мере надобности, например для прогона нагрузочного теста. Интерактивность означает, что изменение применяется с минимальной технологической задержкой, необходимой для распространения информации о новом значении по узлам YDB.
Ограничение Пропускная способность может быть установлено в ноль, что приведет к возникновению исключений превышения нагрузки на любом запросе. Это может быть полезно для тестирования реакции вашего приложения на такое исключение, а также аварийному предотвращению продолжения потребления каких-либо ресурсов, если ваше приложение вышло из-под контроля.
Ограничение Пропускная способность может быть включено или отключено. Мы рекомендуем всегда держать его включенным, однако его отключение может оказаться полезным, если вам необходимо временно получить от БД максимально возможную производительность, например для обработки пакета запросов.
Особенности применения ограничения на пропускную способность, RU/с
При превышении ограничения запрос не принимается к исполнению, возвращается ошибка Throughput limit exceeded. Получение такой ошибки означает, что запрос можно безопасно повторить позже. При повторе рекомендуется использовать конструкции, поставляемые в составе YDB SDK. В предлагаемых конструкциях реализованы алгоритмы повторов, которые в зависимости от типа и кода ошибки используют разные стратегии повторов: без задержки, с экспоненциальным увеличением задержки, быстрый или медленный повтор и другие.
Ограничение срабатывает с некоторой задержкой, поэтому ошибка Throughput limit exceeded возвращается не на запросе, который привел к превышению ограничения, а одном из следующих. После срабатывания ограничения запросы не будут приниматься к исполнению в течение времени, приблизительно равного отношению перерасхода к величине ограничения. Например, если на исполнение единичного запроса потрачено 1000 RU при ограничении в 100 RU/с, то новые запросы не будут приниматься в течение 10 секунд.
Для снижения риска получения отказов при неравномерной нагрузке YDB гибко применяет ограничения, используя механизм резервирования пропускной способности (burst capacity). Пока на обработку запросов тратится меньше RU, чем указано в ограничении, неиспользованная пропускная способность резервируется. Во время пика потребления за счет накопленного резерва может быть временно предоставлена большая пропускная способность, чем указано в ограничении.
В YDB резервируется около 5 минут пропускной способности. Резерв позволяет выполнить, например, единичный запрос со стоимостью около 5 мин × 60 с × квота RU/с без отказа в исполнении следующих запросов. Политика предоставления burst capacity может быть изменена.
Квота на количество запросов в бессерверном режиме также является инструментом защиты от оплаты перерасхода ресурсов при сбоях в приложении или атаках на сервис. Наличие механизма burst capacity позволяет выставлять в квоте наименьшее значение, при котором ваше приложение работает без получения ошибок Throughput limit exceeded, с некоторым запасом на непредвиденный рост нагрузки.
Ограничения — максимальный объем данных
При использовании Serverless БД сумма оплаты зависит от объема хранимых данных.
Так как объем хранилища в Serverless БД неопределенно большой, то и максимальный объем данных, которые в нем можно разместить, также может составить любое значение, приведя к нежелательным начислениям. Например, такое может произойти в результате ошибки в коде, приводящей к вставке данных в бесконечном цикле, или случайном импорте не того бэкапа.
Ограничение Максимальный объем данных на Serverless БД позволяет вам ограничить объем данных, который YDB позволит разместить в этой БД. По умолчанию для новых БД устанавливается ограничение в 50 ГБ, что ограничивает сумму ваших ежемесячных начислений за объем хранимых данных суммой около 650 ₽, по действующему на дату написания этой документации тарифу (13.41 ₽ за 1ГБ, 1ГБ бесплатно).
Ограничение Максимальный объем данных может быть изменено в интерактивном режиме в любой момент, как через графическую консоль, так и через CLI, как в сторону увеличения, так и в сторону уменьшения, без ограничений. Это позволяет вам оперативно менять его по мере надобности.
Не рекомендуется устанавливать ограничение Максимальный объем данных ниже текущего фактического объема данных, так как в таком состоянии станут недоступны все операции изменения данных, включая DELETE. Уменьшить объем данных можно будет только командами DROP TABLE или DROP INDEX. При случайной установке ограничения ниже фактического объема рекомендуется вернуть его к рабочему значению, превышающему фактический объем с некоторым запасом.
Архитектура YDB в разных режимах работы
Разделение compute и storage слоев
Важно понимать, что в YDB явно выделены слои storage и compute. Storage слой отвечает за надежное хранение данных на устройствах хранения и репликацию данных между узлами для обеспечения отказоустойчивости.
В YDB данные пользователя хранятся в таблицах, таблицы партицированы. Шард — это сущность, которая отвечает за хранение партиции таблицы (обычно, одной). За изменение данных в шарде отвечает такая сущность как Таблетка — это компонент, реализующий согласованное изменение данных в шарде и решающий проблему распределенного консенсуса. На инстанс таблетки можно смотреть как на объект, который порожден в адресном пространстве процесса и потребляет процессорные ресурсы и оперативную память. Все свое состояние Таблетка хранит в storage слое. Это, в том числе, означает, что инстанс Таблетки может быть поднят в произвольном процессе, откуда доступен storage слой. Compute слой YDB по сути состоит из Таблеток и слоя выполнения YQL-запросов.
Стоит отметить, что понятие БД состоит не только из пользовательских таблиц и, соответственно, Таблеток обслуживающих эти таблицы, но и определенных системных сущностей. Например, есть Таблетка SchemeShard, которая обслуживает схему данных всех таблиц, есть система координации распределенных транзакций, элементы которых также представляют собой Таблетки.
Dedicated режим работы YDB
Режим работы Dedicated предполагает, что ресурсы на инстансы Таблеток и на выполнение YQL-запросов выбираются из явно выделенных для БД compute ресурсов. Под compute ресурсами понимаются виртуальные машины, обладающие определенным количеством vCPU и памяти. Задача выбора оптимального количества ресурсов для БД в настоящий момент лежит на пользователе. Если ресурсов будет недостаточно для обслуживания подаваемой нагрузки, то latency запросов начнет увеличиваться, а в пределе будет отказ в обслуживании запросов, например с кодом возврата OVERLOADED. Пользователь может добавить compute ресурсы (ВМ) в БД в UI или CLI для того, чтобы обеспечить БД необходимым количеством вычислительных ресурсов. Добавление compute ресурсов в БД происходит относительно быстро и сопоставимо со временем запуска ВМ. Далее YDB автоматически сбалансирует Таблетки по кластеру с учетом добавленных ресурсов.
Serverless режим работы YDB
В Serverless режиме работы инфраструктура YDB определяет, сколько вычислительных ресурсов необходимо выделить для обслуживания пользовательской БД. Количество выделенных ресурсов может быть как очень большим (произвольное количество ядер), так и очень маленьким (значительно менее одного ядра). Если пользователь создал БД из одной таблицы с одной записью в ней, при этом выполняет запросы к БД крайне редко, то YDB, по сути, тратит незначительный объем памяти на инстансы Таблеток, которые входят в состав пользовательской БД. Это возможно за счет того, что компоненты пользовательской БД представляют собой объекты, а не процессы. Если нагрузка возрастает, то компоненты БД начинают потреблять больше процессорного времени и памяти. Если нагрузка возрастает до пределов, когда ресурсов ВМ не хватает, инфраструктура YDB имеет возможность гранулированно балансировать систему, порождая инстансы Таблеток на других ВМ.
Подобная технология позволяет очень плотно упаковывать виртуальные сущности (инстансы Таблеток) в физические ресурсы на основе реального потребления, что дает возможность выставлять счет пользователю за выполненные операции, а не за выделенные ресурсы.