Oracle Database In-Memory

ТЕХНИЧЕСКИЙ ДОКУМЕНТ ORACLE | ИЮЛЬ 2015

Содержание

Краткий обзор ..................................................................................................................................................................3

Целевая аудитория .........................................................................................................................................................3

Введение..........................................................................................................................................................................4

Опция Oracle Database In-Memory .................................................................................................................................5

Строчный формат в сравнении с колоночным форматом........................................................................................5

In-Memory колоночное хранилище .............................................................................................................................6

Загрузка объектов в In-Memory колоночное хранилище...........................................................................................7

Ограничения.................................................................................................................................................................9

In-Memory сжатие данных .........................................................................................................................................10

Oracle Compression Advisor .......................................................................................................................................11

In-Memory сканирование данных ..............................................................................................................................12

In-Memory Storage индекс (In-Memory индекс хранения) ........................................................................................12

SIMD Векторная обработка .......................................................................................................................................13

In-Memory Соединения ..............................................................................................................................................14

In-Memory Агрегирование данных ............................................................................................................................16

DML и In-Memory колоночное хранилище ...................................................................................................................18

Массовая загрузка данных (Bulk Data Loads) ..........................................................................................................19

Загрузка данных с помощью обмена секциями.......................................................................................................19

Обработка транзакций...............................................................................................................................................20

Повторная загрузка данных ......................................................................................................................................21

Накладные расходы на поддержание транзакционной согласованности IM колоночного хранилища..................................................................................................................................................................22

IM колоночное хранилище в RAC ................................................................................................................................23

In-Memory отказоустойчивость .................................................................................................................................24

IM колоночное хранилище в мультиарендном окружении .........................................................................................25

Контроль использования Oracle Database In-Memory ................................................................................................27

Основные параметры инициализации .....................................................................................................................27

Дополнительные параметры инициализации..........................................................................................................28

Хинты оптимизатора..................................................................................................................................................29

1

Мониторинг и управление Oracle Database In-Memory...............................................................................................31

Мониторинг объектов в In-Memory колоночном хранилище...................................................................................31

Управление потреблением CPU ресурсов при загрузке данных в IM колоночное хранилище ...........................32

Заключение....................................................................................................................................................................34

2

3

Краткий обзор

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

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

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

Целевая аудитория

Предполагается, что у читателей имеется практический опыт работы с технологиями Oracle Database, связанный с администрированием баз данных или управлением их производительностью.

4

Введение

Современная информационная архитектура гораздо более динамична, чем еще несколько лет назад. Сегодня бизнес-пользователям нужна информация более аналитического характера, позволяющая им как можно быстрее принимать решения. Чтобы идти в ногу со временем и справляться с увеличивающимся спросом, компании вынуждены хранить аналитические данные в своих операционных системах, в дополнение к хранилищам данных, что приводит к появлению конфликтов между транзакционными нагрузками, состоящих из частых операций вставки и обновления данных, и запросами типа “отчёт”, сканирующими большие объемы данных.

С введением Oracle Database In-Memory одна база данных теперь может эффективно поддерживать смешанные рабочие нагрузки, обеспечивая оптимальную производительность для транзакций и одновременно поддерживая аналитику в реальном времени и отчётность. Это возможно благодаря уникальной «двухформатной» архитектуре, которая поддерживает данные в существующем строчном формате Oracle для OLTP-операций, а также в новом In-Memory колоночном формате, оптимизированном для аналитической обработки. Благодаря In-Memory киоски и хранилища данных предоставляют пользователям больше нерегламентированной аналитики, что дает возможность выполнять несколько запросов за тот же промежуток времени, который сейчас уходит на обработку одного запроса.

Внедрение In-Memory колоночного формата в существующее программное обеспечение Oracle Database гарантирует его полную совместимость со ВСЕМИ существующими функциями и не требует никаких изменений на уровне приложений. Компании, которые стремятся стать предприятиями реального времени, могут с большей легкостью достигать своих целей вне зависимости от того, какими приложениями они пользуются. В настоящей статье описываются основные компоненты Oracle Database In-Memory и предоставляются простыеи воспроизводимые примеры, которые помогут читателям ознакомиться с вышеуказанными компонентами. В ней также описывается, как Database In-Memory может быть интегрирована в существующие транзакционные системы и среды хранения данных для улучшения их производительности и управляемости.

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

5

Опция Oracle Database In-Memory

Строчный формат в сравнении с колоночным форматом

В СУБД Oracle Database данные традиционно хранились в строчном формате. В базе данных строчного формата каждая новая транзакция или запись, которая хранится в базе данных, представлена в виде новой строки в таблице. Эта строка состоит из нескольких столбцов, при этом каждый столбец представляет определенный атрибут записи. Строчный формат идеально подходит для систем обработки транзакций в режиме реального времени, так как формат строки обеспечивает быстрый доступ ко всем столбцам записи, поскольку все данные конкретной записи хранятся вместе в оперативной памяти и на диске.

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

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

До сих пор можно было выбирать только один формат, и данный выбор приходилось делать между неоптимальной производительностью OLTP или неоптимальной производительностью аналитики.

Oracle Database In-Memory (Database In-Memory) совмещает в себе как производительность OLTP, так и производительность аналитики, предоставляя возможность размещения данных в оперативной памяти как в строчном формате (буферный кэш), так и в новом In-Memory колоночном формате.

Обратите внимание, что архитектура двойного формата не требует двойного объема памяти. В отличие от буферного кэша, который в течение многих десятилетий оптимизировался таким образом, чтобы эффективно работать с базами данных, объём которых многократно превышает его размер, размер памяти для данных в колоночном формате должен быть достаточным, чтобы разместить в ней все In-Memory объекты. На практике можно ожидать, что архитектура двойного формата потребует менее 20% дополнительных расходов с точки зрения увеличения общего объема памяти. Это небольшая цена за оптимальную производительность в любое время для любых типов нагрузок.

6

Рис. 1. Уникальная архитектура Oracle двойного формата

Благодаря уникальному подходу Oracle на диске продолжает оставаться одна копия таблицы, что позволяет избежать дополнительных расходов на хранение и проблем синхронизации. База данных обеспечивает полную согласованность транзакций между строчным и колоночным форматами точно так же, как сегодня поддерживается согласованность между таблицами и индексами. Оптимизатор запросов Oracle полностью поддерживает колоночный формат. Он автоматически перенаправляет аналитические запросы на колоночный формат, а OLTP операции - на строчный формат, обеспечивая высокую производительность и полную согласованность данных для всех рабочих нагрузок, не требуя каких-либо изменений приложений.

In-Memory колоночное хранилище

Database In-Memory использует In-Memory колоночное хранилище (IM column store – колоночное хранилище в оперативной памяти), которое является новым компонентом системной глобальной области Oracle Database (SGA) под названием In-Memory Area. Данные в IM (In-Memory) колоночном хранилище хранятся не в традиционном строчном формате, используемом СУБД Oracle Database, а в новом колоночном формате. IM колоночное хранилище не заменяет собой буферный кэш, но дополняет его, так что данные теперь могут храниться в оперативной памяти как в строчном формате, так и в колоночном формате.

In-Memory Area является статическим пулом внутри системной глобальной области SGA, размер которой контролируется инициализационным параметром INMEMORY_SIZE (по умолчанию равен 0). Текущий размер In-Memory Area можно посмотреть в представлении V$SGA. Поскольку этот пул является статическим, любые изменения параметра INMEMORY_SIZE вступают в силу только после перезапуска экземпляра базы данных. Автоматическое управление памятью (AMM) также не влияет на этот параметр и не регулирует его. Размер In-Memory Area должен быть не менее 100 МБ.

