Базы данных и аналитика на AMD EPYC - практический гид по модернизации и подбору серверной платформы

Компании обновляют платформы данных, чтобы поддерживать аналитику в режиме реального времени, получать выводы на основе искусственного интеллекта и надёжно обслуживать критически важные приложения. Microsoft SQL Server 2025 добавляет расширенную обработку запросов, встроенные функции искусственного интеллекта и усиленные механизмы безопасности. Чтобы использовать эти возможности в полной мере, требуется инфраструктура с предсказуемой производительностью, масштабированием и устойчивостью к сбоям.

Современные серверы на базе процессоров AMD EPYC 5-го поколения даёт основу для современных СУБД, в том числе и SQL Server 2025 - с акцентом на безопасность, энергоэффективность и высокую производительность. 

Управление данными - вызовы и возможности

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

У большинства проблем с платформой данных есть не только “боль”, но и понятная точка приложения усилий - в архитектуре и выборе аппаратной базы.

По затратам ключевой источник раздувания бюджета связан не только с железом, но и с моделью лицензирования “по ядрам” и с неуправляемым ростом числа виртуальных машин. Когда под каждый сервис или команду поднимаются отдельные экземпляры ВМ, быстро растёт суммарное число ядер, а вместе с ним и стоимость лицензий и сопровождения. Практическая возможность здесь одна - консолидация за счёт высокой производительности на ядро и предсказуемого поведения под нагрузкой. Чем меньше ядер требуется для заданного уровня отклика и пропускной способности, тем проще удержать лицензии и инфраструктуру в разумных рамках без потери качества сервиса.

По производительности главная претензия бизнеса почти всегда формулируется одинаково - “почему время ответа плавает” и “почему транзакции и запросы ведут себя по-разному в течение дня”. На уровне платформы это упирается в пропускную способность памяти, задержки доступа к данным и в то, как процессор справляется с большими рабочими наборами. Поэтому в качестве “рычагов” логично обсуждать конкретные вещи - пропускную способность DDR5, объёмные кэши третьего уровня, быстрые подсистемы на NVMe через PCIe пятого поколения. Важно, что такие характеристики дают эффект не только в синтетике, а именно в типовой работе базы данных - когда одновременно идут чтения, записи, фоновые операции и аналитические запросы, и нужно удерживать стабильный отклик.

По устойчивости к сбоям картина осложняется тем, что угрозы стали не только внешними. Да, есть шифровальщики, но на практике не меньше проблем приносят ошибки настройки и “дрейф конфигураций” между средами. Отсюда вытекает два уровня требований. Первый - доверенная аппаратная основа, которая снижает риск незаметных изменений и компрометации на низком уровне. Второй - корректная стратегия восстановления и отказоустойчивости на уровне данных. Здесь уместно говорить о неизменяемых резервных копиях и о постоянной доступности - когда отказ узла не превращается в простой сервиса и не вынуждает выбирать между доступностью и целостностью данных.

По устойчивому развитию давление чаще всего проявляется в очень прагматичной форме - “не хватает питания и охлаждения, а нагрузки растут”. В таких условиях ценность смещается к показателю производительности на ватт и к плотности размещения - когда тот же объём транзакций и аналитики удаётся обслуживать меньшим количеством узлов или в меньших энергетических рамках. Это напрямую влияет и на эксплуатационные расходы, и на возможность масштабирования в существующем серверном помещении без дорогостоящей реконструкции инженерной инфраструктуры.

Если свести эти пункты к общей логике, то она простая - современные требования к платформам данных упираются в предсказуемость, управляемость и экономику владения. И именно поэтому обсуждение процессоров и серверной платформы имеет смысл вести не “в общем”, а через связку затрат, времени ответа, восстановления после инцидентов и ограничений по питанию и охлаждению.

Практика по отраслям - сценарии работы с данными и требования к нагрузке

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

Процессоры AMD EPYC 4 и 5 поколения для баз данных и аналитики

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

Логика выбора здесь практичная - если задача ближе к транзакциям, важны быстрые ядра и предсказуемое время ответа, чтобы не раздувать лицензии и парк серверов. Если задача ближе к аналитике, важна масштабируемость по числу ядер и пропускной способности памяти, чтобы удерживать высокую параллельность и «тяжёлые» запросы без провалов по отклику. Для таких сценариев в материалах выделяются процессоры AMD EPYC 5-го поколения - высокая плотность ядер, объёмные кэши L3 и пропускная способность DDR5, которые хорошо ложатся на типичные нагрузки баз данных.

