Термин in-memory долго подталкивал компании к простой закупочной логике: растёт база — значит, почти тем же темпом должна расти DRAM. SAP HANA Native Storage Extension, или NSE, показывает более зрелую модель. Система сохраняет быстрый путь для приоритетных данных, но допускает постраничную загрузку другой части столбцового хранилища.
Для рынка важен не отдельный параметр SAP HANA, а сам архитектурный сдвиг. СУБД, созданная вокруг обработки в памяти, официально использует несколько способов загрузки данных и собственный буферный кэш. Многоуровневая память стала не экспериментом на периферии, а штатным способом отделить рост данных от линейного роста дорогой оперативной памяти.
При этом у многоуровневости есть разные уровни управления. NSE понимает таблицы, секции и столбцы SAP HANA. Инфраструктурный слой ниже приложения видит физические страницы памяти и фактические обращения. Для CTO ценность появляется тогда, когда эти уровни не смешивают, а связывают общей целью: обслуживать больше полезной нагрузки при заданных SLO и бюджете.
NSE показывает зрелость многоуровневой СУБД
SAP представила NSE в SAP HANA Platform 2.0 SPS 04 как встроенное расширение для данных, которые не требуется постоянно держать целиком в основной памяти. Официальный обзор SAP описывает его как часть HANA, прозрачную для приложений и пользователей. Данные NSE остаются в той же базе, участвуют в согласованных транзакциях, резервном копировании, шифровании и репликации.
Это существенно отличает многоуровневую память от архива, куда данные отправляются вне рабочего контура. Page-loadable данные продолжают обслуживаться механизмами HANA, но нужные фрагменты загружаются по запросу. Первичная статья команды SAP в PVLDB называет NSE гибридным столбцовым хранилищем, которое расширяет ёмкость HANA за пределы доступной системной памяти.
Внутри HANA уровни привязаны к объектам данных
В столбцовом хранилище SAP HANA единица загрузки задаёт поведение таблицы, секции или столбца. Column-loadable объект при использовании загружается в память целиком. Для page-loadable объекта HANA загружает только страницы, содержащие части столбца, которые нужны запросу. Это решение выражено в понятиях самой СУБД.
Запрошенные страницы попадают в NSE buffer cache — выделенную область оперативной памяти. Буферный кэш удерживает часто используемые страницы и сокращает повторное чтение с накопителя. Он встроен в менеджер ресурсов HANA, а значит, его работа связана с исполнением запросов, изменением данных и внутренними операциями базы.
NSE Advisor добавляет ещё один нативный контур. Он собирает статистику обращений для наблюдаемой нагрузки и рекомендует единицы загрузки для таблиц, секций и столбцов. Рекомендация остаётся привязанной к объектам HANA: DBA видит, какой объект предлагается сделать page-loadable или column-loadable, и управляет свойством на уровне схемы данных.
Ниже приложения размещаются физические страницы
Инфраструктурный уровень решает другую задачу. Он не выбирает таблицы и не меняет единицы загрузки SAP HANA, а управляет размещением страниц виртуальной памяти между физическими уровнями. Такой подход особенно важен для приложений, в которых собственный NSE-подобный механизм отсутствует или где компании нужен общий контур управления ёмкостью.
Здесь gigaRAM описывается как слой ниже приложения: предиктивная математическая модель по реальным обращениям решает, что, куда и когда перемещать или возвращать между DRAM и NVMe. Решения пересматриваются вместе с нагрузкой, поэтому администратору не требуется вручную размечать страницы. СУБД продолжает работать со своей памятью, а физическое размещение управляется отдельно.
NVMe в этой архитектуре выполняет роль уровня памяти, а не просто места для файлов. Подробнее изменение этой роли разобрано в материале о том, как enterprise SSD входит в вычислительный контур СУБД. Для SAP HANA это не означает перенос свойств NSE на инфраструктуру: нативный механизм и физический слой используют разную информацию и имеют разных владельцев.
Три уровня требуют разного управления
Одно слово «уровень» легко скрывает разные решения. Хранилище отвечает за долговечность данных и файловый ввод-вывод. Нативная функция СУБД понимает объекты движка. Физический слой памяти наблюдает страницы процесса. Чтобы проект не превратился в спор инструментов, CTO сначала фиксирует границу ответственности.
| Уровень | Что он видит | Кто управляет | Управленческий вывод |
|---|---|---|---|
| SAP HANA NSE | Таблицы, секции, столбцы и страницы column store | DBA и архитектор SAP HANA | Решение о способе загрузки остаётся частью модели данных |
| Инфраструктурный слой gigaRAM | Обращения к страницам памяти между DRAM и NVMe | Платформенная команда вместе с владельцем сервиса | Физическая ёмкость управляется ниже приложения |
| Постоянное хранилище | Файлы, тома, надёжность и пропускная способность | Storage-команда и платформа | Долговечность данных отделяется от размещения оперативных страниц |
Инвестиционное решение начинается со смены рабочего набора
Сигналом для инвестиций служит не только общий размер базы. Он появляется, когда рост данных регулярно приводит к увеличению DRAM или числа узлов, а активная часть меняется по времени и бизнес-фазам. Механизм cold memory и смены рабочего набора объясняет, почему снимок использования памяти не заменяет наблюдение за поведением нагрузки.
Для SAP HANA DBA и архитектор данных определяют, какие объекты и режимы загрузки соответствуют бизнес-запросам. Для физического слоя платформенная команда оценивает память и NVMe. Владелец сервиса задаёт целевую задержку, включая p99, и цену нарушения SLO. Решение принадлежит этой группе, а не одному закупщику или администратору.
Риск возникает, если два уровня оптимизируют независимо. Перенос объекта внутри HANA и физическое размещение страниц могут влиять на один путь запроса, хотя измеряются разными инструментами. Поэтому архитектурная оценка должна связывать конфигурацию с одной и той же полезной нагрузкой: числом выполненных операций, задержкой критичных запросов и стоимостью узла.
Момент инвестировать в многоуровневую память наступает, когда линейное наращивание DRAM перестаёт быть лучшим способом обслуживать рост, а нагрузка уже показывает различие между постоянно активным объёмом и меняющейся менее активной частью. Тогда компания сравнивает архитектуры по стоимости обслуженной работы при соблюдённом SLO, а не по максимальному числу терабайт в спецификации.
Сигнал SAP меняет архитектуру и бюджет
NSE подтверждает, что зрелая in-memory СУБД может разделять способы доступа к данным, не выводя их из единого операционного контура. Это важнее отдельной функции SAP: индустрия переходит от правила «всё в DRAM» к управляемой иерархии, где быстрый уровень защищает критичный путь, а ёмкость масштабируется несколькими средствами.
Для CTO итогом становится двухконтурная архитектура. На уровне СУБД сохраняются знания об объектах, транзакциях и запросах. На уровне инфраструктуры управляется физическое размещение памяти. Эти контуры имеют разные метрики и владельцев, но сходятся в p99, SLO, плотности размещения и стоимости полезной нагрузки.
Такой подход делает бюджет точнее. DRAM закупается не как автоматическое отражение общего размера базы, а как ресурс для требуемого качества обслуживания. Узлы и NVMe рассматриваются в составе целой конфигурации, а решение об инвестиции принимается по тому, сколько данных и запросов система обслуживает в заданных границах задержки.
Опыт SAP HANA NSE показывает зрелость категории без необходимости объявлять один механизм заменой другого. Нативное размещение данных и инфраструктурное размещение страниц — самостоятельные уровни управления. Их чёткое разделение позволяет архитектору использовать многоуровневую память как управляемую платформенную стратегию, а не как набор разрозненных настроек.
Источники. Официальный обзор SAP HANA Native Storage Extension, версия 2.3 описывает load units, page-loadable доступ, buffer cache и NSE Advisor. SAP HANA Platform 2.0 SPS 04 — What's New фиксирует появление NSE как встроенного механизма для warm data.
SAP HANA Master Guide 2.0 SPS 06 и SAP HANA Administration with SAP HANA Cockpit подтверждают интеграцию NSE с column store, буферным кэшем, Advisor и средствами наблюдения. Первичная статья команды SAP в PVLDB описывает гибридную архитектуру NSE.
Технология gigaRAM используется только как источник описания предиктивного физического размещения страниц между DRAM и NVMe. Свойства NSE и утверждения о прямой интеграции на инфраструктурный продукт не переносились.