Использование PlanetScale для масштабируемых баз данных MySQL
Если вы создаёте full-stack приложение с использованием MySQL, рано или поздно вы столкнётесь со знакомой проблемой: локальная база данных прекрасно работает во время разработки, но самостоятельное обслуживание production-уровня MySQL-сервера означает необходимость заниматься резервным копированием, доступностью, лимитами соединений и миграциями схемы, которые могут вывести приложение из строя. PlanetScale — это управляемая платформа MySQL, разработанная для того, чтобы снять с вас большую часть этой операционной нагрузки, но это нечто большее, чем просто хостинг MySQL. В этой статье объясняется, что отличает данную платформу от других, как работают её ключевые процессы и когда её действительно имеет смысл использовать.
Ключевые тезисы
- PlanetScale — это управляемая MySQL-совместимая платформа, построенная на Vitess, предоставляющая возможности горизонтального масштабирования и пулинга соединений сверх того, что предлагает стандартный MySQL.
- Ветвление базы данных привносит Git-подобный рабочий процесс в изменения схемы, с deploy-запросами и неблокирующими миграциями, которые сохраняют production в рабочем состоянии.
- Внешние ключи работают на нешардированных базах, но шардированные конфигурации требуют обеспечения ссылочной целостности на уровне приложения.
- PlanetScale особенно полезен для serverless-приложений и команд, которым нужны безопасные, проверяемые изменения схемы, но он может оказаться избыточным для небольших проектов с ограниченным бюджетом.
Что такое PlanetScale на самом деле (и чем он отличается от стандартного MySQL)
PlanetScale — это управляемая MySQL-совместимая платформа баз данных, построенная на Vitess — системе кластеризации баз данных с открытым исходным кодом, изначально разработанной в YouTube для горизонтального масштабирования MySQL на множестве серверов.
Это различие имеет значение. PlanetScale — это не обычный MySQL. Ваше приложение подключается к нему с использованием стандартной строки подключения MySQL, и большая часть SQL-запросов работает в точности так, как ожидается. Однако «под капотом» Vitess добавляет возможности, которых нет в стандартном MySQL: пулинг соединений в больших масштабах, поддержку горизонтального шардирования и неблокирующие изменения схемы.
Для большинства frontend и full-stack разработчиков практический вывод таков: PlanetScale берёт на себя инфраструктурную сложность, которая в противном случае потребовала бы выделенного администратора баз данных.
Как Vitess обеспечивает горизонтальное масштабирование
У одного MySQL-сервера есть жёсткие ограничения — на количество соединений, пропускную способность записи и размер таблицы, после которого запросы начинают замедляться. Vitess решает эту проблему, выступая в роли прокси-уровня, который распределяет запросы между несколькими базовыми экземплярами MySQL.
На практике это означает, что PlanetScale может изящно справляться со всплесками количества соединений — что особенно полезно в serverless-средах, где функции вроде Cloudflare Workers или Vercel Functions могут открывать тысячи одновременных соединений. Vitess объединяет эти соединения в пул внутри себя, чтобы ваша база данных не была перегружена.
Стоит уточнить: это не магическое горизонтальное масштабирование, снимающее все ограничения. Шардирование привносит собственную сложность, и большинству малых и средних приложений оно не понадобится. Но архитектура такова, что PlanetScale может расти вместе с вашим приложением, не требуя последующего перехода на другую платформу.
Ветвление базы данных и рабочий процесс deploy-запросов
Одна из самых удобных для разработчиков функций PlanetScale — это ветвление базы данных, Git-подобный рабочий процесс для изменений схемы.
Вот как это работает на практике:
- Ваша production-база данных работает на защищённой production-ветке. PlanetScale поощряет внесение изменений схемы через deploy-запросы и безопасные миграции, а не их прямое применение к production-ветке.
- Вы создаёте ветку разработки — изолированную копию схемы, — где вносите и тестируете изменения.
- Когда всё готово, вы открываете deploy-запрос для слияния изменений схемы с production.
- PlanetScale применяет эти изменения с помощью неблокирующих миграций схемы, то есть ваша production-база данных остаётся в рабочем состоянии на протяжении всего процесса.
Этот рабочий процесс устраняет распространённый источник production-инцидентов: выполнение ALTER TABLE на большой таблице с блокировкой записи на минуты или часы. С PlanetScale этот риск управляется на уровне платформы.
Discover how at OpenReplay.com.
Внешние ключи, шардирование и соображения совместимости с MySQL
PlanetScale поддерживает ограничения внешних ключей на нешардированных базах данных, что покрывает большинство случаев использования. Если вы включите шардирование, внешние ключи между шардированными таблицами не поддерживаются — это фундаментальное ограничение того, как Vitess распределяет данные. Для шардированных конфигураций ссылочную целостность необходимо обеспечивать на уровне приложения.
Если вы используете Prisma, вы можете настроить relationMode = "prisma" для эмуляции связей без использования внешних ключей на уровне базы данных, а также вручную добавить индексы на колонки внешних ключей, чтобы избежать медленных запросов.
Когда PlanetScale имеет смысл, а когда нет
PlanetScale хорошо подходит, если:
- Вы создаёте приложение, которому нужно масштабироваться за пределы одного сервера базы данных.
- Вам нужны неблокирующие изменения схемы без необходимости самостоятельно управлять инструментарием.
- Вы работаете в serverless-среде с непредсказуемыми паттернами соединений.
- Вам нужен структурированный, проверяемый рабочий процесс для изменений схемы базы данных.
Стоит пересмотреть выбор, если:
- Ваше приложение небольшое и вряд ли перерастёт один управляемый экземпляр MySQL от провайдера вроде AWS RDS или другого конкурирующего сервиса.
- Ваш бюджет ограничен — ценообразование PlanetScale отражает уровень корпоративной платформы.
- Вы активно используете функции MySQL, которые Vitess не полностью поддерживает.
Подключение вашего приложения
PlanetScale предоставляет стандартную строку подключения MySQL для каждой ветки. Вы сохраняете её как переменную окружения и подключаетесь с помощью любого MySQL-совместимого драйвера или ORM:
DATABASE_URL='mysql://username:password@aws.connect.psdb.cloud/your-database?sslaccept=strict'
Это работает с Prisma, Drizzle ORM, прямыми соединениями mysql2 и большинством других MySQL-клиентов. Для serverless-сред PlanetScale также предлагает serverless-драйвер на базе HTTP, который полностью исключает использование постоянных TCP-соединений.
Заключение
PlanetScale предоставляет full-stack разработчикам готовую к production масштабируемую MySQL-платформу с рабочим процессом — ветвление базы данных, deploy-запросы, неблокирующие миграции, — который снижает риск внесения изменений в схему. Это не подходящий инструмент для каждого проекта, и его основа на Vitess означает, что вы работаете с MySQL-совместимым, а не идентичным поведением. Но для приложений, где важны масштаб и безопасность изменений схемы, он снимает значительную часть операционной сложности, которая в противном случае легла бы на плечи вашей команды.
Часто задаваемые вопросы
Да. PlanetScale предоставляет стандартную строку подключения MySQL, поэтому любой MySQL-совместимый клиент работает, включая Prisma, Drizzle ORM, TypeORM, Sequelize и прямые драйверы вроде mysql2. Единственная оговорка состоит в том, что некоторые продвинутые функции MySQL могут вести себя по-другому, поскольку PlanetScale работает на Vitess. Для serverless-нагрузок PlanetScale также предлагает HTTP-драйвер, исключающий постоянные TCP-соединения.
Vitess распределяет данные между несколькими экземплярами MySQL при включённом шардировании, поэтому внешний ключ, ссылающийся на строку в другом шарде, не может эффективно обеспечиваться на уровне базы данных. Это архитектурный компромисс ради горизонтального масштабирования. На нешардированных базах внешние ключи работают нормально. В шардированных конфигурациях ссылочную целостность вы обеспечиваете в коде приложения или на уровне ORM.
PlanetScale использует Vitess для применения изменений схемы в фоновом режиме без блокировки исходной таблицы. Создаётся теневая копия таблицы, к ней применяется изменение, данные копируются, после чего таблицы атомарно меняются местами. Это означает, что такие операции, как добавление колонок или индексов на большие таблицы, происходят без простоев и блокировок записи, что является значительным улучшением по сравнению с прямым выполнением ALTER TABLE.
Может подойти, но ценообразование и набор функций ориентированы на production-приложения, которым полезны масштабирование, ветвление и безопасные миграции. Для небольшого побочного проекта с предсказуемым трафиком базовый управляемый экземпляр MySQL от AWS RDS, DigitalOcean или аналогичного провайдера может быть более экономичным. Выбирайте PlanetScale, когда вам действительно нужны его рабочий процесс или характеристики масштабирования.
Gain Debugging Superpowers
Unleash the power of session replay to reproduce bugs, track slowdowns and uncover frustrations in your app. Get complete visibility into your frontend with OpenReplay — the most advanced open-source session replay tool for developers. Check our GitHub repo and join the thousands of developers in our community.