Как выбрать сервер для баз данных

Сначала выберите сценарий, а не конфигурацию «на пользователей»

Одинаковое число подключений может означать разные задачи: короткие изменения заказов, длинные отчёты или почти бездействующие сессии. Размер базы также не равен объёму данных, который активно читают и меняют. Поэтому шаблон «100 пользователей — столько-то ядер» не даёт воспроизводимого результата.

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

Соберите паспорт нагрузки и отделите симптом от причины

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

• Операции: транзакции или запросы в секунду, чтение/запись, параллельные активные сессии, тяжёлые задания и длительность пика.
• Задержки: время пользовательской операции и отдельно запросов/фиксации; медиана и хвосты p95/p99, ошибки и тайм-ауты. p99 — граница, в которую укладывается 99% наблюдений, а не максимальное время.
• Ресурсы: загрузка отдельных ядер, очередь выполнения, ожидания СУБД, используемая память, вытеснения, временные файлы, I/O по томам данных и журнала.
• Рост: не только размер таблиц, но и индексы, журнал, временные операции, обслуживание и длительность копирования.
• Непрерывность: допустимая потеря данных, время восстановления и результат последнего практического восстановления.

В PostgreSQL 18 представления pg_stat_database и pg_stat_io помогают разделять классы операций; счётчики нужно интерпретировать с учётом времени сброса и настроек сбора. В SQL Server статистика sys.dm_io_virtual_file_stats позволяет оценить I/O по файлам. Эти показатели дополняют наблюдения ОС и приложения, а не заменяют их.

Не включайте дорогое диагностическое журналирование на рабочей системе без оценки влияния. Для испытания используйте согласованную копию с разрешёнными данными. Команда, которая исполняет запрос ради измерения, может изменить данные или создать нагрузку: «план выполнения» не всегда означает безопасный просмотр без запуска.

Какие показатели снять с PostgreSQL перед выбором сервера

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

1. Запишите условия. Версия PostgreSQL и ОС, объём RAM и shared_buffers, число подключений, размер базы, таблиц и индексов, тип хранилища. Размер всей базы даёт ориентир для ёмкости дисков. Для памяти важна часть данных, к которой нагрузка обращается в выбранный интервал.
2. Найдите запросы, которые заняли больше всего времени. Если pg_stat_statements уже включён, снимите calls, total_exec_time, shared_blks_hit, shared_blks_read и blk_read_time в начале и конце интервала. Ранжируйте запросы по приросту total_exec_time. При включённом track_io_timing разделите прирост blk_read_time на прирост total_exec_time для того же запроса. При нулевом знаменателе, сбросе счётчиков или отключённом измерении времени долю не вычисляйте. Если модуль ещё не загружен, добавление его в shared_preload_libraries требует перезапуска сервера. Запланируйте окно. Перед включением track_io_timing оцените стоимость вызовов таймера на этом хосте с помощью pg_test_timing. PostgreSQL 16: pg_stat_statements.
3. Сопоставьте счётчики с хостом. Снимите blks_read и blks_hit из pg_stat_database, а в PostgreSQL 16 — также evictions и writes из pg_stat_io по типу процесса и контексту. Разницу счётчиков делите на длительность интервала. С iostat -x запишите r/s, r_await, w/s, w_await и f/s, если последнее поле доступно. С vmstat снимите us, sy и wa. Сравнивайте интервалы и устройства, на которых лежат данные и WAL. Запросы к PostgreSQL и операции устройства имеют разную гранулярность: близкие скорости подкрепляют гипотезу, а их расхождение само по себе её не опровергает. PostgreSQL 16: накопительная статистика.

Чтобы оценить поток чтения PostgreSQL, умножьте прирост blks_read на размер блока и разделите на длительность интервала и на 1 048 576. При стандартных блоках 8 КиБ 10,6 тыс. блоков в секунду дают около 83 МиБ/с. Это оценка по счётчику PostgreSQL. Для испытания накопителя используйте наблюдаемые пиковые r/s и w/s, рабочую задержку и запас под рост. Для WAL учитывайте частоту и задержку сбросов (f/s и f_await, если доступны) вместе с w_await. Эти значения задают сценарий теста накопителя.

Что показал стенд PostgreSQL 16

