Порівняння продуктивності аналітичних СУБД HPE Vertica і Exasol з використанням TPC-H Benchmark

У цій статті я хочу продовжити тему порівняння баз даних, які можна використовувати для побудови сховища даних (DWH) та аналітики. Раніше я описав результати тестів для Oracle In-Memory Option In-Memory RDBMS Exasol. У цій статті основну увагу буде приділено СУБД Vertica. Для всіх описаних тестів використовувалися tpc-h benchmark на невеликому обсязі вихідних даних (2 Гб) і конфігурація БД на одному вузлі. Ці обмеження дозволили мені багаторазово повторити бенчмарк в різних варіаціях і з різними налаштуваннями. Для вибору аналітичної СУБД під конкретний проект закликаю читачів проводити випробування на своїх кейсах (дані, запити, обладнання та інші особливості).

Коротка інформація про СУБД Vertica
Vertica — це реляційна аналітична column-oriented MPP база даних. На Хабре досить статей з описом основних можливостей цієї СУБД (в кінці статті наведено посилання на деякі їх них), тому я не буду їх описувати і згадаю лише декілька цікавих, на мій погляд, фактів про Vertica:

  • Facebook использует Vertica для своїх внутрішніх аналітичних завдань. 2 роки тому там був кластер з сотень серверів і десятки петабайт даних… Я не знайшов актуальної інформації про цей проект, може хтось поділиться достовірної посиланням в коментарях.

  • Vertica була розроблена командою під керівництвом Майкла Стоунбрейкера (спочатку називалася C-Store). Написана з нуля спеціально для аналітичних завдань з урахуванням великої попереднього досвіду Майкла (Ingres, Postgres, Informix та інші СУБД). Для порівняння підходів можна згадати конкурента Vertica – Greenplum (зараз належить компанії Dell), це MPP СУБД, яка базується на доопрацьованій БД PostgreSQL.

  • В 2016 році Hewlett-Packard Enterprise (HPE) продала свій софтверний бізнес разом з Vertica компанії Micro Focus. Як це позначиться на розвитку Vertica поки не зрозуміло, але я дуже сподіваюся, що дана угода не погубить відмінний продукт.

  • В контексті порівняння з Exasol важливо відзначити, що Vertica не є in-memory базою даних і більш того, в Vertica немає буферного пула. Тобто БД призначена в першу чергу для обробки обсягів даних, які значно перевершують розмір оперативної пам'яті, а на відмову від підтримки буферного Кешу можна заощадити істотну частину ресурсів сервера. У той же час, Vertica ефективно використовує можливості файлової системи і зокрема кешування.
TPC-H Benchmark
Для тих, хто не читав попередні мої 2 статті, коротко опишу tpc-h benchmark. Він призначений для порівняння продуктивності аналітичних систем і сховищ даних. Цей бенчмарк використовують багато виробників як СУБД, так і серверного устаткування. На сторінці tpс-h доступно багато результатів, для публікації яких необхідно виконати всі вимоги специфікації на 136 сторінках. Я офіційно публікувати свої тести не збирався, тому всім правилам строго не дотримувався. Зазначу, що в рейтингу немає жодного тесту СУБД Vertica.

TPC-H дозволяє згенерувати дані для 8-ми таблиць з використанням заданого параметра scale factor, який визначає приблизний обсяг даних в гігабайтах. Для всіх тестів, результати яких публікую, я обмежився 2 Гб.


Бенчмарк включає 22 SQL запиту різної складності. Зазначу, що згенеровані утилітою qgen запити, потрібно коригувати під особливості конкретної СУБД, але як і Exasol, Vertica підтримує стандард ANSI SQL-99 і всі запити для цих 2-х СУБД були абсолютно ідентичні. Для тесту було згенеровано 2 види навантаження:

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

Тестова площадка
Ноутбук з наступними характеристиками:
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: Ubuntu 14.04.4 x64 (Memory: 8 Gb; Processors: 4)
СУБД:
Vertica Analytic Database v7.2.2-1 (single node)
Фізична модель даних Vertica
Обсяг займаного дискового простору і продуктивність запитів в Vertica сильно залежить від порядку сортування та алгоритму стиснення стовпців проекцій. Виходячи з цього, свої тести я виконував в кілька етапів. На першому етапі були створені тільки super projections таким способом:

