Рекомендации по созданию приложения с одним сервером База данных Azure для PostgreSQL

Статья
03/24/2023

Область применения: отдельный сервер Базы данных Azure для PostgreSQL

Внимание

База данных Azure для PostgreSQL — одиночный сервер находится на пути выхода на пенсию. Настоятельно рекомендуется выполнить обновление до База данных Azure для PostgreSQL — гибкий сервер. Дополнительные сведения о миграции на База данных Azure для PostgreSQL — гибкий сервер см. в статье "Что происходит с одним сервером База данных Azure для PostgreSQL?".

Ниже приведены отдельные рекомендации, которые помогут вам создать облачное приложение с помощью базы данных Azure для PostgreSQL. Эти рекомендации позволяют сократить время разработки приложения.

Настройка ресурсов приложения и базы данных

Сохранение приложения и базы данных в одном регионе

Убедитесь, что при развертывании приложения в Azure все зависимости находятся в одном регионе. Из-за распределения экземпляров по регионам или зонам доступности возникает задержка в сети, что может повлиять на общую производительность приложения.

Безопасность сервера PostgreSQL

Настройте безопасность сервера PostgreSQL и запрет на открытый доступ. Используйте один из следующих параметров для настройки безопасности сервера.

В целях безопасности необходимо всегда подключаться к серверу PostgreSQL по протоколу SSL и настраивать сервер PostgreSQL и приложение для использования TLS 1.2. См. раздел Настройка SSL/TLS.

Использование переменных среды для сведений о соединении

Не сохраняйте учетные данные базы данных в коде приложения. В зависимости от интерфейсного приложения следуйте указаниям по настройке переменных среды. Сведения об использовании Службы приложений см. в разделе о том, как настроить параметры приложения. Сведения о Службе Azure Kuberentes см. в разделе Использование секретов Kubernetes.

Производительность и устойчивость

Далее приведены инструменты и рекомендации для устранения проблем с производительностью приложения.

Использование пула Подключение ion

При использовании пулов соединений фиксированный набор соединений устанавливается во время запуска и сохраняется. Это также помогает снизить фрагментацию памяти на сервере, вызванную динамическими новыми соединениями, установленными на сервере базы данных. Пулы подключений можно настроить на стороне приложения, если оно поддерживается платформой приложений или драйвером базы данных. Если это не поддерживается, рекомендуется использовать службу пула прокси-подключений, например PgBouncer или Pgpool, работающую за пределами приложения, и подключиться к серверу базы данных. PgBouncer и Pgpool являются инструментами на основе сообщества, которые работают с базой данных Azure для PostgreSQL.

Логика повторных попыток для обработки временных ошибок

В приложении могут возникнуть временные ошибки, при которых подключения к базе данных периодически разрываются или теряются. В таких ситуациях сервер запускается и работает после одной-двух повторных попыток через 5–10 секунд. Рекомендуется подождать 5 секунд перед первой попыткой. Затем выполняйте каждую повторную попытку, увеличивая время ожидания до 60 секунд. Ограничьте максимальное число повторных попыток, после которых приложение посчитает, что операция завершилась сбоем и вы сможете изучить причины ошибки. Дополнительные сведения см. в разделе Устранение ошибок подключения.

Включение репликации чтения для устранения сбоев при отработке отказа

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

Развертывание баз данных

Настройка конвейера развертывания CI/CD

В отдельных случаях необходимо развернуть изменения в базе данных. В таких случаях можно использовать непрерывную интеграцию (CI) через GitHub Actions для сервера PostgreSQL, чтобы обновить базу данных, запустив для нее пользовательский сценарий.

Определение процесса развертывания базы данных вручную

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

Создайте копию рабочей базы данных в новой базе данных, используя для этого pg_dump.
Обновите новую базу данных, добавив изменения схемы или обновления, требуемые для базы данных.
Переведите рабочую базу данных в состояние "только для чтения". В рабочей базе данных не должно быть операций записи, пока развертывание не будет завершено.
Протестируйте приложение, используя обновленную базу данных, созданную в шаге 1.
Разверните изменения приложения и убедитесь, что приложение теперь использует новую базу данных с последними обновлениями.
Используйте предыдущую рабочую базу данных, чтобы можно было отменить изменения. Затем можно будет либо удалить старую рабочую базу данных, либо при необходимости экспортировать ее в службу хранилища Azure.

Примечание.

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

Схема базы данных и запросы

Ниже приведены рекомендации, которые следует учитывать при создании схемы базы данных и запросов.

Использование BIGINT или UUID для первичных ключей

При создании пользовательского приложения или некоторых платформ для первичных ключей может использоваться INT вместо BIGINT. При использовании INT вы допускаете риск того, что значение в базе данных может превышать емкость хранилища для типа данных INT. Внесение этого изменения в существующее рабочее приложение может занимать много времени, из-за чего может увеличиться время на разработку. Другой вариант — использовать UUID для первичных ключей. Этот идентификатор использует автоматически созданную 128-разрядную строку, например a0eebc99-9c0b-4ef8-bb6d-6bb9bd380a11. Дополнительные сведения о типах данных PostgreSQL.

Использование индексов

Существует много типов индексов в Postgres, которые могут использоваться различными способами. Использование индекса помогает серверу находить и извлекать определенные строки гораздо быстрее, чем без индекса. Но индексы также добавляют дополнительные издержки серверу базы данных, поэтому использовать слишком много индексов не рекомендуется.

Использование автоматической очистки

Вы можете оптимизировать сервер с помощью автоочистки на сервере базы данных Azure для PostgreSQL. PostgreSQL позволяет увеличить параллелизм базы данных, но при каждом обновлении результатом становятся вставка и удаление. При удалении записи имеют мягкую маркировку, которая будет очищена позже. Для выполнения этих задач PostgreSQL запускает задание очистки. Если время от времени не выполнять очистку, накопление неиспользуемых кортежей может привести к:

раздуванию данных — большему размеру баз данных и таблиц;
большему размеру субоптимальных индексов;
увеличению числа операций ввода-вывода.

Подробнее о том, как оптимизировать автоматическую очистку.

Использование pg_stats_statements

Pg_stat_statements является расширением PostgreSQL, которое по умолчанию включено в Базе данных Azure для PostgreSQL. Оно предоставляет средства для отслеживания статистики выполнения всех инструкций SQL, выполняемых сервером. См. также: Как использовать pg_statement.

Использование хранилища запросов

Функция хранилище запросов в База данных Azure для PostgreSQL предоставляет метод отслеживания статистики запросов. Этот компонент рекомендуется в качестве альтернативы использованию pg_stats_statements.

Оптимизация вставки в пакетном режиме и использование временных данных

Если ваши операции рабочей нагрузки включают временные данные или вставляют большие наборы данных в пакетном режиме, рассмотрите возможность использования нерегистрируемых таблиц. Она по умолчанию обеспечивает атомарность и устойчивость. Атомарность, согласованность, изолированность и устойчивость составляют свойства ACID. См. также: Как оптимизировать массовую вставку.

Share via