Сравнение производительности аналитической СУБД Exasol и Oracle In-Memory Option26.12.2016 08:04

5be51a7513da4b5f86b66ebe57a0ebe7.jpg Свою предыдущую статью я посвятил тому, как и на сколько можно ускорить аналитические (типовые для OLAP/BI систем) запросы в СУБД Oracle за счёт подключения опции In-Memory. В продолжение этой темы я хочу описать несколько альтернативных СУБД для аналитики и сравнить их производительность. И начать я решил с in-memory RDBMS Exasol.
Для тестов, результаты которых я публикую, выбран TPC-H Benchmark и при желании читатели могут повторить мои тесты.

Краткая информация о СУБД Exasol


Exasol — это реляционная аналитическая in-memory база данных со следующими ключевыми характеристиками:
  • In-memory. БД в первую очередь предназначена для хранения и обработки данных в оперативной памяти. При этом данные дублируются на диск и вся база данных не обязательно должна помещаться в память. При выполнении запросов отсутствующие в памяти данные читаются с диска;
  • MPP (massive parallel processing). Данные распределяются по узлам кластера для высокопроизводительной параллельной обработки (реализована по архитектуре shared nothing);
  • Сolumn-wise data storage. Информация в таблицах хранится по столбцам в сжатом виде, что значительно ускоряет аналитические запросы;
  • Поддерживает стандарт ANSI SQL 2008;
  • Хорошо интегрируется с большинством BI инструментов;
  • In-Database Analytics. Поддержка пользовательских функций на языках LUA, Python, R, Java.
  • Java-based интерфейс к Hadoop«s HDFS.

Более подробно про возможности Exasol можно прочитать в отличной статье на Хабре. Добавлю только то, что, несмотря на невысокую популярность в наших краях, это зрелый продукт, который присутствует в Gartner Magic Quadrant for Data Warehouse and Data Management Solutions for Analytics с 2012 года.
ac3f927ceecf4051b64f0f47d61c3da0.png

TPC-H Benchmark


Для теста производительности я использовал tpc-h benchmark, который используется для сравнения производительности аналитических систем и хранилищ данных. Этот бенчмарк используют многие производители как СУБД, так и серверного оборудования. На странице tpс-h доступно много результатов, для публикации которых необходимо выполнить все требования спецификации на 136 страницах. Я публиковать официально свой тест не собирался, поэтому всем правилам строго не следовал. В рейтинге TPC-H — Top Ten Performance Results Exasol является лидером по производительности (на объёмах от 100 Гб до 100 Тб), что и стало изначально причиной моего интереса к этой СУБД.

TPC-H позволяет сгенерировать данные для 8-ми таблиц с использованием заданного параметра scale factor, который определяет примерный объём данных в гигабайтах. Я ограничился 2 Гб, так как на этом объёме тестировал Oracle In-Memory.

d205965f91ac46a6be7d8e076f909533.png

Бенчмарк включает 22 SQL запроса различной сложности. Отмечу, что сгенерированные утилитой qgen запросы, нужно корректировать под особенности конкретной СУБД, но в случае Exasol изменения были минимальны: замена set rowcount на LIMIT clause и замена keyword value. Для теста было сгенерировано 2 вида нагрузки:
  • 8 виртуальных пользователей параллельно 3 раза по кругу выполняют все 22 запроса
  • 2 виртуальных пользователя параллельно 12 раз по кругу выполняют все 22 запроса

В итоге, в обоих случаях оценивалось время выполнения 528-ми SQL запросов. Кого заинтересуют DDL cкрипты для таблиц и SQL запросы, напишите в комментариях.

Для целей сравнения БД или оборудования для аналитики (в т.ч. для Big Data) ещё рекомендую обратить внимание на другой более свежий benchmark — TPC-DS. В нём больше таблиц и значительно больше запросов — 99.

Тестовая площадка


Ноутбук со следующими характеристиками:
Intel Core i5–4210 CPU 1.70GHz — 4 virt. processors; DDR3 16 Gb; SSD Disk.
ОС:
MS Windows 8.1×64
VMware Workstation 12 Player
Virtual OS: CentOS 6.8 (Memory: 8 Gb; Processors: 4)
СУБД:
EXASOL V6 Free Small Business Edition rc1 (single node)

Загрузка данных в БД Exasol


Данные я загружал из текстовых файлов с помощью утилиты 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 сек. Отмечу ещё, что очень приятное впечатление оставила документация с множеством примеров. Так, в ней описан ряд альтернативных способов загрузки данных: напрямую из различных СУБД, 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 без необходимости устанавливать виртуальную ОС и загружать данные есть демо Exasol in the cloud. После регистрации мне предоставили доступ на 2 недели к кластеру из 5 серверов. Там доступна TPCH схема со Scale Factor = 50 (50 Gb, ~433 млн. записей). 2-й запуск моего теста с 2-мя сессиями на этих данных занял примерно 2 минуты.

В заключение


Для себя я сделал вывод, что СУБД Exasol — отличный вариант для построения хранилища данных и аналитической системы на нём. В отличии от универсальной Oracle DB, Exasol создана для аналитики. Можно привести аналогию с автомобилями: для поездок на рыбалку хорошо иметь внедорожник, а для передвижения по городу компактный легковой авто.

Как и в предыдущей статье призываю всех делать какие-либо серьёзные выводы только после тестов на ваших конкретных кейсах.

На этом пока всё, на очереди тест для HPE Vertica.

P.S.: Буду очень благодарен, если ребята из Тинькофф Банк (@Kapustor) поделятся информацией о своём итоговом выборе, а Badoo (@wildraid) новостями проекта.

Комментарии (2)

  • 26 декабря 2016 в 02:21

    0

    ↑

    ↓

    А сколько стоит?

    • 26 декабря 2016 в 04:14

      0

      ↑

      ↓

      Если поймаете их промо для стартапов, то облачная база до 500 гигабайт обойдётся всего в 500€ в месяц.

© Habrahabr.ru