Enterprise SSD традиционно воспринимают как место для файлов базы, журнала и резервных копий. В этой роли накопитель находится за интерфейсом хранения: СУБД сама читает блоки, управляет кэшем и отвечает за устойчивость данных. Но многоуровневая память добавляет накопителю другую задачу — участвовать в физическом размещении страниц, с которыми приложение продолжает работать как с памятью.
Это изменение важно не из-за нового названия компонента. Когда SSD входит в вычислительный путь, его задержка, пропускная способность, очередь запросов и ресурс становятся частью поведения СУБД. Решение уже нельзя принимать только по ёмкости дисковой полки или числу IOPS из паспорта: архитектура должна удерживать целевой p99, не создавать конфликт с обычным вводом-выводом базы и оставаться оправданной по стоимости всей конфигурации.
Enterprise SSD и NVMe не являются синонимами. NVMe задаёт интерфейс обмена, а enterprise SSD — класс серверных накопителей с конкретным контроллером, NAND, ресурсом и профилем производительности. Роль памяти создаёт программный контур, связывающий обращения приложения с размещением страниц.
У хранилища и уровня памяти разные обязанности
В обычной роли SSD хранит устойчивые данные. СУБД ожидает, что файлы и журнал переживут перезапуск, а операции чтения и записи будут выполнены с заданной надёжностью. Метрики этой роли связаны с пропускной способностью, задержкой дисковых операций, восстановлением и доступной ёмкостью. Владельцами решения обычно выступают DBA и команда хранения.
Уровень памяти управляет страницами виртуальной памяти, не меняя логическую жизнь таблицы, ключа или файла. Страница может стать важной на короткой фазе запроса, затем уступить быстрый ресурс и вернуться позже. Его характеристика — способность поддерживать меняющийся рабочий набор.
Накопитель может одновременно обслуживать журнал, чтение файлов и перенос страниц. Эти потоки имеют разные требования, поэтому средняя загрузка способна скрыть очередь в критичный период.
SSD входит в вычислительный путь
В официальном материале Samsung с GTC 2026 SSD показаны как компоненты ускоренной инфраструктуры ИИ. Это позиционирование производителя, а не независимый тест, но оно отражает сдвиг: накопитель проектируют как участника подачи данных вычислителям.
Для СУБД аналогичный переход происходит, когда страницы на SSD остаются частью доступного рабочего набора. Процессор всё ещё получает срочные данные из DRAM, однако общий адресуемый объём не обязан целиком состоять из физической оперативной памяти. Программное управление определяет, какие страницы должны находиться на быстром уровне в текущей фазе.
Контур использует различие уровней: срочные обращения обслуживает быстрый ресурс, а ёмкий участвует там, где нагрузка допускает иной профиль доступа. Результат проявляется в работе запросов, а не в самом факте установки SSD.
Предиктивное размещение следует за рабочим набором
Предиктивная математическая модель gigaRAM по реальным обращениям решает, что, куда и когда перемещать или возвращать между DRAM и NVMe. Это не ручная раскладка таблиц и не постоянный ярлык hot/cold: положение страницы пересматривается вместе с поведением нагрузки.
Модель действует ниже приложения и не знает бизнес-смысла ключа или индекса. СУБД продолжает управлять файлами, журналами и кэшами, а инфраструктурный слой отвечает за физическую иерархию памяти.
Работа TMO на ASPLOS’22 подтверждает класс автоматического переноса памяти на неоднородные устройства с учётом чувствительности приложения. Реализация и показатели относятся только к инфраструктуре Meta.
Документация PostgreSQL разделяет собственный буфер СУБД и кэш ОС: полезная работа уже зависит от нескольких уровней памяти. Предиктивный слой добавляет физический уровень, не подменяя shared_buffers или план запроса.
Метрики определяют архитектурную роль
Один и тот же SSD оценивают по-разному в зависимости от роли. Для хранения важны устойчивость и время дисковой операции, для уровня памяти — влияние переносов страниц на p99 приложения, а для совместного контура — конкуренция потоков и запас ресурса устройства. Компактное сравнение помогает назначить владельца до того, как компонент войдёт в эксплуатацию.
| Роль SSD | Что измеряют | Кто отвечает | Управленческий вывод |
|---|---|---|---|
| Хранилище данных и журнала | Задержка и пропускная способность операций СУБД | DBA и storage-команда | Подтверждается устойчивый путь данных |
| Уровень страниц памяти | p99 сервиса, возвраты страниц, полезная нагрузка | Platform и владелец сервиса | Плотность принимается только в пределах SLO |
| Совместный I/O-контур | Очередь, пропускная способность, взаимное влияние потоков | Platform, DBA и storage | Потоки получают раздельную наблюдаемость и резерв |
| Ресурс конфигурации | Состояние SSD, объём записей, срок эксплуатации | Platform и storage | Стоимость считается на срок жизни узла |
Спецификация NVM Express определяет Data Units Written и Percentage Used. Первый показатель отражает данные, переданные хостом контроллеру, второй — оценку использованного ресурса устройства. Это не внутренние записи NAND, но общий язык наблюдения для эксплуатации.
Средний ответ может оставаться приемлемым, пока конкуренция I/O увеличивает p99. Linux PSI показывает время, когда задачи теряют полезную работу из-за давления CPU, памяти или ввода-вывода, и помогает связать занятость устройства с ожиданием приложения.
Страницы памяти появляются на энергонезависимом устройстве, поэтому политики доступа и обращения с носителем должны соответствовать роли данных. Подробнее это разобрано в материале про безопасность многоуровневой памяти на NVMe; здесь вопрос влияет на ответственность команд.
Стоимость считают для целой конфигурации
Цена enterprise SSD сама по себе не отвечает, выгоден ли уровень памяти. В итог входят физическая DRAM, накопитель нужного класса, резервирование, программный слой, энергия, эксплуатация и возможное изменение числа серверов. Одновременно учитывается полезная нагрузка: запросы или транзакции, которые система завершила в пределах SLO.
Если новый контур повышает адресуемую ёмкость, но p99 выходит за согласованную границу, дополнительный объём нельзя считать полноценной производственной мощностью. Если SLO сохраняется, сравнивают стоимость одинакового объёма работы за один период. Такой подход продолжает расчёт стоимости полезной работы СУБД, но добавляет ответственность за конкретный SSD и его I/O-путь.
Журнал транзакций, контрольные точки, чтение файлов и перенос страниц способны совпадать. Важно определить, кто контролирует общий предел, как виден вклад каждого потока и какой запас остаётся на критичную фазу.
Ресурс накопителя входит в стоимость как эксплуатационный параметр. Стандартные счётчики позволяют сопоставлять его расходование с плановым сроком узла; детальная оптимизация записей относится к отдельной задаче.
Владельцем становится межфункциональная команда
Platform-команда владеет иерархией памяти и наблюдаемостью узла. DBA подтверждает профиль запросов и p99. Storage-команда отвечает за устройство и ресурс, владелец сервиса — за SLO, а финансовая функция — за горизонт стоимости.
Инвестиция оправдана, когда рост рабочего набора регулярно требует линейного увеличения DRAM или новых серверов, а в нагрузке есть меняющиеся фазы, которые можно обслуживать общей иерархией. Сигнал подтверждается не долей занятых гигабайтов, а повторяемой картиной: целевой сервис упирается в ёмкость, I/O имеет измеримый запас, а p99 и ресурс накопителя остаются в согласованных границах при более плотном размещении.
В архитектуре с gigaRAM enterprise SSD становится управляемой частью вычислительного контура, а не пассивным архивом. Это позволяет обсуждать рост памяти как системное решение с назначенными владельцами, измеряемым SLO и полной стоимостью. Универсальный процент замещения из такой роли не следует: решение определяется поведением конкретной нагрузки и конфигурации.
Для CTO вопрос звучит так: какую роль получает SSD, какие потоки делят его ресурсы и кто отвечает за p99, ресурс и стоимость. С этими границами enterprise SSD можно проектировать как уровень памяти СУБД, а не ещё одну дисковую полку.
Источники. Samsung на GTC 2026 показывает SSD в ускоренной вычислительной архитектуре. TMO, ASPLOS’22 служит первичным исследованием неоднородной памяти; его результаты относятся только к TMO.
PostgreSQL 17 — Resource Consumption подтверждает разделение буферов СУБД и кэша операционной системы. NVM Express Base Specification 2.0a используется для определений Data Units Written и Percentage Used. Linux PSI является официальным источником о потере полезной работы из-за давления ресурсов.
Технология gigaRAM — единственная коммерческая ссылка и источник описания предиктивного размещения страниц между DRAM и NVMe. Источники не задают универсальный процент замещения или производительности для конкретной СУБД.