Сервер для базы данных: три компонента, от которых зависит всё

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

Ниже — материал внешнего автора о выборе сервера для базы данных. Процессор (частота против ядер, лицензирование MS SQL), оперативная память (ECC, объём, заполнение каналов), дисковая подсистема (RAID 10, отдельный том под журнал транзакций), готовые конфигурации по числу пользователей и сравнение MS SQL с PostgreSQL. Редакция портала о финансах и рынке форекс не несёт ответственности за содержание этого материала, а приведённые рекомендации не следует рассматривать как официальную техническую консультацию. Однако для системного понимания узких мест серверов БД — материал полезный.

Знакомьтесь, сервера для баз данных

Два процессора, терабайт памяти, массив NVMe - и база всё равно тормозит. Такое бывает, когда сервер собирают по принципу «чем мощнее, тем лучше», а не под конкретнюю СУБД и нагрузку. Разбираем, как подобрать CPU, RAM и диски так, чтобы деньги работали, а не лежали в стойке.

Почему сервер для БД - это не «просто мощный сервер»

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

• Процессор - выполняет запросы. Один медленный запрос держит транзакцию, пока не получит результат. Частота ядра важнее количества ядер.
• Оперативная память - кэширует данные. Пока база помещается в RAM, она работает на скорости памяти. Как только нет - на скорости диска, и это в 100 раз медленнее.
• Дисковая подсистема - хранит и пишет данные. HDD выдаёт ~100 IOPS, SSD - от 10 000, NVMe - от 100 000. Для СУБД разница критична.

Ошибка в любом из трёх - и сервер за миллион рублей работает как сервер за двести тысяч. Разберём каждый компонент.

Процессор: частота решает

Для транзакционных баз данных (1С, ERP, интернет-магазин, CRM) большинство операций выполняется в одном потоке. Проведение документа, выполнение SQL-запроса, расчёт отчёта - всё это ждёт результата последовательно. Один поток на частоте 3.4 ГГц сделает работу быстрее, чем один поток на 2.1 ГГц - независимо от того, сколько ядер свободно рядом. Тип нагрузки Что важнее: OLTP (транзакции: 1С, ERP, CRM) — частота на ядро, Turbo Boost критичен. OLAP (аналитика: ClickHouse, BI) — количество ядер, запросы параллелятся. Смешанная (база + приложения на одном сервере) — баланс частоты и ядер.

Ловушка с лицензированием MS SQL

• MS SQL Server лицензируется по ядрам. Больше ядер = дороже лицензия. 16-ядерный процессор обходится вдвое дороже 8-ядерного в пересчёте на лицензии.
• Парадокс: хочется больше ядер для производительности, но каждое ядро стоит денег.
• Решение: выбирайте процессор с высокой частотой и умеренным числом ядер.
• Альтернатива: переход на PostgreSQL полностью снимает вопрос лицензирования по ядрам.

RAM: чем больше - тем быстрее, и это буквально

СУБД работает так: горячие данные кэшируются в оперативной памяти, запросы обслуживаются из кэша. Когда запрашиваемых данных в кэше нет - СУБД читает с диска. Скорость RAM - ~50 ГБ/с. Скорость SSD - ~3 ГБ/с. Скорость HDD - ~0.15 ГБ/с. Вывод: каждый гигабайт RAM, в который поместились данные - это ускорение в десятки раз.

Правила, которые нельзя нарушать

• Только ECC-память (Error Correction Code). Бит-флип в обычной памяти = повреждённая запись в базе.
• Заполняйте слоты кратно числу каналов: 6 каналов на сокет у Xeon Scalable. 6 или 12 модулей - максимальная пропускная способность.
• PostgreSQL требует на 30-50% больше RAM, чем MS SQL для той же базы.

Диски: здесь теряют больше всего денег

Дисковая подсистема - компонент, на котором экономят чаще всего и теряют больше всего. Один HDD 7.2K выдаёт ~100 IOPS на случайном чтении. Один SSD SAS - 10 000-50 000 IOPS. Один NVMe - 100 000-500 000 IOPS. Разница между HDD и NVMe - три порядка. Для СУБД, которая генерирует тысячи мелких случайных обращений в секунду, это разница между «отчёт за 3 секунды» и «отчёт за 5 минут».

Распределение дисков по ролям:

• ОС: 2x SSD SATA 240-480 ГБ, RAID 1
• Данные БД: 2-4x SSD SAS или NVMe, RAID 10
• Журнал транзакций (WAL / TLog): 2x NVMe SSD, RAID 1 (отдельный физический том)
• tempdb / временные таблицы: 1-2x NVMe SSD
• Бэкапы: 2x HDD SAS 10K или SATA 7.2K, RAID 1

Журнал транзакций на отдельном диске - оптимизация, которую пропускают в 80% случаев. Если журнал и данные на одном томе - они конкурируют за I/O. Отдельный NVMe под журнал даёт прирост производительности записи от 30 до 100%.

RAID 10 vs RAID 5: что выбрать для СУБД

RAID 10: потеря ёмкости 50%, высокие IOPS на запись, быстрое перестроение. Для СУБД OLTP, интенсивная запись, 1С, ERP.

RAID 5: потеря ёмкости 1 диск из группы, низкие IOPS на запись, долгое перестроение. Для OLAP, преимущественно чтение, аналитика.

Аппаратный RAID обязателен

• Программный RAID на сервере БД - риск. При сбое питания без батарейки кэш записи теряется, база повреждается.
• Аппаратный контроллер с BBU/FBWC гарантирует запись даже при отключении питания.

