vybor_server_dlya

Выбор сервер для Postgresql

Выбор сервера для Postgresql

Общие сведения

Для подбора сервера важно учитывать сложность запросов, требования к задержкам, запас по памяти, скорость дисков
В большинстве случаев походит сервер с быстрыми ядрами, 64–128 ГБ RAM, NVMe enterprise-класса c настроенным RAID
Для многих транзакционных систем быстрые ядра и низкая задержка важнее, чем максимальное количество потоков.
С учетом роста данных, индексов, количества сущностей в базе, следует выбирать сервер с горизонтом хотя бы на 1 год

При поиске причины медленной работы приложения нельзя исключить блокировки, структуру индексов или неудачные запросы. Сложные тяжелые запросы могут занимать память, создавать временные файлы и мешать коротким транзакциям.
Нагрузку создают сложные пользовательские запросы, массовые действия под которыми подразумевается перебор и сортировка миллиона строк, например при формировании сложного отчета, который может включать в себя большое количество различных сущностей.
База данных продукта имеет довольно сложную структуру, СУБД одновременно обслуживает короткие транзакции, много читает, часто обновляет строки, строит отчеты, хранит большие индексы. В таких сценариях важны быстрые ядра процессора, низкая задержка дисков
Для чтения данных важна оперативная память. Если база часто отдает те же сущности, задачи, сделки, профили пользователей или данные для API, PostgreSQL выигрывает от большого объема RAM, так как при правильной настройке СУБД, часто используемые таблицы и индексы остаются в кэше, а обращений к данным на дисках становится меньше. Оперативная память не поможет, если запрашиваемый объем данных больше, чем выделенной оперативной памяти
Параллельное (одновременное) выполнение запросов, выборка, агрегация, поиск, фильтры и др., где требуется соединение нескольких таблиц, требует больше ядер, больше оперативной памяти, высокой пропускной способности дисков
В некоторых случаях, когда количество пользователей и их активность значительно превышает средние показатели, может потребоваться выносить тяжелые операции на отдельную реплику или выполнять их в периоды меньшей активности.

Минимум для рабочей базы — не одиночный диск и не потребительский накопитель
Потребительский накопитель — это твердотельный накопитель (SSD — Solid State Drive), разработанный для обычных пользователей. Часто предназначен для использования в персональных компьютерах, ноутбуках, игровых приставках и внешних портативных устройствах. Данный тип накопителя может проседать при длительной записи, иметь меньший ресурс и хуже переносить аварийное отключение питания
При выборе дисков важны пиковые IOPS и стабильность длительной записи
Пиковые IOPS — это максимальное количество операций ввода‑вывода в секунду (Input/Output Operations Per Second), которое устройство хранения данных способно обеспечить в кратковременном режиме при оптимальных условиях тестирования.

Требования к серверу

Минимальные требования: 8 ядер, RAM 32-64 Гб оперативной памяти, серверный ssd (SAS или NVMe), raid1

Средняя нагрузка: 16 ядер, RAM 64–128 ГБ, NVMe enterprise-класса, RAID 1, по возможности RAID 10
NVMe enterprise-класс — это твердотельные накопители (SSD), которые предназначены для использования в корпоративных и серверных системах, центрах обработки данных (ЦОД). Они используют протокол NVMe (Non-Volatile Memory Express) и рассчитаны на высокую производительность, надёжность и масштабируемость

Высокая транзакционная нагрузка: 32 ядра, RAM 128–256 ГБ, Несколько быстрых NVMe под RAID 10

Высокая транзакционная нагрузка и аналитика с отчетами: 24-48 ядер, RAM 256–512 ГБ, Быстрые NVMe, возможно стоит задуматься об отдельном массиве под временные операции, отделение аналитики (массовых действий) от обычной нагрузки

Критичная нагрузка: может потребовать дополнительный сервер с аналогичными данными, RAID 1 или RAID 10, репликация, архивирование WAL, возможность восстановления

При выборе сервера нужно считать не только текущий объем данных, но и резервный запас для выполнения различных операций, если диск заполнен почти полностью, база становится уязвимой: могут остановиться транзакции, архивирование WAL, обслуживание таблиц или восстановление
Используемая PostgreSQL использует несколько ядер при большом количестве одноввременных подключений и фоновых процессов ( autovacuum, репликация, резервное копирование, сортировки, построение индексов, обслуживание системы)
Один конкретный запрос не всегда ускоряется пропорционально количеству ядер. Для многих транзакционных систем важнее высокая производительность одного ядра, чем десятки слабых ядер
Небольшие запросы часто зависят от скорости выполнения отдельной операции, задержки диска и состояния индексов. Если процессор мощный, а диски не способны обеспечить быструю синхронную запись, это будет узким местом в системе
Сервис который обслуживает большое количество соединений (pgbouncer) не заменяет быстрые диски и RAM память.

Оперативная память для PostgreSQL нужна для кэширования часто используемых данных, индексов, сортировок, соединений таблиц, обслуживания индексов, vacuum и работы активных запросов.
Часть RAM должна оставаться операционной системе, так как операционная система также использует кэш и кроме СУБД для работы продукта используются другие сервисы, которым также необходим кэш
В официальной документации PostgreSQL подробно описаны параметры связанные с потреблением ресурсов

HDD для активной базы PostgreSQL это плохой выбор. База может обращаться к разным частям таблиц и индексов, а не читать диск только в одном месте, поэтому HDD плохо подходят для активной базы, так как у них высокая задержка случайного доступа. Жесткие диски можно использовать для архивов, резервных копий, холодных данных

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

RAID 1 подходит для 2 дисков, простого зеркалирования, дает небольшой прирост производительности
RAID 10 требует больше дисков, обеспечивает хорошую скорость и отказоустойчивость
Кэш без защиты при сбое питания может привести к потере данных
https://www.postgresql.org/docs/current/wal-reliability.html

WAL

WAL — журнал предзаписи PostgreSQL. Перед фиксацией изменений, они записываются в журнал. С помощью записей в журнале база может восстановиться после сбоя, использовать репликацию, архивировать изменения и возвращаться из резервной копии не только на момент создания резервной копии, но и к конкретной временной точке.
Высокая интенсивность записи в WAL становится ключевой нагрузкой на диски, каждая транзакция связана с записью в журнал
Если накопители плохо справляются с синхронной записью, транзакции начинают ждать
На высоконагруженных системах возможно стоит рассмотреть отдельный быстрый накопитель или отдельный массив под WAL. Если отдельный диск под WAL окажется менее надежным, чем основной массив, архитектура станет хуже, а не лучше.
Отстающая реплика тоже может удерживать старые WAL-файлы
Если для WAL не хватает места или диски плохо держат синхронную запись, база может замедляться

Резервное копирование

У каждого пользователя могут быть разные потребности. Для кого потеря данных за сутки или больше допустимо. Для другого пользователя потеря данных за последние 15 минут будет критична.
RAID или реплика это не бэкап, так как изменение данных просто продублируется зеркально на другой диск или реплику.

PostgreSQL поддерживает непрерывное архивирование WAL и восстановление на точку во времени. Это позволяет восстановить базу не только на момент полной копии, но и на более точный момент, если архив WAL был корректно сохранен.

Если резервное копирование начинает конкурировать с основной нагрузкой, его лучше переносить на реплику или планировать на периоды меньшей активности.

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

Реплика

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