Вот скажите мне, хабравчане, в чём сила? Разве в деньгах? Вот и финдиректор говорит, что в деньгах. А я вот думаю, что сила в данных: у кого данные, тот и сильней!

Техгиганты, вроде 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 часа. Другой вопрос, когда оперативная аналитика для ежедневных решений (например, изменение цен) длится часами — это уже из-за нерелевантной инфраструктуры.

В основе 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-систем.

Вывод какой. Если важна простота, а нагрузка предвидится средняя, то оптимальный вариант — сочетание репликации и кэширования, например PostgreSQL или MySQL с Redis. Когда объём данных растёт, нагрузка увеличивается линейно, а строгая консистентность всей системы не критична, стоит лучше выбирать архитектуру shared-nothing с шардированием. Если же самое важное — строгая согласованность данных (и бюджет позволяет), то выбирайте shared-disk решения, вроде Oracle RAC или Tantum. Для систем с экстремально высокой скоростью обработки или realtime-аналитики я бы рассматривал in-memory базы.

Архитектура OLAP — масштаб и глубина

Если OLTP — это боевая часть бизнеса, то OLAP — штаб стратегического планирования. Здесь работают бизнес-аналитики, дата-сайентисты и менеджеры, которым нужна картина целиком. Запросы здесь идут по сотням гигабайт, а иногда и терабайтам данных, с множеством агрегаций и срезов. Важна не столько целостность каждой отдельной транзакции, сколько возможность получать достоверную аналитику пакетами. Архитектор, проектируя OLAP-систему, закладывает денормализованные схемы наподобие звезды или снежинки, чтобы запросы не вязли в бесконечных джойнах (от англ. JOIN — количество операций соединения).

Он выбирает колоночные базы данных (Columnar Databases) и многомерные хранилища (те самые кубы данных), которые позволяют сканировать огромные массивы быстрее. Добавляет кэширование и уровни агрегации (например, вместо пересчета продаж за месяц для каждого запроса система может хранить готовые итоги по месяцам, регионам или товарам), чтобы аналитик получал отчёты быстрее.

В таблице ниже я собрал основные архитектурные особенности для проектирования OLAP-систем.

Итак, если данных много и нужны тяжёлые аналитические запросы — лучше всего 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). При этом Наклз не так быстр, как Соник, но и самым сильным его тоже не назвать.

Какие выводы? Если у вас классический интернет-магазин или просто 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-запросы, параллельная обработка) в приоритете количество ядер и пропускная способность памяти, так как многие движки оптимизированы для параллелизма.

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-нагрузок и аналитики).

Вместо выводов

Лонгрид вышел большим, но всё затронуть не получилось. Если останутся вопросы — велком в комментарии. Если на что-то ответить не хватит и моих компетенций, то уверен, что на Хабре найдутся знатоки :)