In-Memory Area подразделяется на два пула: пул из 1 МБ блоков, используемый для размещения колоночных данных,и пул из 64K блоков, используемый для хранения метаданных об объектах в IM колоночном хранилище . Объем доступной памяти в каждом пуле можно посмотреть в представлении V$INMEMORY_AREA. Относительный размер двух пулов определяется внутренней

7

логикой, и большая часть In-Memory Area отводится 1 МБ пулу.

Рис. 2. Подробная информация о распределении пространства внутри INMEMORY_AREA, которая видна в V$INMEMORY_AREA

Загрузка объектов в In-Memory колоночное хранилище

В отличие от чисто In-Memory базы данных, не все объекты в базе данных Oracle необходимо загружать в IM колоночное хранилище . В IM колоночное хранилище следует загружать только наиболее важные с точки зрения производительности данные. Наименее важные с точки зрения производительности данные могут находиться на менее дорогостоящих картах флэш-памяти или дисках. Конечно, если ваша база данных достаточно мала, вы можете загрузить в IM колоночное хранилище все свои таблицы. Database In-Memory вводит новый атрибут INMEMORY для таблиц и материализованных представлений. В IM колоночное хранилище загружаются только объекты с атрибутом INMEMORY. Атрибут INMEMORY может быть указан для табличного пространства, таблицы, (суб)партиции или материализованного представления. Если он задан на уровне табличного пространства, то все новые таблицы и материализованные представления в табличном пространстве будут по умолчанию его наследовать и помечаться для размещения в IM колоночном хранилище.

ALTER TABLESPACE ts_data DEFAULT INMEMORY;

Рис. 3. Включение атрибута In-Memory для табличного пространства ts_data посредством указания атрибута INMEMORY

По умолчанию все столбцы в объекте с атрибутом INMEMORY будут загружаться в IM колоночное хранилище. Тем не менее, при желании можно загрузить только часть столбцов. Например, следующая команда устанавливает атрибут In-Memory для таблицы SALES в демонстрационной схеме SH, но исключает столбец PROD_ID.

ALTER TABLE sales INMEMORY NO INMEMORY(prod_id);

Рис. 4. Включение атрибута In-Memory для таблицы sales при исключении столбца prod_id

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

Чтобы указать, что объект больше не является In-Memory кандидатом и мгновенно удалить его из IM колоночного хранилища, необходимо просто указать ключевое слово NO INMEMORY.

8

ALTER TABLE sales MODIFY PARTITION SALES_Q1_1998 NO INMEMORY;

Рис. 5. Выключение атрибута In-Memory для партиции таблицы sales посредством указания ключевого слова NO INMEMORY

IM колоночное хранилище заполняется данными с помощью набора фоновых процессов, называемых рабочими процессами (ora_w001_orcl). При этом база данных остается полностью активной / доступной. Напротив, чисто In-Memory база данных не может быть доступна до тех пор, пока все данные не будут загружены в оперативную память, в результате чего возникают серьезные проблемы с доступностью базы данных.

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

По аналогии с тем, как табличное пространство на диске состоит из нескольких экстентов, IM колоночное хранилище состоит из нескольких блоков In-Memory Compression Unit (IMCU). Каждый рабочий процесс захватывает свой блок IMCU и заполняет его назначенным ему набором блоков базы данных. При заполнении данные не сортируются и не упорядочиваются каким-то определенным образом. Данные считываются в том же порядке, в котором они появляются в строчном формате.

Объекты загружаются в IM колоночное хранилище в порядке приоритета сразу же после открытия базы данных или после того, как они сканируются (запрашиваются) в первый раз. Порядок, в котором загружаются объекты, контролируется ключевым словом PRIORITY («приоритет»), для которого предусмотрены пять уровней (см. рисунок 7). Значение PRIORITY по умолчанию — NONE, что означает, что объект загружается только после того, как он сканируется в первый раз. Прежде чем может начаться загрузка объектов с более низким приоритетом, должны быть загружены все объекты с более высоким приоритетом. Тем не менее, порядок загрузки может быть проигнорирован, если началось сканирование объекта без атрибута PRIORITY, вызвавшее его загрузку в IM колоночное хранилище.

ALTER TABLE customers INMEMORY PRIORITY CRITICAL;

Рис. 6. Включение атрибута In-Memory для таблицы customers с уровнем приоритета «критический»

9

ПРИОРИТЕТ ОПИСАНИЕ

CRITICAL Объект загружается сразу же после открытия базы данных

HIGH Объект загружается после того, как будут загружены все CRITICAL объекты, если в

MEDIUM Объект загружается после того, как будут загружены все CRITICAL и HIGH объекты, если в IM колоночном хранилище останется место

LOW Объект загружается после того, как будут загружены все CRITICAL , HIGH и MEDIUM объекты, если в IM колоночном хранилище останется место

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

Рис. 7. Различные уровни приоритета, контролируемые ключевым словом PRIORITY в выражении INMEMORY

Ограничения

Почти все объекты в базе данных могут быть загружены в IM колоночное хранилище. Тем не менее, имеется несколько исключений. Следующие объекты базы данных не могут быть загружены в IM колоночное хранилище:

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

SYSTEM или SYSAUX

Index Organized Tables (IOT)

кластеризованные таблицы

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

Данные типа LONG (не рекомендуются к использованию, начиная с версии СУБД Oracle Database 8i)

внестрочный LOB (Out of line LOBS)

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

Объекты, размер которых меньше 64 Кбайт, не загружаются в память, так как они будут занимать

10

значительное пространство внутри IM колоночного хранилища, поскольку память в нём выделяется блоками по 1 МБ.

В текущей версии Oracle Database IM колоночное хранилище не может использоваться на резервном Active Data Guard экземпляре. Однако оно может использоваться на логическом резервном экземпляре Logical Standby, а также на экземпляре, поддерживаемом с помощью Oracle Golden Gate.

In-Memory сжатие данных

Обычно сжатие рассматривается только в качестве механизма экономии пространства. Но в случае IM колоночного хранилища загружаемые в него данные сжимаются с использованием набора новых алгоритмов сжатия, которые помогают не только экономить пространство, но и повышать скорость выполнения запросов. Новый Oracle In-Memory формат сжатия данных позволяет выполнять запросы непосредственно на сжатых столбцах. Это означает, что все операции сканирования и фильтрации будут выполняться на гораздо меньшем объёме данных. Распаковка сжатых данных выполняется только тогда, когда это требуется для формирования результата запроса.

In-Memory сжатие данных задается с помощью ключевого слова MEMCOMPRESS при задании атрибута INMEMORY. Имеется шесть уровней, каждый из которых обеспечивает различный уровень сжатия и производительности.

УРОВНИ СЖАТИЯ ДАННЫХ ОПИСАНИЕ

NO MEMCOMPRESS

Данные при заполнении не сжимаются

MEMCOMPRESS FOR DML

Минимальное сжатие, оптимизированное для производительности DML операций

MEMCOMPRESS FOR QUERY LOW

Метод сжатия, оптимизированный для производительности запросов (метод по умолчанию)

MEMCOMPRESS FOR QUERY HIGH

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

MEMCOMPRESS FOR CAPACITY LOW

Метод сжатия для большей экономии пространства