Отдельная практическая деталь для производственных контуров - архитектура с учётом NUMA. Например, при корректной настройке параметров параллельности SQL Server (MAXDOP) и виртуальной NUMA в средах виртуализации проще добиться повторяемого поведения под нагрузкой - без «скачков» времени ответа при росте числа одновременных запросов.

Платформа также определяется тем, как быстро данные попадают в вычисления - через подсистему хранения и сеть. В этой части делается акцент на PCIe Gen5 - до 128 линий, которые позволяют строить быстрые конфигурации на NVMe, высокоскоростных сетевых адаптерах и при необходимости ускорять потоки данных к графическим ускорителям. Подробнее о такой системе можно посмотреть в обзоре сервера Dell PowerEdge R7725xd.

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

Производительность и энергоэффективность серверов на базе AMD EPYC подкрепляется примерами результатов отраслевых тестов и сравнений:

• для Microsoft SQL Server приводится прирост порядка 44% по числу запросов в час и порядка 31% по транзакциям в секунду на одно лицензируемое ядро (Источник: QPHH@3000GB benchmark based on TPC-H 2x 32c EPYC 9374F vs 2P 32c Intel® Xeon® 8562Y+)

• для MySQL приводятся оценки порядка 2,7 раза больше запросов в час и порядка 3,9 раза больше транзакций в секунду в отдельных сценариях тестирования (Источник: TPROC-H on DSS benchmark 2P EPYC 9654 vs. 2P Xeon Platinum 8380)

• для PostgreSQL приводится оценка порядка 58% выше по транзакциям в секунду в сценарии транзакционной нагрузки (Источник: OLTP using a 1P EPYC configuration 1x EPYC 9374 vs 2x Xeon 8462Y+)

• отдельно заявляется рост транзакционной производительности до 290% в сценариях OLTP в сравнении, где подчёркивается влияние высокой плотности ядер и реакция на пиковую нагрузку (Источник: сервер с двумя 192-ядерными AMD EPYC 9965 обрабатывает в 2,9 раза больше транзакций в секунду, чем конфигурация с двумя 64-ядерными Intel Xeon 8592+ в тесте TPROC-C на MySQL)

• по оценке трёхлетней стоимости владения приводятся ориентиры порядка 44% ниже, а также порядка 63% меньше серверов и порядка 45% ниже энергопотребление в сценарии достижения заданного суммарного результата производительности (Источник: Сравнение количества серверов, необходимого для получения суммарного результата SPECrate 2017 int_base на уровне примерно 39 100 - при использовании двухпроцессорных серверов с 192-ядерными EPYC 9965 по сравнению с конфигурациями на 64-ядерных Xeon 8592+)

Отдельно стоит подчеркнуть, что на рынке доступны серверные платформы крупных производителей, а «рекордные» результаты в отраслевых тестах демонстрируются на конфигурациях разных вендоров - для задач СУБД, аналитики и виртуализации регулярно фиксируются высокие показатели на стендах HPE, Dell и Lenovo. В качестве иллюстрации можно сослаться на два недавних примера - мировой результат Lenovo ThinkSystem SR655 V3 в VMmark 4 по виртуализации и серия мировых рекордов HPE ProLiant DL385 Gen11. Это важно с практической точки зрения - выбор не упирается в один единственный сервер, а переносится в плоскость корректной конфигурации под конкретную задачу.

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

В таком контуре AMD EPYC 4-го и 5-го поколения логично рассматривать как основу для двух задач - модернизация действующих баз данных и построение платформы, которая «держит» одновременно транзакции, аналитику и новые функции современных СУБД без разрастания числа серверов и без неконтролируемого роста лицензий.

Подход к архитектуре сервера баз данных на примере СУБД MS SQL Server 2025

Архитектура систем управления базами данных всё чаще строится не вокруг “одной базы”, а вокруг смешанного профиля - транзакции, отчётность, аналитика и новые функции, которые используют векторные представления данных и внешние модели. Поэтому практичный подход начинается с выбора серверной платформы, которая одновременно даёт предсказуемое время отклика, масштабирование по ресурсам и управляемость в эксплуатации.

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

Характеристики универсального сервера на базе 5 поколения AMD EPYC

