Подписаться
Читать в телеграм
Традиционные базы (в том числе Oracle Database) используют строчное хранение данных (Row Database) как в памяти, так и на дисках. Принято считать, что такое хранение оптимально для транзакционных систем класса OLTP, а вот в хранилищах класса DWH определенные аналитические запросы могут работать гораздо быстрее при колоночном хранении. Базы данных, реализующие такое хранение (Columnar Database), достаточно активно развиваются, в том числе в направлении колоночного хранения в памяти.
Появившаяся в Oracle Database 12c опция Database In-Memory реализует колоночное хранение данных в памяти дополнительно к традиционному строчному хранению. Такое хранение возможно благодаря специальной области памяти, в которой администратор Oracle Database может кэшировать данные как целых таблиц, так и отдельных колонок либо партиций в колоночном формате. Эти данные поднимаются в In-Memory кэш при старте экземпляра Oracle и затем поддерживаются в консистентном состоянии с данными обычного буферного кэша Oracle и с данными на дисках.
Такое дополнительное колоночное хранение данных в памяти является прозрачным для приложения, при этом у оптимизатора Oracle появляется возможность выбора из памяти нужных данных как в строчном, так и в колоночном представлении. То есть в Oracle Database реализовано уникальное сочетание строчного и колоночного хранения данных в памяти.
При этом опция In-Memory – это не просто работа с данными в памяти в новом для Oracle колоночном формате, это еще и новые математические подходы: доработанные алгоритмы сжатия, механизмы быстрого определения минимальных и максимальных значений, Bloom фильтры. В результате использование In-Memory в ряде случаев может приводить к серьезному ускорению SQL-запросов (прежде всего аналитических).
При построении хранилищ и витрин данных мы регулярно применяем «шинный» подход к архитектуре, при котором одни и те же справочники используются для разных витрин и разрезов данных. Использование In-Memory для таких справочников позволит значительно ускорить работу бизнес-приложений, в том числе аналитических систем. Например, в банковском секторе скорость и качество обслуживания клиентов во многом зависят от доступности сервисов – от скорости предоставления информации, будь то выписка по счету, список уже приобретенных клиентом услуг или консультации по новым продуктам. Применение In-Memory гарантирует оперативные предоставление и анализ требуемых данных.
Мы неоднократно знакомили оракловое сообщество с результатами, полученными в наших тестированиях работы In-Memory, в частности, мы разработали методику, эмулирующую работу систем класса DWH. В таблицу базы данных Oracle были сложены случайным образом сгенерированные данные о жителях Европы и их зарплатах, а роль аналитика эмулировал запрос, считающий сумму всех зарплат жителей конкретной европейской страны.
На этом запросе нам удалось получить ускорение в сотни и даже тысячи раз при чтении данных из In-Memory кэша в сравнении с чтением данных с дисков. При этом по сравнению с чтением из буферного кэша чтение из кэша In-Memory оказалось быстрее почти в 4 раза (0,51 секунды против 1,9 секунды). Результат значительного ускорения по сравнению с чтением с дисков очевиден, а вот 4-кратное ускорение по сравнению со строчным форматом, на наш взгляд, является заслугой заложенных в In-Memory математических подходов. Этот результат демонстрирует Print Screen из Enterprise Manager, приведенный на рис. 1. Для исследования работы In-Memory мы использовали хинт оптимизатора /* +no_inmemory(имя_таблицы) */, в явном виде запрещающий оптимизатору Oracle использовать In-Memory кэш.
Поскольку заложенная Oracle в новые процессоры SPARC M7 технология SQL in Silicon на сегодняшний день может ускорять работу именно In-Memory, важной частью тестирования серверов T7-2 стала проверка на них работы опции In-Memory по уже отлаженной методике (в ее основе лежит аналитический запрос, считающий суммарную зарплату).
Для таких тестов крайне важно было научиться явно включать возможности сопроцессора DAX на уровне как OS (соответствующие патчи Solaris), так и Oracle Database (специальный параметр экземпляра), а также правильно мониторить работу DAX. Команда busstat вполне адекватно показывает участие сопроцессоров DAX в работе основного процессора с точки зрения OS: на рис. 2 и 3 приведены выводы команды busstat в сравнении с выключенным и включенным параметром экземпляра.
Итак, запрос, суммирующий зарплату жителей всех европейских стран на букву R (Россия и Румыния), в наших тестах показал 1,95 секунды при традиционной работе Oracle Database и 0,51 секунды при настройке опции In-Memory и поднятии части данных (колонка с зарплатой) в специальный In-Memory кэш. Включение дополнительных возможностей сопроцессоров DAX (SQL in Silicon) дало результат 0,39 секунды, т.е. дополнительное ускорение на 30% сверх 4-кратного ускорения в In-Memory. Эти результаты сведены в табл. 1.
Табл. 1. Ускорение работы In - Memory с помощью сопроцессора DAX
Работа запроса | Время исполнения, сек | OS: busstat -w dax |
без In-Memory (обычный кеш) | 1,95 | 0 |
с In-Memory и выключенным DAX | 0,51 | 0 (Рис.2) |
с In-Memory и включенным DAX | 0,39 | Восемь строк >0 (Рис.3 ) |
Много это или мало? С одной стороны, параллельно исследованию SQL in Silicon мы провели тестирование работы сопроцессоров DAX с помощью специально созданного приложения. Это приложение использовало DAX напрямую (через открытые Oracle библиотеки) и показало ускорение в 4–6 раз стандартных математических операций по преобразованию множеств. На фоне этого ускорение работы In-Memory выглядит скромнее. С другой стороны, работа опции In-Memory сама по себе достаточно оптимизирована, и ускорение в 4 раза по сравнению с буферным кэшем наглядно это подтверждает.
Тем не менее вполне возможно, что продуктивные аналитические запросы наших заказчиков смогут ускориться за счет DAX более существенно, поэтому технология SQL in Silicon заслуживает тщательного тестирования на реальных данных реальными аналитическими запросами.
