Недавно один из наших талантливых инженеров, Эллиот Коулман, подробно изучил PlanetScale и его возможности для масштабирования баз данных MySQL. В этой статье изложены все его выводы и идеи, которые могут помочь нашим клиентам выйти на новый уровень. Это следующие ключевые фрагменты информации, которыми он горд поделиться.

Стоит ли использовать его?

PlanetScale — это размещенная платформа MySQL, предназначенная для приложений любого размера — от идеи до IPO, с соответствующей ценовой моделью. Он постоянно развивается, регулярно внедряются новые функции, такие как HTTP API, выпущенный во время написания этого поста!

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

Что такое PlanetScale?

PlanetScale описывает себя как масштабируемую бессерверную платформу базы данных, построенную на основе проекта Vitess. PlanetScale стремится объединить мощь Vitess с дополнительными функциями с простой в использовании платформой базы данных, которую можно развернуть за 10 секунд.

Vitess — один из 16 проектов, получивших дипломы Cloud Native Computing Foundation (CNCF), в котором, что интересно, YLD является серебряным членом. Созданный как побочный проект Google для масштабирования YouTube, Витесс присоединился к CNCF в 2018 году, где с тех пор помог масштабировать таких организаций, как Slack, чтобы обрабатывать миллиарды запросов в день.

Что может предоставить PlanetScale?

Ключевой функцией, предлагаемой PlanetScale, является возможность изменения схемы ветвления. Это позволяет разработчикам изменять схему в изолированных ветках, аналогично рабочему процессу, прописанному в git. Затем эти ветки можно объединить с помощью запроса на развертывание, где другие разработчики команды могут просмотреть изменения схемы, аналогично запросу на извлечение.

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

PlanetScale также обеспечивает уровень абстракции между клиентами и Vitess, который, как и любое крупное развертывание программного обеспечения, может быть сложным в настройке и обслуживании в производственной среде — от обновлений программного обеспечения, настройки и совместимости до управления оборудованием. Вместо этого PlanetScale скрывает все это через управляемую облачную платформу, доступную через интуитивно понятный интерфейс командной строки.

Что может CLI?

Из моего опыта работы с PlanetScale у меня сложилось впечатление, что сначала он был создан с помощью CLI. Он предлагает комплексную функциональность, помогая настроить сложные конвейеры сборки. Я заметил производственную ошибку в их пользовательском интерфейсе, сообщил о ней, и она была исправлена ​​в течение 2 часов. Однако CLI предоставил мне альтернативный интерфейс для достижения той же цели.

Интерфейс командной строки позволяет выполнять ветвление, управлять запросами на развертывание, вносить изменения в схему и развертывать эти изменения. Работая локально, вы можете аутентифицироваться через веб-браузер через вход в pscale. Кроме того, сервисные токены CLI можно использовать там, где невозможно использовать вход pscale, например, в конвейерах CI/CD.

Для локальной разработки PlanetScale предлагает команду CLI для проксирования безопасных соединений с вашей базой данных PlanetScale pscale connect <DATABASE_NAME> <BRANCH_NAME

Это позволяет вам подключаться через локальный хост, где соединение перенаправляется на PlanetScale. Предполагая, что прокси-сервер настроен на использование порта MySQL по умолчанию, ваша база данных будет доступна через 127.0.0.1:3306или mysql://[email protected]:3306/<DATABASE_NAME> Таким образом, вы можете использовать любой инструмент, который может работать с протоколом MySQL Connector (например, TablePlus).

Построение простого конвейера

Чтобы понять возможности интерфейса командной строки PlanetScale, я решил интегрировать его с AWS CodeBuild для автоматизации изменений в базе данных. У PlanetScale есть отличное официальное руководство, описывающее полный процесс создания конвейера сборки AWS, которое вы можете найти здесь.

Моя идея конвейера заключалась в том, что ветвь PlanetScale с именем, соответствующим изменению базы кода, автоматически будет объединена с производством.

  1. Разработчик создает PR для ветки на GitHub
  2. Разработчик создает ветку в базе данных PlanetScale
  3. После слияния PR ветка PlanetScale автоматически развертывается в рабочей среде.

