Выделенный сервер для большой базы данных: конфигурация и цена

MAATRIX

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

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

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

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

ECC — не обсуждается

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

К счастью, выбор здесь фактически сделан за вас: все серверные платформы AMD EPYC и Intel Xeon рассчитаны на регистровую ECC-память, и она идёт стандартом. Именно поэтому большую базу держат на серверном железе, а не на десктопной платформе без ECC — целостность данных важнее экономии на памяти. Держать боевую БД на non-ECC — осознанный риск, на который в продакшене не идут.

Диски: NVMe, ресурс записи и RAID 10

Даже при большой памяти диск для базы критичен: на нём лежат данные целиком, туда идут записи транзакций, оттуда читается всё, что не в кэше. Под базу нужен NVMe-SSD — он даёт сотни тысяч операций в секунду и низкую задержку, а именно мелкие случайные операции и есть нагрузка СУБД. SATA-SSD допустим лишь для небольших и спокойных баз.

Два нюанса, которые отличают серверный подход. Первый — ресурс записи: базы интенсивно пишут, поэтому берут диски с высоким DWPD (сколько раз в день можно перезаписать весь объём) и защитой от потери питания, которая при внезапном отключении не теряет буфер. Второй — RAID: под базу оптимален RAID 10, он сочетает скорость и надёжность и переживает смерть диска без остановки. RAID 5/6 под интенсивную запись базы проседают и на них смотрят реже.

Процессор и параллелизм

Процессор для базы важен, но вторичен по отношению к памяти и диску. Число ядер определяет, сколько тяжёлых запросов и параллельных соединений СУБД обслуживает одновременно: OLTP-нагрузка с множеством коротких транзакций и аналитические запросы на больших выборках нагружают ядра по-разному, но оба выигрывают от достаточного их количества.

Ориентир — AMD EPYC на 16–48 ядер под серьёзную базу, при этом важен и большой кэш L3, который ускоряет работу с данными. Частота отдельного ядра играет роль для однопоточных тяжёлых запросов. Общий принцип: сначала обеспечьте память под рабочий набор и быстрый диск, потом подбирайте процессор под профиль запросов. Мощный CPU при нехватке RAM базе не поможет.

Конфигурации и цена

Сведём ориентиры в таблицу. Точные значения зависят от объёма базы, рабочего набора и профиля нагрузки.

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

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

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

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

Когда достаточно VPS

Честно: не каждой базе нужен выделенный сервер. Если база небольшая, рабочий набор помещается в скромную память, а нагрузка спокойная — VPS с NVMe и достаточной RAM закроет задачу дешевле и поднимется за минуты. Многие проекты годами живут на базе внутри VPS вместе с приложением.

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

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