Oracle Database In-Memory

Oracle Database In-Memory
Игорь Мельников
Oracle
ORACLE
PRODUCT
LOGO

План
 Введение
 Oracle Database In-Memory Option
 Результаты тестирования
 Заключение

Введение

Оперативная память: тренды и влияние
Сегодня память быстрее, дешевле и ее объем больше
Объемы памяти растут
2002 256 MB/DIMM
2012 16 GB/DIMM
DRAM:
2012 100 GB/DOM 2012 $0.0005/MB Flash
Flash: 400x больше емкости 400x дешевле 20x быстрее
Стоимость падает
2002 $0.2/MB
2012 $0.009/MB
Память значительно
быстрее
Disk
5ms – скорость
доступа
DRAM
100ns –
скорость
доступа
64x больше емкости 25x дешевле 50,000х быстрее
0.25ms –
скорость
доступа
Ускорение OLTP и DW приложений, больше пользователей, больше данных

Oracle In-Memory Database
Лучшие технологии для работы в памяти
• 20+ years of scale-up
optimizations
• 10+ years of scale-out
optimizations
• Prefix Index Compression
• Bitmap Index Compression
• Basic & IOT Table
Compression
• And much more
• In-Memory Parallel Query
• OLTP Compression
• Unstructured Data
• Client SQL/PL/SQL Result
• Server SQL/PL/SQL Result
12c Release 1
• Big Memory Cluster
& 2x more index compression
on Exadata
• Rowset Processing
• In-Memory Column Store
for Unstructured Data
• OLTP Wide Table
Compression
• HCC Row Level Locking
Приложение
работает с
памятью без
изменений!
Комбинация DRAM, Flash и HDD
Быстрой памяти и стоимости дисков
Без ограничений на размер БД
Compression
Cache
Cache
• In-Memory Column Store for
DW
• Columnar Compression
• Columnar Processing
• Cache Fusion Optimizations
• In-Memory Parallel Query
Optimizations
• In-Memory Storage Index on
Exadata Storage
Pre-2007 2007 2008 2009 2012

Противоречие которое длится десятилетия
Строчный формат и поколоночный
Row
SALES
Приходится выбирать один формат и идти на компромиссы
 OLTP-операции работают быстрее со
строчным форматом
– Быстрая обработка нескольких строк, много колонок
Column
 Аналитика работает быстрее с
колоночным форматом
– Отчет о сумме продаж по штату
– Быстрая обработка нескольких колонок, много строк
ORDER
SALES
S
T
A
T
E

Oracle Database In-Memory

Задачи Oracle Database In-Memory Option
В 100 раз быстрее запросы для аналитики в
реальном времени
 Мгновенное получение результата
 Запросы к OLTP базе или хранилищу данных
 Актуальные данные в результатах!
В 2 раза ускоряется обработка транзакций
 Вставка строк в 3 – 4 раза быстрее

Oracle In-Memory Columnar Сache
DRAM
Pure Columnar
 Данные в представлении
по колонкам без генерации
redo-информации
 Минимальные затраты на
изменения – даже для
OLTP-транзакций
 Данные загружаются в кэш
при первом
обращении/старте
экземпляра

In-Memory Option: Оба формата в памяти СУБД
 И строчный и поколоночный
формат хранения в памяти для
одних и тех же данных/таблиц
 Данные одновременно активны
и транзакционно согласованы
 В 100 раз быстрее аналитика &
отчетность: поколоночный
формат
 В 2 раза быстрее OLTP:
строчный формат
Column
Format
Memory
Row
Format
Memory
OLTP Analytics Sales Sales

Oracle In-Memory: отдельный кэш в SGA
Instance
SGA
Library
cache
Instance
SGA
Database
buffer cache
 Динамический параметр INMEMORY_SIZE
In-Memory
Columnar
Redo log
buffer cache
Shared pool
Data Dict.
cache
In-row
Cache
PMON SMON DBWR LGWR CKPT Others
Redo log
buffer cache
SQL> ALTER SYSTEM SET inmemory_size=512G SCOPE=SPFILE;

