Oracle Database In-Memory

Copyright © 2014, Oracle and/or its affiliates. All rights reserved.1

Oracle Database In-Memory

ORACLEPRODUCT

LOGO

Игорь МельниковOracle


План

Введение

Oracle Database In-Memory Option

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

Заключение


Введение


Оперативная память: тренды и влияниеСегодня память быстрее, дешевле и ее объем больше

Объемы памяти растут

2002 256 MB/DIMM

2012 16 GB/DIMM

Стоимость падает

2002 $0.2/MB

2012 $0.009/MB

Память значительно быстрее

Disk5ms – скорость

доступа

DRAM100ns – скорость доступа

64x больше емкости 25x дешевле 50,000х быстрее

Ускорение OLTP и DW приложений, больше пользователей, больше данных

DRAM:

2012 $0.0005/MB2012 100 GB/DOM Flash0.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 2012Pre-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

STATE


Oracle Database In-Memory


Задачи Oracle Database In-Memory Option

В 100 раз быстрее запросы для аналитики в реальном времени Мгновенное получение результата Запросы к OLTP базе или хранилищу данных Актуальные данные в результатах!

В 2 раза ускоряется обработка транзакций Вставка строк в 3 – 4 раза быстрее


Oracle In-Memory Columnar Сache

DRAM

Pure Columnar

Данные в представлении по колонкам без генерации redo-информации

Минимальные затраты на изменения – даже для OLTP-транзакций

Данные загружаются в кэш при первом обращении/старте экземпляра


И строчный и поколоночный формат хранения в памяти для одних и тех же данных/таблиц

Данные одновременно активны и транзакционно согласованы

В 100 раз быстрее аналитика & отчетность: поколоночный формат

В 2 раза быстрее OLTP: строчный формат

In-Memory Option: Оба формата в памяти СУБД

Column Format

Memory

Row Format

Memory

AnalyticsOLTP Sales Sales

Sales


Oracle In-Memory: отдельный кэш в SGA

Instance

SGA

Redo logbuffer cache

Shared pool

Data Dict.cache

Library

cache

DBWRSMONPMON CKPTLGWR Others

Databasebuffer cache

SQL> ALTER SYSTEM SET inmemory_size=512G SCOPE=SPFILE;

Instance

SGA

Redo logbuffer cache

Shared pool

Data Dict.cache

Library

cache

DBWRSMONPMON CKPTLGWR Others

In-rowbuffer cache

In-Memory

Columnar

Cache

Динамический параметр INMEMORY_SIZE


Статический пул в SGAПараметр SGA_TARGET должен быть увеличен соответственно

SQL> SELECT * FROM V$SGA;

NAME VALUE------------------ ---------Fixed Size 2927176Variable Size 570426808Database Buffers 4634022912Redo Buffers 13848576In-Memory Area 1024483648


14

Почему сканирование в In-Memory быстрее чем в буферном кэше?

SELECT COL4 FROM MYTABLE;

XXXXX

РЕЗУЛЬТАТ

Строчный формат

Буферный кэш


15

SELECT COL4 FROM MYTABLE;

RESULT

Колоночный формат

In-Memory кэш

РЕЗУЛЬТАТ

XXXX

Почему сканирование в In-Memory быстрее чем в буферном кэше?


Включение 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 | |---------------------------------------------------------------------


Сканирование миллиарда строк в секунду на процессорном ядре

SIMD Compare all values in 1 cycle

Сравнение всех

значений за один цикл

Загрузка значений множества

штатов

Vec

tor

Reg

iste

r

In-Memory Column Store

State columnSales

Пример: Найти все продажи в штате CA

“CA”

более чем в 100

раз быстрее

• Каждое процессорное ядро сканирует одну колонку

При сканировании используются быстрые векторные SIMD-инструкции

Миллиарды строк в секунду сканируются одним ядром

CPU


Oracle In-Memory: “разогрев” кэша

SQL> ALTER DATABASE FASTSTART TABLESPACE inmemory_tbs;

Database altered.

