NVMe против SATA SSD на сервере

MAATRIX

«Берите NVMe, он быстрее» — совет верный, но бесполезный: важно не то, что быстрее в синтетике, а то, упрётся ли ваша задача в диск вообще. На одном сервере разница между NVMe и SATA SSD решает всё, на другом её никто не заметит. Разберём, где эти накопители реально расходятся и как выбрать под конкретную нагрузку, не переплачивая и не экономя на том, что критично.

В чём вообще разница

SATA SSD и NVMe SSD — это одна технология флеш-памяти, но подключённая по-разному. SATA — старый интерфейс, придуманный ещё под жёсткие диски, с потолком около 550 МБ/с и одной очередью команд. NVMe работает напрямую по шине PCI Express, минуя это узкое горло: у него десятки тысяч параллельных очередей и на порядок меньше накладных расходов на каждую операцию.

Практический итог: по линейной скорости NVMe быстрее SATA в 5–10 раз, а по числу мелких операций в секунду (IOPS) и по задержке отклика — ещё заметнее. Именно IOPS и латентность, а не «мегабайты в секунду», решают на серверах, потому что реальная нагрузка — это тысячи мелких разбросанных чтений и записей, а не копирование одного большого файла.

Цифры, которые важны на практике

Чтобы выбор был предметным, держите в голове порядки величин. Они приблизительные и зависят от модели, но соотношение устойчиво.

Обратите внимание на латентность: для базы данных, которая на каждый запрос делает десятки обращений к диску, разница между 100 и 15 микросекундами умножается на эти десятки и превращается в ощутимый прирост отклика приложения. Здесь NVMe выигрывает не на процентах, а в разы.

Где NVMe реально нужен

Есть классы задач, где NVMe — не роскошь, а условие адекватной работы. Первый — базы данных под нагрузкой: PostgreSQL, MySQL, ClickHouse, MongoDB интенсивно читают и пишут мелкими блоками, и диск здесь чаще всего и есть узкое место. Второй — высоконагруженный веб с активной работой с диском: динамические сайты, кэши, сессии, очереди.

Третий — всё, что упирается в параллельные операции: множество контейнеров на одном хосте, виртуализация, CI/CD со сборками, аналитика на больших выборках. Четвёртый — задачи с интенсивной записью: приём логов, телеметрии, событий, стриминговые буферы. Везде, где приложение «ждёт диск», NVMe окупается сразу и заметно.

Где хватит SATA SSD

Не каждая задача упирается в диск, и переплачивать за NVMe там, где он простаивает, — такая же ошибка, как экономить на нём под базой. SATA SSD прекрасно закрывает сайты и приложения средней нагрузки, где данные помещаются в оперативную память и до диска доходит немного. Он отлично подходит под файловые хранилища, бэкапы, медиатеки и архивы, где важнее объём и цена за терабайт, чем пиковые IOPS.

Хорошее правило: если ваш рабочий набор данных целиком кэшируется в RAM, диск обращается редко, и разница между NVMe и SATA стирается — деньги разумнее вложить в память. NVMe раскрывается там, где данных больше, чем памяти, и диск работает постоянно.

Надёжность, ресурс и корпоративные модели

Скорость — не единственный параметр. Для сервера важнее бытового потребителя два других: ресурс записи (TBW/DWPD) и наличие защиты от потери питания. Серверные (enterprise) SSD, что SATA, что NVMe, рассчитаны на постоянную запись и имеют конденсаторы, которые при внезапном отключении дозаписывают буфер и не теряют данные. Потребительские диски такой защиты лишены — на боевом сервере это недопустимо.

Под интенсивную запись (базы, логи, очереди) смотрите на показатель DWPD — сколько раз в день можно перезаписать весь объём диска в течение гарантийного срока. Для баз берите модели с DWPD от 1 и выше. Для преимущественно читающих нагрузок хватит и read-intensive дисков с меньшим ресурсом, зато большего объёма за те же деньги.

RAID и как не потерять скорость NVMe

Диски на сервере почти всегда объединяют в массив ради надёжности. С SATA всё привычно: аппаратный RAID-контроллер с кэшем и батарейкой (BBU) снимает нагрузку с процессора и защищает данные. С NVMe тоньше: классические RAID-контроллеры часто становятся узким горлом и «съедают» преимущество быстрых дисков, поэтому под NVMe нередко используют программный RAID (mdadm, ZFS) или специализированные решения.

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

Отдельно про охлаждение и стабильность под нагрузкой. NVMe при интенсивной длительной записи греется сильнее SATA, и без нормального теплоотвода дешёвый диск уходит в троттлинг — сбрасывает частоту и скорость ради температуры. На синтетическом тесте в пару секунд этого не видно, а под реальной базой, которая пишет часами, разница между честным серверным NVMe с радиатором и бытовым накопителем становится очевидной: первый держит стабильные IOPS, второй проваливается. Поэтому на выделенном сервере важна не только строчка «NVMe» в описании, но и класс самого диска. Серверные модели рассчитаны на круглосуточную нагрузку и держат заявленные цифры под длинной записью, а не только в первые секунды теста.

И про деградацию на заполнении: любой SSD, что SATA, что NVMe, теряет в скорости записи, когда занято больше 80–85% объёма — контроллеру негде маневрировать свободными ячейками. Это ещё одна причина не брать диск впритык: заложите четверть объёма про запас, и накопитель будет держать скорость весь срок службы, а не только пока полупустой.

Как выбрать под свою задачу

Сведём к простому алгоритму. Определите, упирается ли задача в диск: если это база данных, высоконагруженный веб или интенсивная запись — берите NVMe и не раздумывайте. Если рабочие данные помещаются в RAM, а нагрузка спокойная — SATA SSD сэкономит бюджет без потерь. Под объёмное хранение и бэкапы выбирайте по цене за терабайт. Под смешанный профиль частая рабочая схема — небольшой NVMe под систему и базу плюс SATA-массив под данные и архивы.

И честно про масштаб: если вы разворачиваете один сайт-визитку или тестовый стенд, разница дисков вас не коснётся — здесь подойдёт и VPS с SSD. Отдельный выделенный сервер с NVMe-массивом оправдан, когда вам нужна вся производительность диска целиком и предсказуемая латентность без соседей по хосту.

Частые вопросы