Русский
Русский
English
Статистика
Реклама

Sap hana

SAP HANA. Таблицы с типом хранения Row

12.06.2021 12:08:35 | Автор: admin

Добрый день, коллеги. В этой статье я бы хотел затронуть тему таблиц с типом Row. Этот тип таблиц для многих администраторов баз данных, долгое время оставался наиболее естественным типом, так сказать типом по умолчанию. Таблицы типа COLUMN в основнов встречались в хранилищах данных (Data Warehouse), то есть базах данных с преобладающей нагрузкой типа OLAP.

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

Таблицы с типом Row хранятся в специальной области памяти, которая называется shared memory. При запуске базы данных эта область полностью загружается в память и остается там всё время, пока база данных находится в рабочем состоянии.

В таблицах с типом Row, все данные размещаются в строках друг за другом, что облегчает доступ ко всем строкам таблицы. А вот с доступом, ко всем значениям столбца немного сложнее, поскольку эти значения не могут быть переданы из основной памяти в CPU с той же эффективностью, как в случае хранения по столбцам. Компрессия данных при таком типе хранения также менее эффективна.

Классический подход для реляционных баз данных, в которых данные хранятся в табличном формате, заключается в хранении, напоминающем логическую структуру таблицы. Каждая запись храниться как объединенный кусок значений каждой колонки таблицы. Ниже представлена таблица с классическим типом хранения.

Пример таблицы с классическим хранениемПример таблицы с классическим хранением

Этот дизайн имеет очевидное преимущество, заключающееся в прямом мэппинге представления логической таблицы и операций которые с ней выполняются на фактические манипуляции с данными, которые происходят в памяти. Такое представление проще для разработчиков базы данных и администраторов DBA.

Представление Row-store таблицы в памятиПредставление Row-store таблицы в памяти

У такого представления данных есть и свой недостаток, заключается он в том, что для многих операций в базе данных такой подход не очень эффективен. База данных не может получить прямой доступ к определенным колонкам таблицы. Вместо этого страницы с данными необходимо передать CPU для сканирования хранящихся строк по порядку, по идентификатору условияwhereдля определенных столбцов.

Пример сканирования строк в таблицах с типом Row и Column storeПример сканирования строк в таблицах с типом Row и Column store

Эти данные перемещаются из основной памяти (main memory) в кэш CPU, это оказывает влияние на производительность, особенно при массовой обработке данных, в таких случаях как хранилище данных и аналитические запросы. В то время как для смешанного типа нагрузки, при условии доступа к одной или нескольким записям со всеми колонками, этот метод хранения является предпочтительным, так как требования трансформации данных от внутреннего хранилища к внешнему представлению (также называемое проекцией) для клиента базы данных минимальны.

В базе данных HANA, таблицы с типом Row-store имеют целый ряд ограничений:

  • таблицы не могут быть секционированы

  • отсутствует алгоритм для сжатия таблиц

  • к колонке в такой таблице не может быть предоставлен отдельный доступ, а также параллельный доступ.

  • таблица не может быть выгружена из памяти

  • если таблица с строковым типом не может быть полностью загружена в память, сервер базы данных не сможет запуститься

  • для построения большинства информационных моделей, таблицы с этим типом не могут быть использована напрямую.

Для row-store таблиц, доступно два типа индекса: классический b-tree индекс и cpb+-tree (сжатый префикс b-tree) индекс который оптимизирован для обработки символьных индексных ключей в памяти. Несмотря на то, что есть возможность выбрать тип используемого индекса, обычно в этом нет необходимости. SAP HANA будет использовать cpb+-tree тип определенный по полю или комбинации полей типа string, binary string, или decimal. Для всех остальных типов, будет создан классический b-tree индекс. Индексы по row-store таблицам не сохраняются в БД на постоянной основе, вместо этого они пересоздаются каждый раз при загрузке таблицы в память (запуске базы данных).

Управление многоверсионной конкуренцией (Multiversion Concurrency Control)

Multiversion Concurrency Control (MVCC) это концепция, которая гарантирует консистентность транзакционных данных путем изоляции транзакций которые получают доступ к одним и тем же данным в одно и то же время. Для того чтобы это было реализовано параллельно, сохраняется несколько версий записи. Проблемы с MVCC обычно связаны с большим количеством активных версий записи. Старые версии время от времени должны удаляться для того, чтобы освободить память.

