От HDD до NVMe-oF: как менялись хранилища и почему базы снова смотрят на диск
Когда говорят о производительности базы данных, взгляд почти автоматически уходит в CPU и RAM. Это логично: процессор считает, память держит горячие данные, кэш ускоряет чтение. Но у любой базы есть момент, когда данные нужно не просто “держать рядом”, а реально записывать, читать, подтверждать транзакции и сбрасывать WAL. И именно здесь storage снова становится критичным.
Если смотреть на историю коротко, то это не музей железа, а эволюция узких мест. С каждым поколением хранилища становились быстрее, но вместе с этим менялся и характер проблем у баз данных.
От HDD к SSD: когда механика стала тормозить базы
Долгое время всё держалось на HDD. Для архивов и последовательных нагрузок этого часто хватало, но базы быстро упирались в случайные чтения и записи. Особенно болезненно это проявлялось в OLTP-сценариях, где важны короткие операции и стабильный отклик.
Переход к SSD сильно изменил картину. Storage для enterprise-нагрузок за последние полтора десятилетия фактически перестроился вокруг флеша. Но вместе с выигрышем по задержкам и IOPS стало ясно, что “SSD” — это не волшебное слово, а целый класс устройств с очень разным поведением под нагрузкой.
2011 и дальше: NVMe перестал быть просто “SSD побыстрее”
Следующей важной вехой стал NVMe. Для баз данных он оказался важен не как маркетинговый ярлык, а как более подходящая модель работы с быстрым storage, которая уменьшает лишние накладные расходы между приложением и носителем.
Дальше у рынка появился закономерный вопрос: если локальный NVMe настолько хорош, можно ли получить похожую производительность, не привязывая storage жёстко к одному серверу? Так начинается история NVMe-oF — попытка вынести преимущества NVMe за пределы локального PCIe и сделать быстрый storage более гибким и сетевым. Для облака это особенно интересно, потому что позволяет отделять storage от compute без полного отказа от низколатентной модели доступа.
2015–2026: мечта о памяти-классе, урок Optane и новая реальность
Параллельно рынок смотрел в сторону storage-class memory и сверхнизких задержек. История Optane хорошо показала, что одной только скорости мало: даже сильная технология не становится стандартом автоматически, если вокруг неё сложны масштабирование и эксплуатация, да и цена не самая приятная.
К 2025–2026 годам разговор о новых хранилищах уже идёт не по схеме “одна технология победила всех”. Гораздо важнее стала связка из быстрых NVMe-носителей, сетевой дисагрегации и предсказуемого поведения под нагрузкой. И именно к этому нас подводит вся история развития storage: чем быстрее становились CPU, память и сеть, тем заметнее хранилище снова превращалось в проблему — уже не в грубом смысле “диск медленный”, а в более неприятном: storage начинает влиять на хвостовые задержки, стабильность записи, репликацию и общее поведение базы под живой нагрузкой.
Из чего теперь собирается быстрый storage: SSD, NVMe и почему одной надписи “NVMe” уже мало
После такой истории хочется упростить вывод до приятной формулы: HDD остались в прошлом, значит дальше всё просто — берём NVMe и живём спокойно. Но на практике storage для базы давно перестал делиться на “медленно” и “быстро”. Для БД важнее другой вопрос: насколько предсказуемо хранилище ведёт себя под живой нагрузкой.
Именно поэтому одна надпись NVMe сама по себе почти ничего не гарантирует. На бумаге два варианта могут выглядеть как “быстрый NVMe”, а в реальной эксплуатации разница проявится под записью, всплеском нагрузки, compaction или репликацией.
Чтобы не смотреть на storage слишком абстрактно, полезно разложить картину на несколько простых слоёв:
| Что влияет | Почему это важно для БД |
| Тип носителя | От него зависят базовые задержки, стабильность записи и поведение под нагрузкой |
| Интерфейс и протокол | Они определяют, насколько быстро хост вообще может добраться до устройства |
| Контроллер и внутренняя логика диска | Именно здесь часто прячутся скачки latency и разница между “вроде быстрым” и действительно стабильным хранилищем |
| Поведение при записи | Для БД это критично, потому что именно запись часто становится самым болезненным местом |
| Предсказуемость под пиками | Базу редко интересует красивая средняя цифра, если в реальности хвостовые задержки живут своей жизнью |
Таблица выше показывает главное: для базы данных важны не только сам носитель и интерфейс, но и то, как хранилище ведёт себя при записи и пиковых нагрузках. Именно здесь обычно и проходит разница между “быстрым на витрине” и “стабильным в реальной жизни”.
Поэтому storage под БД лучше выбирать не по громкому слову, а по сочетанию нескольких вещей: нормального носителя, адекватного протокола и предсказуемого поведения под нагрузкой. И именно на этом месте становится особенно интересен следующий шаг — что происходит, когда NVMe выносят по сети и зачем это вообще понадобилось облаку.
NVMe-oF: зачем выносить NVMe по сети и где это реально даёт смысл
На этом этапе у storage появляется почти инженерская хитрость. Локальный NVMe хорош тем, что он быстрый, близкий и понятный: устройство живёт рядом с сервером, задержки низкие, путь короткий. Но у такого подхода есть и минус — он жёстко привязывает производительное хранилище к конкретной машине. А облаку такая привязка неудобна.
Именно отсюда и растёт идея NVMe-oF. Если упростить, это попытка вынести преимущества NVMe за пределы одного сервера — по сети, но без слишком тяжёлых накладных расходов. Storage перестаёт быть “диском внутри конкретной коробки” и становится более гибким ресурсом, который можно подключать через fabric.
На бумаге это выглядит почти идеально: быстрый storage сочетается с тем, что облако особенно любит — разделением ресурсов, гибкостью и возможностью масштабировать compute и storage отдельно. Но как только NVMe перестаёт быть локальным, в игру вступает сеть. А значит, вопрос уже не только в качестве носителя, но и в стабильности fabric, транспорте, jitter и поведении системы под пиковыми нагрузками.
Это можно представить так:
| Подход | Что даёт | Где начинаются нюансы |
| Локальный NVMe | Минимальный путь до устройства, очень низкие задержки | Жёсткая привязка storage к конкретному серверу |
| NVMe-oF | Более гибкая архитектура, возможность отделить storage от compute | Зависимость от сети, транспорта и общей стабильности fabric |
| Классический сетевой storage | Удобство и привычная модель эксплуатации | Выше накладные расходы и больше шанс упереться в latency |
На практике NVMe-oF особенно интересен там, где локальный NVMe уже слишком жёстко привязывает storage к серверу, а классический сетевой storage не даёт нужной производительности. Для таких сценариев он становится компромиссом между скоростью и гибкостью.
Но именно компромиссом, а не универсальной заменой всему. Если база очень чувствительна к любому дрожанию задержек, а сеть между узлами живёт не самой спокойной жизнью, дополнительный сетевой слой может съесть часть выигрыша. Поэтому приложение в таком случае чувствует не только сам носитель, а всю дорогу до него.
Для облачных БД это особенно важно, потому что storage здесь почти всегда существует рядом с репликацией, отказоустойчивостью, миграциями и постоянной потребностью в управляемости. И именно поэтому дальше нужно смотреть не просто на “быстрый диск”, а на то, как вся схема ведёт себя по задержкам и насколько предсказуемо работает под живой нагрузкой.
Почему для облачных БД важны не только IOPS, но и tail latency, сеть и предсказуемость
Когда речь заходит о storage для базы данных, разговор очень легко скатывается в красивые цифры. Устройство даёт столько-то IOPS, столько-то гигабайт в секунду, и кажется, что этого уже достаточно, чтобы выбрать победителя. Но для облачной БД проблема почти никогда не звучит как “нам не хватило абстрактной скорости”. Намного чаще она звучит так: всё вроде было нормально, а потом в самый неудобный момент система начала вести себя неровно.
Именно здесь и появляется тема tail latency. Базу редко убивает средняя задержка сама по себе. Её убивают те самые редкие, но неприятные хвосты — моменты, когда часть операций внезапно начинает выполняться заметно дольше обычного. Для приложения это ощущается как рывки, лаги и всплески времени ответа, которые портят всю картину.
Особенно это неприятно в облаке. Там storage живёт не в стерильной коробке, а рядом с сетью, репликацией, соседними сервисами и фоновой активностью. В итоге база чувствует уже не только диск, а целую цепочку условий, от которых зависит её реальное поведение.
Больше всего здесь важны несколько вещей:
- Важна не пиковая скорость сама по себе, а то, насколько ровно storage держит нагрузку;
- IOPS мало что значат без понимания, как устройство ведёт себя на записи, flush и смешанном профиле;
- Если storage вынесен или завязан на удалённые компоненты, сеть начинает влиять на базу не меньше самого носителя;
- Средняя задержка успокаивает только на бумаге, а реальные проблемы чаще приходят через хвостовые лаги;
- Для долгой эксплуатации важна не разовая “быстрота”, а предсказуемость под живой нагрузкой.
Представим типичную ситуацию. У базы в среднем всё выглядит прилично: метрики красивые, диск быстрый, репликация идёт, чтение работает бодро. Но под всплеском записи, checkpoint или интенсивной фоновой работой storage внезапно начинает отвечать не за 1–2 миллисекунды, а заметно дольше. Для мониторинга это может быть “редкий эпизод”. Для приложения — уже история про внезапные тормоза и нестабильные транзакции.
Именно поэтому для облачных БД предсказуемость часто важнее красивой верхней цифры. Устройство, которое показывает менее впечатляющий пик, но ведёт себя ровно и спокойно, нередко оказывается полезнее, чем storage, который прекрасен в тестовом бенчмарке, но начинает нервничать при живой смешанной нагрузке.
Сеть сюда добавляет свой характер. Если storage, репликация или данные завязаны на удалённые компоненты, любая нестабильность начинает бить по базе уже не напрямую через диск, а через всю дорогу до него. И тогда проблема выглядит не как “у нас мало IOPS”, а как более неприятная история: система отвечает то быстро, то медленно, без понятной логики для конечного пользователя.
Именно поэтому в теме storage для облачных БД стоит мыслить не категориями “какое устройство быстрее по паспорту”, а вопросом: насколько ровно и предсказуемо эта схема будет вести себя под нашей реальной нагрузкой.
Как выбирать на практике: тип носителя, репликация, durability, стоимость и профиль нагрузки
На практике выбор storage для облачной базы почти никогда не начинается с вопроса “какой диск самый быстрый”. Гораздо полезнее сначала понять, какой у вас профиль нагрузки и что именно для базы будет болезненнее всего: запись, чтение, смешанный поток, всплески, фоновые операции или чувствительность к задержкам подтверждения транзакций.
Обычно при выборе приходится проверить пять вещей:
- Какой тип носителя лучше подходит под характер нагрузки;
- Как база чувствует себя на записи и смешанном I/O;
- Как устроены репликация и подтверждение записи;
- Во что схема обойдётся не только при запуске, но и в эксплуатации;
- Насколько предсказуемо она переживает реальные пики и сбои.
Именно поэтому storage нельзя выбирать по одной красивой характеристике. Один и тот же NVMe может хорошо выглядеть в коротком тесте и вести себя совсем иначе под живой нагрузкой. А быстрая локальная запись сама по себе ещё не означает надёжную архитектуру, если репликация, durability и сетевой путь вокруг базы устроены слишком хрупко.
По сути, хороший выбор storage — это всегда компромисс. Не между “быстро” и “медленно”, а между скоростью, предсказуемостью, отказоустойчивостью и стоимостью. И если этот компромисс выбран под реальную базу, а не под бенчмарк или красивый слайд, значит хранилище уже работает на систему, а не система подстраивается под капризы хранилища.
Заключение
Storage для облачной базы — это уже давно не просто “диск под данные”. От него зависят задержки, стабильность записи, поведение под пиками, репликация и то, насколько предсказуемо база вообще будет жить в продакшене. Поэтому смотреть только на надпись NVMe, красивые IOPS или громкое имя технологии уже недостаточно.
Если вам действительно нужна база, которая работает ровно, начните не с маркетинга, а с проверки своей нагрузки. Посмотрите, где система упирается сейчас: в запись, хвостовые задержки, сеть, репликацию или поведение storage под смешанным I/O. А потом уже выбирайте схему, которая выдержит именно эту реальность, а не лабораторный бенчмарк. Именно такой подход и отделяет нормальную инфраструктуру от дорогой, но нервной.
