Мы с радостью сообщаем об общей доступности (GA) PostgreSQL 14 на платформе Azure с опцией Hyperscale (Citus). Насколько нам известно, это первый случай, когда крупный облачный провайдер объявляет GA для новой основной версии Postgres на своей платформе всего через день после официального релиза.
Уже сегодня, вы можете развернуть Postgres 14 во многих регионах с Hyperscale (Citus). Позже мы развернем Postgres 14 в большем количестве регионов Azure, а также выпустим его с нашей новой опцией Flexible Server в Azure Database (Гибкий сервер Базы данных Azure) для PostgreSQL.
Данное событие поможет нам предоставить все последние возможности Postgres клиентам Azure по мере появления новых функций. Кроме того, это также показывает нашу приверженность PostgreSQL с открытым исходным кодом и его экосистеме. Мы решили расширять Postgres и предоставлять возможность совместного использования своих ресурсов, вместо того чтобы создавать проприетарный форк в облаке и управлять им.
В этой статье блога вы впервые получите представление о некоторых из наших наиболее понравившихся функций в Postgres 14. К ним относятся масштабирование соединений, более быстрое выполнение операции VACUUM и ускорение времени восстановления после сбоев.
Затем мы опишем работу по обеспечению совместимости расширений Postgres с новыми основными версиями платформы, включая нашу распределенную базу данных Citus, а также другие расширения, такие как HyperLogLog (HLL), pg_cron и TopN. Наконец, вы узнаете, как работает упаковка, тестирование и развертывание в режиме Hyperscale (Citus). Благодаря последней части все связывается воедино и мы можем быстро выпускать новые версии на Azure.
Содержание
Наиболее понравившиеся из новых возможностей в PostgreSQL 14
Обеспечение совместимости Citus и других расширений с PostgreSQL 14
Hyperscale (Citus) - выпуск новой версии PostgreSQL
Наиболее понравившиеся из новых возможностей PostgreSQL 14
После выхода каждой основной версии PostgreSQL появляются новые возможности. Этот выпуск не является исключением. PostgreSQL 14 предлагает ряд усовершенствований, касающихся производительности, типов данных, администрирования баз данных, репликации и безопасности. Вы можете ознакомиться с основными характеристиками здесь, а с полным описанием релиза - здесь.
Для нас, в Microsoft, самым интересным усовершенствованием стало улучшение масштабирования соединений. Благодаря этим изменениям Postgres 14 заметно улучшает работу приложений, которым требуется большое количество соединений с базой данных. Каждое соединение в Postgres обрабатывается отдельным процессом. Такая модель имеет свои преимущества, но большое количество соединений приводит к значительным перегрузкам. В данном релизе масштабирование активных и неиспользуемых соединений стало заметно лучше.
Мы проанализировали основные недостатки масштабирования соединений в Postgres и определили, что главным из них является масштабируемость моментальных снимков, снэпшотов (snapshots). (Postgres использует моментальные снимки для определения того, какие именно операции выполнялись во время снэпшота. Это позволяет операторам решать, какие из строк, созданных другими операциями в данный момент, должны быть видны, а какие нет). Когда проблема была выявлена, наша команда внесла ряд изменений для улучшения масштабируемости снэпшотов в Postgres. Эти изменения, в свою очередь, значительно улучшают характеристики масштабирования соединений, особенно когда многие из этих соединений простаивают.
Подробнее о трех конкретных узких местах, связанных с масштабируемостью снэпшотов, и соответствующих исправлениях для их устранения вы можете прочитать здесь. Мы протестировали эти изменения на Azure F72s v2 с помощью бенчмарка pgbench read-only и увидели следующие преимущества. Другие пользователи также проверили эти изменения и поделились своими результатами.
Помимо масштабирования соединений, нам интересны еще две возможности, которые помогут сделать работу с Postgres лучше. Во-первых, мы слышали, что время восстановления после сбоя и ускорение VACUUM являются потенциальными областями для оптимизации. В Postgres 14 были внесены изменения, которые ускорили восстановление после сбоев в 2,4 раза, а время выполнения VACUUM — на 25% для определенных рабочих нагрузок, привязанных к процессору. И все эти улучшения были внесены в 400 строк кода.
Во-вторых, Postgres открывает и синхронизирует (fsyncs) каждый файл, который ей принадлежит, в начале восстановления после сбоя. С помощью параметра recovery_init_sync_method Postgres может запросить Linux синхронизировать все файлы в каталогах данных и WAL до начала восстановления. Это обеспечивает более быстрое восстановление после сбоя в системах с большим количеством файлов базы данных.
Обеспечение совместимости Citus и других расширений с PostgreSQL 14
Одной из определяющих характеристик PostgreSQL является его расширяемость. При написании расширения Postgres разработчики могут добавлять новые функциональные возможности базы данных, не прибегая к форкингу исходного проекта.
Расширение PostgreSQL состоит из двух частей: набора объектов SQL (например, таблиц метаданных, функций, типов) и совместно используемой библиотеки, которая загружается в PostgreSQL. Все модули базы данных в PostgreSQL являются расширяемыми, за исключением парсера. Это связано в первую очередь с тем, что код парсера генерируется во время сборки, а инфраструктура расширения загружает общую библиотеку во время выполнения. Сохранение парсера нерасширяемым также обеспечивает синтаксическую совместимость между расширениями.
В Microsoft мы разрабатываем и поддерживаем несколько расширений с открытым исходным кодом, включая Citus, pg_cron, HLL (HyperLogLog) и TopN. Среди этих расширений Citus является самым многофункциональным. Он расширяет PostgreSQL, включая слой шардинга, распределенный планировщик и исполнитель запросов, распределенные транзакции и эластичную логику горизонтального масштабирования. Чтобы обеспечить эти возможности, Citus максимально использует API Postgres в трех направлениях.
Опубликованные документации API расширений: С помощью этих API разработчики могут создавать новые типы данных, операторы, функции, индексы, фоновые приложения и многое другое. Большинство расширений используют только эти API. Например, клиенты Citus создают распределенную таблицу, вызывая
SELECT create_distributed_table('table_name', 'distribution_column');. Чтобы реализовать эту логику, Citus использует пользовательские API.Хуки расширения в коде: Хуки — это указатели глобальных функций, которые прописаны в коде. С их помощью разработчики могут расширить планировщик, исполняющий модуль, методы доступа к таблицам, логику транзакций и многое другое. Например, хук утилиты вызывается после парсинга любой команды, которая не проходит через обычный планировщик. Citus использует этот хук при выполнении команд DDL и COPY для распределенных таблиц.
Публичные функции в коде: Расширение также может использовать публичные функции в Postgres, включив соответствующие заголовочные файлы. Эти функции дают огромные преимущества для такой распределенной базы данных, как Citus. Вместо того чтобы реализовывать новые функциональные возможности, Citus может просто полагаться на Postgres. Например, Postgres генерирует дерево запросов для хранения внутреннего представления SQL-оператора. Затем Citus использует функции Postgres для копирования, траверса или манипулирования частями структуры дерева запросов.
При каждом новом выпуске PostgreSQL возможны структурные изменения в любой из вышеперечисленных точек интеграции. Процесс создания расширений, совместимых с версиями Postgres, включает в себя изменения в этих точках интеграции. Например, в PostgreSQL 14 сигнатура хук-утилиты изменилась и стала включать новый аргумент. Поэтому нам пришлось включить это дополнение, как показано ниже. Вы также можете ознакомиться с полным набором изменений для интеграции с Postgres 14 в этом пулл-реквесте.
За годы работы мы разработали процесс создания расширений, совместимых с новыми версиями PostgreSQL. Для Citus этот процесс можно свести к трем основным этапам.
В исходном коде расширения мы устраняем критические изменения, приводящие к сбоям. После этого этапа исходный код может быть скомпилирован для новой версии PostgreSQL.
Мы рассматриваем новые возможности PostgreSQL. Это включает в себя изучение примечаний к выпуску PostgreSQL. Для каждого изменения, которое относится к расширению (например, новая функция), обращаемся в исходном коде расширения, если это необходимо.
Мы запускаем эти изменения через наш тестовый пайплайн и исправляем ошибки.
Этот третий этап обычно занимает больше всего времени и включает в себя следующее:
Непрерывная интеграция (CI): Эти тесты обеспечивают нам 95% покрытие кода и занимают около 5 минут для параллельного выполнения. Они включают четыре большие категории: (a) набор тестов PostgreSQL, (b) регрессионные тесты для валидации вывода базового и сложного SQL, (c) тесты изоляции для проверки поведения параллельных сессий, и (d) тесты отказов, которые отрабатывают сбои (например, сетевые сбои). Эти тесты проводятся на разных версиях Postgres и Citus.
Тесты производительности, масштабирования и памяти: В этих общедоступных тестах выполняются стандартные эталонные тесты в различных масштабах. Мы также запускаем Valgrind в качестве инструмента динамического анализа для выявления любых ошибок в управлении памятью. Если в ходе автоматизированных тестов обнаруживаются какие-либо проблемы, то они устраняются. Поскольку эти тесты занимают много времени, их проводят раз в неделю.
Тесты релиза: Они включают в себя тесты обновления для Postgres/Citus; интеграционные тесты для проверки с внешними инструментами; инструменты статического анализа; и fuzz-тестирование с помощью инструментов SQLancer/SQLsmith для поиска багов в логике. Большинство тестов автоматизированы, но для интерпретации результатов требуется разработчик. Этот этап занимает до недели.
После создания новых пакетов расширения Hyperscale (Citus) может приступить к их использованию.
Hyperscale (Citus) — выпуск новой версии PostgreSQL
Хорошо разбираясь в PostgreSQL и расширяя его, мы сможем предоставлять вам новые версии на ранних этапах. Используя две лучшие практики в Hyperscale (Citus), нам удалось сделать PostgreSQL 14 общедоступным на Azure всего за один день после выхода основного релиза.
Первая передовая практика — это разделение ответственности между плоскостью управления и плоскостью данных в Hyperscale (Citus). В нашей архитектуре плоскость управления отвечает за бизнес-логику управления базами данных Postgres/Citus. Эта логика включает в себя периодические проверки работоспособности, высокую доступность и отказоустойчивость, резервное копирование и восстановление, чтение реплик, регулярные операции обслуживания и другие. Плоскость данных отвечает исключительно за работу базы данных. Как таковая, плоскость данных не содержит практически ничего, кроме базового PostgreSQL и его расширений.
Такое разделение плоскостей позволяет нам легко установить новую версию PostgreSQL на узлы плоскости данных. Останется только обеспечить совместимость новой версии PostgreSQL с бизнес-логикой плоскости управления. Это обычно не вызывает затруднений по двум причинам. Во-первых, плоскость управления предназначена для использования общедоступных интерфейсов PostgreSQL, и сообщество разработчиков PostgreSQL как правило следит за тем, чтобы избежать негативных последствий при внесении несовместимых модификаций. Во-вторых, разработка Postgres происходит в открытом доступе, поэтому можно заранее подготовиться к любым критическим изменениям.
После внесения изменений для поддержки новой версии PostgreSQL вступает в действие вторая лучшая практика для Hyperscale (Citus): тестирование. Наша первая линия обороны - это юнит-тесты (мок-тесты). Мы используем юнит-тесты для получения быстрой обратной связи о наших изменениях и поэтому запускаем их часто. Они выполняются примерно за 2 минуты и дают нам 100% покрытие кода для плоскости управления. Все новые пулл-реквесты на Hyperscale (Citus) должны запускать юнит-тесты и поддерживать 100% покрытие.
В юнит-тестах многие вызовы имитируются. Это позволяет быстро получить обратную связь, но не дает хорошего сквозного представления. Вторым шагом в нашем пайплайне тестирования являются сквозные тесты (E2E). Они охватывают такие распространенные сценарии, как инициализация, высокая доступность и отказоустойчивость, масштабирование с помощью ребалансировщика шардов и другие. С помощью этих тестов мы можем проверить взаимодействие каждого компонента с остальными.
После ревью кода, юнит-тестов и E2E-тестов следующим шагом для новой основной версии PostgreSQL является развертывание. Для этого нам необходимо записать два образа машины. Первый, образ для плоскости управления, включает в себя все изменения управляемых сервисов, которые мы должны были сделать для установки новой версии PostgreSQL. Второй, образ для плоскости данных, содержит исходные двоичные файлы PostgreSQL/Citus и несколько вспомогательных скриптов. Имея эти образы, можно приступать к развертыванию во всех регионах Azure новой полезной нагрузки, пейлоад (payload).
Развертывание в регионах Azure включает в себя третью серию тестов. Во время развертывания мы следуем определенным правилам и порядку в соответствии с практикой безопасного развертывания. Согласно этим правилам, новая пейлоад сначала попадает в промежуточную среду, стейджин (staging), затем в регионы доступа к ранним обновлениям, Azure Early Update Access Program (EUAP) и, наконец, в остальные продакшн-регионы. В каждом новом регионе изменения ожидают определенного периода запекания (baking). Во время запекания для каждого региона наши автоматизированные тесты запускают определенные сценарии для проверки. Эти синтетически сгенерированные тесты включают в себя инициализацию Citus, обновление, вертикальное/горизонтальное масштабирование, восстановление до точки во времени, восстановление после отказа и другие. Если какой-либо из этих сценариев не срабатывает, то процесс развертывания останавливается, для проведения расследования, чтобы при необходимости откатиться назад.
К счастью, наша команда также автоматизировала процесс развертывания. После того, как была проделана огромная работа по созданию процессов, обеспечивающих своевременный выпуск новых версий PG, оставалось только нажать кнопку — и развертывание было запущено. Вся наша работа окупилась и сделала Postgres 14 доступным для вас на Azure всего за один день после его первоначального выпуска.
Если вам необходимо масштабировать Postgres 14 в облаке, зайдите на портал Azure и запустите новый кластер Hyperscale (Citus) уже сегодня. Если у вас уже есть кластеры, работающие на Postgres 12 или 13, вы также можете обновить свои кластеры до основной версии уже сейчас!
Добро пожаловать в Postgres 14
Подводя итоги, мы рады объявить об общей доступности (GA) Postgres 14 на Azure в течение одного дня после официального релиза Postgres 14. Это стало возможным благодаря нашей приверженности открытому исходному коду, решению расширить Postgres, а не форкнуть его, и совокупности усилий по улучшению нашей инфраструктуры автоматизированного тестирования для повышения надежности программного обеспечения.
Материал подготовлен в рамках курса «Базы данных». Если вам интересно узнать подробнее о формате обучения и программе, познакомиться с преподавателем курса — приглашаем на день открытых дверей онлайн. Регистрация здесь.