MEMCOMPRESS FOR CAPACITY HIGH

Метод сжатия для наибольшей экономии пространства

Рис. 8. Различные уровни сжатия, задаваемые ключевым словом MEMCOMPRESS выражения INMEMORY

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

11

широко распрстранённые методы сжатия, такие как Dictionary Encoding, Run Length Encoding и Bit-Packing. В опциях FOR CAPACITY используется дополнительная техника сжатия данных поверх FOR QUERY сжатия, которая может оказывать существенное влияние на производительность, так как каждая запись должна быть распакована до того, как можно будет применить предикаты выражения WHERE. В опции FOR CAPACITY LOW используется патентованный метод сжатия данных под названием OZIP, который позволяет очень быстро распаковывать сжатые данные и который разработан специально для СУБД Oracle Database. В опции FOR CAPACITY HIGH применяется более тяжеловесный алгоритм сжатия, при котором страдает скорость распаковки сжатых данных, но обеспечивается высокая степень сжатия данных.

Коэффициенты сжатия могут варьироваться от 2X до 20X, в зависимости от выбранной опции сжатия, типа данных, а также содержимого таблицы. Метод сжатия может варьироваться от столбца к столбцу или между секциями одной таблицы. Например, вы можете оптимизировать некоторые столбцы в таблице для увеличения скорости сканирования данных, а другие ― для экономии пространства.

CREATE TABLE employees ( c1 NUMBER, c2 NUMBER, c3 VARCHAR2(10), c4 CLOB ) INMEMORY MEMCOMPRESS FOR QUERY

NO INMEMORY(c4) INMEMORY MEMCOMPRESS FOR CAPCITY HIGH(c2);

Рис. 9. Команда создания таблицы, которая задает различные методы сжатия для разных столбцов

Oracle Compression Advisor

Oracle Compression Advisor (DBMS_COMPRESSION) был расширен для поддержки In-Memory сжатия данных. Советник Oracle Compression Advisor оценивает коэффициент сжатия, который может быть реализован путем использования MEMCOMPRESS. Эта оценка основана на анализе выборки данных таблицы и обеспечивает хороший прогноз фактических результатов, которые будут достигнуты после размещения таблицы в IM колоночном хранилище . Поскольку советник применяет новые MEMCOMPRESS алгоритмы к данным, он может быть запущен только в среде СУБД Oracle Database 12.1.0.2 (или более поздней версии).

12

Рис. 10. Использование Oracle Compression Advisor (DBMS_COMPRESSION) для определения размера таблицы MY_SALES в памяти

Примечание. При задании значения параметра comptype MEMCOMPRESS любого типа выходное значение параметра blkcnt_cmp всегда устанавливается равным 0, так как в IM колоночном хранилище нет обычных блоков данных.

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

In-Memory сканирование данных

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

In-Memory Storage индекс (In-Memory индекс хранения)

13

Благодаря In-Memory Storage индексам , которые автоматически создаются и поддерживаются для каждого столбца в IM колоночном хранилище , возможно добиться дополнительного уменьшения количества данных, к которым нужно обращаться при выполнении запроса. In-Memory Storage индексы позволяют пропускать данные на основе фильтр-предикатов, заданных в SQL запросе. In-Memory Storage индекс отслеживает минимальные и максимальные значения для каждого столбца в IMCU. Если в запросе есть предикат в выражении WHERE, In-Memory Storage индекс проверяет столбец, на который ссылается предикат, чтобы определить, имеются ли какие-либо элементы с заданным значением столбца в каждом IMCU путем сравнения этого значения(ий) с минимальным и максимальным значениями из In-Memory Storage индекса. Если значение столбца находится за пределами минимального и максимального диапазона IMCU, сканирование такого IMCU не выполняется.

Для предикатов равенства, in-list (списочных), а также некоторых range (диапазонных) предикатов возможен дополнительный уровень отсечения данных с помощью словаря метаданных, создаваемого для каждого IMCU при использовании dictionary-based compression (сжатия с использованием словаря). Словарь метаданных содержит список различных значений для каждого столбца в IMCU. Таким образом, отсечение данных с использованием словаря позволяет Oracle Database определить, действительно ли значение, которое ищется, существует в пределах IMCU, и проводить сканирование только необходимых IMCU.

SIMD Векторная обработка

Для данных, которые требуется сканировать в IM колоночном хранилище, Database In-Memory использует SIMD векторную обработку (ОКМД - одиночный поток команд, множественный поток данных). Вместо того чтобы проводить сравнение каждого элемента столбца по отдельности, SIMD векторная обработка позволяет сравнить набор значений столбца с помощью одной команды процессора.

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

Например, давайте возьмем таблицу SALES в демонстрационной схеме SH (см. рис. 11) и предположим, что нам необходимо узнать общее количество заказов, в которых использовалось значение PROMO_ID 9999. Таблица SALES была полностью загружена в IM колоночное хранилище. Запрос начинается со сканирования столбца PROMO_ID таблицы SALES. Первые 8 значений столбца PROMO_ID загружаются в SIMD регистр процессора и сравниваются со значением 9999 одной командой процессора (количество загруженных значений будет варьироваться в зависимости от типа данных и используемого метода сжатия памяти). Записывается количество элементов, которые соответствуют значению 9999. Затем загруженные данные сбрасываются, и в регистр загружается еще 8 элементов. И так далее, пока все записи в столбце PROMO_ID не будут проверены.

14

Рис. 11. SIMD векторная обработка позволяет сканировать миллиарды строк в секунду.

Чтобы определить, сканирует ли SQL запрос данные в IM колоночном хранилище, проверьте его план выполнения.

Рис. 12. Новое ключевое слово IN MEMORY в плане выполнения идентифицирует операции, которые являются In-Memory кандидатами.

Вы можете видеть, что в плане выполнения содержится новый набор ключевых слов “IN MEMORY”.

Эти ключевые слова показывают, что таблица LINEORDER была помечена для IN MEMORY и СУБД Oracle Database может использовать в данном запросе колоночное хранилище.

In-Memory Соединения

SQL запросы, которые соединяют несколько таблиц, могут также эффективно обрабатываться в IM колоночном хранилище благодаря фильтрам Блума (Bloom Filter). Фильтр Блума преобразует соединение в фильтр, который может применяться при сканировании более крупной таблицы. Фильтры Блума были первоначально введены в Oracle Database 10g для повышения производительности хеш-соединений и не являются возможностью только Oracle Database In-Memory. Тем не менее, они очень эффективно применяются для данных колоночного формата с помощью SIMD векторной обработки.

Когда две таблицы соединяются с помощью хеш-соединения, сканируется первая таблица (как правило, меньшего размера), и строки, которые удовлетворяют предикатам выражения WHERE (для этой таблицы), используются для создания хеш-таблицы в памяти (хранящейся в глобальной области процесса — Process Global Area, PGA). Во время создания хеш-таблицы на основе

15

столбца соединения также создается битовый вектор или фильтр Блума. Битовый вектор затем отсылается в качестве дополнительного предиката для сканирования второй таблицы. После применения предикатов выражения WHERE при сканировании второй таблицы в полученных строках будет хеширован столбец соединения, и который будет сравниваться со значениями в битовом векторе. При нахождении совпадения в битовом векторе данная строка будет отправлена в хеш-соединение. Если совпадений не найдено, то строка отбрасывается.

Фильтры Блума легко идентифицировать в плане выполнения запроса. Они появляются в двух местах, во время создания и во время применения. Давайте в качестве примера возьмем простое соединение двух таблиц DATE_DIM и LINEORDERS.