CREATE TABLE ORDERS ( O_ORDERKEY INT NOT NULL,
O_CUSTKEY INT NOT NULL,
O_ORDERSTATUS CHAR(1) NOT NULL,
O_TOTALPRICE NUMERIC(15,2) NOT NULL,
O_ORDERDATE DATE NOT NULL,
O_ORDERPRIORITY CHAR(15) NOT NULL, 
O_CLERK CHAR(15) NOT NULL, 
O_SHIPPRIORITY INT NOT NULL,
O_COMMENT VARCHAR(79) NOT NULL)
PARTITION BY (date_part('year', ORDERS.O_ORDERDATE));

Дві найбільш об'ємні таблиці ORDERS LINEITEM були партиционированы по роках. Так як бенчмарк проводився на 1 сайті, сегментування (шардинга) не було. На наступних етапах фізична структура оптимізувалася з допомогою Database Designer, про це нижче.

Завантаження даних в Vertica
Для завантаження даних з текстового файлу я використовував наступний скрипт:

COPY tpch.lineitem FROM LOCAL 'D:\lineitem.tbl' exceptions 'D:\l_error.log';

Час завантаження всіх файлів склало 5 хв. 21 сек. (у Exasol 3 хв 37 сек.). Таким способом дані спочатку завантажуються порядково в оперативну пам'ять в WOS контейнери (параметри wosdata pool за замовчуванням: maxmemorysize = 25%), потім автоматично на диск поколоночно в ROS контейнери. Також я протестував завантаження файлів і з Oracle з використанням ETL інструменту Pentaho DI (aka Kettle), виходить істотно повільніше навіть зі спеціальним плагіном для Vertica.

Результати виконання тесту

* В попередньому тест виконання запитів в Exasol зайняло значно менше часу за рахунок кешування результатів (частина запитів в тесті не змінюються, для частини генеруються значення параметрів). У Vertica такого кешування немає і для зрівняння шансів, я вимкнув його і в Exasol:

alter session set QUERY_CACHE = 'OFF';

Послідовність тестування в Vertica
Етап 1. 1-й запуск
Перший запуск тесту виконувався після завантаження даних в super projections без збору статистики. Час виконання склало 581 секунду для 2-х сесій і 680 секунд для 8-ми сесій. При повторному виконанні час скоротилося мінімально (див. таблиці вище).

Далі у таблиці представлена інформація про те, як дані були організовані в Exasol і Vertica після початкового завантаження:


Запит для отримання інформації по займаному обсягом на диску і в пам'яті у Vertica:

SELECT 
ANCHOR_TABLE_NAME,
PROJECTION_NAME,
USED_BYTES/1024/1024 as USED_Mb,
ROS_USED_BYTES/1024/1024 as ROS_Mb,
WOS_USED_BYTES/1024/1024 as WOS_Mb
FROM PROJECTION_STORAGE 
WHERE ANCHOR_TABLE_SCHEMA='tpch'
order by 1,3 desc;

З таблиці видно, що Vertica трохи краще стиснула дані, незважаючи на те, що проекції були створені не оптимальним способом. В процесі тестування я також пробував оптимізувати структуру DB Designer на підставі завантажених даних та без урахування запитів. Коефіцієнт стиснення вийшов рівним 6.

Етап 2. Збір статистики
Після збору статистики за таблицями час виконання несподівано збільшилася приблизно на 30%. Аналіз статистики і планів виконання запитів показав, що для більшості запитів час виконання незначно зменшилася чи не змінилося, але для пари запитів істотно збільшилася. У цих запитах з'єднувалося безліч таблиць, включаючи ORDERS LINEITEM, і менша вартість (cost) відповідала більш тривалого часу виконання.

Етап 3. Оптимізація структури DB Designer
Був створений Comprehensive design з опцією Query perfomance (larger footprint) на підставі 21-го запиту бенчмарку tpc-h (1 пропущений, оскільки для нього view створюється перед виконанням). В результаті вийшли наступні цифри:


Таким чином, було створено 9 додаткових проекцій, але загальний обсяг даних на диску майже не змінився за рахунок оптимізації структури (порядку проходження колонок і різних алгоритмів стиснення). Однак нова структура ще більше сповільнила проблемні запити і відповідно загальний час виконання.