Статический пул в SGA
Параметр SGA_TARGET должен быть увеличен соответственно
SQL> SELECT * FROM V$SGA;
NAME VALUE
------------------ ---------
Fixed Size 2927176
Variable Size 570426808
Database Buffers 4634022912
Redo Buffers 13848576
In-Memory Area 1024483648

Почему сканирование в In-Memory быстрее
чем в буферном кэше?
Буферный кэш
SELECT COL4 FROM MYTABLE;
1
X
X
X
XX
РЕЗУЛЬТАТ
Строчный формат

Почему сканирование в In-Memory быстрее
чем в буферном кэше?
In-Memory кэш
SELECT COL4 FROM MYTABLE;
1
RESULT
Колоночный формат
РЕЗУЛЬТАТ
X
X
X
X

Включение columnar-кэширования для
таблицы или mview
 Включение columnar-кэширования для группы столбцов таблицы
 Кэшироваться может не вся таблица, а только часть столбцов!
SQL> ALTER TABLE cities
INMEMORY
INMEMORY (Id, Name, Country_Id, Time_Zone)
NO INMEMORY (Created, Modified, State);
Table altered.
SQL> ALTER MATERIALIZED VIEW cities_mv INMEMORY;
Materialized view altered.
•Служебные столбцы – не
участвуют в отчетах:
нужны только для бизнес-
логики

Включение columnar-кэширования для
табличного пространства
 Все таблицы и мат. представления в табличном пространстве
будут кэшироваться в Columnar-кэше
SQL> ALTER TABLESPACE tbs_data DEFAULT INMEMORY
MEMCOMPRESS FOR CAPACITY HIGH
PRIORITY LOW;
Tablespace altered.
 На уровне секций таблицы
SQL> CREATE TABLE customers ……
PARTITION BY LIST
(PARTITION p1 …… INMEMORY,
(PARTITION p2 …… NO INMEMORY);

Изменение плана запроса
SQL-оптимизатор перестраивает план запроса
SQL> SELECT count(*) FROM cities;
Execution Plan
----------------------------------------------------------
Plan hash value: 2756775702
---------------------------------------------------------------------
| Id | Operation | Name | Rows | Cost (%CPU)|
---------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 0 (0)|
| 1 | SORT AGGREGATE | | 1 | |
| 2 | TABLE ACCESS INMEMORY FULL| CITIES | 1 | |
---------------------------------------------------------------------

Сканирование миллиарда строк в секунду на
процессорном ядре
Пример: Найти все продажи в штате CA
In-Memory Column Store
Sales State column
“CA”
SIMD
Compare all
values in 1
cycle
Сравнение
всех
значений за
один цикл
Загрузка
значений
множества
штатов
Vector
Register
более
чем в 100
раз
быстрее
• Каждое процессорное ядро
сканирует одну колонку
 При сканировании
используются быстрые
векторные SIMD-инструкции
 Миллиарды строк в
секунду сканируются одним
ядром
CPU

Oracle In-Memory: “разогрев” кэша
 При старте БД (для Exadata/ZFS/Pillar) – checkpoint-сегмент для
Columnar-кэша
SQL> ALTER DATABASE FASTSTART TABLESPACE inmemory_tbs;
Database altered.
 Для generic hardware – при первом обращении к сегменту для
которого включен атрибут in-memory

Сканирование и объединение данных из
нескольких таблиц
Пример: Найти все продажи в outlet-магазинах
Продажи
Магазины
Type=outlet
T
Y
P
E
Storeid
in
15,38,64
S
T
O
R
E
I
D
A
M
O
U
N
T
 Конвертирует join в
быстрые сканы колонок
 Joins выполняются в 10
раз быстрее
Sum

Multiple Bloom Filter
Несколько соединий с использованием In-Memory

Мгновенная генерация отчетов: доли секунд
Пример: Показать тренды продаж
обуви в outlet магазинах
In-Memory
Report Outline
Stores
Products
Sales
Sales
 Динамически создает в
памяти объект-отчет
 Объект заполняется во
время сканирования
таблицы продаж
 Отчеты строятся в 20 раз
быстрее без заранее
созданных кубов

Cжатие столбцов в columnar-кэше
Метод сжатия Описание
• NO MEMCOPRESS • Данные не сжимаются
• MEMCOMPRESS FOR DML • Метод сжатия оптимизированный для DML-
операций
• MEMCOMPRESS FOR QUERY
LOW
• Метод по умолчанию. Сканирование не требует
декомпресии!!!
• MEMCOMPRESS FOR QUERY
HIGH
• MEMCOMPRESS FOR CAPACITY
HIGH
• MEMCOMPRESS FOR CAPACITY
LOW

Cжатие столбцов в кэше - пример
Сжатие разными методами для группы столбцов
INMEMORY
INMEMORY MEMCOMPRESS FOR CAPACITY HIGH(Country_Id, Time_Zone)
INMEMORY NO MEMCOMPRESS (Id, Name, Name_Eng);
Table altered.
•Уникальные столбцы – не
сжимаются!

Поддержка в Compression Advisor
DECLARE
l_blkcnt_cmp BINARY_INTEGER;
l_blkcnt_uncmp BINARY_INTEGER;
l_row_cmp BINARY_INTEGER;
l_row_uncmp BINARY_INTEGER;
l_cmp_ratio NUMBER;
l_comptype_str VARCHAR2(100);
BEGIN
dbms_compression.get_compression_ratio
--input parameters
scratchtbsname => 'USERS', -- scratch tablespace
ownname => ‘INMEM_DEMO', -- owner of the table
objname => ‘TICKETS', -- table name
subobjname => NULL, -- partition name
comptype => DBMS_COMPRESSION.COMP_INMEMORY_QUERY, -- compression algorithm
--output parameters
blkcnt_cmp => l_blkcnt_cmp, -- number of compressed blocks
blkcnt_uncmp => l_blkcnt_uncmp, -- number of uncompressed blocks
row_cmp => l_row_cmp, -- number of rows in a compressed block
row_uncmp => l_row_uncmp, -- number of rows in an uncompressed block
cmp_ratio => l_cmp_ratio, -- compression ratio
comptype_str => l_comptype_str);-- compression type
END;