SELECT SUM(lo_extendedprice * lo_discount) revenue FROM lineorder l, date_dim d WHERE l.lo_orderdate = d.d_datekey AND l.lo_discount BETWEEN 2 AND 3 AND d.d_date='December 24, 2013';

Рис. 13. Простое соединение двух таблиц, которое может выиграть от применения фильтров Блума в IM колоночном хранилище

Ниже приводится план данного запроса. Фильтр Блума выделен. Первый шаг, который выполняется в данном плане — это на самом деле строка 4, полное сканирование таблицы DATE_DIM в памяти. Фильтр Блума (:BF0000) создается сразу после завершения сканирования таблицы DATE_DIM (строка 3). Затем фильтр Блума применяется в ходе сканирования всей таблицы LINEORDER в памяти (строки 5 и 6).

Рис. 14. Создание и использование фильтра Блума в соединении двух таблиц DATE_DIM и LINEORDER

Если посмотреть на информацию о предикатах под планом, то можно увидеть, какие условия соединения использовались для построения фильтра Блума. Обратите внимание на ‘SYS_OP_BLOOM_FILTER' в фильтр-предикатах . У вас может возникнуть вопрос, почему в плане появляется хеш-соединение (строка 2), если соединение было преобразовано в фильтр Блума. Хеш-соединение присутствует потому, что фильтр Блума может вернуть ложноположительный результат. Хеш-соединение гарантирует, что все строки, возвращаемые после сканирования таблицы LINEORDER, действительно соответствуют условиям соединения. Как правило, этот шаг не требует большого объема работы.

16

Что происходит в случае более сложного запроса, когда соединяются несколько таблиц? Именно в таких случаях на выручку приходит более чем тридцатилетний опыт корпорации Oracle в разработке инновационных технологий СУБД. Благодаря гладкому встраиванию IM колоночного хранилища в СУБД Oracle Database мы можем воспользоваться преимуществами всех оптимизаций, которые были добавлены в базу данных с момента ее первого выпуска. Благодаря использованию серии трансформаций запроса, которые делает оптимизатор, соединения нескольких таблиц могут быть переписаны с целью создания нескольких фильтров Блума и последующего их использования при сканировании большой таблицы или таблицы фактов.

Примечание. Начиная с Oracle Database 12.1.0.2 фильтры Блума можно использовать в serial (серийных) запросах для таблицы, загруженной в IM колоночное хранилище . Для создания или использования фильтров Блума не все таблицы в запросе требуется загружать в IM колоночное хранилище .

In-Memory Агрегирование данных

Аналитическим запросам часто недостаточно простых фильтров или соединений. Они требуют сложных операций аггрегирования и суммирования. В оптимизаторе запросов СУБД Oracle Database 12.1.0.2 была реализована новая трансформация запросов под названием VECTOR GROUP BY для выполнения более сложных аналитических запросов с использованием новых алгоритмов, эффективных с точки зрения CPU.

Преобразование VECTOR GROUP BY представляет собой процесс из двух частей, который не отличается от преобразования типа «звезда». Давайте в качестве примера возьмем следующий бизнес-запрос: Необходимо найти общий объем продаж обуви в фирменных магазинах.

Стадия 1

1. Выполнение запроса начинается со сканирования двух таблиц измерений (таблиц меньшего размера) STORES и PRODUCTS (строки 5 и 10 в приведенном ниже плане).

2. На основании результатов каждого из этих сканирований создается новая структура

данных под названием Key Vector («вектор ключей») (строки 4, 9 в приведенном ниже плане). Вектор ключей похож на фильтр Блума, так как позволяет применять предикаты соединения в качестве дополнительных фильтр-предикатов во время сканирования таблицы SALES (самой большой таблицы). В отличие от фильтра Блума ключевой вектор не возвращает ложноположительные значения.

3. Векторы ключей также используются для создания дополнительной структуры под

названием In-Memory Accumulator («сумматор в памяти»). Сумматор представляет собой многомерный массив, создаваемый в глобальной области процесса PGA, что позволяет Oracle Database проводить агрегацию и группировку данных GROUP BY прямо во время сканирования таблицы SALES, а не после него.

17

4. По окончании первой стадии создаются временные таблицы для хранения payload столбцов (столбцов, указанных в SELECT списке) таблиц измерений (строки 2, 6 приведенного ниже плана). Обратите внимание, что данный шаг не показан на рисунке 15 ниже.

Рис. 15. Пример In-Memory агрегирования — необходимо найти общий объем продаж обуви в фирменных магазинах.

Стадия 2

5. Вторая часть плана выполнения начинается со сканирования таблицы SALES и применения векторов ключей (строки 17-22 нижеприведенного плана). Для каждой записи в таблице SALES, которая соответствует условиям соединения (фирменный магазин, товар — обувь), соответствующий объем продаж будет добавлен в соответствующую ячейку в сумматоре в памяти In-Memory Accumulator. Если значение уже существует в этой ячейке, два значения суммируются и полученное значение вставляется в ячейку.

6. Наконец, результаты сканирования большой таблицы соединяются с временными таблицами, созданными при сканировании таблиц измерений (строки 12, 13). Помните, что эти временные таблицы содержат только payload (необходимые) столбцы. Обратите внимание, что данный шаг не показан на рисунке 15 выше.

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

18

Рис. 16. План выполнения запроса с использованием In-Memory агрегирования

Трансформация VECTOR GROUP BY является стоимостной (cost based) трансформацией запроса, что означает, что оптимизатор оценит стоимость плана выполнения с трансформацией и без неё и выберет вариант с наименьшей стоимостью. Например, преобразование VECTOR GROUP BY может быть выбрано в следующих случаях:

• столбцы, по которым делается соединение таблиц, содержат «в основном» уникальные ключи или числовые ключи;

• таблица фактов (самая большая таблица в запросе) как минимум в 10 раз больше других

таблиц;

• таблицы загружены в IM колоночное хранилище;

В следующих случаях преобразование VECTOR GROUP BY вряд ли будет выбрано:

• соединения выполняются между двумя или несколькими очень большими таблицами;

• таблицы измерений содержат более 2 миллиардов строк;

• система не имеет достаточных ресурсов памяти.

DML и In-Memory колоночное хранилище

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

19

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

Массовая загрузка данных (Bulk Data Loads)

Массовая загрузка данных чаще всего происходит в средах хранилищ данных и, как правило, осуществляется в direct path (прямом) режиме. Режим прямой загрузки анализирует входные данные, преобразует данные каждого входного поля в соответствующий тип данных Oracle, а затем строит column array structure (структуру, состоящую из массива столбцов) для данных. Эти структуры из массивов столбцов используются для форматирования блоков данных Oracle и построения индексных ключей. Отформатированные блоки базы данных затем записываются непосредственно в базу данных, минуя стандартную обработку SQL и кеш буфера базы данных.

Операция прямой загрузки представляет собой операцию «все или ничего». Это означает, что операция не будет завершена до тех пор, пока не будут загружены все данные. Если что-то пойдет не так в середине операции, будет прервана вся операция полностью. Чтобы удовлетворить такому строгому критерию, прямая загрузка вставляет данные в блоки базы данных, создаваемые выше маркера максимального заполнения сегмента (high water mark - максимальное количество блоков базы данных, которое используется объектом или сегментом в данный момент). Как только прямая загрузка будет совершена, маркер максимального заполнения переместится, чтобы присоединить вновь созданные блоки к сегменту, и блоки станут видимыми для других SQL-операций в той же таблице. До этого момента IM колоночное хранилище не может распознать, что в сегменте произошло изменение данных.

