Комментарии по теме

«Ре­ко­ме­нда­ции по обе­спе­че­нию бе­зо­па­сно­сти и контроля SAP HANA»
Дмитрий Буслов:
(1) Автор начинает с того, что HANA — это СУБД, позволяющая хранить записи в колонках и работающая в оперативной памяти. Я бы, хотел сделать акцент на том, что HANA — не просто СУБД,...
«Различие между двумя текущими версиями HANA»
Олег Точенюк:
Спасибо конечно... я вот не понимаю как консалт выживает в этом мире, когда есть такой чудесный традиционный сайт help.sap.com/ :-)
«Что делать, если надо внедрять?»
Олег Точенюк:
Как-то вот читал, читал, и вроде тема интересная и комментариев что-то нет, а потом понял или точнее не понял, но предположу почему в ответ тишина, а потому что никто наверное так и не понял как же...

Расширение возможностей управления «температурой данных» в SAP HANA с помощью опции Dynamic Tiering

1013

Ключевое понятие

Термин «расширенная таблица» означает таблицу, которая была определена в одном приложении, но ее содержимое хранится во вторичном приложении. Такая настройка позволяет сократить объем хранимых данных в первичном приложении, сохраняя доступ к данным и контроль над метаданными в так называемых расширенных таблицах. Dynamic Tiering в SAP HANA позволяет осуществить этот принцип, определяя выбранные таблицы как расширенные. Основная память SAP HANA выступает в роли первичного приложения, а дисковое пространство — в роли вторичного приложения. (*Необходимо разделять выгрузку на диск таблицы (UNLOAD TABLE) и работу с таблицей с диска – Dynamic Tiering). Другими словами, содержимое расширенных таблиц хранится исключительно на диске SAP HANA, но доступ к ним и управление данными осуществляется так же, как и в случае стандартных таблиц SAP HANA. Нужно отметить, что загрузка данных с диска происходит медленнее, чем загрузка из оперативной памяти.

   

Загрузка данных в память для быстрого доступа и копирование данных на диск для продолжительного хранения — новая концепция «in-memory» базы данных SAP HANA. Тем не менее, не всегда целесообразно загружать все данные в оперативную память: это неэкономично и во многих случаях нежелательно.

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

В управлении данными, в зависимости от их важности, ключевую роль играет стратегия хранения данных с разными «температурными» характеристиками. В то же время ее можно использовать для более эффективного использования ресурсов памяти SAP HANA: как оперативной памяти, так и дискового пространства. Как упоминалось в более ранних статьях, таких как «Обзор особенностей Nearline-носителя (NLS) для SAP NetWeaver BW на базе Sybase IQ», не все данные в хранилище являются критическими для бизнес-операций.

В пределах спектра данных с разными «температурными» характеристиками (рис. 1) существуют более статичные данные, которые редко нужны пользователям. Как правило, это относится к историческим данным, значение которых для текущих бизнес-процессов со временем снизилось. Такие примеры включают в себя контракты с истекшим сроком действия, выполненные поставки или финансовые операции, проведенные несколько лет назад. Данные, соответствующие таким условиям, считаются «холодными». Как правило, эти данные предназначены для миграции в решения Near Line Storage (NLS), например, SAP Sybase IQ, чтобы очистить базу данных SAP HANA для более важных бизнес-данных.

Рис. 1. Спектр данных с разными “температурными характеристиками”

   

В базе данных SAP HANA хранятся не только «холодные» и «горячие» данные. По определению «горячие» данные — данные, которые часто требуются пользователям, и в некоторых случаях данные, которые нуждаются в постоянном обновлении: например, статус. Однако встречаются случаи, когда данные являются статическими и вызываются время от времени по запросу. Такое регулярно случается с историческими данными в специализированных хранилищах с разделением по годам. Другие примеры «не очень горячих» данных включают в себя таблицы Persistent Staging Area (PSA) и оптимизированные для записи объекты хранилища данных (DSO).

Как правило, содержимое таблиц PSA используется только один раз, при загрузке больших объемов данных. Однако его зачастую требуется сохранять в базе данных в течение определенного периода времени — для страховки. Другой классический пример — оптимизированные для записи объекты хранилища данных (DSO), которые имеют большое значение для корпоративной памяти.

В крупных компаниях, использующих многоуровневую масштабируемую архитектуру (LSA) для хранения данных, корпоративная память содержит постоянные данные оптимизированных для записи объектов DSO, полученные из таблиц PSA с отношением полей 1:1. Над этими данными не производится никаких манипуляций. Единственное предназначение этого слоя памяти — возможность загрузки существующих провайдеров данных или инициализация новых без влияния на дельта-указатели исходной системы.

Во всех приведенных примерах данные можно отнести к так называемым «теплым» данным, которые не требуется хранить в основной памяти.

Управление «теплыми» данными

Рассмотрим, как осуществляется управление «теплыми» данными в SAP HANA в настоящее время, и как можно использовать для этого динамическое перемещение по уровням.

Сейчас для управления содержимым оперативной памяти SAP HANA используются алгоритмы замещения наиболее давно использовавшихся данных. Процедура замещения запускается автоматически, когда достигается лимит объема памяти SAP HANA. Недавно использовавшиеся таблицы или разделы считаются активным содержимым. Им присваивается более высокий приоритет для хранения в основной памяти SAP HANA. Давно не использовавшиеся таблицы считаются неактивными, следовательно, в первую очередь удаляются из основной памяти.

При удалении таблицы из основной памяти SAP HANA, ее содержимое остается только в дисковом хранилище. При запросе таблицы, хранящейся на диске, нужное содержимое возвращается в основную память SAP HANA. Причем в память возвращается не все содержимое таблицы, а только конкретные столбцы, соответствующие запросу. Эти столбцы остаются там и после выполнения запроса, пока позволяет объем памяти. При достижении лимита запускается цикл выгрузки наиболее давно использовавшихся данных из основной памяти.

Можно предотвратить заполнение памяти SAP HANA и запуск выгрузки наиболее давно использовавшихся данных. Для этого используются процедуры отслеживания потребления оперативной памяти и ручной выгрузки конкретных таблиц из основной памяти до того, как будет достигнут лимит. В ходе стандартного мониторинга SAP HANA генерирует сообщения о высоком потреблении памяти. В папке SAP HANA щелкните правой кнопкой мыши по таблице SAP HANA и вызовите контекстное меню с несколькими опциями (рис. 2). Выберите опцию «Unload from Memory…» (Выгрузить из памяти).

Вы хотели бы увидеть полную версию статьи?

Если вы являетесь подписчиком журнала SAP Professional Journal, пожалуйста, введите в правом верхнем углу логин и пароль.

Если вы хотите подписаться на журнала SAP Professional Journal, пожалуйста, обратитесь в редакцию или сделайте заказ на сайте.

Правила получения тестового доступа к статьям SAP Professional Journal


Любое воспроизведение запрещено.
Копирайт © «Издательство ООО «Эксперт РП» Copyright © 2010 Wellesley Information Services. All rights reserved.