Етап 4. Ручна оптимізація
Враховуючи свій попередній досвід роботи з Vertica на інших моделях даних (переважно star schema), я очікував від БД кращих результатів, тому вирішив глибше пошукати вузькі місця. Для цього були виконані наступні дії:

  • Аналіз статистики і планів виконання запитів — системні таблиці v_monitor: query_requests, query_plan_profiles, execution_engine_profiles, query_events;
  • Аналіз рекомендацій БД за результатом виконання функції ANALYZE_WORKLOAD();
  • Створення декількох додаткових проекцій;
  • Зміна параметрів для general пулу.
Все це значимих результатів не принесло.

Далі був переписаний проблемний запит, який займав близько 30% часу виконання всіх запитів:

Вихідний код запиту:
select
nation,
o_year,
сума(amount) as sum_profit
from
(
select
n_name as nation,
extract(year from o_orderdate) as o_year,
l_extendedprice * (1 - l_discount) - ps_supplycost * l_quantity as amount
from
part,
supplier,
lineitem,
partsupp,
orders,
nation
where
s_suppkey = l_suppkey
and ps_suppkey = l_suppkey
and ps_partkey = l_partkey
and p_partkey = l_partkey
and o_orderkey = l_orderkey
and s_nationkey = n_nationkey
and p_name like '%thistle%'
) as profit
group by
nation,
o_year
order by
nation,
o_year desc;


Переписаний код запиту з використання підказки оптимізатору:
select
/*+SYNTACTIC_JOIN */ 
n_name as nation,
extract(year from o_orderdate) as o_year,
sum(l_extendedprice * (1 - l_discount) - ps_supplycost * l_quantity) as amount
from lineitem
join orders on o_orderkey = l_orderkey
join partsupp on ps_suppkey = l_suppkey and ps_partkey = l_partkey
join part on p_partkey = l_partkey and p_name like '%thistle%'
join supplier on s_suppkey = l_suppkey
join nation on s_nationkey = n_nationkey
group by 
n_name,
extract(year from o_orderdate)
order by 1, 2 desc;


В результаті запит прискорився приблизно в 4 рази.

У підсумку, мінімальний час виконання тесту в 2 сесії зі структурою створеної DB Designer і коригуванням 1 запиту становило 531 секунду (самий перший запуск без оптимізацій тривав 581 с.).

На цьому я зупинився, так як не було мети вичавити максимум шляхом переписування запитів, зміни моделі та інших не зовсім «чесних» способів.

Висновки
Даний тест в черговий раз підтверджує правило, що завжди необхідно вибирати інструменти і варіанти реалізації, які будуть оптимальні для вашого конкретного завдання/проекту. Бенчмарк tpc-h з моїми заданими обмеженнями є «незручним» для СУБД Vertica з наступних причин:

  • Всі дані містилися в оперативну пам'ять, а Vertica не є in-memory DB;
  • Нормалізована модель tpc-h і помилки оптимізатора. Коли пріоритетним вимогою є продуктивність ad-hoc запитів, для презентаційного шару сховища в Vertica краще підходить денормализованная модель (наприклад, star schema). A БД Exasol відмінно справляється і з нормалізованої моделлю, в чому, на мій погляд, її велика перевага, так як можна скоротити кількість шарів DWH.
Vertica не перевантажена зайвим функціоналом і відносно проста для розробки та адміністрування, але Exasol в цьому плані ще простіше і майже все робить за вас. Що краще гнучкість або простота, залежить від конкретної задачі.

Вартості ліцензій Vertica і Exasol порівнянні, а також доступні безкоштовні версії з обмеженнями. В процесі вибору аналітичної СУБД я б рекомендував розглядати обидва продукту.

Корисні посилання про Vertica
  1. Огляд архітектури та основних можливостей;
  2. Більше всіх ділиться практичним досвідом російською мовою, напевно, Олексій Константінов ascrus. Спасибі йому за це, рекомендую всі його публікації на Хабре і в блог;
  3. Вступна стаття і практичний досвід від alexzaitsev;
  4. Вибір методології для сховища на Vertica від Миколая Голова azathot. Цікавий і несподіваний для Vertica вибір Anchor Modeling (6 NF). Микола нерідко ділиться практичним досвідом на різних заходах, наприклад, на Higload++ або HPE конференції;
  5. Офіційна on-line документація з безліччю прикладів;
  6. Коротка статья про те, чого немає у Vertica, але що багато шукають.
Спасибі за увагу, на черзі один з лідерів серед аналітичних БД — Teradata.
Джерело: Хабрахабр

0 коментарів

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