Как только операция будет зафиксирована (committed), IM колоночное хранилище сразу распознает, что в него загружены не все данные объекта. Размер недостающих данных будет виден в столбце BYTES_NOT_POPULATED представления v$IM_SEGMENTS (см. раздел мониторинга). Если для данного объекта указан уровень PRIORITY, тогда вновь добавленные данные будут автоматически загружены в IM колоночное хранилище. В противном случае, в следующий раз, когда в отношении объекта будет выполняться запрос, сработают фоновые рабочие процессы, которые начнут загружать недостающие данные, предполагая, что в IM колоночном хранилище имеется свободное пространство.

Загрузка данных с помощью обмена секциями

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

20

не генерирует redo и undo и поэтому занимает доли секунды, поэтому маловероятно, что данная операция будет влиять на производительность, в отличие от традиционных подходов к перемещению данных, таких как INSERT.

Так же как и в случае с прямой загрузкой, IM колоночное хранилище не сможет распознать обмен секциями до тех пор, пока операция не будет полностью завершена. После завершения операции данные во временной таблице являются частью секционированной таблицы. Если для временной таблицы был установлен атрибут INMEMORY и все его данные были загружены в IM колоночное хранилище, никаких дальнейших действий происходить не будет. Доступ к данным, которые находились во временной таблице, а также к данным в секционированной таблице будет осуществляться через IM колоночное хранилище при следующем сканировании.

Однако, если для временной таблицы атрибут INMEMORY установлен не был, то все последующие доступы к данным в партиции, которая была подвергнута обмену, будут осуществляться через буферный кеш. Помните, что атрибут INMEMORY является физическим атрибутом объекта. Если вы хотите, чтобы секция имела данный атрибут после обмена, его необходимо указать во временной таблице до выполнения обмена. Указание атрибута для пустой партиции не является достаточным.

Рис. 17. Пять шагов, необходимых для выполнения загрузки данных в INMEMORY таблицу посредством обмена секциями

Обработка транзакций

Операции изменения данных одной строки (DML) выполняются через буферный кэш (OLTP изменения) точно так же, как без использования Database In-Memory. Если объект, в котором происходят операции DML, загружен в IM колоночное хранилище, то изменения будут отображаться в IM колоночном хранилище, как только они произойдут. Буферный кеш и IM колоночное хранилище транзакционно согласуются посредством In-Memeory Transaction Manager (менеджера транзакций в памяти). Журналирование (logging) делается для базовой таблицы точно так же, как оно делалось раньше. Для IM колоночного хранилища журналирование не требуется.

Для каждого IMCU в IM колоночном хранилище автоматически создается и поддерживается

21

журнал транзакций (см. рис. 18). Когда команда DML изменяет строку в объекте, который загружен в IM колоночное хранилище, соответствующие записи для этой строки маркируются в IMCU как устаревшие и в in-memory журнал транзакций добавляется копия новой версии строки. Оригинальные записи в IMCU заменяются не сразу, чтобы обеспечить согласованность по чтению и сжатие данных. Для любой транзакции, выполняемой в отношении объекта в IM колоночном хранилище, которая была запущена до начала DML, требуется оригинальная версия записей из IMCU. Согласованность по чтению в колоночном хранилище в памяти обеспечивается с помощью системных номеров изменений (SCN) точно так же, как она обеспечивается без включённой Database In-Memory.

Рис. 18. Каждый IMCU в колоночном хранилище в памяти содержит подмножество строк объекта и журнала транзакций

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

Повторная загрузка данных

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

В дополнение к стандартному алгоритму повторного заполнения данных, существует еще один алгоритм, который делает попытку очистить все устаревшие записи, используя фоновый процесс с низким уровнем приоритета. Фоновый процесс IMCO (In-Memory Coordinator) может также инициировать непрерывную повторную загрузку (trickle repopulation) данных в IMCU в IM колоночном хранилище, которые имеют некоторые устаревшие записи, но не подпадают под порог устаревания. Непрерывная повторная загрузка данных представляет собой постоянную фоновую активность.

22

IMCO процесс пробуждается каждые две минуты и проверяет, имеются ли какие-либо задачи перезагрузки данных, которые должны быть выполнены. Например, для нового объекта был только что указан атрибут INMEMORY в выражении PRIORITY. IMCO также проверяет, имеются ли в IMCU в IM колоночном хранилище какие-либо устаревшие записи. При нахождении устаревших записей IMCO запускает рабочие процессы для повторной загрузки данных. Количество IMCU, заполняемых с помощью непрерывной повторной загрузки за каждый 2-х минутный интервал, ограничивается новым инициализационным параметром INMEMORY_TRICKLE_REPOPULATE_SERVERS_PERCENT. Этот параметр контролирует максимальный процент времени, в течение которого рабочие процессы могут участвовать в непрерывной повторной загрузке данных. Чем больше рабочих процессов, которые участвуют, тем большее количество IMCU, заполняемых с помощью непрерывной повторной загрузки. Однако, чем больше рабочих процессов, которые участвуют в загрузке, тем выше уровень загруженности процессора. Вы можете отключить непрерывную повторную загрузку полностью, установив параметр INMEMORY_TRICKLE_REPOPULATE_SERVERS_PERCENT в 0.

Накладные расходы на поддержание транзакционной согласованности IM колоночного хранилища

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

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

Для таблиц с большой частотой DML операций, рекомендуется использовать MEMCOMPRESS FOR DML, а также, в тех случаях, когда это возможно, рекомендуется использовать секционирование для локализации изменений в таблице. Например, для локализации данных в таблице по дате можно использовать range partitioning (секционирование по диапазону), так что большинство изменений будут ограничены данными, хранящимися в последней партиции. Секционирование по диапазонам дат также предоставляет множество других преимуществ управляемости и производительности.

23

IM колоночное хранилище в RAC

Каждый узел в среде RAC имеет свое собственное IM колоночное хранилище. Настоятельно рекомендуется использовать IM колоночное хранилище одинакового размера на каждом узле RAC. Параметр INMEMORY_SIZE для всех узлов RAC, где не требуется IM колоночное хранилище, должен быть установлен в 0. По умолчанию все объекты, загружаемые в память, будут распределяться по всем IM колоночным хранилищам в кластере. Кроме того, можно сделать так, чтобы одни и те же объекты были целиком загружены в IM колоночное хранилище на каждом узле кластера (только для Engineered System комплексов). Распределение объектов по IM колоночным хранилищам в кластере управляется двумя дополнительными ключами атрибута INMEMORY: DISTRIBUTE и DUPLICATE.

В среде RAC объект, для которого задан только INMEMORY атрибут, будет распределяться по всем IM колоночным хранилищам в данном кластере, что делает IM колоночное хранилище архитектурой без разделения ресурсов (shared nothing архитектура) в среде RAC. То, каким образом объект распределяется по кластеру, контролируется ключом DISTRIBUTE. По умолчанию Oracle выбирает лучший способ распределения объекта в кластере с учетом используемого типа секционирования (если оно вообще используется). В качестве альтернативы вы можете указать DISTRIBUTE BY ROWID RANGE для распределения по диапазону rowid, DISTRIBUTE BY PARTITION для распределения партиций по разным узлам или DISTRIBUTE BY SUBPARTITION для распределения субпартиций по разным узлам.