Колоночные и строковые таблицы реализуют это функцию совершенно по-разному.

Для row store таблиц, каждая измененная страница сначала копируется и размещается в цепочке версий страниц, где каждая версия имеет состояние данных на определенную операцию commit. Эти цепочки страниц хранятся в виртуальном контейнере в памяти, который называется undo. Представление для мониторинга M_UNDO_CLEANUP_FILES показывает детальную информацию по этим внутренним виртуальным файлам-контейнерам.

За удаление старых версий записи отвечает Garbage Collector. Сборка мусора происходит после операции commit, а также периодически (по умолчанию каждый час). Сборщик мусора может удалить лишь те старые версии записей, для которых транзакции обновления были завершены (была выполнена операция commit или rollback). В случае, если транзакция изменяет десятки или тысячи строк без фиксации изменений (операции commit), вы можете попасть в ситуацию, когда большой объем избыточных данных необходимо хранить в основной памяти (main memory), так как в базе данных будут храниться десятки тысяч блокированных версий записей и новых активных версий записи. Я уже наблюдал картину, когда по большим таблицам в памяти хранилось до 8 млн. версий записей.

Если обраться к представлению с потоками (например M_SERVICE_THREADS), то в поле Thread Type периодическая сборка мусора будет обозначаться как MVCCGarbageCollector. Для того, чтобы найти транзакции, которые зафиксировали свои изменения, необходимо в представлении потоков, сделать выборку по условиям THREAD_TYPE=SqlExecutor и THREAD_METHOD=CommitTrans.

Реорганизация Row-store области

Реорганизация Row-store области представляет собой процесс дефрагментации сегментов памяти с целью более компактного хранения. Несмотря на значительные улучшения в самом процессе реорганизации, который претерпел существенные изменения начиная еще с HANA 1.0, сама по себе процедура всё еще остается проблемной. Об этом я расскажу ниже, а сейчас немного общей информации.

Пространство Row store увеличивается путем выделения сегментов памяти размером 64 Мб. Сегмент внутренне разделен на страницы фиксированного размера. Когда row-store таблице требуется больше памяти для хранения записей, для неё выделяются свободные страницы из существующего сегмента. Если свободных страниц в сегменте больше нет, выделяется новый сегмент.

Удаление большого числа записей может привести к появлению разрозненных сегментов. В этом случае может помочь реорганизация области row store с целью более компактного хранения в памяти. Страницы из разрозненных сегментов переносятся в другие сегменты, в результате освобождается свободное пространство. SAP рекомендует выполнять реорганизацию Row Store пространства при условии, что его размер превышает 10Gb при этом свободных блоков более 30%. В базе данных HANA доступно два режима реорганизации пространства ONLINE и OFFLINE.

ONLINE реорганизация стала доступна с версии HANA 1.0 SPS8. С тех пор этот режим постоянно улучшается с целью снижения влияния на бизнес процессы и повышения эффективности хранения в области Row store. До версии SAP HANA 2.0 SPS3 включительно, при проведении онлайн реорганизации, на таблицы участвующие в реорганизации устанавливалась эксклюзивная блокировка, в результате чего, изменения записей по этим таблицам были невозможны. Начиная с версии SAP HANA 2.0 SPS4 в процессе реорганизации произошли изменения, теперь при онлайн реорганизации блокировка устанавливается на уровне строки, а не таблицы целиком. В соответствии с рекомендациями SAP online реорганизация необходимо запускать в период минимальной нагрузки для того, чтобы добиться лучшего результата. Именно в этом и кроется основная претензия к этому режиму реорганизации, он не позволяет добиться такого же результата, как в случае OFFLINE реорганизации.

До версии HANA 2.0 SPS4, компания SAP рекомендовала использовать именно OFFLINE режим, для получения лучшего результата. При этом OFFLINE режим несёт в себе один существенный недостаток, логически вытекающий из его названия. Систему работающую в режиме 24х7 для реорганизации row-store пространства никто останавливать не будет. По этому, обычно, OFFLINE реорганизацию совмещают с другими работами, требующими останова системы.

