Порівняння продуктивності аналітичної СУБД Exasol і Oracle In-Memory Option

Свою попередню статті я присвятив тому, як і на скільки можна прискорити аналітичні (типові для 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 року.



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.


Бенчмарк включає 22 SQL запиту різної складності. Зазначу, що згенеровані утилітою qgen запити, потрібно коригувати під особливості конкретної СУБД, але в разі Exasol зміни були мінімальні: заміна set rowcount LIMIT clause і заміна keyword value. Для тесту було згенеровано 2 види навантаження:

  • 8 віртуальних користувачів паралельно 3 рази по колу виконують всі 22 запиту
  • 2 віртуальних користувача паралельно 12 разів по колу виконують всі 22 запиту
У підсумку, в обох випадках оцінювався час виконання 528-ми SQL запитів. Кого зацікавлять DDL скрипти для таблиць і SQL запити, напишіть в коментарях.

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

Тестова площадка
Ноутбук з наступними характеристиками:
Intel Core i5-4210 CPU 1.70 GHz – 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)
Завантаження даних в БД Exasol
Дані я завантажував з текстових файлів за допомогою утиліти EXAplus. Скрипт завантаження:

IMPORT INTO ТРСН.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) новинами проекту.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.