Вот скажите мне, хабравчане, в чём сила? Разве в деньгах? Вот и финдиректор говорит, что в деньгах. А я вот думаю, что сила в данных: у кого данные, тот и сильней!
Техгиганты, вроде Google (Alphabet), Meta (признана экстремистской в России) и Яндекса, получают огромную прибыль с монетизации пользовательских данных; менее очевидные Spotify, OZON и т.п. тоже неплохо зарабатывают на данных и рекламе. Банки каждую секунду проводят сотни тысяч транзакций, небольшие интернет-магазины собирают кучу телеметрии, а социальные сети крутят бесконечные алгоритмические фиды, чтобы вы смотрели свою персональную ленту с котиками и мемами.
Каждый клик, каждое движение мышкой, каждый свайп или тап по экрану — это запись в базе данных. И да, серверы давно умеют с этим всем работать.
И вот есть у бизнеса база данных, зачем тогда изобретать ложку для супа отдельные подходы для работы с данными в ней? Выбираешь что-то оптимальное/лучшее — и радуешься жизни.
А вот зачем
Для транзакций в реальном времени нужна одна система — OLTP (Online Transaction Processing), а для аналитики другая — OLAP (Online Analytical Processing). OLTP похож на Соника — он всегда в движении, стремительно мчится вперёд, реагирует на каждое препятствие и собирает колечки. А OLTP — отрабатывает каждую транзакцию быстро и предсказуемо. OLAP же напоминает Кирби — он втягивает в себя всё, что попадётся — горы предметов, врагов, целые миры. А OLAP поглощает массивы данных — миллионы и миллиарды строк, чтобы потом переварить их и превратить в осмысленный отчёт.
И раз сценарии настолько разные, то логично, что и архитектура серверов, СХД и даже СУБД для них тоже разные.
Вот тут-то мы и переходим к сабжу. Из этого лонгрида вы узнаете про OLAP, OLTP, а также про оборудование для них.
OLAP и OLTP — что это и зачем
Для начала чуть углубимся в технологии. Итак, у OLAP и OLTP совершенно разные цели и архитектура. Поэтому вопрос для бизнеса стоит не в выборе между ними, а в том, как грамотно совмещать их в инфраструктуре.
OLAP — это инструмент для сложного анализа больших объёмов данных. С его помощью бизнес получает полноценные аналитические выводы. Представьте продуктовую розницу: аналитический отдел собирает все данные о продажах за период из разных источников — операционных баз, внешних сервисов и других систем. Всё это отправляется в специализированное хранилище (Data Warehouse), оптимизированное под многомерный анализ.
Дальше аналитики отправляют запрос: «Сколько сливочного масла и хлеба продано в июне 2024 года по всем магазинам Центрального округа и как изменилась динамика в июне 2025-го, а также как зависимость между этими продуктами?». Такой запрос требует агрегировать миллионы строк, отфильтровать данные по регионам, категориям и датам, а потом ещё вычислить зависимости, изменения и построить прогноз. Выполняться он может долго (в пределах разумного) — и это нормально, ведь на результате будут принимать бизнес-решения и строить стратегию развития.
В OLAP важнее полнота и точность анализ��, чем мгновенный отклик, поэтому стратегическая аналитика (например, годовые отчёты или долгосрочные прогнозы) может длиться 1–2 часа. Другой вопрос, когда оперативная аналитика для ежедневных решений (например, изменение цен) длится часами — это уже из-за нерелевантной инфраструктуры.
Ремарка! Аналитики чаще всего работают через BI-системы (Business Intelligence, не путать с BIM), вроде Power BI, Tableau, Qlik, Looker, Apache Superset (довольно популярен при импортозамещении) и т.п., где интерфейс позволяет строить визуальные запросы, дашборды и отчёты без глубокого знания SQL. |
В основе OLAP лежат многомерные массивы (кубы), которые позволяют смотреть на данные под разными углами — по времени, регионам, товарам, клиентам и десяткам других параметров. Это идеальный инструмент для стратегической аналитики. В отличие, например, от CRM: там главная задача — оперативное управление клиентами и транзакциями, а не сложные выборки из терабайтной истории продаж.
Классические инструменты: ClickHouse (особенно популярен в России), Greenplum, Hadoop/Spark, Amazon Redshift. Они заточены под массовую обработку и параллелизм.
OLTP — наоборот, технология, заточенная под скорость обработки единичных операций. На кассе в супермаркете каждая транзакция (пробили товар, приняли оплату, сохранили запись) должна происходить моментально. Любая задержка — очередь растёт и/или люди уходят. Покупатель не станет ждать по 3 минуты на каждый товар, чтобы пробить масло и хлеб. OLTP-системы оптимизированы именно под такие быстрые, частые операции в реальном времени. Но использовать их для стратегической аналитики почти бессмысленно — сложные запросы на огромных базах данных они просто не потянут.
Типичные СУБД: PostgreSQL, MySQL/InnoDB, Oracle Database, Microsoft SQL Server.
Есть и гибридные решения — HTAP (Hybrid Transactional/Analytical Processing), где в одной системе пытаются совмещать транзакции и аналитику (например, TiDB, YugabyteDB). Но чаще на практике компании разделяют нагрузки: одна база отвечает за быструю работу, другая — за аналитику.
Примеры: TiDB, SAP HANA, YugabyteDB. Но за удобство придётся платит�� сложностью инфраструктуры и более высокими требованиями к железу.
И вот тут-то у IT-архитектора, админа или любого другого ответственного возникают вопросики. Какой сервер выбрать под OLAP, а какой под OLTP? Это должны быть два разных сервера? Или лучше виртуалки? Или вообще кластер нужен? А может, связка вычислительных узлов и отдельного хранилища? А сколько тогда СХД? А если их несколько, то active-active или active-standby? И ещё сотня-другая нюансов.
И от этих нюансов зависит бизнес. К сожалению на всё ответить я не смогу (задачи-то у всех разные), но постараюсь дать вам полезные ориентиры. Ну и комментарии всегда открыты для вопросов :)
Как выбрать сервер и СХД для OLTP и OLAP
Подбор серверов для OLTP и OLAP — это разные задачи. И ошибка тут обходится дорого. Поставите медленные накопители под OLTP — получите очередь запросов и недовольных клиентов. Попробуете запустить OLAP на нерелевантном сервере — будете смотреть, как запросы обрабатываются неделями. Сэкономите на резервировании данных и компонентов… ну вы поняли.
В мире высоконагруженных баз данных производительность и надёжность в прямой зависимости от архитектуры и железа. Но прежде, чем закупать оборудование, надо решить вопросы с архитектурой. Начнём с OLTP.
Архитектура OLTP — скорость и предсказуемость
OLTP-системы — это боевая часть бизнеса. На ней работают интернет-банкинг, платёжные шлюзы и интернет-магазины. К этим системам довольно чёткие требования: десятки и сотни тысяч транзакций в секунду, строгие SLA по времени отклика (миллисекунды) и целостность данных — потеря одной записи о переводе равна потере денег.
В основе любой транзакционной системы лежат требования ACID (Atomicity, Consistency, Isolation, Durability — атомарность, согласованность, изоляция, надёжность). Проще говоря:
Транзакция выполняется целиком или не выполняется вовсе (Atomicity),
Данные остаются в согласованном состоянии (Consistency),
Параллельные операции не мешают друг другу (Isolation),
Данные не теряются даже при сбое (Durability).
IT-архитектор, глядя на такую систему, сначала думает не о железе, в первую очередь его интересует, как нормализовать данные, чтобы транзакции оставались быстрыми и согласованными; как распределить нагрузку по кластерам через шардинг (разделение данных по нескольким серверами, то есть шардам) и репликацию; как организовать отказоустойчивость, чтобы падение одной или сразу нескольких нод не сломало всю систему.
В таблице ниже я собрал основные архитектурные особенности для проектирования OLTP-систем.
Технология / подход | Как работает | Плюсы | Минусы | Когда применять |
Все узлы обращаются к одному общему хранилищу (SAN/NAS/RAID. Координация транзакций идёт через СУБД. Пример: Oracle RAC. Российский аналог: Tantum (от компании "Росплатформа"). | + Единая база, не нужно шардировать данные вручную. + Удобство администрирования (одна логическая БД). + Автоматический баланс запросов по узлам. | – Очень дорого. – Требует специализированного оборудования. – Масштабирование упирается в СХД и блокировки на уровне базы. – Сложная поддержка. | Когда критична консистентность и отказоустойчивость, а бюджет позволяет (банковские системы, биллинг крупных операторов). | |
Shared-nothing (SN) / Шардирование | Каждый узел хранит только свою часть данных, транзакции обслуживаются локально. Связь между узлами только по сети. Примеры: Cassandra, CockroachDB. Российские: Yandex Database (YDB), Arenadata DB, Postgres Pro Patroni-кластеры). | + Масштабирование почти линейное: добавляешь узлы — растёт производительность. + Нет единой точки отказа в виде СХД. + Гибкость при росте данных. | – Сложность проектирования шардирования (как делить данные?). – Трудные глобальные транзакции и JOIN’ы. – Нужна логика маршрутизации запросов. | Интернет-сервисы с огромным числом пользователей: соцсети, маркетплейсы, онлайн-игры. |
Кластеризация и репликация | Данные копируются между нодами (синхронно или асинхронно). Используется для отказоустойчивости и/или распределения нагрузки. Примеры: PostgreSQL streaming replication, MySQL Galera Cluster, MongoDB ReplicaSet. Российский: Tarantool Data Grid для аналитических нагрузок. | + Высокая доступность. + Операции чтения и поиска можно распределять по репликам. + Failover при падении узла. | – Репликация не ускоряет записи (даже может замедлять). – Возможна задержка между мастером и репликами (лаг репликации). – Сложности при конфликтных транзакциях (особенно в multimaster). | Когда критична доступность и нужна высокая скорость чтения. |
Кэширование | Горячие данные выносятся в оперативную память. Чтение идёт из кэша, запись — в БД. Примеры: Redis, Memcached. Российские: Tarantool, Arenadata Grid (часто используют вместо Redis) | + Снимает до 70–80% нагрузки с базы. + Очень быстро (данные в памяти). + Простая интеграция. | – Данные в кэше могут устаревать. – Нужна стратегия инвалидации (удаление данных из кэша или присвоение недействительного статуса). – Отдельный слой инфраструктуры. | Когда нагрузка на чтение намного выше, чем на запись (интернет-магазины, рекомендательные сервисы, API). |
In-memory базы | Данные целиком или частично хранятся в памяти, диски используются только для сохранности. Примеры: SAP HANA, VoltDB Российские: Tarantool, Postgres Pro с in-memory-расширениями. | + Максимальная скорость транзакций. + Подходит для real-time аналитики + OLTP. | – Очень дорого. – Требует много оперативной памяти. – Сложнее администрировать. | Высокочастотный трейдинг, телеком, IoT с миллионами событий в секунду. |
Микросервисная архитектура (это скорее инфраструктурные паттерны, а не чисто базы данных) | Логика разделена на независимые сервисы, общаются по API. Используются любые стеки, чаще всего — Kubernetes (K8s), OpenShift + можно Astra Linux и отечественные СУБД. | + Масштабируемость. + Независимые команды разработки. + Гибкость технологий. | – Сложное взаимодействие. – Рост накладных расходов. | Крупные проекты с быстрым развитием и высокими требованиями к масштабируемости. |
Брокеры сообщений | Асинхронная передача сообщений между сервисами. Пример: Kafka, RabbitMQ. Российские: Red Soft Message Broker (разработка на основе Apache Kafka), Tarantool Queue, а также решения на базе NATS. | + Разгрузка БД и сервисов. + Гибкость технологий. | – Сложнее отлаживать. – Задержки обработки. | При пиковых нагрузках и высокой интеграции сервисов. |
Вывод какой. Если важна простота, а нагрузка предвидится средняя, то оптимальный вариант — сочетание репликации и кэширования, например PostgreSQL или MySQL с Redis. Когда объём данных растёт, нагрузка увеличивается линейно, а строгая консистентность всей системы не критична, стоит лучше выбирать архитектуру shared-nothing с шардированием. Если же самое важное — строгая согласованность данных (и бюджет позволяет), то выбирайте shared-disk решения, вроде Oracle RAC или Tantum. Для систем с экстремально высокой скоростью обработки или realtime-аналитики я бы рассматривал in-memory базы.
Архитектура OLAP — масштаб и глубина
Если OLTP — это боевая часть бизнеса, то OLAP — штаб стратегического планирования. Здесь работают бизнес-аналитики, дата-сайентисты и менеджеры, которым нужна картина целиком. Запросы здесь идут по сотням гигабайт, а иногда и терабайтам данных, с множеством агрегаций и срезов. Важна не столько целостность каждой отдельной транзакции, сколько возможность получать достоверную аналитику пакетами. Архитектор, проектируя OLAP-систему, закладывает денормализованные схемы наподобие звезды или снежинки, чтобы запросы не вязли в бесконечных джойнах (от англ. JOIN — количество операций соединения).
Он выбирает колоночные базы данных (Columnar Databases) и многомерные хранилища (те самые кубы данных), которые позволяют сканировать огромные массивы быстрее. Добавляет кэширование и уровни агрегации (например, вместо пересчета продаж за месяц для каждого запроса система может хранить готовые итоги по месяцам, регионам или товарам), чтобы аналитик получал отчёты быстрее.
В таблице ниже я собрал основные архитектурные особенности для проектирования OLAP-систем.
Архитектура / подход | Как работает | Плюсы | Минусы | Когда применять |
Shared-disk | Все узлы работают с одним общим хранилищем (обычно SAN/NAS). | + Единая база, нет ручного шардирования. + Простота администрирования. | – Масштабирование ограничено производительностью СХД. – Дорого. – Узкое место на уровне блокировок и сети. | Подходит для небольших аналитических систем или когда уже есть shared-disk инфраструктура. |
Shared-nothing | Каждый узел хранит и обрабатывает только свою часть данных. Общение между узлами — через сеть. | + Почти линейное масштабирование. + Нет единой точки отказа в виде СХД. + Гибкость при росте данных. | – Сложность проектирования схемы шардирования. – JOIN’ы между узлами дороги по времени. – Балансировка нагрузки требует опыта. | Большие хранилища данных, BI-системы, отчётность по терабайтам/петабайтам данных. |
MPP-системы (Massively Parallel Processing) | Развитие shared-nothing: данные нарезаются на сегменты, узлы обрабатывают их параллельно, результаты агрегируются. Примеры: Snowflake, Teradata. Аналоги: Greenplum (форк PostgreSQL), ClickHouse, YDB. | + Массовый параллелизм даёт высокую скорость на больших данных. + Отлично подходит для терабайтной и даже петабайтной аналитики. + Почти линейное масштабирование. | – Высокая стоимость. – Сложность администрирования – Требует грамотного проектирования запросов. | Когда нужны сложные аналитические запросы на очень больших данных: телеком, e-commerce, реклама. |
Колоночные базы данных | Данные хранятся по колонкам, а не по строкам, что ускоряет агрегации Примеры: Vertica, Amazon Redshift. Аналоги: ClickHouse. | + Запросы с агрегацией и фильтрацией работают быстрее. + Отлично сжимает данные. + Экономия диска. + Масштабируемость. | – Медленно для OLTP-нагрузки (много вставок/апдейтов). – Сложнее администрировать, чем классические БД. | Для аналитики, где важны агрегации и сканы по большим объёмам, BI-платформы, дашборды. |
Data Lake / Lakehouse | Хранилище сырых данных в любом формате (JSON, CSV, Parquet), а аналитика поверх — через движки. Примеры: Presto, Trino, Spark, Databricks. Аналоги: Yandex Data Lake, ClickHouse с Lakehouse-расширениями. | + Гибкость — можно хранить всё подряд. + Масштабируется почти бесконечно. + Дешевле хранения в классических DW. | – Медленнее, чем MPP/колоночные базы без спец. движков. – Нет строгой консистентности. – Сложность в управлении метаданными. | Для хранения огромных объёмов данных на потом: обработка логов, IoT-данные, аналитика на сырых данных. |
ETL/ELT-пайплайны | Данные загружаются из разных источников, очищаются и трансформируются. Примеры: Apache Airflow, DBT (Data Build Tool). Аналог: Arenadata Airflow (форк апача), Modus ETL. | + Единый источник истины (single source of truth, SSOT). + Автоматизация процессов. + Контроль качества данных. | – Требует сложной инфраструктуры. – Высокая стоимость поддержки. | Когда источников данных много, и нужна консолидация. |
OLAP-кубы (многомерные хранилища) | Данные агрегируются в виде кубов по измерениям (время, продукт, регион). Примеры: Microsoft Analysis Services (MS SSAS), Tableau, Qlik, Power BI. Аналоги: ClickHouse, PostgreSQL, Alpha OLAP. | + Быстрый доступ к агрегированным данным. + Удобство для аналитиков. | – Сложность ETL. – Взрывной рост данных при большом числе измерений. | Системы, где важны отчёты в разрезах (финансы, ритейл, логистика). |
Схема «звезда» и «снежинка» | Денормализованная модель: факты + измерения. Таблицы строятся не по строгим правилам (1NF, 2NF, 3NF), а раздуваются так, чтобы уменьшить количество соединений (JOIN’ов) при запросах. | + Упрощает и ускоряет запросы. + Оптимизация для BI. + Хорошо ложится в кубы. | – Дублирование данных. – Возможны ошибки при ETL. | Хранилища данных для анализа продаж, логов, метрик. |
Pre-aggregation / Materialized Views | Хранение заранее подсчитанных итогов (по времени, регионам и т. д.) | + Быстрые ответы на частые запросы. + Снижение нагрузки. | – Дополнительное место. – Нужно обновлять заранее подсчитанные итоги. | Подходит, если аналитика строится вокруг однотипных отчётов. |
Итак, если данных много и нужны тяжёлые аналитические запросы — лучше всего shared-nothing / MPP. Для сценариев с потоковыми данными, логами, IoT и другими big data решениями лучше подходят lakehouse или data lake. Если же система небольшая и важна простота, можно использовать и shared-disk, хотя такое встречается редко.
HTAP — третий путь
Поскольку бизнесу нужно и то, и другое, — транзакции в реальном времени и одновременно аналитика — появились гибридные системы HTAP (Hybrid Transactional/Analytical Processing).
HTAP можно рассматривать как объединение обоих подходов в одном решении. Нагрузка у него смешанная: рядом со множеством мелких операций выполняются и достаточно тяжёлые аналитические запросы. Масштабирование в HTAP зависит от конкретной реализации: где-то сильнее выражена транзакционная часть, где-то аналитическая. Инфраструктура тоже различается. Классический OLTP строится вокруг СУБД с кэшированием и репликацией, OLAP предполагает отдельное хранилище или MPP-кластер, а вот HTAP объединяет эти функции в одной системе или в связке движков. Но это всегда компромисс. Аналитика будет не такой быстрой, как в чистых MPP, а транзакции не так надёжны, как в традиционных OLTP.
HTAP — это ехидна Наклз из вселенной Соника. Умеет и быстро бегать, и мощно рыть землю, совмещая в себе быстроту Соника (OLTP) и мощь (OLAP). При этом Наклз не так быстр, как Соник, но и самым сильным его тоже не назвать.
Архитектура / подход | Как работает | Плюсы | Минусы | Когда применять |
HTAP (гибрид OLTP+OLAP) | В одной системе совмещаются транзакционная и аналитическая нагрузка. Обычно реализуется через разделение хранилищ (строковое для транзакций, колоночное для аналитики) или через отдельные движки под капотом. Примеры: SAP HANA, TiDB, PostgreSQL+Timescale, SingleStore. | + Нет необходимости строить отдельный OLAP-кластер + быстрая аналитика вместе с транзакциями. + Удобно для real-time дашбордов и триггеров. + Меньше инфраструктуры, чем у связки из отдельных OLTP и OLAP. | – Сложнее в администрировании, чем классический OLTP. – Обычно уступает специализированным OLAP-системам по скорости тяжёлых запросов. – Дороже лицензии (в случае SAP HANA и аналогов). – Не все сценарии одинаково поддерживаются (некоторые движки сильнее в OLTP, другие — в OLAP). | Аналитика в реальном времени и транзакции на одном стеке: финтех (мгновенное выявление мошенничества), онлайн-игры (аналитика поведения игроков), IoT (обработка событий в реальном времени), e-commerce (рекомендации прямо здесь). |
Какие выводы? Если у вас классический интернет-магазин или просто CRM в компании, достаточно связки OLTP с периодической выгрузкой данных в OLAP, и HTAP будет избыточен. Когда же требуется аналитика здесь и сейчас — например, в финансах, системах безопасности, онлайн-играх или IoT — HTAP позволяет объединить два стека в одной системе. Если же речь идёт о действительно огромных объёмах данных (петабайты), HTAP не справится, и лучше оставлять отдельные OLTP и OLAP. Главная фича HTAP в том, что он сокращает количество оборудования, но дороже и сложнее администрируется.
От архитектуры к железу: основные принципы конфигурирования
И наконец пора поговорить про железо. Во-первых, нужен баланс и конфигурация под задачу. Частая ошибка при проектировании OLTP или OLAP (да и вообще любых серверов) — вкладывать всё в одно звено (например, топовые процессоры или NVMe-хранилище). Когда упор делают на что-то одно, нередко душат систему в другом месте, создавая бутылочное горлышко (например, узкий канал, мало памяти, слабый RAID-контроллер без кэша). Конфигурация должна быть гармоничной, учитывать все комплектующие без перекосов: CPU—RAM—накопители—сеть.
Процессоры (CPU)
Для OLTP главный ориентир — высокая частота и IPC (instructions per cycle, инструкции за такт), а также минимальные задержки в цепочке CPU—память—NVMe (то есть желательна быстрая шина PCIe 5.0 и DDR5 4800+ МГц). Такое комбо позволяет очень быстро обрабатывать одиночные транзакции.
Но современным инфраструктурам часто нужно и ядер побольше — поэтому CPU лучше выбирать с балансом частоты и количества ядер/потоков. Можно подобрать что-то из Intel Xeon Scalable 4-го (Sapphire Rapids) и 5-го (Emerald Rapids) поколений, а также Xeon 6 (линейки Sierra Forest — E-core и Granite Rapids — P-core) и AMD EPYC 7003/8004/9004/9005.
Для OLTP часто хватает 1–2 сокетов на узел; жёстких требований к 2 сокетам нет — мощные EPYC тоже вывозят серьёзные нагрузки.
Смотрим на цену за ядро, пиковую частоту и — в идеале — на поддержку памяти DDR5 и PCIe 5.0 (серверная база тоже должна работать с этим), хотя при ограниченном бюджете можно выбрать DDR4 и PCIe 4.0 (или если у вас не миллионы транзакций в секунду).
Для OLAP (например, агрегация больших датасетов, сложные SQL-запросы, параллельная обработка) в приоритете количество ядер и пропускная способность памяти, так как многие движки оптимизированы для параллелизма.
Ремарка! При выборе процессора нужно смотреть не только на количество ядер, но и и на топологию NUMA (Non-Uniform Memory Access). Чем больше в системе независимых NUMA-узлов (каждый из которых объединяет локальные ядра и память), тем выше риск возникновения межсокетных задержек. Когда ядро из одного NUMA-узла запрашивает данные, физически находящиеся в памяти другого узла, доступ к ним происходит намного медленнее — через межсокетную шину (например, Intel UPI или AMD Infinity Fabric). В итоге сервер c де-факто менее производительным процессором, но с одной NUMA-зоной (например, односокетный AMD EPYC с монолитным дизайном), зачастую выигрывает по стабильности и производительности в приложениях, чувствительных к задержкам (например, СУБД или виртуализация), у многосокетных систем с сотнями ядер. Поэтому для критичных к задержках задач лучше конфигурации с меньшим количеством NUMA-узлов, но с быстрой локальной памятью внутри каждого. |
AMD EPYC по плотности ядер выигрывает, но некоторые OLAP-движки (например, Microsoft SQL Server, SAP HANA) исторически лучше оптимизированы под Intel из-за инструкций (AVX-512) и тесной интеграции (хотя для новых AMD EPYC 4 и 5 поколений уже неактуально). Ну и конечно для OLAP нужен многопроцессорный сервер — два и более CPU. Начинайте с 16-24 ядер на сокет, а для крупных систем можно смотреть на 64+ ядер на сокет(!).
Память (RAM)
Для OLTP объём памяти должен покрывать все горячие данные + буферы индексов — если возможно, — так как это резко снижает задержки I/O (даже самый быстрый NVMe-диск во много раз медленнее оперативки). У некоторых СУБД (например, PostgreSQL с правильным тюнингом) кэш работает крайне эффективно. Вы же не хотите, чтобы система постоянно подкачивала данные из медленного хранилища?
Для среднего интернет-магазина стартовый ориентир — от 64 ГБ, но лучше 128–512 ГБ на ноду (точнее можно сказать если взглянуть на вашу задачу); для серьёзных платёжных систем — это 512 ГБ–1 ТБ и выше. Если бюджет ограничен, не урезайте память под горячие данные и индексы — лучше взять не такой мощный CPU или NVMe-хранилище поменьше/помедленнее.
В OLAP акценты другие — память нужна не для того, чтобы держать все горячие данные, а для того, чтобы максимально эффективно работать с большими выборками, сортировками и джойнами. Поэтому чем больше памяти, тем лучше: 256 ГБ и выше на узел для начальных MPP-кластеров; для тяжелой аналитики — уже 1–4 ТБ на узел. OLAP часто работает с большими объёмами данных, которые частично или полностью загружаются в RAM (in-memory аналитика).
Но важен не только объём, но и пропускная способность памяти. При аналитических нагрузках именно скорость чтения и агрегации больших таблиц чаще всего становится узким местом, а не частота CPU. Поэтому многоканальная архитектура памяти критична. Например, AMD EPYC (Genoa, 9004) поддерживает до 12 каналов DDR5, что при модулях DDR5-4800 даёт 460–480 ГБ/с на сокет (ещё выше при DDR5-5200/5600). Intel Xeon Scalable четвёртого поколения (Sapphire Rapids) работают с 8 каналами DDR5-4800 (~300–350 ГБ/с), а пятое и шестое поколение ещё быстрее.
Большой L3-кэш и аккуратная NUMA-настройка тоже в плюс — если задачи бегают между CPU, часть прироста от памяти просто теряется из-за межпроцессорного взаимодействия. У стандартных EPYC 9004 — сотни мегабайт кэша L3; а у версий с 3D V-Cache — уже 1152 МБ на сокет (96 МБ на кристалл).
Хранилище (Storage)
NVMe — стандарт для OLTP и OLAP; SATA/SAS SSD постепенно уходят на периферию.
Для OLTP (например, базы данных для интернет-магазинов, платежных систем, CRM) приоритет — низкие задержки и высокая производительность на случайных операциях ввода-вывода (IOPS), так как транзакции требуют быстрого чтения/записи небольших блоков данных (4-16 КБ). Желательно организовать RAID 1/10. Про RAID 5 вообще забываем, так как пятый даёт ощутимый штраф на запись по задержкам (особенно при активных транзакциях, а при деградации вообще начинает шевелиться как снулая рыба — примерно никак). Если бюджет ограничен, лучше уж RAID 6, но при 4 дисках его полезный объём фактически равен RAID 10. Поэтому для боевых баз стандартный выбор остаётся тем же — зеркала или RAID 10.
Выбирайте NVMe (PCIe 4.0/5.0) для низких задержек и высоких IOPS. Для среднего интернет-магазина хватит 1-4 ТБ (2-4x NVMe/SATA SSD). Для платежных систем — 4-16 ТБ. И не экономьте на скорости хранилища.
Для OLAP (аналитика больших данных, data warehouse, например, ClickHouse, Snowflake) приоритет — высокая ёмкость и пропускная способность последовательного чтения/записи, так как запросы работают с большими наборами данных (гигабайты-терабайты). Задержки не так критичны, как в OLTP, но важны объём хранилища, скорость обработки больших блоков данных, скоростная шина (PCIe 5.0) и контроллеры. Для экономии можно сочетать NVMe (1-4 ТБ для горячих данных) и HDD (10-40 ТБ для холодных). HDD более чем актуальны для этого.
Начальный MPP-кластер требует 8-32 ТБ на узел (2x 1.92 ТБ NVMe + 4x 4 ТБ HDD), нагрузки посерьёзнее — 32-100 ТБ. Используйте RAID 6 или ZFS (или аналоги). В продакшене для больших кусков аналитики часто используют ZFS с кэшем на NVMe, чтобы не жертвовать скоростью при хранении больших массивов. Для shared-disk/SAN берите быстрые NVMe СХД с поддержкой NVMe-oF и высокоскоростными FC/NVMe-RDMA (да, стоимость будет космической, но для хайэнд сегмента это эффективно, особенно если нужен единый массив для кластера из десятков нод). Но в большинстве случае�� проще и дешевле держать локальное хранилище + репликацию.
Сеть (Network)
Сеть — ключевой элемент любых высоконагруженных систем, связывающий серверы, хранилища и клиентов. Сразу отмечу, что один коммутатор со схемой звезды — это тупик для кластера. Нужна leaf-spine архитектура с низкой задержкой линков.
Leaf-spine архитектура — это сетевая топология для дата-центров, где leaf-коммутаторы держат серверы, а магистральные коммутаторы (spine) связывают leaf между собой. Это даёт высокую пропускную способность (10–100 Гбит/с и выше), низкие задержки и масштабируемость за счёт полного соединения всех leaf с каждым spine. Эта архитектура идеальна для OLTP и OLAP, так как минимизирует конкуренцию за канал и ускоряет обмен данными.
Для OLTP (интернет-магазины, финансы) важны низкие задержки и стабильность, чтобы приложение быстро отвечало пользователю. Медленная или перегруженная сеть тормозит даже быструю базу данных. Для старта хватит 10 Гбит/с для связи между серверами, кэшами и бэкендами. Многие интернет-магазины и CRM до сих пор живут на этой скорости и не страдают. В крупных же проектах (финансы, телеком) с упором на минимальный пинг лучше использовать 25/40/100/200/400 Гбит/с. Отказоустойчивость обязательна: настройте LACP (Link Aggregation Control Protocol), используйте два независимых коммутатора и сетевых канала, чтобы избежать простоев. В продакшене даже полчаса простоя сети может стоить дороже, чем апгрейд IT-инфраструктуры до дублированной схемы.
Для OLAP (аналитика, MPP-кластеры) важна высокая пропускная способность сети, так как узлы обмениваются большими объёмами данных при распределенных запросах. Медленная сеть сводит на нет мощность процессоров и памяти. Минимально — 40–100 Гбит/с на узел. На 10 Гбит/c можно разве что демо поднять, но не реальную аналитику. Технологии, вроде RoCE (RDMA over Converged Ethernet), ускоряют передачу данных, обходя процессор, что критично для in-memory аналитики, где скорость сети должна быть близка к скорости RAM.
Но есть одно но. RoCE требует очень аккуратной настройки lossless Ethernet (PFC, ECN). Иногда проще поставить InfiniBand. Берите свитчи с низкими задержками и стройте leaf-spine.
Ещё важно сказать про SmartNIC/DPU и ускорители — первые берут на себя фильтрацию трафика, шифрование, NVMe-oF/RDMA, разгружая CPU и стабилизируя задержки.
Если в проекте есть GPU/FPGA под AI/аналитику — заранее планируйте PCIe-слоты, линии и охлаждение. Несколько таких карт могут быстро превратить стойку в печку.
Конкретные серверы, которые можно выбрать
Начну с самых бюджетных вариантов на Xeon Scalable 2-го поколения. В целом процессоры верхнего сегмента из этой линейки всё ещё неплохо справляются с задачами для среднего бизнеса, но при этом восстановленные серверы стоят недорого.
Я бы рассматривал для самого начального уровня двухсокетные серверы Dell PowerEdge T440 (Tower) и HPE ProLiant DL360 Gen10 (1U Rack). Либо можно посмотреть на ассортимент Supermicro/Lenovo, выйдет немного дешевле. Если же бюджет позволяет, то лучше выбрать серверы поновее — R450 (Rack) и DL360 Gen10 Plus, там уже и шина PCIe 4.0, и Scalable 3.
Если же смотреть на что-то современное, то у Dell в линейке PowerEdge сейчас актуальны 16-е и 17-е поколения: PowerEdge R760 (16-е поколение) как универсальная платформа для тяжёлых по вычислениям и хранению задач, и R770 (17-е поколение) как более свежая платформа с упором на память, поддержку Intel Xeon 6/AMD EPYC 5 и расширенные NVMe-возможности.
Эти серверы удобны и для OLTP (в конфигурации с быстрыми NVMe и большом обёмом памяти), и для узлов OLAP при увеличении количества ядер и хранилища.
Ещё варианты серверов под специфические задачи:
Dell PowerEdge XE8712
Сервер для AI/HPC с NVIDIA GB200 (Grace CPU + GPU) — для сверхтяжёлых аналитических и AI-задач, где важна GPU-обработка.Dell PowerEdge XE9780 / XE9785 (или постарше —XE9680)
2U/4U сервера с NVIDIA GB300 Blackwell GPU.
У HPE последние поколения ProLiant — Gen11 и Gen12. Главной моделью для большинства задач остаётся ProLiant DL380 Gen11 — гибкий двухсокетный сервер, который прекрасно масштабируется по памяти и накопителям. Gen12 нацелен на более плотные AI/GPU-конфигурации и поддержку новых процессоров.
Либо можно посмотреть на DL325 и DL345 — они поддерживают 5-е поколение AMD EPYC, до 6 ТБ RAM — вдвое больше, чем предыдущие поколения, — и AI-управление через Compute Ops Management. Отлично подходят под OLAP, in-memory аналитику и большие данные. Для задач, где важна плотная GPU-сборка, у HPE есть модификации DL380a Gen12 (мощный 4U-сервер, поддерживает до 8 GPU RTX PRO 6000 Blackwell — идеально для AI-нагрузок и аналитики).
Вместо выводов
Лонгрид вышел большим, но всё затронуть не получилось. Если останутся вопросы — велком в комментарии. Если на что-то ответить не хватит и моих компетенций, то уверен, что на Хабре найдутся знатоки :)
