Db in-memory-overview 2015-10_14

www.partner.fors.ru 1
Новая опция
Oracle Database 12c
In-Memory
Валерий Юринский
Директор отделения технологического консалтинга
vyourinsky@fors.ru
14 октября 2015 г.

План
 Введение
 Oracle Database In-Memory Option
 Несколько примеров
 Заключение

Введение

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

Oracle In-Memory Database
Лучшие технологии для обработки данных в памяти
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
Быстрой памяти и стоимости дисков
Без ограничений на размер БД
2007 2012До 2007 20092008
• 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
Compression
• Client SQL/PL/SQL Result
Cache
• Server SQL/PL/SQL Result
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

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

Давнее противоречие
Строчный формат и поколоночный формат
Row
Выборка одного заказа в построчном формате
- Обращение к одной непрерывной строке
= БЫСТРО
Column
Выборка одного заказа в поколоночном формате
- Обращение к нескольким столбцам
= М Е Д Л Е Н Н О
SALES
StoresSALES
Query
Query
Query
Query
Query
Приходилось выбирать один формат и идти на компромиссы

Database In-Memory
Option

Oracle Database In-Memory Option
В опцию Oracle Database In-Memory входят
следующие функциональные возможности:
– In-Memory Column Store
– In-Memory Aggregation
– Fault Tolerant In-Memory Column Store (Requires Exadata or
Supercluster)

Аналитика в
реальном
времени
Неизменность
приложений
Простота
внедрения
100x 2x
10
Задачи Oracle Database In-Memory
Призводитель-
ность при сме-
шаной нагрузке

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

Прорыв: база данных с двойным форматом
• Использует OБA (два) формата
для одной таблицы: строчный и
поколоночный
• Работают совместно,
транзакционно согласованы
• Аналитика и отчетность
используют новый
поколоночный формат In-
Memory
• OLTP использует проверенный
построчный формат
Обычный
Buffer Cache
Новый формат
In-Memory
SALES SALES
Строчный
формат
Поколоночный
формат
SALES

Oracle In-Memory Columnar Technology
Оперативная память
Истинно поколоночный
 In-Memory Column Store (IMCS) -
постолбцовое оперативное
хранилище
 Истинно поколоночное (pure
columnar) хранение в памяти
 изменяемые данные
 нет генерации REDO-данных
 Минимальные затраты на
изменения – даже для OLTP-
транзакций
 Данные загружаются в кэш при
первом обращении

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

Oracle Instance 12c без In-Memory
Instance
SGA
Redo log
buffer cache
Shared pool
Data Dict.
cache
Library
cache
DBWRSMONPMON CKPTLGWR Others
Database
buffer cache
Shared pool
Data Dict.
cache
Library
cache

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

Статический пул в 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;
X
X
X
X
X
РЕЗУЛЬТАТ
Строчный формат
Буферный кэш

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

Включение постолбцового представления для
таблицы или mview
 Включение постолбцового представления для группы столбцов
 Кэшироваться может не вся таблица, а только часть её столбцов!
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.
•Служебные столбцы – не
участвуют в отчетах:
нужны только для бизнес-
логики

Включение постолбцового представления для
табличного пространства и секции
 Все таблицы и mview в табличном пространстве будут
представлены в постолбцовом оперативном хранилище (IMCS)
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 | |
---------------------------------------------------------------------

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

При первом обращении к сегменту для которого включен атрибут
in-memory начинается наполнение постолбцового оперативного
хранилища (In-Memory Column Store = IMCS)
Oracle In-Memory: “разогрев” IMCS

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

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

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

Cжатие столбцов в IMCS - пример
Сжатие разными методами для группы столбцов
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 в *_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

Системное представление [G]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 • Наивысший приоритет

Приоритет загрузки в IMCS - пример
Один приоритет для всей таблицы/секции/мат. представления
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)
RAC
ASM
RMAN
Data Guard & GoldenGate

Oracle In-Memory в RAC
 Управление распределением объектов в кэше между узлами RAC:
– AUTO DISTRIBUTE – синхронизацией кэша управляет СУБД
(поведение по умолчанию)
– DUPLICATE – (ES-only) кэши принудительно синхронизируются между
узлами RAC (2 копии chunk-а кластер)
– DUPLICATE ALL – ( ES-only) кэши одинаковы
на всех узлах RAC
– DISTRIBUTE BY
 ROWID RANGE,
 PARTITION,
 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, NO_INMEMORY
– INMEMORY_PRUNING, NO_INMEMORY_PRUNING

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

DML and the In-Memory Column Store
• Каждый объект помещенный в Column
Store состоит из множества колоночных
элементов (column units=IMCU)
/Each object populated in the Column Store is
actually made up of multiple column units (IMCU)/
• Каждый колоночный элемент содержит
значения столбца для подмножества
(нескольких) строк объекта
/Each column unit contains the column
entries for a subset of rows in the object/
• В зависимости от типа данных и степени
сжатия колоночные элементы могут
быть разного размера
/Column units can vary in size depending
on datatypes used and compression rates/
Memory
SALES
Column
Format

Memory
Column
Format
IMCU IMCU
IMCU IMCU
IMCU IMCU
IMCU IMCU
IMCU IMCU
• Каждый объект помещенный в Column
Store состоит из множества колоночных
элементов (column units=IMCU)
/Each object populated in the Column Store is
actually made up of multiple column units (IMCU)/
• Каждый колоночный элемент содержит
значения столбца для подмножества
(нескольких) строк объекта
/Each column unit contains the column
entries for a subset of rows in the object/
• В зависимости от типа данных и степени
сжатия колоночные элементы могут
быть разного размера
/Column units can vary in size depending
on datatypes used and compression rates/

• Каждый колоночный элемент (IMCU)
содержит значения столбца для
подмножества (нескольких) строк
объекта
/Each IMCU contains the column entries for a
subset of rows in the object/
• У каждого IMCU имеется связанный с
ним журнал транзакций
/Each IMCU also has a transaction journal
associated with it/
• Журнал транзакций используется для
поддержания транзакционной
согласованности Column Store
/The transaction journal is used to keep the IM
column store transactionally consistent/
Memory
Column
Format
IMCU
JOURNAL

JOURNAL
• Операции DML обрабатываются
обычным образом в обычном
строчном хранилище
/DML operations processed in row store
just as they are today/
Memory
Column
Format
• Соответствующие измененным
строкам элементы Column Store
помечаются, Как "устаревшие"
/Corresponding entry in column store
marked stale/
• Копия измененных строк хранятся в
транзакционном журнале
/Copy of changed row stored in the
Transaction Journal/
IMCU

JOURNAL
• In-Memory Column Store никогда не
устаревает
/In-Memory Column Store is never out of
date/
• Согласованность по чтению
достигается объединением
актуального содержимого столбцов
и транзакционного журнала
/Read consistency achieved by merging
contents of column and the transaction
journal/
Memory
Column
Format
IMCU

• Когда число записей в
транзакционном журнале достигает
определенного порогового
значения, колоночный элемент
автоматически обновляется
/When number of entries in transaction
journal hits an internal threshold CU
automatically refreshed/
• Column Store всегда доступен,
Поскольку обновление
выполняется online
/This is an online operation – column store
always available/
Memory
Column
Format
JOURNAL
IMCU

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

Новые параметры в 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

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

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

Oracle Database 12c Runs SAP Applications 2x Faster
Than SAP HANA
По Why Risk Disrupting Your Business with SAP HANA?
Oracle Database In-Memory is 100 percent compatible with all existing
applications, therefore there is no need to rewrite your application to take
advantage of it. No complexity, no compromises, no risks. Modern in-memory
technology that simply and seamlessly works with your business—not the other
way around. In contrast, with SAP HANA, the application will need to be
rewritten, spending precious resources, time, and budget.
Get Analytics 2x Faster Than with SAP HANA
Oracle Database In-Memory implements state-of-the-art technology to
accelerate analytics by orders of magnitude to allow users to get
immediate answers to business questions that previously took hours. This
same Oracle in-memory technology is proven to speed up SAP
applications 2x faster than SAP HANA on SAP's own benchmarks.
Read the Benchmark white paper*
https://www.oracle.com/corporate/features/oracle-powers-sap.html
15-sep-2015

Oracle Database In-Memory Advisor (Doc ID 1965343.1)
Пример рекомендаций

Несколько примеров

Тестовый стенд
 Сервер Oracle Sun T5-2
– 2 x Sixteen-core 3.6 GHz SPARC T5 processor = 32 cores
– 32 cores x 8 threads/core = 256 threads
– 512 ГБ RAM
 Oracle Database 12.0.1.2
– Буферный кэш: 240Gb
– In-Memory Columnar Cache: 100Gb

Данные для "тренировочных забегов" в In-Memory
Схема данных  Схема типа "Звезда"
 Вариация стандартной
схемы теста TPC-H –
производительность
хранилища данных (DWH)
 Схема построена для
масштаба 100 ГБ (100 GB
scale factor)
Таблица Объем, МБ Кол-во строк
CUSTOMER 2 309,2 15 000 000
DATE_DIM 0,2 2 556
LINEORDER 42 279,0 600 019 253
PART 1 778,1 20 000 000
SUPPLIER 147,5 1 000 000
Compression BASIC

Конфигурирование
Sun Server T5-2 – RAM 512 GB
SQL> SHOW SGA
Total System Global Area 498 216 206 336
Fixed Size 7 663 664
Variable Size 147 102 633 936
Database Buffers 243 202 523 136
Redo Buffers 529 203 200
In-Memory Area 107 374 182 400
Размер устанавливается параметром INMEMORY_SIZE
(Minimum IN_MEMORY_SIZE = 100MB)

Заполнение Buffer Cache и In-Memory Column Store
Установка параметров Cache и In-Memory
-- Устанавливается для эксперимента, чтобы не было дисковых операций
ALTER TABLE CUSTOMER CACHE;
ALTER TABLE DATE_DIM CACHE;
ALTER TABLE LINEORDER CACHE STORAGE (BUFFER_POOL KEEP);
ALTER TABLE PART CACHE;
ALTER TABLE SUPPLIER CACHE;
-- Указание на размещение в In-Memory Column Store
ALTER TABLE CUSTOMER INMEMORY;
ALTER TABLE DATE_DIM INMEMORY;
ALTER TABLE LINEORDER INMEMORY;
ALTER TABLE PART INMEMORY;
ALTER TABLE SUPPLIER INMEMORY;

-- Заполнение Buffer Cache
-- и инициирование заполнения In-Memory Column Store
SELECT /*+ FULL(T) NO_PARALLEL */ COUNT(*) FROM CUSTOMER T;
SELECT /*+ FULL(T) NO_PARALLEL */ COUNT(*) FROM DATE_DIM T;
SELECT /*+ FULL(T) NO_PARALLEL */ COUNT(*) FROM LINEORDER T;
SELECT /*+ FULL(T) NO_PARALLEL */ COUNT(*) FROM PART T;
SELECT /*+ FULL(T) NO_PARALLEL */ COUNT(*) FROM SUPPLIER T;