Внимание! OFFLINE реорганизация может существенно увеличить время запуска базы данных HANA.

Начина я с версии SAP HANA 2.0 SPS4 стал доступен режим автоматической ONLINE реорганизации. По умолчанию раз в час запускается проверка на фрагментированность области row store. Если показатель полезного использования памяти менее 60% от размера области row-store, запускается автоматическая реорганизация. Пороговое значение фрагментированности, а также частота запуска проверки может быть изменена. Подробнее о автоматическом режиме можно прочитать в ноте 2789255 - Automatic Online Row Store Reorganization.

На этом я бы хотел завершить краткий обзор таблиц с типом хранения Row. Несмотря на преимущества колоночных таблиц, в базе данных HANA продолжают использоваться и строковые таблицы. В основном такие таблицы используются как технические или настроечные с относительно небольшим количеством записей, при этом основная роль отдана таблицам с колоночным типом хранения.

Подробнее..

Как сделать памятку по родословной греческих богов в SAP HANA Cloud

29.06.2020 14:12:48 | Автор: admin
В этом году у компании SAP появилось новое решение SAP HANA Cloud, которое предоставляет широкий спектр возможностей для работы с данными, позволяет создавать, запускать, развертывать новые и обновлять существующие приложения. Основу этого решения составляет SAP HANA, применяемая для работы с данными, требующими высокую скорость обработки. Мы называем такие данные горячими, поскольку они размещены в оперативной памяти. Это гарантирует быстрый доступ и высокую производительность. Кроме этого, в SAP HANA Cloud интегрировано озеро данных, и его развертывание происходит автоматически, а управление не вызывает затруднений. Оно реляционное и позволяет оптимизировать стоимость хранения структурированной информации. Там находятся холодные данные, то есть они будут обрабатываться несколько медленнее, чем горячие. SAP HANA Cloud предлагает и промежуточный уровень хранения данных SAP HANA Native Storage Extension, хранение данных на диске и загрузка через буферный кеш. Возможности многоуровневого хранения обеспечивают высокий показатель масштабирования и эластичности, оптимизации затрат без ущерба для производительности. Предлагаю разобраться как работает новинка на примере создания родословной греческих богов и героев.

image

За основу возьмем скрипты из приложения Appendix B Greek Mythology Graph Example документации SAP HANA Graph Reference для обычной платформы SAP HANA, которая развертывается локально в ЦОДе. Основное назначение этого примера показать аналитические возможности SAP HANA, показать, как можно анализировать взаимосвязь объектов и событий с помощью алгоритмов работы с графами. Мы не будем останавливаться подробно на этой технологии, основная идея будет понятна из дальнейшего изложения. Кому интересно могут разобраться самостоятельно, испытав возможности SAP HANA express edition или пройти бесплатный курс Analyzing Connected Data with SAP HANA Graph.
Давайте разместим данные в реляционном облаке SAP HANA Cloud и посмотрим возможности по анализу родственных связей греческих героев. Помните, в Мифах и легендах Древней Греции было очень много персонажей и к середине уже не помнишь кто сын и брат кого? Вот мы сделаем себе памятку и никогда уже не забудем.
Для начала создадим экземпляр SAP HANA Cloud. Это сделать достаточно просто, надо заполнить параметры будущей системы и подождать несколько минут, пока экземпляр будет для вас развернут (рис.1).

image
Рисунок 1

Итак, нажимаем кнопку Create Instance и перед нами открывается первая страница мастера создания, на которой надо указать краткое название экземпляра, задать пароль и привести описание (рис.2)
image
Рисунок 2

Нажимаем кнопку Step 2, теперь наша задача указать параметры будущего экземпляра SAP HANA. Здесь можно задать только размер оперативной памяти будущей системы, все остальные параметры будут определены автоматически (рис.3).

image
Рисунок 3

Мы видим, что сейчас у нас есть возможность выбрать минимальное значение 30Гб и максимальное 900Гб. Выбираем 30Гб и автоматически определяется, что при таком объеме памяти необходимо два виртуальных процессора для поддержки расчетов и 120Гб для хранения данных на диске. Здесь места выделяется больше, поскольку мы можем применять технологию SAP HANA Native Storage Extension (NSE). Если выбрать размер памяти больше, например, 255Гб, то потребуется уже 17 виртуальных процессоров и 720ГБ дисковой памяти (рис. 4).