На PostgreSQL 16.15 в Ubuntu 24.04.5 использовали 2 vCPU, 8 ГБ RAM, shared_buffers 2 ГБ и pgbench с 8 клиентами. В первом режиме данные помещались в память. Во втором часть RAM заняли с помощью tmpfs, и база была примерно в 1,9 раза больше доступной памяти. В тесте только на чтение доля blk_read_time во времени главного запроса выросла с 3,7% до 96%, а результат pgbench снизился с 53 735 до 9 100 транзакций в секунду. Во втором режиме PostgreSQL показывал около 10,6 тыс. чтений блоков в секунду, а устройство — около 10 тыс. операций чтения в секунду. В первом режиме теста только на чтение CPU был занят примерно на 99%, ожидание I/O и чтения устройства были близки к нулю.

В смешанной нагрузке доля времени чтения выросла с 21% до 84%. При этом доля попаданий в буферный кэш снизилась с 99,2% лишь до 95,9%, а %util диска был около 56% в обоих режимах. В первом режиме существенная часть операций приходилась на синхронную запись WAL. В статистике pg_stat_io для client backend во втором режиме наблюдалось около 665 тыс. вытеснений и 228 тыс. записей. Вытеснения означают, что обслуживающие запросы процессы освобождали место в буферах, а записи — что эти процессы сами записывали буферы. Рост обоих счётчиков показывает, что часть работы с буферами пришлась на обслуживающие процессы. Причину проверяйте по контексту pg_stat_io и работе фоновой записи.

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

Частота против ядер: сначала найдите, где тратится время

Если критичная последовательная часть запроса действительно упирается в вычисления одного ядра, важна производительность этого ядра на вашей версии СУБД. Если одновременно выполняются независимые вычислительные задачи, нужен достаточный суммарный ресурс. Гигагерцы разных архитектур нельзя напрямую переводить в скорость запроса.

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

Перед выбором двух сокетов проверьте, действительно ли нужны их ресурсы, каналы памяти и расширение. Дополнительная топология усложняет размещение вычислений и памяти. Один сокет тоже не гарантирует один NUMA-узел. Не выбирайте сокетность только по числу пользователей.

Фиксируйте ограничения мощности и охлаждения в испытании. Короткий результат на разогнанном тестовом профиле не подтверждает скорость длительного регламентного задания в рабочем сервере. Отдельно учитывайте лицензирование ядер: лишние лицензируемые ресурсы могут увеличить стоимость без выигрыша для критичной операции.

Память: рабочий набор, конкурентные операции и NUMA

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

В PostgreSQL память не ограничивается shared_buffers: work_mem относится к отдельным операциям запроса, а не ко всему серверу. Несколько операций и сессий способны расходовать память одновременно; hash-операции дополнительно зависят от hash_mem_multiplier. Поэтому увеличение одного параметра без оценки конкурентности может ухудшить устойчивость.

У SQL Server буферный пул — часть процесса, а не вся память машины. Настройку max server memory рассматривают вместе с ОС и другими потребителями. Лимиты редакции и версии проверяют отдельно: установка физических модулей сверх полезного для данного сценария объёма сама по себе не обеспечивает ускорения.

NUMA описывает неодинаковую стоимость доступа к памяти относительно вычислительных узлов. Проверьте заполнение каналов по инструкции платформы и видимую СУБД топологию; для ВМ — ещё и vNUMA на хосте. Закрепление CPU, изменение NUMA-режима и принудительное размещение памяти требуют измерения, а не копирования универсального рецепта.

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

NVMe и RAID: проверьте не интерфейс, а путь сохранения данных

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

NVMe определяет способ подключения и протокол, но не гарантирует нужный ресурс записи, защиту при потере питания или приемлемую задержку после исчерпания кэша. В разделе серверных SSD сравнивайте точные характеристики накопителя, прошивку, поддержку платформой и условия показателей производителя. Уточняйте, как ведёт себя накопитель при длительной записи и заполнении.

RAID выбирают по требуемой полезной ёмкости, переносимым отказам, поведению при восстановлении и совместимости программного стека. RAID10 с зеркальными парами не переживает любые два отказа: потеря обоих дисков одной пары разрушает массив. У parity-схем отдельно проверяют стоимость записи и восстановление. Конкретную схему подтверждают испытанием, а не обещанием «RAID всегда ускоряет».

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

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

IOPS без задержки и условий измерения не описывает СУБД

IOPS — количество операций ввода-вывода в секунду, но размер операции, чтение/запись и глубина очереди меняют смысл показателя. Миллион IOPS в спецификации накопителя не равен миллиону транзакций приложения. Кэш и объединение записей также меняют соотношение между операциями базы и физическим I/O.

Учебный пример: 12 000 операций/с по 8 КиБ — это 98,304 МБ/с, или 93,75 МиБ/с. Невысокий поток байтов ещё не означает, что накопитель выдержит нужные мелкие операции с требуемой задержкой. Обратно, высокая последовательная скорость ничего не говорит о хвосте задержек записи журнала.

Для стационарного потока связь среднего числа незавершённых I/O со скоростью и средним временем даёт: 12 000 × 0,002 с = 24 операции в среднем в обработке. Это иллюстрация закона Литтла, а не рекомендация установить queue depth 24: среднее не описывает p99, а условия реального стека нужно измерять.

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

Расчёт: полезная ёмкость и память с явными допущениями

Ниже синтетический пример, не результат испытаний и не готовая конфигурация. Все числа — условия задачи; на реальном проекте их заменяют измерениями. Дисковая ёмкость считается в десятичных ГБ/ТБ, память — в ГиБ.

Пусть текущие данные вместе с индексами занимают 800 ГБ. Принят рост 20% в год на два года: 800 × 1,2 × 1,2 = 1152 ГБ. Для общего пула дополнительно заложены 200 ГБ журнала, 240 ГБ временных данных и 400 ГБ на обслуживание. Получаем 1992 ГБ занятого пространства. Эти резервы выбраны для примера: реальный объём журнала зависит в том числе от интенсивности изменений, архивации и отстающих потребителей.

Если в этом примере принято держать 20% доступного пространства свободным, требуется 1992 / 0,8 = 2490 ГБ, или 2,49 ТБ доступной файловой системе ёмкости после RAID. Умножить исходный объём на 1,2 здесь недостаточно. Резерв 20% — условие расчёта, не универсальная норма для СУБД.

Это бюджет одного общего пула; при физическом разделении данных, журнала и временных файлов каждый том рассчитывают отдельно. Служебные расходы и доступную ёмкость проверяют на выбранной файловой системе. Хранилище резервных копий в эти 2,49 ТБ не входит: ему нужны собственные расчёт, политика хранения и независимость от основного узла.

Для RAM предположим бюджет: 48 ГиБ общего кэша, 16 ГиБ конкурентных операций, 16 ГиБ ОС, 8 ГиБ обслуживания и 4 ГиБ других служб — 92 ГиБ. Если дополнительно принят резерв 20% от доступной RAM, ориентир доступной системе ёмкости — 92 / 0,8 = 115 ГиБ. Затем подбирают поддерживаемую конфигурацию модулей, проверяют реально доступную память и повторяют измерение. Это не означает, что любая база 800 ГБ должна работать на таком объёме RAM.

Отдельно считают ресурс SSD. Если предполагаемая запись хоста — 1,5 ТБ в день, а ёмкость накопителя — 3,84 ТБ, отношение равно примерно 0,39 полной записи ёмкости в день. Это оценка записей хоста для примера, не расход NAND и не обещание срока службы. Сверяют TBW/DWPD, период гарантии и условия производителя, фактическую запись и поведение массива.

Сеть рассчитывают по потоку данных и окну операций

При локальных дисках и удалённой СХД сеть участвует в работе базы по-разному. Уточните пути приложения, storage, репликации и backup: один физический порт и общая очередь способны стать общей точкой конкуренции. При разделении VLAN физическая пропускная способность сама по себе не увеличивается.

Для учебного окна копирования 800 ГБ за час требуется средний поток 800 000 / 3600 ≈ 222,2 МБ/с, или 1,78 Гбит/с полезных данных. Это уже больше номинальной скорости 1GbE без учёта накладных расходов. Но установка 10GbE не доказывает выполнение окна: источник, приёмник, шифрование, сжатие, конкурирующий трафик и процесс восстановления могут ограничивать результат.

Измерьте устойчивый поток по всему маршруту и отставание реплики во время пика изменений. Для синхронной схемы отдельно проверяют задержку, а не только полосу. Скорость одного адаптера не характеризует весь путь до другой СХД или площадки.

Резервирование не равно восстановлению

RAID решает часть отказов накопителей, резервный блок питания — часть отказов питания, реплика — часть сценариев доступности. Ошибочные изменения могут попасть на реплику; отказ основного узла не доказывает доступность копии и управления. Проект должен разделять продолжение работы и возврат к нужному состоянию данных.

Определите RPO — допустимую потерю данных по времени — и RTO — допустимое время восстановления сервиса. Для PostgreSQL восстановление на момент времени строится на базовой копии и непрерывной нужной последовательности WAL. Обычный логический dump не является заменой базовой физической копии для такого процесса. План восстановления проверяют именно для выбранного способа копирования.

Проверка обещания: пусть нужно вернуть текущие 800 ГБ данных за 30 минут. При условной устойчивой скорости восстановления 250 МБ/с только передача 800 000 МБ займёт 3200 секунд — 53 минуты 20 секунд. В эти сроки ещё не включены подготовка, replay журнала и запуск приложения. Значит, такая схема не выполняет RTO 30 минут даже при исправной копии.

Испытание заканчивается не сообщением «backup завершён», а запуском восстановленной базы в изолированной среде, проверкой согласованности выбранным инструментом СУБД и критичных операций приложения. Фиксируют фактически потерянные операции, длительность, состав копии, доступность ключей шифрования и порядок возврата клиентов. Не переключайте production ради проверки без отдельного согласованного плана.

Для удалённой реплики и копий оцените пропускную способность, задержку, объём изменений и отставание. Синхронная репликация может добавить ожидание подтверждения по сети; асинхронная оставляет окно отставания. Режим согласуют с допустимой потерей данных, а не с единственной целью получить красивую скорость теста.

Лицензирование и виртуализация — часть выбора платформы

У коммерческой СУБД изменение числа ядер, редакции или способа размещения может изменить лицензионные требования. Сначала согласуйте, что лицензируется: физический сервер, виртуальная среда, пользователи или иной объект, — затем сравнивайте полную стоимость вариантов. Требования одного продукта нельзя переносить на PostgreSQL, MySQL или другую редакцию SQL Server.

Руководство Microsoft по SQL Server 2025 различает лицензирование физического сервера и ВМ, модели Per Core и Server + CAL; для отдельных прав существенны подписка и Software Assurance. Оно прямо отсылает к Product Terms и договору. Поэтому в техническое задание включают редакцию, версию, физические ядра и сокеты, vCPU, сценарий миграции и резервные экземпляры; условия письменно подтверждают применительно к вашей программе. Эта статья не устанавливает лицензионные права.

В ВМ дополнительно проверяют фактическую конкуренцию за CPU, память и I/O, топологию NUMA, поддержку гостевой ОС и механизм резервного копирования. Добавление vCPU способно изменить планирование и лицензирование, но не гарантирует ускорение. Миграцию и размещение резервной копии проверяют по поддерживаемой архитектуре и правам использования.

Ошибки, из-за которых дорогая конфигурация не решает задачу

• Выбирать по числу клиентов. Сначала измерьте активные операции и пики, отдельно учитывая отчёты и фоновые задания.
• Покупать ядра вместо разбора ожиданий. Определите, теряется ли время на CPU, блокировках, I/O или внешнем сервисе.
• Считать RAW-ёмкость свободным местом базы. Учтите избыточность, индексы, журнал, временные операции и обслуживание.
• Сравнивать пиковые IOPS. Зафиксируйте одинаковый режим и требуемые задержки, длительность и заполнение.
• Разделять нагрузку только буквами дисков. Проверьте физические устройства и общие контроллеры, каналы и пулы.
• Считать реплику резервной копией. Проверьте возврат к нужному состоянию после ошибки пользователя и потери узла.
• Забывать про лицензии и обслуживание. Учитывайте ограничения редакции, отказоустойчивую схему и условия поддержки до заказа.

Согласуйте критерии приёмки до покупки

У поставщика должна быть не просьба «быстрый сервер для БД», а проверяемый сценарий. Передайте паспорт нагрузки, версии ПО, бюджет ёмкости и RAM, требования к восстановлению, размещению и обслуживанию. Явно перечислите неподтверждённые параметры: размер базы без индексов или средний CPU не следует выдавать за полный профиль.

1. Зафиксируйте точные CPU, RAM и её установку, накопители и прошивки, RAID/HBA, ОС, версию СУБД и настройки сохранности записи.
2. Испытайте согласованные запросы и конкурентность на представительном наборе данных; оцените прогрев и устойчивую работу, а не только короткий пик.
3. Проверьте время операций приложения и хвосты задержек, ошибки и потребление ресурсов. Порог каждого показателя задают требования вашего сервиса.
4. Повторите допустимые сочетания: отчёт, backup, обслуживание массива и репликация. Результат одного спокойного режима не подтверждает остальные.
5. Восстановите согласованную копию, измерьте RPO/RTO и убедитесь, что приложение выполняет критичные операции.

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