Одним из ключевых нововведений СУБД Oracle версии 12.1.0.2 стала опция In-Memory. Основная её идея заключается в том, что для выбранных таблиц вы можете легко активировать dual-format режим, который объединяет стандартный для Oracle DB построчный формат хранения данных на диске и поколоночный формат в оперативной памяти.
Соответствующее преобразование и дублирование данных в память происходит автоматически. Лично для меня это было большой новостью, так как я занимаюсь разработкой хранилищ данных (DWH) и имел опыт работы с column-oriented DBMS Sybase IQ и HP Vertica, которые созданы для хранилищ и аналитики. А Oracle предложил Column Store плюс In-Memory плюс все возможности любимой СУБД! По сути, с этим решением Oracle вышел на рынок аналитических in-memory баз данных (кто не читал, рекомендую отличную статью на Хабре со сравнением баз данных этого класса). Идея Oracle очень многообещающая, но на практике на моих тестовых примерах результаты, к большому сожалению, не впечатлили. Было это в прошлом году и я решил подождать пока технологию усовершенствуют. После выхода очередного патча с улучшениями In-Memory Option я вернулся к этому вопросу. Для статьи был выбран более объективный тест, который при желании смогут повторить читатели.
Прежде чем перейти к своему бенчмарку, приведу пару ссылок. В статье на Хабре в блоге компании Oracle подробное описание In-Memory Option и её фантастических результатов. В другой статье этого же блога приведён тест производительности, но используются только 2 таблицы и пару простых запросов.
TCP-H Benchmark
Для теста производительности я использовал tcp-h benchmark, который используется для сравнения производительности аналитических систем и хранилищ данных. Этот бенчмарк используют многие производители как СУБД, так и серверного оборудования. На странице tcp-h доступно много результатов, для публикации которых необходимо выполнить все требования спецификации на 136 страницах. Я публиковать официально свой тест не собирался, поэтому всем правилам строго не следовал. Также для упрощения процесса тестирования я воспользовался бесплатной версией программы Benchmark Factory for Databases.
TCP-H позволяет сгенерировать данные для 8-ми таблиц с использованием заданного параметра scale factor, который определяет примерный объём данных в гигабайтах. Я ограничился 2 Гб, так как больше не позволяет бесплатная версия Benchmark Factory. Итоговое количество строк в таблицах:
| Таблица | Кол-во строк |
|---|---|
| H_LINEITEM | 11 996 782 |
| H_ORDER | 3 000 000 |
| H_PARTSUPP | 1 600 000 |
| H_PART | 400 000 |
| H_CUSTOMER | 300 000 |
| H_SUPPLIER | 20 000 |
| H_NATION | 25 |
| H_REGION | 5 |
Тест включает 22 SQL запроса различной сложности. Сравнивалось время выполнения с использованием In-Memory и без. При этом была сгенерирована следующая нагрузка: 8 виртуальных пользователей параллельно 3 раза по кругу выполняют все 22 запроса. В итоге оценивалось время выполнения 528-ми SQL запросов.
Тем, кому данный тест покажется недостаточно сложным, рекомендую обратить внимание на другой более свежий Benchmark — TCP-DS. В нём больше таблиц и значительно больше запросов – 99.
Стенд для тестирования
Ноутбук со следующими характеристиками:
— Intel® Core™ i5-4210 CPU 1.70GHz – 4 cores; DDR3 16 Gb; SSD Disk.
ОС:
— MS Windows 8.1 x64
СУБД:
— Oracle Database 12c EE 12.1.0.2.0
— Interim patches (1): «WINDOWS DB BUNDLE PATCH 12.1.0.2.160531(64bit): 23179016»
DB Memory Configuration:
— memory_target = 10G;
— sga_target = 8G;
— inmemory_size = 3G;
Установка параметров In-Memory (IM)
Кроме установки параметра БД inmemory_size достаточно указать данные каких таблиц или их частей необходимо дублировать в кэше IM, всё остальное Oracle сделает за вас. Таким образом, перевести существующую БД на IM очень просто при наличии достаточного количества оперативной памяти. Переписывать ничего не нужно, можно только удалить индексы, которые не нужны для таблиц IM. Также отмечу стабильную работу, я не столкнулся ни с одним багом, связанным с IM.
В моём тесте все таблицы целиком отправились в IM:
ALTER TABLE MY_TABLE_NAME INMEMORY MEMCOMPRESS FOR QUERY HIGH PRIORITY CRITICAL;- MEMCOMPRESS FOR QUERY HIGH — оптимизированный для производительности запросов и для экономии памяти вариант (есть ещё 5 других вариантов, про которые можно прочитать в документации).
- PRIORITY CRITICAL – определяет приоритет репликации в IM кэш.
Важным нюансом ещё является то, что данные в колонках хорошо сжимаются, что и делает Oracle. Следующий запрос показывает объём данных на диске, в IM и коэффициент сжатия:
select
SEGMENT_NAME,
ROUND(SUM(BYTES)/1024/1024/1024,2) "ORIG SIZE, Gb",
ROUND(SUM(INMEMORY_SIZE)/1024/1024/1024,2) "IM SIZE, Gb",
ROUND(SUM(BYTES)/SUM(INMEMORY_SIZE),2) "COMPRESS RATIO"
from V$IM_SEGMENTS
group by SEGMENT_NAME
order by 2 desc;
| SEGMENT_NAME | ORIG SIZE, GB | IM SIZE, GB | COMPRESS RATIO |
|---|---|---|---|
| H_LINEITEM | 1,74 | 0,67 | 2,62 |
| H_ORDER | 0,39 | 0,35 | 1,1 |
| H_PARTSUPP | 0,12 | 0,08 | 1,58 |
| H_PART | 0,06 | 0,02 | 2,96 |
| H_CUSTOMER | 0,04 | 0,03 | 1,42 |
| H_NATION | 0 | 0 | 0,22 |
| H_SUPPLIER | 0 | 0 | 0,89 |
| H_REGION | 0 | 0 | 0,22 |
Результаты выполнения теста
| #1 No In-Memory | #2 In-Memory | |
|---|---|---|
| Elapsed Time | 7 мин. 23 сек. | 6 мин. 26 сек. |
| Avg. Response Time (sec) | 5.617 | 4.712 |
В заключение
Я не считаю, что по результатам одного любого теста можно делать какие-то категоричные выводы. Результаты могут сильно варьироваться в зависимости от моделей и объёмов данных, специфики запросов, конфигурации параметров СУБД, а также от аппаратной части. В качестве альтернативного примера приведу ссылку на некогда нашумевший бенчмарк, где компания Oracle сравнила производительность Oracle IM (на Exadata+Exalogic) и SAP HANA. Использовался SAP BW-EML Benchmark. В этом тесте аппаратно-программный комплекс от Oracle был на высоте.
Если у вас есть опыт использования Oracle In-Memory, буду рад прочитать об этом в комментариях.
Автор: mkrupenin