При старте БД (для Exadata/ZFS/Pillar) – checkpoint-сегмент для Columnar-кэша

Для generic hardware – при первом обращении к сегменту для которого включен атрибут in-memory


Сканирование и объединение данных из нескольких таблиц

ПродажиМагазины

Type=outlet

Пример: Найти все продажи в outlet-магазинах

TYPE

Storeid in

15,38,64

STOREID

AMOUNT

Конвертирует join в быстрые сканы колонок

Joins выполняются в 10 раз быстрее

Sum


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


Мгновенная генерация отчетов: доли секунд

In-Memory Report Outline

Пример: Показать тренды продаж обуви в outlet магазинах

Stores

Products

Sales

Outlets

FootwearSales

Динамически создает в памяти объект-отчет

Объект заполняется во время сканирования таблицы продаж

Отчеты строятся в 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жатие столбцов в кэше - примерСжатие разными методами для группы столбцов

SQL> ALTER TABLE cities INMEMORY INMEMORY MEMCOMPRESS FOR CAPACITY HIGH(Country_Id, Time_Zone) INMEMORY NO MEMCOMPRESS (Id, Name, Name_Eng);

Table altered.

•Уникальные столбцы – не сжимаются!


Поддержка в Compression AdvisorDECLARE 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 typeEND;


Атрибут INMEMORY в USER_TABLES

SQL> SELECT table_name, inmemoryFROM USER_TABLES;

TABLE_NAME INMEMORY------------ --------CHANNELS DISABLEDCOSTSCUSTOMERS DISABLEDPRODUCTS ENABLEDSALESTIMES 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 STARTEDCITIES 1179648 5242880 0 COMPLETEDCOMPANIES 1179648 5242880 0 COMPLETEDAIRPORTS 1179648 5242880 0 COMPLETED

Мониторинг использования кэша


Управление приоритетом загрузки в кэш

Приоритет Синтаксис Описание

• NONE

(default)

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

• LOW PRIORITY LOW • Низкий приоритет

• MEDIUM PRIORITY MEDIUM • Средний приоритет

• HIGH PRIORITY HIGH • Высокий приоритет

• CRITICAL PRIORITY CRITICAL • Высший приоритет


Приоритет загрузки в кэш - примерОдин приоритет для всей таблицы/секции/мат. представления

SQL> ALTER TABLE cities 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 – (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 MemoryColumn

Store

In MemoryColumn

Store

In MemoryColumn

Store

In MemoryColumn

Store


Полный синтаксис кэширования таблицыМощный и гибкий синтаксис

SQL> ALTER TABLE citiesINMEMORY 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,


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

Insert Chart Here

Storage Index в In-Memory Columnar Store


Space Manager Управляет памятью в In-

Memory Column Store (create, extend, drop)

Загружает данные в кэш

Transaction Manager Обеспечивает

согласованность данных в In-Memory Column Store с буферным кэшем

Обеспечивает версионность

Insert Chart Here

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


Для каких приложений подходит 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

Application

Application

Application

TimesTen In-Memory Database• Встраиваемая БД для приложений• Экстремальная быстрая

производительность для OLTP-нагрузки (время ответа - микросекунды)

• Адаптивный кэш для инженерной системы Oracle Exalytics

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


43

Public


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


Тестовый стенд

Сервер 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корость полного сканирования

SELECT /*+ FULL(tickets) */ count(*) FROM tickets;

In-Memory Cache: идентичен обычному буферному кэшу

0

0,5

1

1,5

2

2,5

3

Обычный кэш Сolumnar Cache

1,25 1,28


Тест N2: cкорость фильтрации

SELECT count(*) FROM tickets WHERE reservaton_code=‘test';

In-Memory Cache: в 5 раз быстрее!

0

0,5

1

1,5

2

2,5

3

Обычный кэш Сolumnar Cache

2,51

0,5


Тест N3: cжатие In-Memory Cache: в 2 раза, без потери скорости!

0

20

40

60

80

100

120

140

160

Размер на диске

С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



Technology

Oracle Database In-Memory