ALTER TABLE lineorder INMEMORY DISTRIBUTE BY PARTITION;

Рис. 19. Данная команда распределяет партиции таблицы lineorder по IM колоночным хранилищам в кластере.

DISTRIBUTE BY PARTITION или SUBPARTITION рекомендуется в тех случаях, когда таблицы разбиты на партиции или субпартиции посредством HASH и когда ожидается partition-wise join план (план с соединением по секциям). Благодаря этому все соединения секций смогут быть выполнены в пределах одного узла. DISTRIBUTE BY ROWID RANGE может использоваться для несекционированных таблиц или для секционированных таблиц в тех случаях, когда DISTRIBUTE BY PARTITION может привести к неравномерному распределению данных по узлам кластера.

Если объект очень мал (состоит только из 1 IMCU), он будет загружен в IM колоночное хранилище только на одном узле кластера.

Поскольку данные, загруженные в память в среде RAC привязаны к конкретному узлу RAC, то требуются параллельные серверные процессы, каждый из которых будет выполняться на своём узле RAC и сканировать ту часть объекта, которая располагается в IM колоночном хранилище на данном узле. Координатор запросов агрегирует результаты каждого из параллельных серверных процессов, прежде чем вернуть их конечному пользователю. Чтобы обеспечить надлежащее распределение параллельных серверных процессов по узлам RAC кластера, необходимо использовать Automatic Degree of Parallelism (автоматическую степень параллелизма - AutoDOP), чтобы координатор запросов учитывал местоположение IMCU.

24

Если AutoDOP не используется, а степень параллелизма указывается вручную (с помощью хинта или атрибута таблицы PARALLEL), возможно, что не все данные будут читаться из IM колоночного хранилища, так как параллельные серверные процессы могут запуститься не на тех узлах, где лежат назначенные им IMCU, а мы не передаём IMCU между узлами RAC.

Если DML предложение выполняется для объекта на узле, где объект или часть объекта находятся в IM колоночном хранилище, соответствующая строка в IM колоночном хранилище отмечается устаревшей, и в журнал транзакций данного IMCU добавляется копия новой строки. Однако если команда DML выполняется на другом узле, в таком случае для сохранения транзакционной согласованности IM колоночное хранилище будет использоваться механизм Cache Fusion (синхронизация кэшей узлов RAC кластера). Записи столбцов в блоке базы данных с измененной строкой будут маркироваться как устаревшие в соответствующем колоночном IM колоночном хранилище на удаленном узле.

In-Memory отказоустойчивость

Учитывая тот факт, что IM колоночное хранилище в среде RAC имеет архитектуру без разделения ресурсов, для некоторых чувствительных с точки зрения производительности приложений может потребоваться обеспечение отказоустойчивости. В Engineered System комплексе можно зеркалировать данные, загруженные в IM колоночное хранилище, посредством указания ключа DUPLICATE атрибута INMEMORY. Это означает, что у всех IMCU в IM колоночном хранилище будет зеркальная копия на одном из других узлов кластера RAC. Зеркалирование IMCU блоков позволяет добиться отказоустойчивости, так как данные остаются доступными в IM колоночном хранилище даже при падении узла. Зеркалирование также улучшает производительность, так как запросы могут обращаться как к основной, так и резервной копии IMCU в любой момент времени.

IMCU дублирован на другом узле кластера RAC

Рис. 20. Объекты в IM колоночном хранилище в комплексах Engineered System могут зеркалироваться для повышения отказоустойчивости.

В случае отказа узла RAC и его простоя в течение некоторого времени будет выполнено повторное зеркальное копирование первичных IMCU, находившихся на данном узле. И только в случае отказа второго узла и его простоя в течение некоторого времени потребуется перераспределение данных.

Если требуется дополнительная отказоустойчивость, в IM колоночные хранилища на всех узлах в кластере можно загрузить объект посредством указания ключевых слов DUPLICATE ALL

25

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

ALTER TABLE lineorder INMEMORY DUPLICATE ALL;

Рис. 21. Данная команда используется для того, чтобы каждый IMCU таблицы lineorder загрузился во все IM колоночные хранилища кластера.

Опция DUPLICATE ALL может оказаться также полезной для co-locate соединений (соединений, выполняемых в рамках одного узла) между большими распределенными таблицами фактов и более мелкими таблицами измерений. При указании опции DUPLICATE ALL для более мелких таблиц измерений в IM колоночное хранилище на каждом узле загружается полная копия этих таблиц.

Ключ DUPLICATE применим только для Oracle Engineered System комплексов и игнорируется при задании на других компьютерах.

В случае отказа узла RAC в не Engineered System комплексе загруженные в IM колоночное хранилище на данном узле данные больше не будут доступны в памяти во всём кластере. Запросы, выполняемые в отношении отсутствующих частей объектов, ошибкой не заканчиваются. Вместо этого они читают данные либо из буферного кэша, либо с диска, что влияет на скорость выполнения этих запросов. Если узел не может использоваться в течение некоторого времени, объекты или части объектов, которые находятся в IM колоночном хранилище на этом узле, загружаются на остальные узлы кластера (при условии, что имеется свободное пространство для их загрузки). Чтобы свести к минимуму отрицательное влияние на производительность при отказе узла RAC, в IM колоночном хранилище на каждом узле кластера рекомендуется оставлять некоторый объем свободного пространства.

Обратите внимание, что данные не перераспределяются на другие узлы кластера сразу же после отказа узла или экземпляра, потому что очень вероятно, что узел или экземпляр быстро вернутся в эксплуатацию. Если бы данные перераспределялись немедленно, процесс перераспределения добавлял бы дополнительную нагрузку на систему, которую затем нужно откатывать обратно при возвращении узла или экземпляра в эксплуатацию. Поэтому, прежде чем начать перераспределение данных, система выжидает несколько десятков минут. За время ожидания узел или кластер могут снова вернуться в кластер.

Когда узел снова присоединяется к кластеру, данные кластера перераспределяются на вновь присоединившийся узел. Распределение выполняется на основе IMCU, и во время данного процесса объекты остаются полностью доступными.

IM колоночное хранилище в мультиарендном окружении Архитектура Oracle Multitenant1 представляет собой новую модель консолидации базы данных, в которой в контейнерной базе данных (Container Database – CDB) консолидируются

1 Более подробную информацию об Oracle Multitenant можно найти в техническом документе Oracle

Multitenant

26

многочисленные подключаемые базы данных (Pluggable Databases – PDBs). Сохраняя многие аспекты изоляции одиночных баз данных, данная архитектура позволяет подключаемым базам данных совместно использовать глобальную системную область (SGA) и фоновые процессы общей контейнерной базы данных. Таким образом, подключаемые базы данных также совместно используют одно IM колоночное хранилище.

Рис. 22. Три подключаемые базы данных в одной контейнерной базе данных Oracle Database 12c

Общий размер IM колоночного хранилища контролируется установкой параметра INMEMORY_SIZE на уровне CDB. Параметр INMEMORY_SIZE, заданный на уровне PDB определяет, какой объём общего колоночного IM колоночного хранилища она может использовать. Не всем подключаемым базам данных в конкретной контейнерной базе данных может быть нужно IM колоночное хранилище. Параметр INMEMORY_SIZE для некоторых подключаемых баз данных может быть установлен в 0. Это означает, что они совсем не будут использовать IM колоночное хранилище.