image
Рисунок 4

Но нам столько памяти для примера не требуется. Возвращаем параметры в исходное значение и нажимаем Step 3. Теперь мы должны выбрать, будем ли использовать озеро данных. Для нас ответ очевиден. Конечно, будем. Именно такой эксперимент мы и хотим провести (рис.5).

image
Рисунок 5

На этом шаге у нас значительно больше возможностей и свободы по созданию экземпляра озера данных. Вы можете выбирать размеры необходимых вычислительных ресурсов и дискового хранилища. Параметры используемых компонент/узлов выберутся автоматически. Система сама определит необходимые вычислительные ресурсы для координатора и рабочих узлов. Если вы хотите побольше узнать об этих компонентах, то лучше обратится к ресурсам SAP IQ и озеру данных SAP HANA Cloud. А мы двигаемся дальше, нажимаем Step 4 (рис.6).

image
Рисунок 6

На этом шаге мы определим или ограничим IP адреса, которые могут получить доступ к будущему экземпляру SAP HANA. Как видим, это последний шаг нашего мастера (рис.7), осталось нажать Create Instance и пойти налить себе кофе.

image
Рисунок 7

Процесс запущен и пройдет совсем немного времени, мы как раз успели выпить крепкого кофе, несмотря на позднюю ночь. А когда еще можно спокойно экспериментировать с системой и прикручивать разные фишки? Итак, наша система создана (рис.8).

image
Рисунок 8

У нас есть два варианта: открыть SAP HANA Cockpit или SAP HANA Database Explorer. Мы знаем, что запустить второй продукт можно будет из Cockpit. Поэтому открываем SAP HANA Cockpit, заодно и посмотрим, что там есть. Но сначала необходимо будет указать пользователя и его пароль. Обратите внимание, что пользователь SYSTEM вам недоступен, вы должны применять DBADMIN. При этом указать пароль, который вы задали при создании экземпляра, как на рис.9.

image
Рисунок 9

Мы зашли в Cockpit и видим традиционный интерфейс SAP в виде плиточек, когда каждая из них отвечает за свою задачу. Справа в верхнем углу видим ссылку на SQL Console (рис.10).

image
Рисунок 10

Именно она нам позволяет перейти к SAP HANA Database Explorer.
image
Интерфейс этого инструмента похож на SAP Web IDE, но предназначен только для работы с объектами базы данных. В первую очередь, конечно, нас интересует как попасть в озеро данных. Ведь сейчас мы открыли инструмент для работы с HANA. Перейдем в навигаторе на пункт Remote Source и увидим ссылку на озеро (SYSRDL, RDL Relation Data Lake). Вот он желанный доступ (рис.11).

image
Рисунок 11

Двинемся дальше, мы же не должны работать под администратором. Нужно создать тестового пользователя, под которым проведем эксперимент с графовым движком HANA, но данные разместим в реляционном озере данных.

image
Рисунок 12
СКРИПТ:
CREATE USER tstuser PASSWORD Password1 NO FORCE_FIRST_PASSWORD_CHANGE SET USERGROUP DEFAULT;

Мы планируем работать с озером данных, поэтому надо обязательно дать права, например, HANA_SYSRDL#CG_ADMIN_ROLE, чтобы можно свободно создавать объекты, делать все, что нам вздумается.
image
СКРИПТ:
GRANT HANA_SYSRDL#CG_ADMIN_ROLE TO tstuser;
Теперь работа под администратором SAP HANA завершена, SAP HANA Database Explorer можно закрыть и нам надо войти в него под новым созданным пользователем: tstuser. Для простоты, вернемся в SAP HANA Cockpit и завершим сессию администратора. Для этого в левом верхнем углу есть такая ссылка Clear Credentials (рис.12).

image
Рисунок 12

После нажатия на нее нам снова надо войти в систему, но теперь под пользователем tstuser (рис.13)
image
Рисунок 13

И мы снова можем открыть SQL Console, чтобы вернуться в SAP HANA Database Explorer, но под новым пользователем (рис.14).