100 GB Scale Factor
WITH bh AS (SELECT objd, file#, ROUND(COUNT(block#)*16384/1024/1024, 1) AS mbytes
FROM v$bh group by objd, file#)
SELECT T.table_name, bh.mbytes AS buff_cache_mb
, ROUND(T.blocks*16384/1024/1024,1) AS tab_mb, num_rows
FROM bh, user_objects O, user_tables T
WHERE bh.objd = O.object_id AND T.table_name = O.object_name
AND O.object_name IN ('LINEORDER', 'DATE_DIM', 'CUSTOMER', 'SUPPLIER', 'PART')
ORDER BY O.object_name;
TABLE_NAME BUFF_CACHE_MB TAB_MB NUM_ROWS
CUSTOMER 2303,1 2309,2 15 000 000
DATE_DIM 0,2 0,2 2 556
LINEORDER 42234,1 42279 600 019 253
PART 1772,6 1778,1 20 000 000
SUPPLIER 146,1 147,5 1 000 000

Enterprise Manager Cloud Control 12c Release 4
In-Memory Central

Enterprise Manager Cloud Control 12c Release 4

MIN / MAX

Выборка из Buffer Cache и In-Memory Column Store
Запуск-1 (с трассировкой)
SQL> SELECT MAX(LO_ORDTOTALPRICE) AS most_expensive_order FROM lineorder;
MOST_EXPENSIVE_ORDER
--------------------
564829.26
Elapsed: 00:00:11.95 (12 s)
-----------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 6 | 41510 (31)| 00:00:04 |
| 1 | SORT AGGREGATE | | 1 | 6 | | |
| 2 | TABLE ACCESS INMEMORY FULL| LINEORDER | 600M| 3433M| 41510 (31)| 00:00:04 |
-----------------------------------------------------------------------------------------
4 recursive calls
0 db block gets
10 consistent gets
1 physical reads
0 redo size
230 bytes sent via SQL*Net to client
387 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed

Запуск-1 (с трассировкой)
SQL> SELECT /*+ NO_INMEMORY */ MAX(LO_ORDTOTALPRICE) AS most_expensive_order FROM LINEORDER;
--------------------
564829.26
Elapsed: 00:01:34.95 (95 s)
--------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 6 | 1027K (2)| 00:01:21 |
| 1 | SORT AGGREGATE | | 1 | 6 | | |
| 2 | TABLE ACCESS FULL| LINEORDER | 600M| 3433M| 1027K (2)| 00:01:21 |
--------------------------------------------------------------------------------
4 recursive calls
0 db block gets
2703058 consistent gets
0 physical reads
0 redo size
0 sorts (memory)
0 sorts (disk)
1 rows processed
Buffer_cache/InMemory
= 95s/12s = 8

Запуск-2 (без трассировки)
SQL> SELECT MAX(lo_ordtotalprice) AS MOST_EXPENSIVE_ORDER FROM lineorder;
--------------------
564829.26
Elapsed: 00:00:00.52 (1s)
SQL> SELECT /*+ NO_INMEMORY */ max(lo_ordtotalprice) most_expensive_order From LINEORDER;
--------------------
564829.26
Elapsed: 00:01:35.59 (96s)
= 96s/1s = 96

Запуск-3
SQL> SELECT MIN(lo_ordtotalprice) least_expensive_order FROM lineorder;
LEAST_EXPENSIVE_ORDER
---------------------
903.95
Elapsed: 00:00:00.50 (1s)
SQL> SELECT /*+ NO_INMEMORY */ MIN(lo_ordtotalprice) least_expensive_order FROM lineorder;
LEAST_EXPENSIVE_ORDER
---------------------
903.95
Elapsed: 00:01:34.98 (95s)
= 95s/1s = 95

In-Memory Column Store vs Buffer Cache

In-Memory Column Store vs Buffer Cache
Statistics In-Memory Buffer Cache
consistent gets 4 2 703 055
consistent gets from cache 4 2 703 055
consistent gets pin 4 2 703 055
consistent gets pin (fastpath) 4 2 703 055
CPU used by this session 2 899 9 517
CPU used when call started 2 899 9 517
DB time 2 900 9 517
IM scan bytes in-memory 36 353 580 495 0
IM scan bytes uncompressed 61 888 813 221 0
IM scan CUs columns accessed 1 058 0
IM scan CUs columns theoretical max 17 986 0
IM scan CUs memcompress for query low 1 058 0
IM scan CUs split pieces 1 073 0
IM scan rows 600 019 253 0
IM scan rows projected 600 019 253 0
IM scan rows valid 600 019 253 0
IM scan segments disk 0 1
logical read bytes from cache 65 536 44 286 853 120
no work - consistent read gets 0 2 702 974
table scans (IM) 1 0

Поиск по точному значению

SQL> -- In-Memory Column Store query
SQL> Select lo_orderkey, lo_custkey, lo_revenue From LINEORDER Where lo_orderkey = 5000000;
LO_ORDERKEY LO_CUSTKEY LO_REVENUE
----------- ---------- ----------
5000000 9532031 145267
. . .
Elapsed: 00:00:00.25 (1s)
SQL> -- Buffer Cache query with the column store disables via NO_INMEMORY hint
SQL> select /*+ NO_INMEMORY */ lo_orderkey, lo_custkey, lo_revenue
3 from LINEORDER where lo_orderkey = 5000000;
----------- ---------- ----------
5000000 9532031 145267
. . .
Elapsed: 00:01:30.60 (91s)
= 91s/1s = 91

Buffer Cache
-------------------------------------------------------------------------------
|* 1 | TABLE ACCESS FULL| LINEORDER | 4 | 76 | 1022K (1)| 00:01:20 |
-------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter("LO_ORDERKEY"=5000000)
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
2703056 consistent gets
0 physical reads
0 redo size
0 sorts (memory)
0 sorts (disk)
5 rows processed
= 91s/1s = 91

Работа Storage Index

Использование Storage Index
IM scan CUs pruned 125
IM scan CUs columns accessed 935
IM scan segments minmax eligible 1058
Был доступ к 933 IMCU (1058 – 125 = 933)
плюс еще к двум для получения lo_custkey и lo_revenue
933 + 1 + 1 = 935

Индексный доступ
или поиск в памяти?

Построен невидимый индекс
SQL> CREATE INDEX LINEORDER#I#LO_ORDERKEY
2 ON LINEORDER(LO_ORDERKEY)
3 INVISIBLE;
Index created.
Elapsed: 00:23:35.28
SQL> SELECT segment_name, ROUND(bytes/1024/1024) AS mbytes
2 FROM user_segments
3 WHERE segment_name = 'LINEORDER#I#LO_ORDERKEY';
SEGMENT_NAME MBYTES
----------------------- -------
LINEORDER#I#LO_ORDERKEY 11520 <-- 11.5 GB

In-Memory Scan
SQL> Select /* Without index */ lo_orderkey, lo_custkey, lo_revenue
2 From LINEORDER
3 Where lo_orderkey = 5000000;
----------- ---------- ----------
5000000 9532031 145267
. . .
Elapsed: 00:00:00.44
----------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
----------------------------------------------------------------------------------------
|* 1 | TABLE ACCESS INMEMORY FULL| LINEORDER | 4 | 76 | 41612 (32)| 00:00:04 |
----------------------------------------------------------------------------------------

Index Range Scan
SQL> ALTER SESSION SET OPTIMIZER_USE_INVISIBLE_INDEXES = TRUE;
Session altered.
SQL> Select /* With index */ lo_orderkey, lo_custkey, lo_revenue
2 From LINEORDER
3 Where lo_orderkey = 5000000;
----------- ---------- ----------
5000000 9532031 145267
. . .
Elapsed: 00:00:00.45
---------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------------
| 1 | TABLE ACCESS BY INDEX ROWID BATCHED| LINEORDER | 4 | 76 | 7 (0)| 00:00:01 |
|* 2 | INDEX RANGE SCAN | LINEORDER#I#LO_ORDERKEY | 4 | | 3 (0)| 00:00:01 |
---------------------------------------------------------------------------------------------------------------
SQL> ALTER SESSION SET OPTIMIZER_USE_INVISIBLE_INDEXES = FALSE;
Session altered.

In-Memory Scan vs Index Range Scan
SQL> SELECT segment_name, ROUND(bytes/1024/1024) AS mbytes
2 FROM user_segments
3 WHERE segment_name = 'LINEORDER#I#LO_ORDERKEY';
SEGMENT_NAME MBYTES
----------------------- -------
LINEORDER#I#LO_ORDERKEY 11520 <-- 11.5 GB
Время одинаковое, но индекс занимает место, замедляет
DML и его нужно администрировать: наблюдать,
перестраивать, собирать статистику и т.п.
Index range Scan/In-Memory Scan
= 0.44s/0.45s = 1

Множественные условия выборки

In-Memory Scan
SQL> Select lo_orderkey, lo_custkey, lo_revenue
2 From LINEORDER
3 Where lo_custkey = 5641
4 And lo_shipmode = 'XXX AIR'
5 And lo_orderpriority = '5-LOW';
no rows selected
Elapsed: 00:00:00.32 (1s)
----------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------
|* 1 | TABLE ACCESS INMEMORY FULL| LINEORDER | 2 | 92 | 30248 (6)| 00:00:03 |
----------------------------------------------------------------------------------------
---------------------------------------------------
1 - inmemory("LO_CUSTKEY"=5641 AND "LO_SHIPMODE"='XXX AIR' AND
"LO_ORDERPRIORITY"='5-LOW')
filter("LO_CUSTKEY"=5641 AND "LO_SHIPMODE"='XXX AIR' AND

Buffer Cache
SQL> Select /*+ NO_INMEMORY */ lo_orderkey, lo_custkey, lo_revenue
2 From LINEORDER
3 Where lo_custkey = 5641
4 And lo_shipmode = 'XXX AIR'
5 And lo_orderpriority = '5-LOW';
no rows selected
Elapsed: 00:01:24.73 (85s)
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
|* 1 | TABLE ACCESS FULL| LINEORDER | 2 | 92 | 1032K (2)| 00:01:21 |
-------------------------------------------------------------------------------
---------------------------------------------------
1 - filter("LO_CUSTKEY"=5641 AND "LO_SHIPMODE"='XXX AIR' AND
= 85s/1s = 85

Выборка не по равенству

In-Memory Scan
Scale Factor 100 GB
SQL> Select max(lo_supplycost) most_expensive_bluk_order
2 From LINEORDER
3 Where lo_quantity > 49;
MOST_EXPENSIVE_BLUK_ORDER
-------------------------
1000
Elapsed: 00:00:01.89 (2s)
-----------------------------------------------------------------------------------------
-----------------------------------------------------------------------------------------
| 1 | SORT AGGREGATE | | 1 | 8 | | |
|* 2 | TABLE ACCESS INMEMORY FULL| LINEORDER | 12M| 93M| 39671 (28)| 00:00:04 |
-----------------------------------------------------------------------------------------
---------------------------------------------------
2 - inmemory("LO_QUANTITY">49)
filter("LO_QUANTITY">49)

Buffer Cache
Scale Factor 100 GB
SQL> SELECT /*+ NO_INMEMORY */
2 max(lo_supplycost) most_expensive_bluk_order
3 From LINEORDER
4 Where lo_quantity > 49;
MOST_EXPENSIVE_BLUK_ORDER
-------------------------
1000
Elapsed: 00:01:27.86
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
| 1 | SORT AGGREGATE | | 1 | 8 | | |
|* 2 | TABLE ACCESS FULL| LINEORDER | 12M| 93M| 1027K (2)| 00:01:21 |
--------------------------------------------------------------------------------
---------------------------------------------------
2 - filter("LO_QUANTITY">49)
= 88s/2s = 44

Более сложная выборка

In-Memory Scan
SQL> Select lo_orderkey, lo_revenue
2 From LINEORDER
3 Where lo_revenue = (Select min(lo_revenue)
4 From LINEORDER
5 Where lo_supplycost = (Select max(lo_supplycost)
6 From LINEORDER
7 Where lo_quantity > 10)
8 And lo_shipmode LIKE 'TRUCK%'
9 And lo_discount between 2 and 5);
no rows selected
Elapsed: 00:00:39.82 (40s)
--------------------------------------------------------------------------------------------
--------------------------------------------------------------------------------------------
|* 1 | TABLE ACCESS INMEMORY FULL | LINEORDER | 44 | 572 | 39609 (28)| 00:00:04 |
| 2 | SORT AGGREGATE | | 1 | 25 | | |
|* 3 | TABLE ACCESS INMEMORY FULL | LINEORDER | 78 | 1950 | 30248 (6)| 00:00:03 |
| 4 | SORT AGGREGATE | | 1 | 8 | | |
--------------------------------------------------------------------------------------------

Buffer Cache
SQL> SELECT /*+ NO_INMEMORY */ lo_orderkey, lo_revenue
2 From LINEORDER
3 Where lo_revenue = (Select /*+ NO_INMEMORY */ min(lo_revenue)
4 From LINEORDER
5 Where lo_supplycost = (Select /*+ NO_INMEMORY */ max(lo_supplycost)
6 From LINEORDER
7 Where lo_quantity > 10)
8 And lo_shipmode LIKE 'TRUCK%'
9 And lo_discount between 2 and 5);
no rows selected
Elapsed: 00:03:02.45 (182s)
-----------------------------------------------------------------------------------
-----------------------------------------------------------------------------------
|* 1 | TABLE ACCESS FULL | LINEORDER | 44 | 572 | 1030K (2)| 00:01:21 |
| 2 | SORT AGGREGATE | | 1 | 25 | | |
|* 3 | TABLE ACCESS FULL | LINEORDER | 78 | 1950 | 1032K (2)| 00:01:21 |
| 4 | SORT AGGREGATE | | 1 | 8 | | |
-----------------------------------------------------------------------------------
= 182s/40s = 4,5

Соединения и агрегация

Соединять или фильтровать?
To join or to filter?

Filter Create – Filter Use
SQL> Select sum(lo_extendedprice * lo_discount) revenue
2 From LINEORDER l, DATE_DIM d
3 Where l.lo_orderdate = d.d_date_as_date
4 And l.lo_discount between 0.02 and 0.03
5 And l.lo_quantity < 24
6 And d.d_date='December 24, 1996';
REVENUE
----------
9751240
Elapsed: 00:00:01.35 (2s)
-------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------
| 1 | SORT AGGREGATE | | 1 | 48 | | |
|* 2 | HASH JOIN | | 33003 | 1547K| 47924 (41)| 00:00:04 |
| 3 | JOIN FILTER CREATE | :BF0000 | 1 | 28 | 1 (0)| 00:00:01 |
|* 4 | TABLE ACCESS INMEMORY FULL| DATE_DIM | 1 | 28 | 1 (0)| 00:00:01 |
| 5 | JOIN FILTER USE | :BF0000 | 79M| 1513M| 47503 (40)| 00:00:04 |
-------------------------------------------------------------------------------------------

Hash Join
SQL> SELECT /*+ NO_INMEMORY */
2 SUM(lo_extendedprice * lo_discount) revenue
3 FROM lineorder l,
4 date_dim d
5 WHERE l.lo_orderdate = d.d_date_as_date
6 AND l.lo_discount BETWEEN 0.02 AND 0.03
7 AND l.lo_quantity < 24
8 AND d.d_date='December 24, 1996';
REVENUE
----------
9751240
Elapsed: 00:01:54.97 (95s)
---------------------------------------------------------------------------------
---------------------------------------------------------------------------------
| 1 | SORT AGGREGATE | | 1 | 48 | | |
|* 2 | HASH JOIN | | 33003 | 1547K| 1030K (2)| 00:01:21 |
|* 3 | TABLE ACCESS FULL| DATE_DIM | 1 | 28 | 6 (0)| 00:00:01 |
---------------------------------------------------------------------------------
= 95s/2s = 48

Filter Create – Filter Use - 3
PARALLEL(2)
SQL> Select /*+ PARALLEL(2) */ p.p_name, sum(l.lo_revenue)
2 From LINEORDER l, DATE_DIM d, PART p
3 Where l.lo_orderdate = d.d_date_as_date And l.lo_partkey = p.p_partkey
5 and p.p_type = 'PROMO BRUSHED STEEL' And d.d_year = 1996 And d.d_month = 'December'
8 Group by p.p_name;
5800 rows selected.
Elapsed: 00:00:21.98 (22s)
----------------------------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | TQ |IN-OUT| PQ Distrib |
----------------------------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 45681 | 4684K| | 30192 (44)| 00:00:03 | | | |
| 1 | PX COORDINATOR | | | | | | | | | |
| 2 | PX SEND QC (RANDOM) | :TQ10001 | 45681 | 4684K| | 30192 (44)| 00:00:03 | Q1,01 | P->S | QC (RAND) |
| 3 | HASH GROUP BY | | 45681 | 4684K| 5200K| 30192 (44)| 00:00:03 | Q1,01 | PCWP | |
| 4 | PX RECEIVE | | 45681 | 4684K| | 30192 (44)| 00:00:03 | Q1,01 | PCWP | |
| 5 | PX SEND HASH | :TQ10000 | 45681 | 4684K| | 30192 (44)| 00:00:03 | Q1,00 | P->P | HASH |
| 6 | HASH GROUP BY | | 45681 | 4684K| 5200K| 30192 (44)| 00:00:03 | Q1,00 | PCWP | |
|* 7 | HASH JOIN | | 45681 | 4684K| | 29849 (45)| 00:00:03 | Q1,00 | PCWP | |
| 8 | JOIN FILTER CREATE | :BF0000 | 27 | 621 | | 2 (0)| 00:00:01 | Q1,00 | PCWP | |
|* 9 | TABLE ACCESS INMEMORY FULL | DATE_DIM | 27 | 621 | | 2 (0)| 00:00:01 | Q1,00 | PCWP | |
|* 10 | HASH JOIN | | 4126K| 322M| | 29836 (45)| 00:00:03 | Q1,00 | PCWP | |
| 11 | JOIN FILTER CREATE | :BF0001 | 133K| 8072K| | 954 (25)| 00:00:01 | Q1,00 | PCWP | |
|* 12 | TABLE ACCESS INMEMORY FULL | PART | 133K| 8072K| | 954 (25)| 00:00:01 | Q1,00 | PCWP | |
| 13 | JOIN FILTER USE | :BF0000 | 600M| 11G| | 27293 (42)| 00:00:03 | Q1,00 | PCWP | |
| 14 | JOIN FILTER USE | :BF0001 | 600M| 11G| | 27293 (42)| 00:00:03 | Q1,00 | PCWP | |
| 15 | PX BLOCK ITERATOR | | 600M| 11G| | 27293 (42)| 00:00:03 | Q1,00 | PCWC | |
|* 16 | TABLE ACCESS INMEMORY FULL| LINEORDER | 600M| 11G| | 27293 (42)| 00:00:03 | Q1,00 | PCWP | |
----------------------------------------------------------------------------------------------------------------------------------------

Database In-Memory
When will an object benefit from being in the IM column store?
 Storing a database object in the IM column store can improve
performance significantly for the following types of operations performed
on the database object:
– A query that scans a large number of rows and applies filters that use
operators such as the following: =, <, >, and IN
– A query that selects a small number of columns from a table or materialized
view with a large number of columns, such as a query that selects five
columns from a table with 100 columns
– A query that joins a small table to a large table
– A query that aggregates data

Database In-Memory
When will an object not benefit from being in the IM column store?
– Queries with complex predicates
– Queries that select a large number of columns
– Queries that return a large number of rows
– Queries with multiple large table joins

Заключение

Наблюдения-выводы
– Database In-Memory – это панацея от многих, но не от всех бед
– При адекватном применении Database In-Memory дает огромный
прирост производительности запросов
– Упразднение индексов для поиска данных в хранилище (DWH)
 существенно повышает скорость выполнения операций
запоминания (INSERT, UPDATE, DELETE)
 Не снижает скорость выполнения запросов, поскольку выборка
средствами In-Memory, как минимум, не медленнее индексного
доступа
– Не стоит "пихать" In-Memory "во все углы", т.к. некоторые углы могут
"рассыпаться" :-(
– Никогда не забываем: Все проблемы решаемы при вдумчивой
аккуратной работе!

"Каждому делу
учиться надо!"
(с) Незнайка из Цветочного города

Приходите в наш Центр решений!
Все покрутим, повертим, попробуем!
У нас есть чему и на чём поучиться!
(с) Валерий Юринский и все, все, все ФОРС

"ФОРС Дистрибуция"
http://www.partner.fors.ru
129626, Москва,
Графский переулок, 14, стр. 2
Телефон: +7 (495) 913-3-913
Oracle Partner Hub
Центр решений ФОРС
ФОРС ExaStack Studio
http://exastack.ru

Db in-memory-overview 2015-10_14

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Db in-memory-overview 2015-10_14

Similaire à Db in-memory-overview 2015-10_14 (20)

Db in-memory-overview 2015-10_14