Интернет-журнал «FORS»

Архив номеров На Главную

Обработка данных с опцией In-

Memory ускоряет бизнес-
аналитику
Сверхпроизводительная бизнес-аналитика с Oracle
Database In-Memory

Источник статьи в оригинале: Oracle Magazine, январь-

февраль 2015
http://www.oracle.com/technetwork/issue-archive/2015/15-
jan/o15ba-2398995.html

Марк Риттман
Oracle ACE Director,
сооснователь компании Rittman Mead,
Oracle Gold Partner

Опция In-Memory добавляет в базу данных Oracle

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

Когда для таблицы базы данных,

материализованного представления или набора
столбцов включается опция In-Memory, Oracle Database автоматически создает
в памяти копию данных, синхронизированную с их построчной записью, а затем
использует этот новый оптимизированный поколоночный формат данных,
чтобы выполнять запросы, связанные с процессами бизнес-аналитики.
Поскольку Oracle Database In-Memory не требует никаких изменений на уровне
приложений, то при использовании решений Oracle Business Intelligence легко
воспользоваться преимуществами Oracle Database In-Memory без какой-либо
адаптации существующих отчетов, процедур загрузки или способов хранения
данных.

В этой статье мы загрузим в Oracle Database 12c Release 1 (12.1.0.2.0) набор

данных BI AIRLINES, который входит в состав последней версии Oracle
Business Intelligence Enterprise Edition 11g SampleApp (SampleApp v406 по
ссылке oracle.com/technetwork/middleware/bi-foundation/obiee-samples-
167534.html). Используя эти данные, мы создадим простой репозиторий и
анализ, для которого сохраним план выполнения запроса и время отклика
перед тем, как опция Oracle Database In-Memory будет включена. Затем мы
подключим Oracle Database In-Memory, загрузим таблицы в память и выполним
те же тесты снова, чтобы продемонстрировать, как эта новая опция базы
данных значительно повышает производительность таких аналитических
запросов.

Если вы хотите самостоятельно выполнить тестовые примеры из этой статьи,

вам потребуется загрузить и установить следующее программное обеспечение
и настроить сетевое подключение между двумя серверами:

Oracle Database 12c Release 1 (12.1.0.2.0) по ссылке

bit.ly/databasedownloads

Oracle Business Intelligence 11g (11.1.1.3 или новее) по ссылке

bit.ly/1kQW3Ey

Кроме того, если вы используете Oracle Business Intelligence на платформе

UNIX или Linux, вам потребуется окружение клиента Microsoft Windows, чтобы
запустить утилиту администрирования Oracle Business Intelligence для создания
репозитория BI.

Чтобы читателям не пришлось загружать целиком образ SampleApp v406

VirtualBox ради получения набора данных BI AIRLINES, я выделил этот набор
данных из базы даных SampleApp v406 как файл экспорта Oracle Database и
сделал доступным для скачивания в заархивированном и сжатом виде по
ссылке bit.ly/flights_data.

Размер загружаемого файла — 355 Мб, и чтобы скачать и распаковать его,

потребуется около 3,5 Гб свободного места в файловой системе вашего
сервера базы данных, а также еще 2,5 Гб места в базе данных для размещения
импортированного набора данных.

Чтобы загрузить и установить набор данных SampleApp v406 в вашу Oracle

Database 12c Release 1 (12.1.0.2.0), надо выполнить следующие шаги:

1. Загрузите файл bit.ly/flights_data и скопируйте его в директорию на сервере

базы данных, например, в /home/oracle.

2. Распакуйте файл следующей командой:

tar -zxvf flights_data.dmp.tar.gz

В результате у вас появится файл экспорта базы данных

flights_data.dmp.

3. Используйте SQL*Plus и установите соединение как пользователь SYS.

Создайте аккаунт пользователя, в котором будут храниться тестовые
данные, и откройте ему доступ к новому динамическому представлению
характеристик (которое будет использоваться ниже для отчета о хранении
данных в памяти), выполнив следующие команды:

sqlplus / as sysdba

create user flights_data

identified by welcome1
quota unlimited on users;

grant connect, resource to

flights_data;

grant select on v_$im_segments to

flights_data;

exit

4. Зайдя на сервер от имени пользователя oracle, с помощью утилиты IMP из

командной строки импортируйте содержимое загруженного файла
экспорта базы данных в схему FLIGHTS_DATA, созданную выше. Для этого
установите параметры соединения для пользователя DBA, например,
SYSTEM, и используйте следующую команду:

imp system/password
file=./flights_data.dmp
fromuser=BI_AIRLINES
touser=FLIGHTS_DATA

5. Установите соединение с SQL*Plus (как пользователь FLIGHTS_DATA) и

убедитесь, что тестовые таблицы базы данных находятся на своем месте:
 sqlplus flights_data/welcome1

select table_name from user_tables;

Примечание: Предыдущие шаги даны в предположении, что база данных

Oracle Database 12c Release 1 (12.1.0.2.0) установлена на сервере под
управлением Linux.

Ожидается, что читатели этой статьи в достаточной степени знакомы с

процессом создания репозитория BI и анализа. Если вам требуется более
подробное описание этих действий, обратитесь к Oracle Fusion Middleware
Metadata Repository Builder’s Guide для Oracle Business Intelligence Enterprise
Edition и Oracle Fusion Middleware User’s Guide для Oracle Business Intelligence
Enterprise Edition.

Создание репозитория

В этом разделе мы опишем, как создать репозиторий BI для тестирования

производительности до и после включения Oracle Database In-Memory.

1. С рабочего стола Windows запустим утилиту администрирования Oracle

Business Intelligence и откроем существующий репозиторий или установим
соединение с ним, либо создадим новый репозиторий для этого
упражнения.

2. Открыв этот репозиторий для редактирования, выберем File -> Import

Metadata, установим соединение с экземпляром Oracle Database 12c и
начнем импортировать метаданные таблиц. Чтобы установить соединение
со схемой, содержащей тестовые данные, выберем и введем следующие
параметры, подставляя вместо TNS service name нашу базу данных:

Connection Type: OCI 10g/11g

Data Source Name: <<имя вашего TNS сервиса, например, orcl_inmem>>
User Name: flights_data
Password: welcome1

Нажмем Next, чтобы продолжить.

3. На странице Create New Repository - Select Metadata Objects выберем

схему FLIGHTS_DATA в панели слева и нажмем кнопку Import Selected,
чтобы выбрать все таблицы в схеме.

В диалоговом окне Connection Pool - Connection Pool оставим всем

параметрам значения по умолчанию и нажмем OK, чтобы закрыть
диалоговое окно. Затем нажмем Finish, чтобы завершить процесс и
вернуться в главное окно, где на панели Physical должны отобразиться
записи для четырех таблиц в схеме FLIGHTS_DATA.

4. Для таблиц в схеме FLIGHTS_DATA уже есть отношения первичного ключа и

внешнего ключа, определенные для таблиц фактов и измерений. Можно
перетащить таблицы на панель Business Model and Mapping утилиты
администрирования BI, чтобы быстро создать бизнес-модель. Для этого
удерживайте Ctrl на клавиатуре, кликните на физической схеме
FLIGHTS_DATA и перетащите ее на панель Business Model and Mapping.

В созданной бизнес-модели откроем логическую таблицу PERFORMANCE и удалим

все столбцы, кроме ARRDELAY, DEPDELAY и FLIGHTS. Затем дважды щелкнем на
каждом из оставшихся измерений, перейдем на вкладку Aggregation в
диалоговом окне Properties и выберем Count в качестве типа агрегации по
умолчанию для FLIGHTS, а Avg для ARRDELAY и DEPDELAY. Перетащим бизнес-
модель FLIGHTS_DATA целиком на панель Presentation и создадим новую
предметную область для отчетов так, чтобы новая физическая база данных,
бизнес-модель и предметная область выглядели как на рис. 1.
 Рис. 1. Тестовые данные с репозиторием

Сохраните репозиторий командой File -> Save, и если вы работаете с

репозиторием онлайн, то проверьте его на целостность перед окончанием
сохранения. Если вы работаете с репозиторием оффлайн, с помощью
инструмента Fusion Middleware Control в составе Oracle Enterprise Manager
загрузите ваш репозиторий на сервер Oracle Business Intelligence и
перезапустите ваш экземпляр Business Intelligence, чтобы репозиторий стал
доступен пользователям.

Также надо убедиться, что в вашем экземпляре Business Intelligence отключено