image
image
Рисунок 14

СКРИПТ:
SELECT SESSION_USER, CURRENT_SCHEMA FROM DUMMY;
Все, теперь мы уверены, что работаем с HANA под нужным пользователем. Пора создавать таблицы в озере данных. Для этого есть специальная процедура SYSRDL#CG.REMOTE_EXECUTE, в которую надо передать один параметр строку = команду. Используя, эту функцию создаем в озере данных таблицу (рис. 15), в которой будут хранится все наши персонажи: герои, греческие Боги и титаны.

image
Рисунок 15
СКРИПТ:
CALL SYSRDL#CG.REMOTE_EXECUTE ('
BEGIN

CREATE TABLE MEMBERS (
NAME VARCHAR(100) PRIMARY KEY,
TYPE VARCHAR(100),
RESIDENCE VARCHAR(100)
);

END');
И затем создаем таблицу в которой будем хранить родственные связи этих персонажей (рис. 16).

image
Рисунок 16

СКРИПТ:
CALL SYSRDL#CG.REMOTE_EXECUTE ('
BEGIN
CREATE TABLE RELATIONSHIPS (
KEY INTEGER UNIQUE NOT NULL,
SOURCE VARCHAR(100) NOT NULL,
TARGET VARCHAR(100) NOT NULL,
TYPE VARCHAR(100),
FOREIGN KEY RELATION_SOURCE (SOURCE) references MEMBERS(NAME) ON UPDATE RESTRICT ON DELETE RESTRICT,
FOREIGN KEY RELATION_TARGET (TARGET) references MEMBERS(NAME) ON UPDATE RESTRICT ON DELETE RESTRICT
);
END');
Мы не будем сейчас заниматься вопросами интеграции, это отдельная история. В исходном примере есть команды INSERT для создания греческих Богов и их родственных отношений. Используем эти команды. Надо только помнить, что команду мы передаем через процедуру в озеро данных, поэтому надо кавычки удвоить, как показано на рис.17.

image
Рисунок 17

СКРИПТ: CALL SYSRDL#CG.REMOTE_EXECUTE ('
BEGIN
INSERT INTO MEMBERS(NAME, TYPE)
VALUES (''Chaos'', ''primordial deity'');
INSERT INTO MEMBERS(NAME, TYPE)
VALUES (''Gaia'', ''primordial deity'');
INSERT INTO MEMBERS(NAME, TYPE)
VALUES (''Uranus'', ''primordial deity'');
INSERT INTO MEMBERS(NAME, TYPE, RESIDENCE)
VALUES (''Rhea'', ''titan'', ''Tartarus'');
INSERT INTO MEMBERS(NAME, TYPE, RESIDENCE)
VALUES (''Cronus'', ''titan'', ''Tartarus'');
INSERT INTO MEMBERS(NAME, TYPE, RESIDENCE)
VALUES (''Zeus'', ''god'', ''Olympus'');
INSERT INTO MEMBERS(NAME, TYPE, RESIDENCE)
VALUES (''Poseidon'', ''god'', ''Olympus'');
INSERT INTO MEMBERS(NAME, TYPE, RESIDENCE)
VALUES (''Hades'', ''god'', ''Underworld'');
INSERT INTO MEMBERS(NAME, TYPE, RESIDENCE)
VALUES (''Hera'', ''god'', ''Olympus'');
INSERT INTO MEMBERS(NAME, TYPE, RESIDENCE)
VALUES (''Demeter'', ''god'', ''Olympus'');
INSERT INTO MEMBERS(NAME, TYPE, RESIDENCE)
VALUES (''Athena'', ''god'', ''Olympus'');
INSERT INTO MEMBERS(NAME, TYPE, RESIDENCE)
VALUES (''Ares'', ''god'', ''Olympus'');
INSERT INTO MEMBERS(NAME, TYPE, RESIDENCE)
VALUES (''Aphrodite'', ''god'', ''Olympus'');
INSERT INTO MEMBERS(NAME, TYPE, RESIDENCE)
VALUES (''Hephaestus'', ''god'', ''Olympus'');
INSERT INTO MEMBERS(NAME, TYPE, RESIDENCE)
VALUES (''Persephone'', ''god'', ''Underworld'');
END');
И вторая таблица (рис. 18)

