Выделенный сервер в России для большой базы данных

MAATRIX

Большая база данных, обслуживающая российское приложение, должна быть в России — по двум причинам сразу: закон и задержка. Выделенный сервер (dedicated) в России для большой базы данных закрывает требование 152-ФЗ по хранению персональных данных и даёт минимальный пинг до вашего приложения и пользователей. Разберём, почему для российских проектов локация в РФ — выбор по умолчанию, как считать конфигурацию под рабочий набор и где граница с VPS.

Почему для российской базы локация в РФ — по умолчанию

Первая причина — закон. Базы данных почти всегда хранят персональные данные: клиентов, пользователей, сотрудников. Закон 152-ФЗ требует, чтобы персональные данные россиян хранились и обрабатывались на серверах в России. Держать боевую базу российского сервиса за рубежом — создавать себе прямой правовой риск. Сервер в РФ снимает этот вопрос.

Вторая причина — задержка. База обслуживает приложение, и они постоянно обмениваются данными: каждый запрос страницы порождает десятки обращений к БД. Если приложение в России, а база за рубежом, эта задержка умножается и убивает отзывчивость сервиса. Сервер в РФ рядом с приложением и пользователями убирает трансграничные задержки. Для российского проекта это делает локацию в России очевидным выбором.

Память — главный ресурс базы

Для базы данных оперативная память важнее всего остального. Любая СУБД — PostgreSQL, MySQL, MongoDB, ClickHouse — работает быстро, пока горячие данные помещаются в RAM. Как только рабочий набор перестаёт влезать в память, каждый запрос начинает ходить на диск, и производительность падает в разы независимо от мощности процессора.

Считайте так: оцените размер рабочего набора — той части данных, к которой обращаются постоянно (обычно меньше полного объёма базы), — и подберите память, чтобы он помещался в RAM с запасом под кэш, соединения и ОС. Если рабочий набор 60 ГБ, сервер со 128 ГБ будет летать, а с 32 ГБ — задыхаться. Для больших баз типичны 128–512 ГБ и выше. Это первое, на что смотрят, и последнее, на чём экономят.

ECC, диски и RAID

Раз память несущий элемент, её надёжность критична. ECC-память исправляет одиночные сбои битов на лету и для боевой базы обязательна: тихое искажение байта уходит в данные, реплики и бэкапы и обнаруживается поздно и дорого. Серверные платформы EPYC и Xeon идут с ECC по умолчанию, поэтому базу и держат на них.

Диск для базы критичен даже при большой памяти: на нём данные целиком, туда пишутся транзакции. Нужен NVMe-SSD с высоким ресурсом записи (DWPD) и защитой от потери питания — базы интенсивно пишут. Оптимальный массив — RAID 10: сочетает скорость и надёжность, переживает смерть диска без остановки. RAID 5/6 под интенсивную запись базы проседают, их берут реже.

Процессор и конфигурации

Процессор для базы важен, но вторичен по отношению к памяти и диску. Число ядер определяет, сколько тяжёлых запросов и параллельных соединений СУБД обслуживает одновременно. Ориентир — AMD EPYC на 16–48 ядер с большим кэшем L3; частота отдельного ядра важна для однопоточных тяжёлых запросов.

Принцип неизменен: сначала обеспечьте память под рабочий набор и быстрый диск, потом подбирайте процессор под профиль запросов. Мощный CPU при нехватке RAM базе не поможет.

Надёжность: бэкапы и репликация

Большая база — это ценность, потеря которой недопустима. RAID 10 спасает от смерти диска, но не от повреждения базы, ошибочного запроса, удаления или шифровальщика. От этого защищают только регулярные бэкапы с обязательной проверкой восстановления — бэкап, который не разворачивается, бесполезен. Держите копию в отдельном месте.

Для критичных баз добавляют репликацию: вторая копия на отдельном сервере принимает изменения в реальном времени и при отказе основного берёт нагрузку, а заодно разгружает чтение и упрощает обслуживание. Такую схему строят под требования к доступности. Выделенный сервер даёт полный контроль над репликацией, бэкапами и тюнингом СУБД без ограничений виртуального окружения — на VPS вы ограничены его ресурсами и соседями по диску.

Отдельно про тюнинг: значительная часть производительности берётся не из железа, а из настройки СУБД. Правильно выставленные параметры памяти (shared_buffers, work_mem и аналоги), пул соединений, продуманные индексы и регламент обслуживания (VACUUM, обновление статистики) дают на большой базе кратный эффект. База «из коробки» на мощном сервере способна работать медленнее, чем аккуратно настроенная на скромном. Планируйте тюнинг как часть внедрения. И следите за здоровьем железа — SMART дисков, температуры, счётчик ECC-ошибок: плановая замена подношенного NVMe в RAID 10 безопаснее аварийной.

Цена, оплата и когда хватит VPS

Цену аренды определяют объём и тип памяти, диски (объём, ресурс, RAID), процессор, резервирование и администрирование. Машина под базу в сотни гигабайт с рабочим набором в памяти дороже сервера под спокойную базу средней руки. Ориентируйтесь на диапазоны и логику, а не на жёсткий прайс; точные конфигурации уточняйте на сайте. Плюс российской локации и в оплате — картой РФ, по СБП, криптой или токеном MAAT.

И честно: не каждой базе нужен выделенный сервер. Если база небольшая, рабочий набор помещается в скромную память, а нагрузка спокойная — VPS в России с NVMe и достаточной RAM закроет задачу дешевле и так же в правовом поле РФ. Выделенный сервер оправдан, когда база большая, рабочий набор требует десятков-сотен гигабайт памяти, нужна предсказуемая производительность без соседей по диску или полный контроль под репликацию и тюнинг. Разумный путь — расти на VPS и переезжать на dedicated, когда база перестаёт помещаться в память виртуалки.

Частые вопросы