Этим летом я по уши увяз в serverless-тематике и даже решил переписать один из своих pet-проектов целиком на serverless. Движок для сайта, поддерживающий бессерверные вычисления и вендор для кэширующей прослойки были найдены быстро - NextJS (с деплоем на Vercel) и Upstash с оплатой за каждую отдельную операцию и байт в хранилище. Камнем преткновения стал выбор провайдера для DBaaS. Мне бы хотелось реализовать всё таким образом, чтобы у проекта было две разных базы данных - для разработки и для production, и мне совсем не хотелось запускать базу данных для разработки на локальной машине. Поверхностное ознакомление с DBaaS провайдерами показало, что за дополнительную базу данных пришлось бы платить вдвое больше несмотря на то, что она использовалась бы дай Бог пару раз в неделю. И я ушёл в просмотр докладов и презентаций на YouTube и это именно тот момент когда я открыл для себя PlanetScale.

Serverless in a nutshell

Перед тем как окунаться в прочтение этой статьи, крайне рекомендую ознакомиться с замечательными статьями о том, что именно представляет собой serverless:

Если совсем-совсем коротко и простыми словами для конечного потребителя, то serverless целиком и полностью освобождает вас от необходимости администрировать инфраструктуру, платить за простой и нанимать аудиторов-безопасников. Serverless провайдер сделает всё за вас, вам остаётся лишь писать код для своих приложений.

Так что такое PlanetScale? В первую очередь это компания, разработавшая Vitess - программное обеспечение с открытым исходным кодом для кластеризации баз данных с целью их вертикального масштабирования. На секундочку, Vitess используют в YouTube, о чём господин Сугу рассказывал ещё 7 лет назад.

В PlanetScale решили, что пора двигаться дальше и принялись упрощать жизнь не только гигантам из Кремниевой Долины, но и обыкновенному разработчику из глубинки. Так появился PlanetScale.com - веб-приложение, где вы можете создать свою, основанную на Vitess, Serverless MySQL базу данных в один клик и начать работу с ней прямо сейчас.

А что особенного в PlanetScale?

Схему базы данных нельзя изменять. Не пугайтесь, это касается только production баз данных. А ещё в PlanetScale базу данных принято называть веткой (branch). Уже догадываетесь, к чему всё идёт? Вы совершенно правы, это всё напоминает git, где push изменений в мастер-ветку запрещён и единственный способ сделать изменение - это открыть pull request (deploy request). Для этого вы создаёте новую development ветку, которая является полной копией основной базы данных, производите необходимые изменения схемы и на этом всё - PlanetScale автоматически определит какие именно изменения были произведены и визуализирует их в веб-панели в виде SQL.

Deploy Request выглядит следующим образом.

Внешний вид страницы с Deploy Reqeust
Внешний вид страницы с Deploy Reqeust

Здесь ничего нового - автор изменений, summary этих самых изменений, количество апрувов, проверка на наличие конфликтов, etc. Всё это позволяет проводить миграции схемы в стиле git не опасаясь навредить production базе раньше чем вы готовы к этому.

Ещё PlanetScale умеет деплоить в разные регионы как основную базу данных, так и ветки. Пока что их немного - US West (LA), US East (NY), EU West (Dublin, Ireland), но этот вопрос открыт и прямо сейчас вы можете оставить запрос на добавление нужного вам региона (из списка регионов, поддерживаемых Amazon AWS) в разделе дискуссий на GitHub planetscale/beta.

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

В чём подвох?

Нельзя использовать Foreign Key поскольку они делают задачу шардинга крайне нетривиальной и неоправданно сложной. Если в работе с базой данных вы используете ORM, то разница останется незаметной. Поскольку Foreign Key это ограничение на уровне самой базы данных, то его можно продублировать и на уровне ORM (что, собственно говоря, и реализовано в Sequelize, TypeORM и Prisma, например - самых популярных ORM для NodeJS). Проблем от этого не прибавится, но гарантирующая прослойка останется в случае чего. Не для любителей чистых SQL запросов, короче говоря.

Сколько это стоит?

Как и любой другой serverless сервис, PlanetScale использует модель "pay as you go" - чем больше используется ресурсов, тем пожирнее счета вы получаете в конце месяца. Если ресурсы не используются, то и платить вам ни за что не надо. Ценовая политика такова:

Тариф Developer

Тариф Scaler

Максимальное количество баз данных

3

Стоимость хранилища объёмом 1GB

$0

$1.25

Стоимость 100 миллионов операций чтения

$0

$15

Стоимость 10 миллионов операций на запись

$0

$15

Важно! Тариф Developer действует лишь во время проведения бета-тестирования, в рамках которого вы можете создать 3 базы данных с безлимитным количеством операций на чтение и запись и 10 гигабайтами хранилища на каждую из баз данных. Последующие базы данных будут тарифицироваться согласно тарифа Scaler.

Тарификация производится за каждый байт или операцию записи/чтения. Это означает, что при цене за одну операцию чтения в $0.00000015 и использовании квоты в 50 млн. операций чтения вы заплатите ровно $7.25. Объём использованной квоты и цена за её использование будет доступна вам в конце расчётного периода в инвойсе.

Напоследок советую посмотреть презентацию интеграции PlanetScale с Vercel. Там Head of Engineering из PlanetScale рассказывает о сервисе и отвечает на вопросы, которые ему успели задать в чате (в ходе презентации и Q&A ответил буквально на все заданные и витающие в воздухе вопросы).

Интересный факт: PlanetScale работает на PlanetScale :)

Комментарии (7)


  1. anonymous
    00.00.0000 00:00


    1. charypopper
      27.08.2021 12:07

      Это же pet, люди хотят быстрый результат и писать по делу, разбираясь с тем что интересно(надо им для развития), а не возиться с каждым компонентом в каждом проекте


  1. anonymous
    00.00.0000 00:00


  1. JamesJGoodwin Автор
    27.08.2021 14:10

    Администрирование кластера и поддержание его в рабочем состоянии ложится мёртвым грузом на разработчика. Лично для меня это уже пройденный этап - я пытался одновременно администрировать MySQL, Redis, Jenkins и сам хост. В какой-то момент осознал, что прокрастинирую даже запускать проект на локалке. Преимущество serverless заключается именно что в делегировании обязательств по администрированию поставщику, не дерущему с разработчика семь шкур.


  1. vitaly_il1
    27.08.2021 16:38

    А вы не смотрели на Aurora Serverless?


    1. JamesJGoodwin Автор
      28.08.2021 00:02

      Смотрел На первый взгляд показалось, что довольно выгодно, но в AWS калькуляторе посчитал и получилось $115 за одну минимальную базу с бэкапами.


      1. vitaly_il1
        28.08.2021 21:29

        Интересно! Мне кажется что должно быть дешевле.