image
Рисунок 18

СКРИПТ:
CALL SYSRDL#CG.REMOTE_EXECUTE ('
BEGIN
INSERT INTO RELATIONSHIPS(KEY, SOURCE, TARGET, TYPE)
VALUES (1, ''Chaos'', ''Gaia'', ''hasDaughter'');
INSERT INTO RELATIONSHIPS(KEY, SOURCE, TARGET, TYPE)
VALUES (2, ''Gaia'', ''Uranus'', ''hasSon'');
INSERT INTO RELATIONSHIPS(KEY, SOURCE, TARGET, TYPE)
VALUES (3, ''Gaia'', ''Cronus'', ''hasSon'');
INSERT INTO RELATIONSHIPS(KEY, SOURCE, TARGET, TYPE)
VALUES (4, ''Uranus'', ''Cronus'', ''hasSon'');
INSERT INTO RELATIONSHIPS(KEY, SOURCE, TARGET, TYPE)
VALUES (5, ''Gaia'', ''Rhea'', ''hasDaughter'');
INSERT INTO RELATIONSHIPS(KEY, SOURCE, TARGET, TYPE)
VALUES (6, ''Uranus'', ''Rhea'', ''hasDaughter'');
INSERT INTO RELATIONSHIPS(KEY, SOURCE, TARGET, TYPE)
VALUES (7, ''Cronus'', ''Zeus'', ''hasSon'');
INSERT INTO RELATIONSHIPS(KEY, SOURCE, TARGET, TYPE)
VALUES (8, ''Rhea'', ''Zeus'', ''hasSon'');
INSERT INTO RELATIONSHIPS(KEY, SOURCE, TARGET, TYPE)
VALUES (9, ''Cronus'', ''Hera'', ''hasDaughter'');
INSERT INTO RELATIONSHIPS(KEY, SOURCE, TARGET, TYPE)
VALUES (10, ''Rhea'', ''Hera'', ''hasDaughter'');
INSERT INTO RELATIONSHIPS(KEY, SOURCE, TARGET, TYPE)
VALUES (11, ''Cronus'', ''Demeter'', ''hasDaughter'');
INSERT INTO RELATIONSHIPS(KEY, SOURCE, TARGET, TYPE)
VALUES (12, ''Rhea'', ''Demeter'', ''hasDaughter'');
INSERT INTO RELATIONSHIPS(KEY, SOURCE, TARGET, TYPE)
VALUES (13, ''Cronus'', ''Poseidon'', ''hasSon'');
INSERT INTO RELATIONSHIPS(KEY, SOURCE, TARGET, TYPE)
VALUES (14, ''Rhea'', ''Poseidon'', ''hasSon'');
INSERT INTO RELATIONSHIPS(KEY, SOURCE, TARGET, TYPE)
VALUES (15, ''Cronus'', ''Hades'', ''hasSon'');
INSERT INTO RELATIONSHIPS(KEY, SOURCE, TARGET, TYPE)
VALUES (16, ''Rhea'', ''Hades'', ''hasSon'');
INSERT INTO RELATIONSHIPS(KEY, SOURCE, TARGET, TYPE)
VALUES (17, ''Zeus'', ''Athena'', ''hasDaughter'');
INSERT INTO RELATIONSHIPS(KEY, SOURCE, TARGET, TYPE)
VALUES (18, ''Zeus'', ''Ares'', ''hasSon'');
INSERT INTO RELATIONSHIPS(KEY, SOURCE, TARGET, TYPE)
VALUES (19, ''Hera'', ''Ares'', ''hasSon'');
INSERT INTO RELATIONSHIPS(KEY, SOURCE, TARGET, TYPE)
VALUES (20, ''Uranus'', ''Aphrodite'', ''hasDaughter'');
INSERT INTO RELATIONSHIPS(KEY, SOURCE, TARGET, TYPE)
VALUES (21, ''Zeus'', ''Hephaestus'', ''hasSon'');
INSERT INTO RELATIONSHIPS(KEY, SOURCE, TARGET, TYPE)
VALUES (22, ''Hera'', ''Hephaestus'', ''hasSon'');
INSERT INTO RELATIONSHIPS(KEY, SOURCE, TARGET, TYPE)
VALUES (23, ''Zeus'', ''Persephone'', ''hasDaughter'');
INSERT INTO RELATIONSHIPS(KEY, SOURCE, TARGET, TYPE)
VALUES (24, ''Demeter'', ''Persephone'', ''hasDaughter'');
INSERT INTO RELATIONSHIPS(KEY, SOURCE, TARGET, TYPE)
VALUES (25, ''Zeus'', ''Hera'', ''marriedTo'');
INSERT INTO RELATIONSHIPS(KEY, SOURCE, TARGET, TYPE)
VALUES (26, ''Hera'', ''Zeus'', ''marriedTo'');
INSERT INTO RELATIONSHIPS(KEY, SOURCE, TARGET, TYPE)
VALUES (27, ''Hades'', ''Persephone'', ''marriedTo'');
INSERT INTO RELATIONSHIPS(KEY, SOURCE, TARGET, TYPE)
VALUES (28, ''Persephone'', ''Hades'', ''marriedTo'');
INSERT INTO RELATIONSHIPS(KEY, SOURCE, TARGET, TYPE)
VALUES (29, ''Aphrodite'', ''Hephaestus'', ''marriedTo'');
INSERT INTO RELATIONSHIPS(KEY, SOURCE, TARGET, TYPE)
VALUES (30, ''Hephaestus'', ''Aphrodite'', ''marriedTo'');
INSERT INTO RELATIONSHIPS(KEY, SOURCE, TARGET, TYPE)
VALUES (31, ''Cronus'', ''Rhea'', ''marriedTo'');
INSERT INTO RELATIONSHIPS(KEY, SOURCE, TARGET, TYPE)
VALUES (32, ''Rhea'', ''Cronus'', ''marriedTo'');
INSERT INTO RELATIONSHIPS(KEY, SOURCE, TARGET, TYPE)
VALUES (33, ''Uranus'', ''Gaia'', ''marriedTo'');
INSERT INTO RELATIONSHIPS(KEY, SOURCE, TARGET, TYPE)
VALUES (34, ''Gaia'', ''Uranus'', ''marriedTo'');
END');
Откроем теперь снова Remote Source. Нам надо на основании описания таблиц в озере данных создать виртуальные таблицы в HANA (рис. 19).