Атрибут INMEMORY в USER_TABLES
SQL> SELECT table_name,
inmemory
FROM USER_TABLES;
TABLE_NAME INMEMORY
------------ --------
CHANNELS DISABLED
COSTS
CUSTOMERS DISABLED
PRODUCTS ENABLED
SALES
TIMES DISABLED
 Новый столбец INMEMORY в
представлениях словаря
*_TABLES
 INMEMORY – это атрибут
сегмента
 *_TABLES не отображают
атрибуты логических объектов
 COST и SALES –
секционированные таблицы
(логические объекты)
 Столбец INMEMORY также
появился в *_TAB_PARTITIONS

Системное представление V$IM_SEGMENTS
Мониторинг использования кэша
SQL> SELECT
segment_name,inmemory_size,bytes,bytes_not_populated,populate_status
FROM
v$im_segments;
SEGMENT_NAME INMEMORY_SIZE BYTES BYTES_NOT_POPULATED POPULATE_STATUS
--------------------------------------------------------------------------
COUNTRIES 131072 5242880 425984 STARTED
CITIES 1179648 5242880 0 COMPLETED
COMPANIES 1179648 5242880 0 COMPLETED
AIRPORTS 1179648 5242880 0 COMPLETED

Управление приоритетом загрузки в кэш
Приоритет Синтаксис Описание
• NONE
(default)
PRIORITY NONE • Приоритет загрузки определяется
СУБД. Загрузка может быть
задержана, если память используется
для другого более приоритетного
сегмента. - Запрос переключаетcя на
обычный (in-row) кэш.
• LOW PRIORITY LOW • Низкий приоритет
• MEDIUM PRIORITY MEDIUM • Средний приоритет
• HIGH PRIORITY HIGH • Высокий приоритет
• CRITICAL PRIORITY CRITICAL • Высший приоритет

Приоритет загрузки в кэш - пример
Один приоритет для всей таблицы/секции/мат. представления
INMEMORY
PRIORITY CRITICAL
INMEMORY MEMCOMPRESS FOR CAPACITY HIGH(Country_Id, Time_Zone)
INMEMORY MEMCOMPRESS NO (Id, Name, Name_Eng);
Table altered.

