Решение: определение размера сервера
Правильное определение размера начинается с профиля нагрузки (OLTP, хранилище данных, смешанная) и требует найти реальное узкое место (CPU, ввод-вывод или RAM). Золотое правило: часто используемый набор данных (working set) должен помещаться в RAM; сначала измеряйте, затем масштабируйте и оставляйте запас на внезапную нагрузку. Это дерево помогает определить нагрузку и выбрать ресурс и направление масштабирования (вертикальное/горизонтальное) по узкому месту.
Каков профиль вашей нагрузки?
Определение размера начинается с нагрузки, потому что OLTP и аналитическая нагрузка требуют совершенно разных профилей ресурсов. Что преобладает в работе системы: множество небольших быстрых транзакций (OLTP), отчётность/аналитика с большими сканированиями и агрегациями (DWH) или смесь того и другого? Если не уверены, сначала нужно измерить.
- OLTP — множество небольших коротких транзакций (веб/приложение)
- Аналитика / хранилище данных (DWH) — большие сканирования и агрегации
- Смешанная нагрузка или точно не знаю
- Я знаю узкое место; масштабировать вертикально или горизонтально?
Где узкое место: RAM, ввод-вывод или CPU?
В OLTP найдите реальное узкое место вместо того, чтобы вслепую добавлять ресурсы. Посмотрите на метрики: часто используемые данные не помещаются в RAM и много чтений с диска (RAM/ввод-вывод), недостаточны задержка/IOPS диска (ввод-вывод), или данные уже в памяти, но CPU загружен (CPU)? Масштабирование не того ресурса тратит деньги и время.
- Часто используемые данные не помещаются в RAM; много чтений с диска
- Данные в памяти, но задержка/IOPS диска недостаточны (интенсивная запись)
- Данные в памяти и с диском всё в порядке, но CPU постоянно загружен
Рекомендация: сначала измерьте, затем определяйте размер
Покупка оборудования на основе догадок почти всегда даёт неверный размер. Профиль нагрузки и узкое место выявляются из реальных метрик. Определение размера — не догадка, а итерации на основе измерений.
Рекомендация: добавьте RAM — рабочий набор (working set) должен помещаться в память
Самое важное правило OLTP: часто используемые данные и индексы (working set) должны помещаться в память (буфер/кэш). Если нет, каждый запрос идёт на диск, задержка резко растёт, а ввод-вывод становится узким местом. RAM обычно — вложение с наибольшей отдачей.
Рекомендация: усильте уровень ввода-вывода (IOPS/задержка)
Даже когда данные в памяти, при нагрузке с интенсивной записью решающей является скорость диска (commit, WAL/redo/binlog, checkpoint). Проблема здесь не в ёмкости, а в IOPS и задержке. Неверный класс дисков ставит систему на колени, несмотря на быстрые CPU/RAM.
Рекомендация: устраните узкое место CPU (сначала запросы, затем ядра)
Если CPU загружен, когда данные в памяти и с диском всё в порядке, первопричина обычно — неэффективные запросы (плохие планы, недостающие индексы, множество мелких запросов) или избыточный параллелизм. Снизить нагрузку до добавления ядер обычно дешевле и эффективнее.
Рекомендация: аналитика/DWH — пропускная способность, параллелизм и горизонтальное масштабирование
Нагрузка хранилища данных состоит из небольшого числа тяжёлых запросов, сканирующих и агрегирующих большие таблицы. Приоритет здесь — не низкая задержка, а высокая пропускная способность сканирования, параллелизм и обычно горизонтально масштабируемая архитектура.
Общий принцип: вертикальное vs горизонтальное + запас + сначала измерения
Способ масштабирования важен так же, как и выбор ресурса. Вертикальное (более мощная машина) — просто, но есть потолок и единая точка отказа; горизонтальное (больше машин) масштабируется, но добавляет сложности. В любом случае оставляйте запас на внезапную нагрузку и подтверждайте решение измерениями.