Поскольку CodeBuild предоставляет номер запроса на слияние в качестве переменной среды CODEBUILD_WEBHOOK_TRIGGER=pr/[pr-number] во время триггера PR, он использовался для соответствия имени ветки PlanetScale.

Первым шагом, который нужно было сделать CodeBuild, было создание запроса на развертывание (DR) на основе триггера запроса на вытягивание. Имя базы данных предоставляется вместе с именем ветки, сгенерированным на основе переменной среды веб-перехватчика. Поскольку это будет выполняться удаленно, предоставляются сведения о маркере службы, а результат форматируется как JSON для интерпретации дальнейшими командами.

pscale deploy-request create $DB_NAME 
"pr${CODEBUILD_WEBHOOK_TRIGGER#*/}" --service-token $PS_TOKEN 
--service-token-id $PS_TOKEN_ID --org $PS_ORG --format json

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

pscale deploy-request show $DB_NAME $DR_NUM 
--service-token $PS_TOKEN 
--service-token-id $PS_TOKEN_ID 
--org $PS_ORG --format json

Если в ветке есть изменения схемы, DR можно развернуть в рабочей ветке.

DR_NUM=$(pscale deploy-request create $DB_NAME 
"pr${CODEBUILD_WEBHOOK_TRIGGER#*/}" --service-token $PS_TOKEN 
--service-token-id $PS_TOKEN_ID --org $PS_ORG --format json | jq '.number' )
DR_STATE=$(pscale deploy-request show $DB_NAME $DR_NUM 
--service-token $PS_TOKEN --service-token-id $PS_TOKEN_ID --org $PS_ORG --format json | jq -r '.deployment.state')
while [ "$DR_STATE" = "pending" ];
do
   sleep 5
   DR_STATE=$(pscale deploy-request show $DB_NAME $DR_NUM 
--service-token $PS_TOKEN --service-token-id $PS_TOKEN_ID --org 
$PS_ORG --format json | jq -r '.deployment.state')
   echo "State: $DR_STATE"
done
if [ "$DR_STATE" = "no_changes" ]; then
   pscale deploy-request close $DB_NAME $DR_NUM --service-token 
$PS_TOKEN --service-token-id $PS_TOKEN_ID --org $PS_ORG
else
   pscale deploy-request deploy $DB_NAME $DR_NUM --service-token 
$PS_TOKEN --service-token-id $PS_TOKEN_ID --org $PS_ORG
fi

Может ли он масштабироваться?

Да, это в его названии, в конце концов! Поскольку PlanetScale построен на основе Vitess, он использует скорость, предлагаемую пулом соединений MySQL. Тысячи легковесных соединений объединены в соединения MySQL, интенсивно использующие оперативную память. С AWS RDS количество подключений ограничено 16 тысячами, тогда как PlanetScale ограничено 250 тысячами подключений, хотя говорят, что это практически неограничено. Чтобы получить 16 тыс. подключений с RDS, требуется ручная настройка для включения пула подключений, в то время как PlanetScale предоставляет такое масштабирование по умолчанию.

Что еще может предложить Витесс?

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

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

Как насчет граничных вычислений?

Сложно (если не невозможно) заставить родные драйверы работать в современных периферийных средах. Кроме того, даже не рекомендуется сохранять или объединять соединения на очень эластичных платформах (таких как Lambda или Workers). В таких случаях можно использовать «новый совместимый с Fetch драйвер от PlanetScale, который может работать где угодно и взаимодействует с простым HTTP API.

Как YLD может помочь?

Если вы хотите познакомиться с новейшими технологиями или хотите присоединиться к совместной команде отличных инженеров и дизайнеров, которые работают над впечатляющими проектами клиентов, не стесняйтесь обращаться к нам в YLD по адресу [email protected] для открытых вакансий или [email protected], чтобы обсудить перспективу потенциального проекта.