OLTP работает медленно из-за аналитических
индексов
Таблица
1 - 3
OLTP
индекса
10 - 20
аналитических
 Большинство индексов в OLTP индексов
(например, в ERP) базах
строится только для
аналитических запросов
 Индексы хорошо подходят для
предсказуемых запросов (и в
памяти, и на диске)
 Вставка одной строки в таблицу
приводит к обновлению 10-20
аналитических индексов:
Медленно!
Поколоночное
хранение в памяти

Oracle In-Memory – высокая доступность
 Представление по столбцам в
памяти не влияет на формат
данных на диске: datafiles,
logging, backup, recovery, и т.д.
 Все технологии, в том числе
ASM, RAC, DG, GG работают
прозрачно для In-Memory Option
 Защита от любых видов ошибок
 На уровне железа
 Логические ошибки
приложения (Flashback)
Data Guard & GoldenGate
RAC
ASM
RMAN

Oracle In-Memory в RAC
 Управление распределением объектов в кэше между узлами RAC:
– AUTO DISTRIBUTE – синхронизацией кэша управляет СУБД
(поведение по умолчанию)
– DUPLICATE – (exa-only) кэши принудительно синхронизируются между
узлами RAC (2 копии chunk-а кластер)
– DUPLICATE ALL – (exa-only) кэши одинаковы на всех узлах RAC
– DISTRIBUTE BY ROWID RANGE, DISTRIBUTE BY
PARTITION, DISTRIBUTE BY SUBPARTITION
SQL> ALTER TABLE cites INMEMORY
DUPLICATE;
Table altered.
In Memory
Column
Store
In Memory
Column
Store
In Memory
Column
Store
In Memory
Column
Store

Полный синтаксис кэширования таблицы
Мощный и гибкий синтаксис
INMEMORY
PRIORITY CRITICAL
DUPLICATE
INMEMORY MEMCOMPRESS FOR CAPACITY HIGH (Country_Id, Time_Zone)
INMEMORY MEMCOMPRESS NO (Id, Name, Name_Eng)
NO INMEMORY (Created, Modified, State);
Table altered.

Подсказки для оптимизатора
Включение/выключение columnar-кэширования и pruning-а
SQL> SELECT /*+ NO_INMEMORY (mytbs) */
sum(a.amount)
FROM
cities c,
amounts a
WHERE
c.id = a.city_id;
 Новые хинты: INMEMORY, INMEMORY_PRUNING,
NO_INMEMORY_PRUNING,

Storage Index в In-Memory Columnar Store
 Хранит
минимальное и
максимальное
значение столбца в
каждом экстенте
памяти кэша
 Прозрачно
исключает ненужные
сканирования
столбцов, например:
WHERE prod_id > 14
AND prod_id < 29

In-Memory Option - архитектура
 Space Manager
 Управляет памятью в In-
Memory Column Store
(create, extend, drop)
 Загружает данные в кэш
 Transaction Manager
 Обеспечивает
согласованность данных
в In-Memory Column
Store с буферным
кэшем
 Обеспечивает
версионность

Новые параметры в init.ora
 INMEMORY_SIZE
 INMEMORY_FORCE= { DEFAULT | OFF }
 INMEMORY_CLAUSE_DEFAULT= [INMEMORY] [NO INMEMORY]
[compression-clauses][priority-clauses]
 INMEMORY_QUERY={ENABLE | DISABLE}
 INMEMORY_MAX_POPULATE_SERVERS
 OPTIMIZER_INMEMORY_AWARE
 INMEMORY_TRICKLE_REPOPULATE_SERVERS_PERCENT

Для каких приложений подходит In-Memory
Option?
 Если в приложении есть много запросов сканирующих много строк
с фильтрами такими как: “=, <, >, и IN”
 Запрашивает всего лишь несколько столбцов, напр: 5 столбцов из
100 столбцов таблицы
 Приложение часто делает соединение большой факторной