Сумма параметров INMEMORY_SIZE подключаемых баз данных необязательно должна быть меньше или равна значению параметра INMEMORY_SIZE контейнерной базы данных. Подключаемые базы данных могут запрашивать объём памяти в IM колоночном хранилище больше его реального размера. Превышение реального размера IM колоночного хранилища допускается для того, чтобы ценное пространство в нём не пропадало впустую, если одна из подключаемых баз данных будет остановлена или отключена. Поскольку параметр INMEMORY_SIZE является статическим (для активации изменений параметра требуется перезапуск экземпляра базы данных), то лучше позволить подключаемым базам данных запросить объём IM памяти с запасом, чтобы обеспечить использование всего пространства IM колоночного хранилища.

Тем не менее, в результате такого переиспользования (oversubscription) памяти может случиться так, что одна из подключаемых баз данных лишит другую подключаемую базу данных необходимого пространства в IM колоночном хранилище. Если не планируется надолго останавливать какие-либо подключаемые базы данных или отключать их, то переиспользование памяти не рекомендуется.

27

Рис. 23. Для каждой подключаемой базы данных с помощью параметра INMEMORY_SIZE задается объем пространства, которое она может использовать в общем IM колоночном хранилище.

Каждая подключаемая база данных (PDB) сама по себе является полной базой данных Oracle, так что каждая PDB будет иметь свой собственный приоритетный список объектов, размещаемых в IM колоночном хранилище. При запуске подключаемой базы данных объекты из ее приоритетного списка будут загружены в IM колоночное хранилище с допущением, что в нем имеется свободное пространство.

Контроль использования Oracle Database In-Memory

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

Основные параметры инициализации

Для непосредственного управления разными аспектами новой In-Memory функциональности было введено шесть новых параметров инициализации с префиксом INMEMORY. Существует также новый параметр оптимизатора, который может оказывать влияние на то, будут ли запросы использовать IM колоночное хранилище или нет.

28

Рис. 24. Новые In-Memory параметры инициализации

INMEMORY_SIZE

Как было описано ранее в этом документе, параметр INMEMORY_SIZE контролирует объем памяти, выделенный для IM колоночного хранилища. По умолчанию размер IM колоночного хранилища составляет 0 байт. Этот параметр может изменяться только на системном уровне и, чтобы изменения вступили в силу, требуется перезапуск базы данных. Минимальное значение параметра INMEMORY_SIZE составляет 100 МБ.

INMEMORY_QUERY

Оптимизатор запросов Oracle знает об объектах, загруженных в IM колоночное хранилище, и автоматически перенаправляет запросы, которые, по его мнению, выиграют от использования in-memory колоночного формата, на IM колоночное хранилище. Установка параметра INMEMORY_QUERY в значение DISABLE на уровне сессии или системы полностью отключает использование IM колоночного хранилища. Это делает невидимым для оптимизатора запросов всё, что находится в колоночном хранилище в памяти, и не позволит уровню выполнения (execution layer) сканировать и фильтровать данные в IM колоночном хранилище. Значение по умолчанию — ENABLE.

INMEMORY_MAX_POPULATE_SERVERS

Максимальное количество рабочих процессов, которые могут быть запущены, контролируется параметром INMEMORY_MAX_POPULATE_SERVERS, который по умолчанию равен 0,5 Х CPU_COUNT. Уменьшение количества рабочих процессов снизит потребление CPU ресурсов при загрузке, но, скорее всего, увеличит период времени, необходимый для загрузки данных в IM колоночное хранилище.

Дополнительные параметры инициализации

INMEMORY_CLAUSE_DEFAULT

Параметр INMEMORY_CLAUSE_DEFAULT позволяет настроить режим по умолчанию для in-memory

29

таблиц посредством задания допустимого набора значений для INMEMORY выражений, которые явно не указаны в синтаксисе. Значением по умолчанию является пустая строка. Это означает, что в IM колоночное хранилище будут загружаться только явно указанные таблицы.

ALTER SYSTEM SET INMEMORY_clause_default= ‘INMEMORY PRIORITY LOW’;

Рис. 25. Использование параметра INMEMORY_CLAUSE_DEFAULT для маркировки всех новых таблиц в качестве кандидатов для загрузки в IM колоночное хранилище

Значение параметра разбирается таким же образом, как выражение INMEMORY, с такими же значениями по умолчанию, если какие-либо ключевые слова не заданы. Все таблицы, определяемые явно для in-memory использования, будут брать все неуказанные значения из данного параметра.

INMEMORY_TRICKLE_REPOPULATE_SERVERS_PERCENT

Этот параметр контролирует максимальный процент времени, в течение которого рабочие процессы могут выполнять непрерывную повторную загрузку данных (trickle repopulation). Допустимые значения – от 0 до 50. Установка данного параметра на 0 отключает непрерывную повторную загрузку. Значение по умолчанию равно 1 — это означает, что рабочие процессы будут тратить один процент своего времени на непрерывную повторную загрузку.

INMEMORY_FORCE

По умолчанию любой объект, для которого указан атрибут INMEMORY, является кандидатом для загрузки в IM колоночное хранилище. Тем не менее, если параметр INMEMORY_FORCE установлен в OFF, то, даже если настроена in-memory область, таблицы в неё загружаться не будут. Значение по умолчанию — DEFAULT.

OPTIMIZER_INMEMORY_AWARE

Как уже упоминалось выше, оптимизатор знает об IM колоночном хранилище и при оценке альтернативных in-memory планов для SQL запроса учитывает стоимость доступа к in-memory. Если параметр OPTIMIZER_INMEMORY_AWARE установить в FALSE, возможно будет отключить все in-memory улучшения стоимостной модели оптимизатора запросов. Обратите внимание, что даже если in-memory улучшения оптимизатора отключены, вы все равно можете получить In-Memory план.

Хинты оптимизатора

Различные аспекты In-Memory — in-memory сканирования, соединения и операции агрегирования — могут контролироваться на уровне SQL предложения или на уровне блока SQL предложения (query block) посредством использования хинтов оптимизатора. Как и в случае с большинством хинтов оптимизатора, соответствующий отрицательный хинт для всех хинтов,

30

описанных ниже, начинается с префикса ‘NO_’. Помните, что хинт оптимизатора представляет собой директиву, которая будет выполняться только в тех случаях, когда это применимо.

INMEMORY хинт

Единственное, что делает хинт INMEMORY, — позволяет использовать IM колоночное хранилище, когда для параметра INMEMORY_QUERY установлено значение DISABLE.

Хинт не вызывает загрузку таблицы или партиции без атрибута INMEMORY в IM колоночное хранилище. Если вы укажете хинт INMEMORY в SQL запросе, когда ни одна из таблиц, указанных в запросе, не загружена в память, хинт будет рассматриваться как комментарий, так как он не применим к данному SQL запросу.

Также INMEMORY хинт не будет заставлять оптимизатор выбирать полное сканирование таблицы через IM колоночное хранилище, если план по умолчанию (план с наименьшей стоимостью) представляет собой план индексного доступа. Вам нужно ещё указать хинт FULL, чтобы изменения в плане вступили в силу.

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

In-Memory сканирование

Как было описано выше, если вы хотите заставить оптимизатор использовать In-Memory полное сканирование таблицы, вам нужно использовать FULL хинт, чтобы изменить способ доступа для объекта (таблицы или (суб)партиции).