MS SQL vs PostgreSQL: выбор СУБД влияет на железо

MS SQL Server: платная лицензия (от 100 000 ), лицензирование по ядрам, требует Windows Server, эффективный buffer pool, эталон с 1С.

PostgreSQL: бесплатный (коммерческие сборки Postgres Pro — от 50 000 ), без ограничений по ядрам, работает на Linux, требует на 30-50% больше RAM, требует ручной настройки, в реестре российского ПО.

Практический вывод: при бюджете «железо + лицензии» PostgreSQL позволяет перераспределить деньги в пользу RAM и SSD. Сервер с 256 ГБ RAM и NVMe-массивом на PostgreSQL часто работает быстрее, чем сервер с 128 ГБ на MS SQL.

Готовые конфигурации по числу пользователей

До 20 пользователей

Один сервер: 1x Xeon Silver 4214R (12 ядер) или Xeon E-2388G, 64 ГБ ECC DDR4, 2x SSD RAID 1 (ОС+данные), 2x HDD RAID 1 (бэкапы), аппаратный RAID-контроллер.

20-50 пользователей

Один мощный сервер: 1-2x Xeon Gold 6242R, 128-256 ГБ RAM, 4x SSD SAS RAID 10 (данные), 2x NVMe RAID 1 (журнал), 2x HDD RAID 1 (бэкапы), аппаратный RAID с FBWC, 2x 10GbE.

50-100+ пользователей

Раздельные серверы. Сервер СУБД: 2x Xeon Gold 6246R, 256-512 ГБ RAM (для PostgreSQL — 512 ГБ+), 6-8x NVMe RAID 10 (данные), 2x NVMe RAID 1 (журнал), отдельный том под tempdb.

Отказоустойчивость: что должно быть обязательно

• ECC-память
• RAID для всех дисков
• Два блока питания (hot-plug)
• Аппаратный RAID с BBU/FBWC
• Удалённое управление (iLO, iDRAC, IPMI)
• Регулярные бэкапы на отдельный том

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

Восстановленный HPE ProLiant Gen10 или Dell PowerEdge 14-го поколения с Xeon Scalable 1-2 поколений стоит на 40-60% дешевле нового. Разницу можно вложить в SSD и дополнительную память — то, что напрямую ускоряет базу. В каталоге представлены серверы для базы данных HPE, Dell и Rikor с гарантией 3 года и доставкой по России.

Чеклист перед покупкой

1. Какая СУБД? (MS SQL, PostgreSQL, MySQL) — требования к RAM, лицензии, ОС.
2. Размер базы сейчас и через 2 года? — объём RAM и ёмкость SSD.
3. Сколько пользователей одновременно? — процессор (частота и ядра) + RAM.
4. Тип нагрузки: OLTP или OLAP? — приоритет частоты или количества ядер.
5. СУБД и приложения на одном сервере или раздельно? — количество серверов.
6. Где стоит сервер: офис или ЦОД? — форм-фактор: 2U для офиса, 1U для ЦОД.
7. Бюджет с лицензиями СУБД или без? — MS SQL + Windows = дополнительные 200-500 тыс. руб.

Заключительные мысли и главне итоги

Сервер для базы данных - это не про максимальные характеристики, а про правильные характеристики. Высокочастотный процессор для быстрых транзакций. RAM, в которую помещается рабочий набор данных. SSD или NVMe в RAID 10 для дисковой подсистемы. Журнал транзакций на отдельном физическом томе. Аппаратный RAID-контроллер с батарейкой. Ошибка в одном компоненте обнуляет вложения в остальные. Баланс решает всё.

Баланс компонентов: почему сервер для БД — это не про «максимум ватт»

Для финансового директора или владельца IT-инфраструктуры выбор сервера под базу данных — это классическая инвестиционная задача с тремя переменными. Процессор, RAM и диски. Каждая влияет на производительность, но эффект от увеличения бюджета на один компонент может быть обнулён узким местом в другом. Автор последовательно раскрывает эти зависимости: частота ядра важнее количества для OLTP, RAM должна вмещать рабочий набор данных (иначе база упирается в диск), дисковая подсистема на NVMe даёт прирост в сотни раз по сравнению с HDD.

Особенно ценны два момента. Первый — лицензионная ловушка MS SQL: больше ядер = дороже лицензия, поэтому для этой СУБД выгоднее высокочастотный процессор с умеренным числом ядер. Второй — требование аппаратного RAID с батарейным кэшем (BBU/FBWC): программный RAID при сбое питания теряет кэш записи, и база повреждается. Экономия 30 тысяч рублей на контроллере может стоить миллионов на восстановлении данных.

Вывод для тех, кто отвечает за закупку серверов: не собирайте конфигурацию по принципу «бюджет остался — добавим ещё памяти». Начните с трёх вопросов: какая СУБД (лицензирование), сколько пользователей (нагрузка на CPU), какой размер базы (объём RAM). Для транзакционных систем (1С, ERP, CRM) — приоритет высокой частоты процессора, отдельного NVMe под журнал транзакций и RAID 10 для данных. Для аналитических систем — больше ядер и объёмных дисков, RAID 5 допустим. И помните: восстановленный сервер HPE или Dell с 3-летней гарантией позволяет направить сэкономленные 40-60% в NVMe и дополнительную RAM. А это именно то, что реально ускоряет базу, а не красивые цифры в спецификации.