таблицы с таблицей измерений, с фильтром по таблице измерений
 Типы приложений предпочтительные для использования In-
Memory Option: хранилища данных (DataWarehouse) и cмешанного
типа (Mixed Application)

Oracle In-Memory Options не требует
изменения приложений
Полная функциональность - Нет ограничений на SQL
Простота реализации - Не нужна миграция данных
Полная совместимость - Не надо изменять приложения
Полностью Multitenant - Oracle In-Memory готова для cloud
Приложения получают все преимущества In-Memory опции без изменения кода приложения

Oracle Database In-Memory и TimesTen
TimesTen In-Memory Database
• Встраиваемая БД для приложений
• Экстремальная быстрая
производительность для OLTP-нагрузки
(время ответа - микросекунды)
• Адаптивный кэш для инженерной системы
Oracle Exalytics
Application
Application
Application
Oracle Database In-Memory Option
• Масштабируемая обработка данных в
памяти для любых видов нагрузки, в том
числе и смешанной (OLTP и DWH)

TimesTen In-Memory Database и Columnar
 TimesTen также используется и для
аналитических задач
 TimesTen имеет технологию обработки по
столбцам для ускорения аналитики
– Ядро системы обработки и хранения данных
по столбцам общее для TT и Oracle Database
– Дополнительно TT имеет встроенный
аналитический “движок”
TimesTen Grid
Scale-Out In-Memory DB
Columnar
42

Public 4

Результаты
тестирования

Тестовый стенд
 Сервер Oracle Sun X2-4
– 4CPU Intel Xeon E7-4800 (40 ядер)
– 1Тб RAM
 Oracle Database 12.0.1.2 – Beta
– Буферный кэш: 300Gb
– In-Memory Columnar Cache: 300Gb
 Объем таблицы: 167Gb

Тест N1: cкорость полного сканирования
In-Memory Cache: идентичен обычному буферному кэшу
 SELECT /*+ FULL(tickets) */ count(*) FROM tickets;
3
2,5
2
1,5
1
0,5
0
1,25 1,28
Обычный кэш Сolumnar Cache

Тест N2: cкорость фильтрации
In-Memory Cache: в 5 раз быстрее!
 SELECT count(*) FROM tickets WHERE reservaton_code=‘test';
3
2,5
2
1,5
1
0,5
0
2,51
0,5
Обычный кэш Сolumnar Cache

Тест N3: cжатие
In-Memory Cache: в 2 раза, без потери скорости!
160
140
120
100
80
60
40
20
0
Размер на
диске
Сolumnar
Cache (Мин.
степень)
Сolumnar
Cache (Макс.
степень)
167
128
86

Тест N4: 3-ый запрос после 10 секунд
In-Memory Cache: мгновенный результат!
SQL> SELECT count(*) FROM tickets WHERE reservation_code='test'
COUNT(*)
----------
0
Elapsed: 00:00:00.00
 Внутренний неявный result cache

Oracle Database In-Memory Option
 Мощная технология обработки данных в памяти
– Эффективно интегрирована в СУБД Oracle Database
 Обеспечивает увеличение производительности
– Аналитических и Ad-Hoc отчетов на “живых” данных
– Для OLTP-приложений и хранилищ данных
 Готовое решение в “коробке”: прозрачно для приложений!

Заключение: Oracle In-Memory Option
 Экстремальная производительность для OLTP и
хранилищ данных на актуальных данных
 Прозрачное масштабирование по CPU и RAM
 Прозрачно для всех технологий СУБД Oracle
Все преимущества обработки в памяти
без изменения приложений

Заключение: Oracle Database 12c R1 Patchset 1
 Oracle Database - In-Memory Database :
– In-Memory Database Option
– Automatic Big Table Cache
– Full Database Caching Mode
 Встроенная поддержка JSON
 Attribute Clustering
 Zone Mapping

Oracle Database In-Memory

Recommended

Recommended

More Related Content

What's hot

What's hot (17)

Similar to Oracle Database In-Memory

Similar to Oracle Database In-Memory (20)

More from Andrey Akulov

More from Andrey Akulov (20)

Oracle Database In-Memory

Editor's Notes