кэширование запросов. Войдите в Fusion Middleware Control и отключите
кэширование, если оно было включено. (Если кэширование не будет отключено,
то при повторном запуске тестового отчета сервер Oracle Business Intelligence
Server не будет посылать новый физический SQL-запрос к базе данных, а
вместо этого возьмет результаты анализа из кэша запросов.) Более подробное
руководство по проверке и отключению кэширования запросов читатель найдет
в Oracle Fusion Middleware System Administrator’s Guide для Oracle Business
Intelligence Enterprise Edition.

Построение анализа на стандартных таблицах

хранилища данных

Для демонстрации эффекта, которого достигает на наборе данных сжатое

поколоночное хранение данных в памяти, мы сначала создадим анализ на
данных, которые хранятся в построчном формате на диске.

С помощью веб-браузера откроем стартовую страницу Oracle Business

Intelligence по адресу http://[server_name:port]/analytics (например,
http://obi11gserver:9704/analytics). Авторизуемся и создадим следующий
новый анализ, используя предметную область FLIGHTS_DATA:

1. В качестве критериев анализа выберем измерения PERFORMANCE.FLIGHTS

и PERFORMANCE.DEPDELAY и столбцы аттрибутов
OBIEE_GEO_ORIG.TR_AIRPORT_NAME и OBIEE_GEO_DEST.TR_STATE_NAME.

2. Для нашего анализа создадим следующие два фильтра:

OBIEE_GEO_ORIG.AIRPORT is equal to/is in SFO; ORD; LAX; DEN

OBIEE_GEO_DEST.TR_STATE_NAME is equal to / is in Florida; Texas

3. Для записи результатов анализа создадим представление сводной

таблицы с TR_AIRPORT_NAME в качестве строк и TR_STATE_NAME в качестве
столбцов, так чтобы анализ суммировал общее число полетов и среднюю
 задержку вылета в минутах для полетов из этих четырех аэропортов во
Флориду и Техас, как показано на рис. 2.

Рис. 2. Тестовый анализ

Обратите внимание, как долго выполняется запрос. В моем экземпляре Oracle

Database 12c, с 6 миллионами записей о полетах в главной таблице фактов,
результаты запроса отобразились в браузере только через 10 секунд. Этот
запрос относится в точности к тому типу запросов, которые могут быть
оптимизированы с Oracle Database In-Memory. А именно, с опцией In-Memory
можно повысить производительность следующих типов операций над базой
данных:

запросы, которые обрабатывают большое количество строк, фильтруя

значения с помощью операторов сравнения =, <, > и операторов IN;

запросы, которые возвращают небольшое подмножество строк из таблицы

или материализованного представления;

запросы, которые объединяют маленькие таблицы с большой;

запросы, которые агрегируют данные.

Это в точности такие типы запросов, которые генерируются решениями Oracle

Business Intelligence при отображении информации на информационных
панелях и в анализах. Теперь посмотрим, что требуется, чтобы включить для
наших четырех таблиц обработку в оперативной памяти с помощью Oracle
Database In-Memory.

Включение опции In-Memory в Oracle Database 12c

Прежде чем сделать наши четыре таблицы доступными для хранения и

обработки в оперативной памяти, вам или вашему администрату базы данных
потребуется включить Oracle Database In-Memory, выделив неоходимый объем
памяти для поколоночного хранения таблиц из системной глобальной области
SGA. При этом вы, возможно, решите увеличить общий объем SGA, чтобы
компенсировать количество памяти, выделенное для поколоночного хранения.

Чтобы проверить объем SGA в Oracle Database 12c Release 1 (12.1.0.2.0),

увеличить его на 1 Гб и выделить эту дополнительную память для
поколоночного хранения, выполним следущие шаги:

1. Установим соединение с базой данных, содержащей таблицы, которые

требуется настроить для хранения в памяти. Авторизуемся от имени
пользователя с привилегиями уровня SYSDBA, например, пользователя SYS:

sqlplus sys/password@orcl as sysdba

2. С помощью следующей команды отобразим текущее значение параметра

SGA_TARGET:

SHOW PARAMETER sga_target

 Чтобы увеличить объем SGA, например, с 7056 Мб до 8080 Мб (на 1024
Мб — количество памяти, которое мы отведем для поколоночного
хранения таблиц), следующей командой увеличим общий размер
SGA_TARGET:

ALTER SYSTEM SET sga_target = 8080M

SCOPE = spfile;

3. Зарезервируем 1024 Мб памяти для поколоночного хранения, чтобы

включить опцию In-Memory при перезапуске базы данных, следующим
образом:

ALTER SYSTEM
SET inmemory_size = 1024M
SCOPE = spfile;

4. Чтобы перезапустить базу данных с новыми размерами SGA и области

поколоночного хранения в памяти, введем следующие команды:

shutdown immediate;
startup;

База данных перезапустится и отобразит новые размеры статических

пулов в SGA, включая область для поколоночного хранения, которую мы
только что выделили. Вот пример такого отчета:

SQL> startup
ORACLE instance started.

Total System Global Area

7398752256 bytes
Fixed Size 2941528 bytes
Variable Size 1207963048 bytes
Database Buffers 5100273664 bytes
Redo Buffers 13832192 bytes
In-Memory Area 1073741824 bytes
Database mounted.
Database opened.

Теперь все готово для хранения и анализа в памяти схемы FLIGHTS_DATA.

Настройка таблиц для хранения в памяти и повторный

запуск запроса

Для поколоночного хранения в памяти можно выбрать отдельные столбцы из

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

Можно выбрать, оставить ли данные в поколоночном хранилище без сжатия

или применить одну из степеней сжатия, оптимизированную по скорости
работы либо объему. В нашем примере мы оставим степень сжатия по
умолчанию, MEMCOMPRESS FOR QUERY LOW — степень сжатия, наиболее
оптимизированная по производительности выполнения запросов.

Чтобы сделать наши таблицы доступными для поколоночного хранения и

анализа в памяти с такими настройками, с помощью SQL*Plus выполним
следующие шаги:

1. Установите соединение с SQL*Plus как пользователь FLIGHTS_DATA и

введите команды

ALTER TABLE obiee_geo_orig inmemory

priority high;

ALTER TABLE obiee_geo_dest inmemory

priority high;
 ALTER TABLE unique_carriers inmemory
priority high;

ALTER TABLE performance inmemory

priority high;

2. Чтобы проверить атрибуты In Memory для наших таблиц можно запросить

соответствующие новые столбцы в представлении USER_TABLES:

SELECT table_name
, inmemory
, inmemory_priority
, inmemory_compression
FROM user_tables;

3. Чтобы проверить все или некоторые таблицы на успешную загрузку в

память, можно запросить новое динамическое представление
характеристик V$IM_SEGMENTS:

SELECT v.owner
, v.segment_name name
, v.populate_status status
, v.bytes
, v.inmemory_size
, v.bytes_not_populated
missing_bytes
FROM v$im_segments v;

Обратите внимание, что если вы захотите получить доступ к этому

динамическому представлению характеристик от имени пользователя без
привилегий SYSDBA, вам потребуется получить доступ на запрос SELECT к
представлению V$IM_SEGMENTS, полученный от одного из пользователей с
привилегиями SYSDBA, например, от пользователя SYS.

Выполнив последний запрос, мы вероятно увидим, что таблицы меньших

размерностей уже загружены в память, а для полной загрузки в память таблицы
PERFORMANCE придется подождать около минуты. База данных Oracle Database в
дальнейшем будет автоматически загружать эти таблицы в память при каждом
своем перезапуске или при первом доступе к таблице (если параметру
приоритета загрузки установлено значение NONE).

Теперь вернемся в Oracle Business Intelligence к нашему анализу и заново

запустим запрос, исходные данные для которого теперь находятся в памяти в
сжатом формате, оптимизированном в сторону скорости выполнения запросов.
Результаты будут готовы намного быстрее, чем при первом запуске.

Когда я запустил запрос для данных в памяти, он выполнился приблизительно

вдвое быстрее, чем выполнялся до того, как данные были загружены в память.
А именно, выполнение заняло 5 секунд против 10 секунд, которые требовались
до включения опции Oracle Database In-Memory, и все это без каких-либо
изменений в репозитории BI, отчетах или модели данных.

Заключение

Опция Oracle Database In-Memory размещает ваши наиболее востребованые

для отчетов данные в оптимизированном поколоночном хранилище в памяти,
которое автоматически синхронизируется с построчным хранилищем данных, и
такое поколоночное размещение в памяти может значительно уменьшить время
отклика для запросов, генерируемых решениями Oracle Business Intelligence.
База данных Oracle Database 12c автоматически управляет поколоночным
хранилищем в памяти, получая данные для отчетов, анализов и
информационных панелей, не требуя каких-либо изменений в репозитории BI
или пользовательских отчетах.