В качестве “универсального” профиля рассматривается двухпроцессорный сервер форм-фактора 2U, рассчитанный на современные процессоры AMD EPYC серий 9004 и 9005. Такой класс платформы даёт несколько опорных возможностей, которые важны именно для баз данных.

Память - DDR5, до 6 ТБ, 12 каналов на процессор. Для СУБД это означает не только высокий потолок по объёму, но и возможность получать стабильную пропускную способность памяти при корректном заполнении каналов, что напрямую влияет на время ответа запросов и работу с крупными наборами данных.

Хранение - конфигурации “полностью на NVMe” или смешанные SAS-SATA-NVMe. Это позволяет разделять профили ввода-вывода - журналы, TempDB и пользовательские данные - по разным пулам, чтобы нагрузки не мешали друг другу.

Расширение - слоты PCIe Gen5 под NVMe и высокоскоростные сетевые адаптеры. Для сервера БД это важно уже не только из-за хранилища, но и из-за интеграций “почти в реальном времени” и вызовов внешних моделей, где сеть становится частью критического пути.

Безопасность и управление - аппаратный Root-of-Trust, TPM 2.0 и защищённая загрузка, плюс контроллер удалённого управления и средства автоматизации жизненного цикла. В результате проще поддерживать единое состояние прошивок, контролировать доступ к управлению и быстрее проходить типовые операции эксплуатации - обновления, аудит, диагностику.

Особенности СУБД SQL Server 2025

SQL Server 2025 добавляет возможности, которые одновременно повышают стабильность производительности, упрощают работу с данными “в моменте” и позволяют строить приложения с поддержкой искусственного интеллекта без разрастания внешних компонентов.

Векторные данные и поиск по сходству. Появление встроенного типа данных для векторов и функций поиска по близости позволяет хранить представления и выполнять семантический поиск прямо внутри базы. Это снижает число внешних сервисов и упрощает контроль доступа и аудит. На сервере с высокой пропускной способностью DDR5 и быстрым NVMe проще удерживать предсказуемый отклик по мере роста числа векторов. Необходимо заранее оценить размер векторов, долю “горячих” данных и селективность индекса, а затем размещать наиболее востребованные векторы рядом с аналитическими данными, где часто используются комбинированные фильтры.

Индекс DiskANN для масштабирования векторного поиска. Дисковый индекс ускоряет поиск по большим наборам векторов за счёт сочетания структур в памяти и обращений к быстрым SSD. Для конфигураций “полностью на NVMe” это типовой путь обслуживать большие массивы векторов с контролируемыми хвостовыми задержками. Для стабильности важно отделять построение и обновление индексов от “боевой” нагрузки - выделенным пулом NVMe или отдельным окном обслуживания.

Определения моделей в T-SQL - вызов внешних моделей. SQL Server 2025 позволяет регистрировать и вызывать внешние модели из T-SQL через интерфейс запросов, при этом сами вычисления выполняются вне движка СУБД. Это удобный механизм для генерации векторных представлений, классификации, суммаризации и других задач, где важны локальность данных и контроль доступа. Здесь критично следить за задержками сети и пределами параллельности, подбирать сетевые адаптеры под требуемую пропускную способность и ограничивать интенсивность вызовов со стороны базы, чтобы не ухудшать показатели транзакционного контура.

Поток событий изменений для интеграций в реальном времени. Механизм передачи вставок-обновлений-удалений в downstream-системы снижает потребность в “самодельных” контурах выгрузки и ускоряет построение оперативных витрин, антифрода и сценариев видимости запасов. На практике это означает - защищать основной экземпляр группами доступности и, где возможно, выносить чтение потока на вторичную реплику. На уровне платформы важны выделенная полоса сети под поток и контроль скорости генерации журнала относительно отставания потребителей.

Улучшения интеллектуальной обработки запросов. Механизмы оптимизации планов и параллелизма в SQL Server 2025 направлены на то, чтобы снижать число регрессий при перекосах данных и удерживать стабильное использование процессора под пиковыми нагрузками. Проверка эффекта должна идти не по “средней температуре”, а по метрикам p95-p99 задержек и по ключевым ожиданиям, которые обычно первыми сигнализируют о проблемах - WRITELOG, PAGEIOLATCH, CX.

Удобство разработки - регулярные выражения и улучшенная работа с JSON. Когда преобразования и проверки можно делать внутри базы, меньше потребность в внешних слоях разбора и меньше риск “разъезда” логики. Это полезно для очистки текстов, сценариев “схема при чтении” и валидации входящих полезных нагрузок перед сохранением.

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

Типовые нагрузки для эталонной архитектуры

На практике существует три базовых профиля, под которые чаще всего проектируется серверная платформа.

Рекомендации по проектированию и подбору конфигурации

Проектирование SQL Server 2025 на сервере с AMD EPYC 5-го поколения лучше вести по пяти плоскостям - процессор, память, раскладка хранения, настройки SQL Server, виртуализация и эксплуатация.

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

Память - буферный пул разумно закладывать с запасом относительно активного набора данных, чтобы уменьшить обращения к диску, а модули памяти распределять равномерно по 12 каналам на процессор для баланса NUMA. Дополнительно требуется резерв под выделения памяти запросам, объектный пул columnstore и сценарии in-memory OLTP, если они используются.

Хранение - журналы транзакций лучше держать на выделенном пуле NVMe с “аккуратной” глубиной очереди для низких задержек. TempDB - отдельный NVMe-пул и несколько одинаковых файлов, стартовая практика - от одного файла на логический процессор, но не более восьми, с последующей настройкой по наблюдениям. Данные - широкий NVMe-пул, а выбор уровня отказоустойчивости зависит от профиля чтения и записи - для OLTP целесообразен RAID 6, для нагрузок с преобладанием чтения также уместен RAID 6. Томам полезно задавать размер единицы размещения 64 КБ.

Настройки SQL Server - MAXDOP следует привязывать к числу ядер в узле NUMA, порог стоимости параллелизма настраивать так, чтобы не тратить ресурсы на лишний параллелизм, а планировщик держать ближе к локальной памяти, избегая “прыжков” между процессорами. TempDB лучше заранее выделять по объёму и контролировать конкуренцию, чтобы не ловить деградации под пиками.

Виртуализация - виртуальную NUMA необходимо выравнивать с физической топологией NUMA, избегать переподписки по памяти, применять механизмы ограничения ресурсов для изоляции арендаторов и ограничивать vCPU значениями, соответствующими ядрам.

Отказоустойчивость, резервное копирование, безопасность и контроль - для высокой доступности синхронная фиксация и автоматическое переключение, для аварийного восстановления асинхронные реплики, плюс регулярные учения по RTO-RPO. Для резервных копий уместна схема 3-2-1-1-0 с неизменяемыми копиями и проверкой восстановления. Для безопасности - защищённая загрузка и TPM, обновления прошивок только подписанными пакетами, многофакторная защита доступа к управлению, шифрование данных при передаче и хранении и регулярная ревизия прав. Для контроля - мониторинг задержек p95-p99, скорости запросов, ключевых ожиданий и задержек NVMe с глубиной очереди, а также телеметрия по питанию и температурному режиму.

Риски при внедрении - любой проект модернизации несёт в себе риски. Успех во многом зависит от того, насколько эти риски заранее понятны и насколько последовательно применяются меры, которые не дают им превратиться в простои и перерасход бюджета.

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

Неэффективность NUMA - ошибки в выравнивании NUMA часто дают всплески задержек и непредсказуемую производительность. Меры снижения включают согласование vNUMA с физической топологией, настройку MAXDOP по числу ядер в узле NUMA и проверку конфигурации по статистике ожиданий и метрикам задержек p95.

Конкуренция за ресурсы TempDB - в средах с высокой параллельностью TempDB нередко становится узким местом. Снизить риск помогает настройка нескольких TempDB-файлов одинакового размера, размещение TempDB на выделенном хранилище NVMe и мониторинг конкуренции PFS и SGAM.

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

Производительность баз данных на серверах с AMD EPYC на примере HPE Proliant DL385 Gen11 - оценка производительности баз данных имеет смысл только в привязке к двум вещам - лицензированию и стабильности задержек. Для сервера баз данных это обычно означает измерения производительности на лицензируемое ядро, задержек p95-p99 и поведения в сценариях высокой доступности и аварийного восстановления. В качестве ориентиров используются отраслевые наборы тестов - для транзакций HammerDB TPROC-C или сценарии уровня TPC-E, для аналитики - наборы запросов на базе TPC-H. Отдельно фиксируются показатели задержек p50-p95-p99 и телеметрия по энергопотреблению и температурному режиму.

Показательный пример из публичных результатов - серия мировых достижений в TPC-H v3 на Microsoft SQL Server 2025 Enterprise Edition на масштабе 10 TB, где для платформы DL385 Gen11 отмечены пять первых мест и первый результат выше 4 млн QphH - 4 036 908.

Чтобы показать компромисс между производительностью на ядро и максимальной пропускной способностью, для тестов использовались две конфигурации одного класса сервера - с разными моделями EPYC и разным целевым профилем.

Вариант A - акцент на частоту и отдачу на лицензируемое ядро. Используется процессор EPYC 9375F на 32 ядра, 1,5 TB DDR5, полностью NVMe-подсистема - 2 NVMe под журналы в выделенном массиве RAID 6, 4 NVMe под TempDB, 12 NVMe под данные, сеть 2 x 25GbE, Windows Server Datacenter и SQL Server 2025 Enterprise. В этом профиле результат по транзакционной пропускной способности составляет 1 050 000 TPM при p95 задержки транзакций 2,1 мс. Ключевой эффект для SQL Server - высокая производительность на лицензируемое ядро - 32 800 TPM на ядро при энергопотреблении в установившемся режиме 540 Вт.

Вариант B - акцент на суммарную пропускную способность. Используется EPYC 9965 с высоким числом ядер, 3,0 TB DDR5 и та же NVMe-конфигурация и сеть. Здесь достигается 2 850 000 TPM, но хвостовая задержка p95 выше - 3,4 мс, а показатель на лицензируемое ядро ниже - 14 800 TPM на ядро. Энергопотребление в установившемся режиме также выше - 880 Вт. При этом скорость резервного копирования в тесте выше - 9,1 GB-с против 7,2 GB-с у варианта A.

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

Отдельно показателен пример “универсальной” высокоплотной конфигурации под смешанные нагрузки - сервер с 2 x 64-ядерными EPYC 9575F на 3,3 ГГц, 128 физических ядер и 256 логических потоков, 6,4 TB DDR5 и 12 NVMe SSD по 3,2 TB. Такой профиль обычно выбирается, когда одновременно нужны большая ёмкость памяти, быстрые рабочие наборы на NVMe и запас по параллельности для аналитики и сервисных операций.

Обзор современных серверов на базе AMD EPYC 4 и 5 поколений

Современные серверы на базе AMD EPYC 4 и 5 поколений дают широкий выбор по форм-фактору и масштабированию - от компактных 1U систем с одним процессором до 2U конфигураций с двумя процессорами, максимальным объёмом памяти и высокой плотностью накопителей. Для задач баз данных, аналитики и виртуализации обычно важны три параметра - сколько памяти можно установить, насколько плотной может быть подсистема хранения и какие варианты расширения доступны под быстрые накопители и сеть. Ниже приведены типовые линейки серверов HPE, Lenovo и Dell с поддержкой EPYC 9004 и 9005 - в разрезе конфигураций, памяти и вариантов установки дисков.

HPE ProLiant Gen11 - конфигурации на AMD EPYC под базы данных

Lenovo ThinkSystem V3 - конфигурации на AMD EPYC под базы данных

Dell PowerEdge - конфигурации на AMD EPYC под базы данных

Выбор производителя в этой линейке обычно определяется не “кто быстрее”, а тем, какой профиль эксплуатации важнее - у HPE сильная ставка на встроенную безопасность и управляемость, у Lenovo часто выигрывает гибкость конфигураций и плотность вариантов под разные форм-факторы, у Dell сильная сторона в широте модельного ряда PowerEdge и большом выборе опций под хранение и расширение. Отдельный фактор - корпоративные стандарты: наличие внутреннего склада запасных частей, отлаженные процедуры замены узлов и компетенции системных администраторов под конкретного производителя нередко дают больший эффект для доступности и скорости восстановления, чем разница в характеристиках. Практичный подход - зафиксировать требования по памяти, плотности NVMe и сети, затем отобрать 1–2 подходящие модели у каждого производителя и сравнить их по доступности нужных опций, совместимости с внутренними стандартами и целевой конфигурации под конкретную задачу.

Как понять, что модернизация сервера баз данных необходима

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

Первый сигнал - экономика перестаёт сходиться. Когда парк серверов разрастается из-за разрозненных виртуальных машин, затраты на лицензии и поддержку начинают расти быстрее, чем нагрузка. В таких ситуациях выигрывает консолидация на современных процессорах, где можно получить больше результата на лицензируемое ядро - за счёт более быстрых ядер там, где важны транзакции, и за счёт масштабирования по числу ядер там, где важна аналитика. Правильно подобранный объём памяти позволяет удерживать SLA без “перестраховки” железом, а значит снижать и программные, и аппаратные расходы.

Второй сигнал - “плывёт” производительность на критичных нагрузках. Для транзакционных систем решающим фактором становится не средняя скорость, а задержки p95-p99. Если в пике появляются провалы времени ответа, а причины регулярно упираются в память или дисковую подсистему, платформа уже работает на пределе. Современные конфигурации с крупными кэшами процессора, высокой пропускной способностью DDR5 и NVMe на PCIe Gen5 помогают убрать узкие места по хранению и стабилизировать поведение как для одиночных потоков, так и для параллельного выполнения. Отдельно это заметно в операциях резервного копирования и восстановления - когда окна перестают укладываться в требования бизнеса, модернизация становится вопросом управляемого риска.

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

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

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

Наконец, отдельным фактором становится энергоэффективность и плотность размещения. Когда питание и охлаждение ограничивают развитие, а рост нагрузки требует всё больше серверов, модернизация даёт выигрыш “на ватт” и позволяет удерживать рост потребления и занимаемого места под контролем.

Успешное внедрение в 2025 году - кластер на AMD EPYC 9275F для 1С ERP и MS SQL в финансовой компании

Финансовая компания эксплуатировала специализированную 1С ERP в связке с MS SQL - тяжёлая транзакционная база, высокая параллельность и регулярная отчётность. В пиковые периоды одновременная работа пользователей и запуск отчётов приводили к просадкам отклика - вплоть до ситуации, когда один сложный запрос ухудшал работу всей системы. Для такого профиля критична не только суммарная производительность, но и стабильная задержка на уровне процессора и дисковой подсистемы - при росте задержек хранения транзакции начинают ждать ввод-вывод, увеличиваются блокировки и деградация развивается лавинообразно.

Чтобы зафиксировать причины измерениями, был проведён независимый аудит производительности по методике Гилёва и контрольный прогон нагрузочного теста - он подтвердил, что текущая платформа не обеспечивает требуемую предсказуемость и запас исчерпан. 

В новой архитектуре мы сделали ставку на высокочастотные серверные процессоры и NVMe-подсистему с понятной траекторией роста - выбран двухпроцессорный Dell PowerEdge R7725 на AMD EPYC 9275F, фронтальная NVMe-корзина E3.S Gen5 с запасом расширения, аппаратные RAID-контроллеры PERC13 для контролируемого поведения при отказах носителей и предсказуемого восстановления. 

Результат подтвердили тестами до ввода в продуктив - устранены просадки отзывчивости на пиках, снизился риск «лавинной» деградации, появился запас по масштабированию NVMe без смены класса оборудования.

Полное описание проекта с архитектурой, составом оборудования и результатами тестирования приведено в отдельном материале.

Заключение

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

В качестве современной опоры отлично подходят серверы на базе AMD EPYC 5-го поколения - с высокой пропускной способностью DDR5, подсистемой NVMe на PCIe Gen5 и встроенной безопасностью, опирающейся на аппаратную цепочку доверия. Такая конфигурация позволяет удерживать предсказуемую производительность как для OLTP, так и для аналитики и смешанных нагрузок. Если дополнить это автоматизацией жизненного цикла и экспертными услугами по проектированию и внедрению, снижается риск изменений, ускоряется получение результата и упрощается эксплуатация на масштабе.

Почему стоит действовать сейчас

• Современные СУБД готовы к сценариям с искусственным интеллектом - раннее внедрение помогает быстрее использовать семантический поиск, аналитику почти в реальном времени и встроенные механизмы машинного обучения

• Экономика лицензий и поддержки стимулирует консолидацию - затраты можно заметно снизить, переходя на архитектуры с высокой отдачей на ядро

• Давление со стороны безопасности и соответствия растёт - современные платформы со встроенной основой доверия и управляемостью уменьшают риск кибер инцидентов и штрафов

• Цели по гибридным сценариям и энергоэффективности требуют обновления - выигрыш по производительности на ватт и гибкие модели потребления лучше согласуются с целями устойчивого развития и контролем затрат