Pull to refresh

Тестирование производительности Oracle In-Memory Option c использованием TPC-H Benchmark

Reading time 4 min
Views 9.1K
Одним из ключевых нововведений СУБД 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 таблицы и пару простых запросов.

TPC-H Benchmark


Для теста производительности я использовал tpc-h benchmark, который используется для сравнения производительности аналитических систем и хранилищ данных. Этот бенчмарк используют многие производители как СУБД, так и серверного оборудования. На странице tpc-h доступно много результатов, для публикации которых необходимо выполнить все требования спецификации на 136 страницах. Я публиковать официально свой тест не собирался, поэтому всем правилам строго не следовал. Также для упрощения процесса тестирования я воспользовался бесплатной версией программы Benchmark Factory for Databases.

TPC-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 — TPC-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, буду рад прочитать об этом в комментариях.
Tags:
Hubs:
+17
Comments 24
Comments Comments 24

Articles