Хинт(NO_)INMEMORY_PRUNING может также влиять на производительность In-Memory сканирования, так как он контролирует использование In-Memory storage индексов. По умолчанию все запросы, выполняемые через IM колоночное хранилище, могут использовать In-Memory storage индексы, позволяющие уменьшать объём сканируемых данных на основе указанных в SQL предложении фильтр-предикатов. Как и в случае с большинством хинтов, хинт INMEMORY_PRUNING был введен для тестирования новой функциональности. Другими словами, хинт был изначально введён для отключения In-Memory storage индексов.

In-Memory cоединения

Оптимизатор запросов решает использовать фильтр Блума для преобразования соединения в фильтр на основе стоимости. Если оптимизатор не выбирает фильтр Блума, его применение можно форсировать с помощью хинта PX_JOIN_FILTER.

31

In-Memory агрегирование

Новая возможность in-memory агрегирования (VECTOR GROUP BY) является трансформацией запроса на основе стоимости. Это означает, что оптимизатор запросов можно заставить использовать эту трансформацию, даже если результирующий план выполнения запроса не будет планом с наименьшей стоимостью. Принудительное использование VECTOR GROUP BY плана задаётся с помощью хинта VECTOR_TRANSFORM.

Мониторинг и управление Oracle Database In-Memory

Мониторинг объектов в In-Memory колоночном хранилище

Два новых представления v$, v$IM_SEGMENTS и v$IM_USER_SEGMENTS, показывают, какие именно объекты в настоящее время загружены в IM колоночное хранилище.

Рис. 26. Новое представление v$IM_SEGMENTS

Эти новые представления не только показывают, какие объекты загружены в IM колоночное хранилище, но они также показывают, как объекты распределены по узлам RAC кластера и был ли загружен весь объект полностью (BYTES_NOT_POPULATED). Это представление можно также использовать для определения коэффициента сжатия каждого объекта, загруженного в IM колоночное хранилище, относительно его размера на диске в несжатом виде.

Рис. 27. Определение коэффициента сжатия объектов, загруженных в IM колоночное хранилище

Еще одно новое представление, V$_IM_COLUMN_LEVEL, содержит подробную информацию о столбцах, загруженных в колоночное хранилище, так как не все столбцы таблицы обязательно

32

должны быть в IM колоночном хранилище.

Рис. 28. Столбец PROD_ID не был загружен в IM колоночное хранилище

USER_TABLES

В *_TABLES таблицы словаря был добавлен новый столбец с булевыми значениями под названием INMEMORY, который показывает, для каких таблиц был задан атрибут INMEMORY.

Рис. 29. Новый столбец INMEMORY в *_TABLES таблицах, показывающий, какие таблицы имеют INMEMORY атрибут

В приведенном выше примере вы можете видеть, что две таблицы — COSTS и SALES — не имеют значений для столбца INMEMORY. Атрибут INMEMORY задаётся на уровне сегмента. Таблицы COSTS и SALES являются секционированными таблицами и, следовательно, логическими объектами. Атрибут INMEMORY для этих таблиц будет записан на уровне партиции или субпартиции в * _TAB_ (SUB) PARTITIONS.

Три дополнительных столбца — INMEMORY_PRIORITY, INMEMORY_DISTRIBUTE и

INMEMORY_COMPRESSION, — также были добавлены в представления *_TABLES для отображения текущих значений In-Memory атрибутов для каждой таблицы.

Управление потреблением CPU ресурсов при загрузке данных в IM колоночное хранилище

Начальная загрузка данных в IM колоночное хранилище представляет собой CPU интенсивную операцию, способную повлиять на производительность других рабочих нагрузок, которые

выполняются в этот же момент. Вы можете использовать Resource Manager2 (диспетчер ресурсов

2 Более подробную информацию о диспетчере ресурсов Oracle Database можно найти в техническом документе Using Oracle Resource Manager

33

СУБД Oracle), чтобы контролировать потребление CPU операциями загрузки данных в IM колоночное хранилище и при необходимости менять их уровень приоритета. Для этого необходимо активировать CPU Resource Manager, включив один из готовых ресурсных планов, такой как default_plan, или создав свой собственный план распределения ресурсов. По умолчанию in-memory загрузка данных выполняется в группе потребителей (consumer group) ora$autotask, за исключением загрузки по требованию, которая выполняется в группе потребителей пользователя, инициировавшего загрузку данных. Если в ресурсном плане отсутствует группа потребителей ora$autotask, то загрузка будет выполняться в группе OTHER_GROUPS. Другие операции в ora$autotask включают в себя автоматизированные операции сопровождения, такие как сбор статистики и анализ сегментов.

Для изменения группы потребителей для in-memory загрузки данных может использоваться процедура SET_CONSUMER_GROUP_MAPPING.

Рис. 30. Изменение Resource Manager группы потребителей для INMEMORY операции

34

Заключение

Oracle Database In-Memory на порядки ускоряет аналитические запросы прозрачным образом, что позволяет предприятиям принимать бизнес-решения в режиме реального времени. Oracle Database In-Memory значительно ускоряет работу хранилищ данных и сред со смешанными OLTP нагрузками. Уникальная “двухформатная” архитектура Oracle автоматически поддерживает данные как в существующем строчном формате Oracle для OLTP операций, так и в новом исключительно in-memory колоночном формате, оптимизированном для аналитической обработки. Оба формата одновременно активны и транзакционно согласованны. Реализация колоночного хранилища внутри СУБД Oracle Database гарантирует его полную совместимость со ВСЕМИ существующими возможностями и не требует никаких изменений на уровне приложения. Это означает, что вы сможете воспользоваться всеми преимуществами технологии Oracle Database In-Memory уже с первого дня её использования вне зависимости от приложения.

Oracle Corporation, World Headquarters

500 Oracle Parkway

Redwood Shores, CA 94065, USA

Worldwide Inquiries

Phone: +1.650.506.7000

Fax: +1.650.506.7200

C O N N E C T W I T H U S Hardware and Software, Engineered to Work Together © Oracle и/или аффилированные компании, 2014. Все права защищены. Данный документ предоставляется исключительно в информационных целях, и его содержание может меняться без уведомления. Документ может

blogs.oracle.com/russia

facebook.com/oracle.russia

twitter.com/oracleRU

oracle.com/ru

содержать ошибки, на него не распространяются никакие гарантии или условия, выраженные устно или предусмотренные законодательством. Сюда включаются подразумеваемые гарантии, а также соображения о пригодности продуктов для определенной цели. Мы особо оговариваем, что не несем никакой ответственности в связи с данным документом. Документ также ни прямо, ни косвенно не создает никаких договорных обязательств. Воспроизведение или передача этого документа в любой форме, любым способом (электронным или физическим) и для любой цели возможны только с предварительного письменного разрешения Oracle. Oracle и Java являются зарегистрированными товарными знаками компании Oracle и/или ее филиалов. Другие названия могут быть товарными знаками соответствующих владельцев. Intel и Intel Xeon являются товарными знаками или зарегистрированными товарными знаками компании Intel Corporation. Все товарные знаки SPARC используются по лицензии и являются товарными знаками или зарегистрированными товарными знаками SPARC International, Inc. AMD, Opteron. Логотип AMD и логотип AMD Opteron являются товарными знаками или зарегистрированными товарными знаками компании Advanced Micro Devices. UNIX — зарегистрированный товарный знак The Open Group. 0415 Технический документ Oracle Database In-Memory Июль 2015 Автор: Мария Колган

1 | ORACLE DATABASE IN-MEMORY