- PVSM.RU - https://www.pvsm.ru -
Свою предыдущую статью [1] я посвятил тому, как и на сколько можно ускорить аналитические (типовые для OLAP/BI систем) запросы в СУБД Oracle за счёт подключения опции In-Memory. В продолжение этой темы я хочу описать несколько альтернативных СУБД для аналитики и сравнить их производительность. И начать я решил с in-memory RDBMS Exasol [2].
Для тестов, результаты которых я публикую, выбран TPC-H Benchmark [3] и при желании читатели могут повторить мои тесты.
Exasol – это реляционная аналитическая in-memory база данных со следующими ключевыми характеристиками:
Более подробно про возможности Exasol можно прочитать в отличной статье [4] на Хабре. Добавлю только то, что, несмотря на невысокую популярность в наших краях, это зрелый продукт, который присутствует в Gartner Magic Quadrant for Data Warehouse and Data Management Solutions for Analytics [5] с 2012 года.
Для теста производительности я использовал tpc-h benchmark [3], который используется для сравнения производительности аналитических систем и хранилищ данных. Этот бенчмарк используют многие производители как СУБД, так и серверного оборудования. На странице tpс-h [3] доступно много результатов, для публикации которых необходимо выполнить все требования спецификации на 136 страницах. Я публиковать официально свой тест не собирался, поэтому всем правилам строго не следовал. В рейтинге TPC-H — Top Ten Performance Results [6] Exasol является лидером по производительности (на объёмах от 100 Гб до 100 Тб), что и стало изначально причиной моего интереса к этой СУБД.
TPC-H позволяет сгенерировать данные для 8-ми таблиц с использованием заданного параметра scale factor, который определяет примерный объём данных в гигабайтах. Я ограничился 2 Гб, так как на этом объёме тестировал Oracle In-Memory.
Бенчмарк включает 22 SQL запроса различной сложности. Отмечу, что сгенерированные утилитой qgen запросы, нужно корректировать под особенности конкретной СУБД, но в случае Exasol изменения были минимальны: замена set rowcount на LIMIT clause и замена keyword value. Для теста было сгенерировано 2 вида нагрузки:
В итоге, в обоих случаях оценивалось время выполнения 528-ми SQL запросов. Кого заинтересуют DDL cкрипты для таблиц и SQL запросы, напишите в комментариях.
Для целей сравнения БД или оборудования для аналитики (в т.ч. для Big Data) ещё рекомендую обратить внимание на другой более свежий benchmark — TPC-DS [7]. В нём больше таблиц и значительно больше запросов – 99.
Ноутбук со следующими характеристиками:
Intel Core i5-4210 CPU 1.70GHz – 4 virt. processors; DDR3 16 Gb; SSD Disk.
ОС:
MS Windows 8.1 x64
VMware Workstation 12 Player
Virtual OS: CentOS 6.8 (Memory: 8 Gb; Processors: 4)
СУБД:
EXASOL V6 Free Small Business Edition rc1 (single node)
Данные я загружал из текстовых файлов с помощью утилиты EXAplus. Скрипт загрузки:
IMPORT INTO TPСH.LINEITEM
FROM LOCAL CSV FILE 'D:lineitem.dsv'
ENCODING = 'UTF-8'
ROW SEPARATOR = 'CRLF'
COLUMN SEPARATOR = '|'
SKIP = 1
REJECT LIMIT 0;
Время загрузки всех файлов составило 3 мин. 37 сек. Отмечу ещё, что очень приятное впечатление оставила документация с множеством примеров. Так, в ней описан [8] ряд альтернативных способов загрузки данных: напрямую из различных СУБД, c использованием ETL инструментов и другие.
Далее в таблице представлена информация о том, как данные организованы в Exasol и Oracle In-Memory:
Exasol | Oracle IM | |||||||
---|---|---|---|---|---|---|---|---|
Таблица | Кол-во строк | Объём сырых данных (Mb) | Объём таблиц в памяти (Мб) | Коэф. сжатия | Кол-во индексов | Объём индексов в памяти (Мб) | Объём таблиц в памяти (Мб) | Коэф. сжатия |
LINEITEM | 11 996 782 | 1 562.89 | 432.5 | 3.61 | 4 | 109.32 | 474.63 | 3.29 |
ORDERS | 3 000 000 | 307.25 | 97.98 | 3.14 | 2 | 20.15 | 264.38 | 1.16 |
PARTSUPP | 1 600 000 | 118.06 | 40.46 | 2.92 | 2 | 5.24 | 72.75 | 1.62 |
CUSTOMER | 300 000 | 39.57 | 20.99 | 1.89 | 2 | 1.42 | 32.5 | 1.22 |
PART | 400 000 | 51.72 | 10.06 | 5.14 | 1 | 1.48 | 20.5 | 2.52 |
SUPPLIER | 20 000 | 2.55 | 2.37 | 1.08 | 4.5 | 0.57 | ||
NATION | 25 | 0 | 0.01 | 0.00 | 1.13 | 0.00 | ||
REGION | 5 | 0 | 0.01 | 0.00 | 1.13 | 0.00 | ||
TOTAL | 17 316 812 | 2 082.04 | 604.38 | 3.44 | 11 | 137.61 | 871.52 | 2.39 |
Эту информацию в Exasol можно посмотреть в системных таблицах SYS.EXA_ALL_OBJECT_SIZES и SYS.EXA_ALL_INDICES.
Oracle IM | Exasol | |
---|---|---|
8 сессий (1-й запуск), сек. | 386 | 165 |
8 сессий (2-й запуск), сек. | ~386 | 30 |
2 сессии (1-й запуск), сек. | 787 | 87 |
2 сессий (2-й запуск), сек. | ~787 | 29 |
Таким образом, видим, что данный тест на Exasol выполняется быстрее относительно Oracle IM при 1-м запуске и значительно быстрее со 2-го запуска. Ускорение повторных выполнений SQL запросов в Exasol обеспечивается за счёт автоматического создания индексов. 11 индексов заняли в оперативной памяти примерно 23% относительно размера самих таблиц, что, на мой взгляд, стоит такого ускорения. Отмечу, что Exasol не даёт возможности управлять индексами. Приведу перевод фразы из документации на тему оптимизации:
EXASolution сознательно прячет сложные механизмы настройки производительности для клиентов, такие, как например: создание различных типов индексов, вычисление статистики по таблицам и т.д. Запросы в EXASolution анализируются с помощью оптимизатора и необходимые для оптимизации действия выполняются в полностью автоматическом режиме.
Ещё по результатам выполнения видно, что в моём случае Oracle лучше параллелил запросы (8 сессий в сравнении с 2-мя). С причинами этого я пока детально не разбирался.
Для желающих самостоятельно оценить производительность Exasol без необходимости устанавливать виртуальную ОС и загружать данные есть демо Exasol in the cloud [9]. После регистрации мне предоставили доступ на 2 недели к кластеру из 5 серверов. Там доступна TPCH схема со Scale Factor = 50 (50 Gb, ~433 млн. записей). 2-й запуск моего теста с 2-мя сессиями на этих данных занял примерно 2 минуты.
Для себя я сделал вывод, что СУБД Exasol – отличный вариант для построения хранилища данных и аналитической системы на нём. В отличии от универсальной Oracle DB, Exasol создана для аналитики. Можно привести аналогию с автомобилями: для поездок на рыбалку хорошо иметь внедорожник, а для передвижения по городу компактный легковой авто.
Как и в предыдущей статье призываю всех делать какие-либо серьёзные выводы только после тестов на ваших конкретных кейсах.
На этом пока всё, на очереди тест для HPE Vertica.
P.S.: Буду очень благодарен, если ребята из Тинькофф Банк (@Kapustor) поделятся информацией о своём итоговом выборе [10], а Badoo (@wildraid) новостями проекта [4].
Автор: mkrupenin
Источник [11]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/oracle/225598
Ссылки в тексте:
[1] статью: https://habrahabr.ru/post/317774/
[2] Exasol: http://www.exasol.com/
[3] TPC-H Benchmark: http://www.tpc.org/tpch/
[4] статье: https://habrahabr.ru/company/badoo/blog/271753/
[5] Gartner Magic Quadrant for Data Warehouse and Data Management Solutions for Analytics: https://www.gartner.com/doc/reprints?id=1-2ZFVZ5B&ct=160225&st=sb
[6] TPC-H — Top Ten Performance Results: http://www.tpc.org/tpch/results/tpch_perf_results.asp
[7] TPC-DS: http://www.tpc.org/tpcds/default.asp
[8] описан: https://www.exasol.com/portal/pages/viewpage.action?pageId=1835054
[9] Exasol in the cloud: http://www.exasol.com/en/download/
[10] выборе: https://habrahabr.ru/company/tcsbank/blog/310620
[11] Источник: https://habrahabr.ru/post/318416/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best
Нажмите здесь для печати.