Облачный сервер для PostgreSQL в Европе: настройка под GDPR

Облачный сервер для PostgreSQL в Европе: настройка под GDPR

Облачный сервер для PostgreSQL в Европе: настройка под GDPR

PostgreSQL - выбор для приложений, которым нужны надёжность, сложные запросы и строгая целостность данных. Если ваши пользователи или бизнес находятся в Европе, запуск PostgreSQL на облачном сервере в ЕС - не просто техническое предпочтение, а юридическая и коммерческая необходимость по GDPR.

Это руководство описывает, какое оборудование нужно PostgreSQL, как поднять соответствующий требованиям облачный сервер в ЕС и как ввести экземпляр в работу менее чем за час.

Почему место хранения данных в ЕС важно для PostgreSQL

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

Помимо соответствия требованиям, серверы в ЕС дают меньшую задержку европейским пользователям. База во Франкфурте или Праге отвечает берлинскому приложению на 30-80 мс быстрее, чем размещённая в Вирджинии. Для транзакционных нагрузок эта разница складывается в заметное улучшение пользовательского опыта.

Минимальные требования к серверу для PostgreSQL

Правильная конфигурация зависит от нагрузки, но вот практические отправные точки:

  • Небольшая (разработка и стейджинг, менее 10 тыс. строк в секунду) - 4 vCPU, 8 ГБ RAM, 100 ГБ NVMe SSD
  • Средняя (продакшен-приложение, 10-100 тыс. строк в секунду) - 8 vCPU, 32 ГБ RAM, 500 ГБ NVMe SSD
  • Крупная (аналитика или OLTP с интенсивной записью) - 16 и более vCPU, 64-128 ГБ RAM, 1 ТБ и более NVMe SSD

PostgreSQL сильно выигрывает от RAM: чем больше shared_buffers и effective_cache_size, тем меньше дискового ввода-вывода вы создаёте. Хранилище NVMe важно для нагрузок с интенсивной записью, потому что записи WAL последовательные, но частые.

Рекомендуемая конфигурация DCXV

Облачные серверы DCXV работают на сертифицированной по Tier III инфраструктуре в ЕС с хранилищем на NVMe и выделенными сетевыми каналами. Практичная продакшен-схема для PostgreSQL на DCXV:

  • 8 vCPU, 32 ГБ RAM, 500 ГБ NVMe - справляется с большинством продакшен-баз SaaS
  • 16 vCPU, 64 ГБ RAM, 1 ТБ NVMe - аналитические базы с одновременными отчётными запросами
  • Полное хранение данных в ЕС в дата-центрах, сертифицированных по ISO 27001
  • Приватная сеть между серверами приложений и базы без доплаты

Напишите на sales@dcxv.com, чтобы обсудить вашу нагрузку и получить рекомендацию по конфигурации.

Команды для быстрой установки

# Установка PostgreSQL 16 на Ubuntu 22.04
sudo apt update && sudo apt install -y postgresql-16

# Запуск и включение службы
sudo systemctl start postgresql
sudo systemctl enable postgresql

# Переход на пользователя postgres и открытие psql
sudo -u postgres psql

# Создание базы и пользователя
CREATE DATABASE myapp;
CREATE USER myapp_user WITH ENCRYPTED PASSWORD 'strongpassword';
GRANT ALL PRIVILEGES ON DATABASE myapp TO myapp_user;
\q
# Ключевые параметры postgresql.conf для сервера с 32 ГБ RAM
# Правьте /etc/postgresql/16/main/postgresql.conf

# Параметры памяти
shared_buffers = 8GB           # 25% RAM
effective_cache_size = 24GB    # 75% RAM
work_mem = 64MB                # на каждую сортировку или хеш
maintenance_work_mem = 2GB     # для VACUUM, CREATE INDEX

# Производительность записи
wal_buffers = 64MB
checkpoint_completion_target = 0.9
max_wal_size = 4GB

# Соединения
max_connections = 200

# После изменений перезапустите
sudo systemctl restart postgresql
# Разрешение удалённых подключений (правьте pg_hba.conf)
# Добавьте приватный адрес вашего сервера приложений
echo "host myapp myapp_user 10.0.0.0/24 scram-sha-256" | sudo tee -a /etc/postgresql/16/main/pg_hba.conf

# Также обновите postgresql.conf, чтобы слушать приватный адрес
sudo sed -i "s/#listen_addresses = 'localhost'/listen_addresses = '10.0.0.5,localhost'/" /etc/postgresql/16/main/postgresql.conf

sudo systemctl reload postgresql

Что на самом деле делает каждый параметр памяти

Четыре значения в том блоке конфигурации выбраны не случайно, и только одно из них - предел на сервер. Неверно понятая разница - это то, как машина с большим объёмом RAM оказывается в свопе:

Параметр Что он покрывает Значение выше Как узнать, что оно неверно
shared_buffers Общий кеш страниц, один раз на сервер 8 ГБ Чтения продолжают идти на диск, а свободная память простаивает
work_mem Одна сортировка или хеш, на операцию 64 МБ В журнале появляются временные файлы, или сервер уходит в своп под нагрузкой
maintenance_work_mem VACUUM и построение индексов, на каждый рабочий процесс 2 ГБ Автовакуум никогда не заканчивает работу на самой крупной таблице
effective_cache_size Ничего - это подсказка планировщику 24 ГБ Планировщик выбирает последовательное сканирование вместо вполне подходящего индекса

Кусается именно work_mem. Он применяется к каждой сортировке, а не к соединению, поэтому запрос с тремя сортировками на пятидесяти соединениях может запросить в сто пятьдесят раз больше заданного значения. Поднимайте его для одного отчётного запроса, которому это нужно, внутри его сеанса, а не для всего сервера.

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

На инстансе 8 vCPU / 32 ГБ RAM / NVMe с PostgreSQL 16 и правильной настройкой:

  • pgbench, транзакций в секунду (только чтение, масштаб 100) - 12 000-18 000
  • pgbench, транзакций в секунду (чтение и запись, масштаб 100) - 4 000-7 000
  • Задержка выборки одной строки (по индексу) - менее 0,5 мс
  • Пакетный INSERT (1 млн строк) - менее 60 секунд

Эти цифры предполагают, что рабочий набор помещается в shared_buffers. Для наборов данных больше RAM узким местом становится пропускная способность SSD: хранилище NVMe держит устойчивое последовательное чтение свыше 3 000 МБ/с, что сохраняет приемлемую задержку даже при промахах кеша.

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

Итог

PostgreSQL на облачном сервере в ЕС даёт соответствие GDPR, низкую задержку для европейских пользователей и полный контроль над данными. Начните с правильно рассчитанного инстанса DCXV, примените параметры настройки выше, и у вас будет готовая к продакшену база заметно быстрее, чем за час.

Как подключиться к новому облачному серверу по SSH
sshtutorialcloud

Как подключиться к новому облачному серверу по SSH

Сервер готов, а в панели есть IP, логин и пароль. Вот первое подключение по SSH, четыре ошибки, которые встречаются чаще всего, и первые десять минут.

Как подключиться к Windows-серверу через удалённый рабочий стол
rdpwindowstutorialcloud

Как подключиться к Windows-серверу через удалённый рабочий стол

У вас есть адрес, имя пользователя и пароль. Вот как превратить их в рабочий стол Windows у себя на экране - с ПК, Mac или телефона, шаг за шагом.

Облачный сервер для Stable Diffusion в Европе: настройка GPU
cloudaigpu

Облачный сервер для Stable Diffusion в Европе: настройка GPU

Какое оборудование GPU нужно Stable Diffusion, как поднять два самых популярных интерфейса и какой скорости генерации изображений ожидать в ЕС.

Облачный сервер для хостинга LLM в Европе: руководство по AI и GDPR
cloudaigpu

Облачный сервер для хостинга LLM в Европе: руководство по AI и GDPR

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

Запустите Claude Code, Codex и Grok CLI на своём облачном сервере
cloudaivps

Запустите Claude Code, Codex и Grok CLI на своём облачном сервере

Превратите облачный сервер на Debian или Ubuntu в песочницу для ИИ-агентов вроде Claude Code, Codex и Grok CLI. Пишите код откуда угодно, даже с телефона.