image
Рисунок 19

Находим обе таблицы, устанавливаем галочки напротив таблиц и нажимаем кнопку Create Virtual Object(s), как показано на рис.20.

image
Рисунок 20
У нас есть возможность указать схему, в которой виртуальные таблицы будут созданы. И там надо указать префикс, чтобы эти таблицы легче было найти. После этого мы можем в навигаторе выбрать Table, увидеть наши таблицы и посмотреть данные (рис. 21).

image
Рисунок 21

На этом шаге важно обратить внимание на фильтр внизу слева. Там должно быть указано имя нашего пользователя или наша схема TSTUSER.
Вот почти все готово. Мы создали в озере таблицы и загрузили в них данные, а для доступа к ним с уровня HANA у нас есть виртуальные таблицы. Мы готовы создать новый объект граф (рис. 22).

image
Рисунок 22

СКРИПТ:
CREATE GRAPH WORKSPACE GREEK_MYTHOLOGY
EDGE TABLE TSTUSER.RDL_RELATIONSHIPS
SOURCE COLUMN SOURCE
TARGET COLUMN TARGET
KEY COLUMN KEY
VERTEX TABLE TSTUSER.RDL_MEMBERS
KEY COLUMN NAME;
Все сработало, граф готов. И сразу можно попробовать сделать какой-нибудь простой запрос к данным графа, например, найти всех дочерей Хаоса и всех дочерей этих дочерей. Для этого нам поможет Cypher язык для анализа графов. Он был специально создан для работы с графами, удобный, простой и помогает решать сложные задачи. Нам только надо помнить, что скрипт Cypher надо обернуть в SQL запрос с помощью табличной функции. Посмотрите, как на этом языке решается наша задача (рис.23).

image
Рисунок 23

