IOPS и Throughput: выбираем правильные метрики производительности для вашей базы данных

By Mirko Peters · 2026-08-11 · Updated 2026-08-26

Когда архитекторы и администраторы баз данных начинают проектировать высокопроизводительную инфраструктуру для тяжёлых нагрузок, таких как SQL Server, они сталкиваются с лавиной технических аббревиатур и характеристик хранилищ…

Automatically translated with AI from the original post. Read the English original

Когда архитекторы и администраторы баз данных начинают проектировать высокопроизводительную инфраструктуру для тяжёлых нагрузок, таких как SQL Server, их встречает лавина технических аббревиатур и спецификаций хранилищ. Среди самых важных, но часто неправильно понимаемых метрик — IOPS и throughput. Выбор не той метрики при подборе хранилища может привести к медленным запросам, узким местам в системе и напрасно потраченному бюджету. Понимание того, как база данных на самом деле читает и записывает данные, — первый шаг к созданию отказоустойчивой архитектуры.

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

Введение в метрики производительности баз данных

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

Чтобы спроектировать среду, которая не сломается под нагрузкой, сначала нужно понять особенности каждой из ваших нагрузок. Для этого следует глубоко разобраться в двух столпах производительности хранилища: Input/Output Operations Per Second (IOPS) и мегабайтах в секунду (Throughput).

Что такое IOPS: почему базы данных опираются на мелкие операции чтения и записи

IOPS расшифровывается как Input and Output Operations Per Second. Это показатель того, сколько отдельных запросов к хранилищу устройство может обработать за одну секунду. Для интенсивных платформ баз данных, таких как SQL Server, IOPS обычно является главной метрикой.

Базы данных по своей природе транзакционны. Когда пользователь входит в приложение, база данных обычно не читает и не записывает один огромный файл размером в несколько гигабайт. Вместо этого она выполняет тысячи мелких целевых операций. Она может прочитать страницу данных размером 8 КБ, чтобы получить профиль пользователя, записать несколько сотен байт в журнал транзакций или обновить индекс. Поскольку эти операции так малы, главным фактором производительности становится способность подсистемы хранения обрабатывать большое количество отдельных команд, то есть её пропускная способность в IOPS. Если вашей базе для обработки пользовательских транзакций нужно 10 000 IOPS, а диск способен выдать только 3 000, запросы начнут выстраиваться в очередь, блокировки станут каскадными, а время отклика приложения резко упадёт.

Что такое Throughput: когда важнее всего полоса пропускания

Если IOPS измеряет *количество* операций, то throughput измеряет *объём* данных, переданных за определённый период, обычно выражаемый в мегабайтах в секунду (МБ/с). Представьте IOPS как количество машин, едущих по шоссе, а throughput — как общий вес груза, который они везут.

Есть сценарии, в которых throughput важнее IOPS. Возьмём, например, ночное резервное копирование базы, масштабный импорт в хранилище данных или аналитические запросы, которые сканируют миллионы строк в таблице. Этим задачам не так важно, сколько отдельных запросов обрабатывается в секунду; для них важно, как быстро может быть загружен или выгружен непрерывный поток больших объёмов данных. Если попытаться выполнить масштабную миграцию данных на хранилище с высоким IOPS, но низким лимитом throughput, миграция займёт на несколько часов дольше ожидаемого, потому что канал передачи данных просто недостаточно широк.

Сопоставление нагрузок приложений с конфигурациями хранилища

У каждого приложения в вашей организации свой характер нагрузки на хранилище. Чтобы грамотно спроектировать среду, нужно сопоставить эти конкретные шаблоны чтения и записи с подходящей конфигурацией хранилища. Например, базе данных для обработки транзакций (OLTP) нужны высокие возможности по IOPS, чтобы обслуживать параллельные запросы пользователей без скачков задержки. И наоборот, озеро данных или сервер отчётности может потребовать высокого throughput для обработки аналитических запросов.

Проблема возникает, когда в одной среде работают несколько нагрузок с конфликтующими профилями. База данных SQL может достигать пика во время формирования финансовой отчётности в конце месяца, сервер отчётов может переживать всплеск каждое утро в 8:00, а система резервного копирования может ночью перегружать сеть трафиком. Раньше администраторы выделяли отдельные диски под каждый такой пик, что приводило к огромной избыточности ресурсов и простою мощностей.

Узкое место виртуальной машины: дело не только в дисках

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

Например, виртуальные машины Azure накладывают жёсткие лимиты на общее количество IOPS и пропускную способность диска в зависимости от размера и уровня выбранной ВМ. Можно подключить сверхбыстрые диски корпоративного класса к скромному размеру виртуальной машины, но ВМ ограничит трафик хранилища своим максимальным порогом. Система хранения может обеспечить 20 000 IOPS, но если путь через виртуальную машину ограничивает вас 10 000 IOPS, то именно это и будет потолком. Всегда проверяйте и спецификации дисков, и конфигурацию вычислительных ресурсов, чтобы убедиться, что канал между ними достаточно широк для ваших пиковых нагрузок.

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

Чтобы разорвать цикл выделения изолированных и избыточных дисков под каждую отдельную нагрузку, современные облачные архитектуры используют общие пулы хранения, напоминающие традиционные сети хранения данных (SAN). Вместо того чтобы запирать производительность внутри отдельных жёстких контейнеров, общая модель объединяет ёмкость и IOPS в единый пул.

В средах, использующих объединённые ресурсы, показатели производительности масштабируются вместе с ёмкостью. Например, в Azure Elastic SAN каждый 1 TiB базовой ёмкости вносит в центральный пул определённый объём производительности, например 5 000 IOPS и 200 МБ/с пропускной способности. Такой общий пул позволяет разным томам использовать общий бюджет производительности. Если вашей финансовой базе данных во время интенсивного формирования отчётов требуется дополнительный поток IOPS, а система складского учёта в это время простаивает, эти ресурсы могут динамически перераспределяться в пользу активной нагрузки.

Подводные камни: баланс между пиковыми нагрузками и общими лимитами

Общие пулы хранения дают впечатляющую гибкость и экономию, но они не являются волшебной палочкой для неограниченной производительности. Объединение ресурсов означает, что вы рассчитываете на статистическую вероятность того, что не все базы данных одновременно достигнут своего абсолютного пика нагрузки.

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

Заключение: выбор правильных метрик для вашей базы данных

Умение находить баланс между IOPS и пропускной способностью необходимо каждому, кто управляет интенсивными нагрузками баз данных в облаке. Точно определив, чего не хватает вашим приложениям: мелких и быстрых операций или огромной полосы пропускания для данных, вы сможете избежать дорогостоящих узких мест производительности. Кроме того, использование современных парадигм хранения, таких как общие пулы, может существенно повысить эффективность и помочь вашей инфраструктуре масштабироваться разумно вместе с ростом бизнеса. Чтобы глубже разобраться в том, как современные облачные архитектуры хранения решают именно эти задачи масштабирования и производительности, обязательно послушайте связанный выпуск подкаста: Azure Elastic SAN — Simply Explained.