СКРИПТ:
SELECT * FROM OPENCYPHER_TABLE( GRAPH WORKSPACE GREEK_MYTHOLOGY QUERY
'
MATCH p = (a)-[*1..2]->(b)
WHERE a.NAME = ''Chaos'' AND ALL(e IN RELATIONSHIPS(p) WHERE e.TYPE=''hasDaughter'')
RETURN b.NAME AS Name
ORDER BY b.NAME
'
)
Проверим, как работает визуальный инструмент SAP HANA для анализа графов. Для этого в навигаторе выберем Graph Workspace (рис. 24).

image
Рисунок 24

И теперь можно увидеть наш граф (рис. 25).

image
Рисунок 25

Вы видите уже раскрашенный граф. Это мы сделали с помощью настроек в правой стороне экрана. Слева в верхнем углу показывается детальная информация по узлу, который в данный момент выделен.
Что ж Мы сделали это. Данные находятся в озере данных, а их анализ мы проводим инструментами в SAP HANA. Одна технология вычисляет данные, а другая отвечает за их хранение. Когда происходит обработка данных графа, они запрашиваются из озера данных и передаются в SAP HANA. Можем ли мы ускорить наши запросы? Как сделать так, чтобы данные хранились в оперативной памяти и не подгружались из озера данных? Есть простой, но не очень красивый способ создать таблицу, в которую загрузить содержимое таблицы озера данных (рис. 26).

image
Рисунок 26

СКРИПТ:
CREATE COLUMN TABLE MEMBERS AS (SELECT * FROM TSTUSER.RDL_MEMBERS)
Но есть еще один способ это применение репликации данных в оперативную память SAP HANA. Это может обеспечить лучшую производительность запросов SQL, чем доступ к данным, размещенным в озере данных с помощью виртуальной таблицы. Вы можете переключаться между виртуальными и таблицами репликации. Для этого необходимо к виртуальной таблице добавить таблицу реплики. Это можно сделать с помощью инструкции ALTER VIRTUAL TABLE. После чего, запрос, использующий виртуальную таблицу, автоматически обращается к таблице реплик, которая размещается в оперативной памяти SAP HANA. Давайте посмотрим, как это сделать, проведем эксперимент. Выполним такой запрос (рис. 27).

image
Рисунок 27

СКРИПТ:
SELECT R.KEY, R.SOURCE, R.TYPE
FROM TSTUSER.RDL_RELATIONSHIPS R inner join TSTUSER.MEMBERS M on R.SOURCE=M.NAME

И посмотрим, сколько надо было времени, чтобы выполнить этот запрос (рис. 28).

image
Мы видим, потребовалось 92 миллисекунды. Давайте включим механизм репликации. Для этого надо сделать ALTER VIRTUAL TABLE виртуальной таблицы, после чего данные Озера будут реплицированы в оперативную память SAP HANA.

image
Рисунок 28

СКРИПТ:
ALTER VIRTUAL TABLE RDL_RELATIONSHIPS ADD SHARED SNAPSHOT REPLICA COLUMN LOADABLE;
Проверим время выполнения, как на рисунке 29.

image
Рисунок 29

Получили 7 миллисекунд. Это отличный результат! Минимальными усилиями мы переместили данные в оперативную память. Причем, если вы закончили анализ и вас устроит производительность, можно снова отключить репликацию (рис. 30).

image
Рисунок 30

СКРИПТ:
ALTER VIRTUAL TABLE RDL_RELATIONSHIPS DROP REPLICA;
Теперь данные опять подгружаются из Озера только по запросу, а оперативная память SAP HANA свободна для новых задач. Сегодня мы выполнили, на мой взгляд, интересную работу и протестировали SAP HANA Cloud на быстроту, легкую организацию единой точки доступа к данным. Продукт будет развиваться, и мы ожидаем, что в ближайшее время может появится прямое соединение с озером данных. Новая возможность обеспечит более высокую скорость загрузки больших объемов информации, отказ от ненужных служебных данных и повышение производительности операций, специфичных для озера данных. Мы будем создавать и выполнять хранимые процедуры непосредственно в облаке данных на технологии SAP IQ, то есть сможем применять обработку и бизнес-логику там, где находятся сами данные.
Александр Тарасов, старший бизнес-архитектор SAP CIS
Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru