Комментарии 25
А сколько стоит?
Если поймаете их промо для стартапов, то облачная база до 500 гигабайт обойдётся всего в 500€ в месяц.
Ещё можно ориентироваться на спец. предложение для Tableau:
до 100 Gb of raw data — 12 000 Евро
до 500 Gb — 26 000
до 2 Тб — 45 000
Не думаю, что итоговая договорная стоимость для других кейсов, будет значительно дороже.
до 100 Gb of raw data — 12 000 Евро
до 500 Gb — 26 000
до 2 Тб — 45 000
Не думаю, что итоговая договорная стоимость для других кейсов, будет значительно дороже.
Free Small Business Edition — бесплатно, в том числе для коммерческого использования.
200GB памяти на одной ноде будут держать примерно 1Tb сырых данных без сжатия.
Также, видимо, ничто не мешает поднять несколько таких instance'ов и, при необходимости, делать между ними запросы через SELECT… FROM EXA (...).
200GB памяти на одной ноде будут держать примерно 1Tb сырых данных без сжатия.
Также, видимо, ничто не мешает поднять несколько таких instance'ов и, при необходимости, делать между ними запросы через SELECT… FROM EXA (...).
Вот интересно как так можно анализировать производительность. В статье два расходящихся факта:
1) субд работает лучше всего от 100гб
2) сравнение в статье идёт на системе с 2гб
1) субд работает лучше всего от 100гб
2) сравнение в статье идёт на системе с 2гб
del
В Badoo с Exasol всё отлично. Продолжаем наращивать кластер и обвязку над ним. Особых эксплуатационных проблем в нём не встречали пока. В трудных местах ETL добавили функций на питоне. Очень ждём Exasol 6 и его интеграции с HCatalog. А в настоящий момент рассматриваем как-бы нам 40Тб данных Exasol бекапить пооптимальнее.
А по новым плюшкам, надеюсь wildraid тут отпишет 8)
А по новым плюшкам, надеюсь wildraid тут отпишет 8)
Спасибо alexxz, очень интересен ваш опыт.
Можете ещё поделиться, какой подход используете для модели DWH (3NF, DataVault, Kimball, Anchor,...)?
Меня в Exasol очень заинтересовало то, что они рекомендуют использовать полностью нормализованную модель (например, Data Vault), не опасаясь проблем с производительностью запросов при соединении множества таблиц. Планирую это проверить.
Можете ещё поделиться, какой подход используете для модели DWH (3NF, DataVault, Kimball, Anchor,...)?
Меня в Exasol очень заинтересовало то, что они рекомендуют использовать полностью нормализованную модель (например, Data Vault), не опасаясь проблем с производительностью запросов при соединении множества таблиц. Планирую это проверить.
Ну, ни одной модели в чистом виде у нас нет. Есть 2 основных фактора, которые берутся в учёт при добавлении данных — исходный формат данных и требования от reporting tool (Microstrategy). Если тормозит, проводим подготовку в ETL под конкретный репортинг.
Двумя самыми важными факторами оптимизации, обычно, выступают DISTRIBUTE BY и точное совпадение типов данных в полях JOIN, есть и много других, но эти два — ключевые. Хотя, в вашем тестовом примере для Single node дистрибуция не даст ничего.
Автогенеренными суррогатными ключами не увлекаемся. По строкам джойнит пекрасно. Джойны маленьких справочников (до сотен тысяч), как правило производительность аффектят не сильно.
Практикуем большие CTE, которые Exasol переваривает хорошо. Ещё у Exasol есть слой кеширования результатов view, но у нас он выключен.
Двумя самыми важными факторами оптимизации, обычно, выступают DISTRIBUTE BY и точное совпадение типов данных в полях JOIN, есть и много других, но эти два — ключевые. Хотя, в вашем тестовом примере для Single node дистрибуция не даст ничего.
Автогенеренными суррогатными ключами не увлекаемся. По строкам джойнит пекрасно. Джойны маленьких справочников (до сотен тысяч), как правило производительность аффектят не сильно.
Практикуем большие CTE, которые Exasol переваривает хорошо. Ещё у Exasol есть слой кеширования результатов view, но у нас он выключен.
Если коротко, то почти нет проблем с JOIN'ами.
У нас много случаев, когда внешний софт создаёт гигантские запросы, в которых соединяет по 30+ таблиц. Больших и маленьких, с группировкой и без, с sub-select'ами и CTE. До тех пор, пока промежуточный результат остаётся в рамках разумного, всё хорошо работает.
За редким исключением, нет необходимости как-то трансформировать данные специально для наилучшей производительности. Проекций, pre join'ов, вручную создаваемых индексов нет. Есть DISTRIBUTE BY, который здорово помогает снизить нагрузку на сеть, но он не обязателен.
У нас много случаев, когда внешний софт создаёт гигантские запросы, в которых соединяет по 30+ таблиц. Больших и маленьких, с группировкой и без, с sub-select'ами и CTE. До тех пор, пока промежуточный результат остаётся в рамках разумного, всё хорошо работает.
За редким исключением, нет необходимости как-то трансформировать данные специально для наилучшей производительности. Проекций, pre join'ов, вручную создаваемых индексов нет. Есть DISTRIBUTE BY, который здорово помогает снизить нагрузку на сеть, но он не обязателен.
Чуть-чуть комментариев по самой статье.
1) После загрузки данных и построения индексов есть смысл запустить RECOMPRESS. Коэффициент сжатия заметно улучшится. В обычной жизни Exasol сам периодически запускает его в background по мере роста объёма данных. Также последний блок в таблице хранится без сжатия для оптимизации быстрых маленьких INSERT'ов.
Проще говоря, чем больше таблица и чем чаще её используют, тем лучше будет сжатие. В некоторых случаях коэффициент может спокойно дойти до 10 и выше.
2) У Exasol на самом деле одна сессия выполняет запрос. Вторая сессия — это ExaPlus подключился, чтобы считывать мета-данные без конфликтов. Имена схем, таблиц, функций, вот это всё. Если во время выполнения теста посмотреть, чем она занята, то будет статус IDLE.
1) После загрузки данных и построения индексов есть смысл запустить RECOMPRESS. Коэффициент сжатия заметно улучшится. В обычной жизни Exasol сам периодически запускает его в background по мере роста объёма данных. Также последний блок в таблице хранится без сжатия для оптимизации быстрых маленьких INSERT'ов.
Проще говоря, чем больше таблица и чем чаще её используют, тем лучше будет сжатие. В некоторых случаях коэффициент может спокойно дойти до 10 и выше.
2) У Exasol на самом деле одна сессия выполняет запрос. Вторая сессия — это ExaPlus подключился, чтобы считывать мета-данные без конфликтов. Имена схем, таблиц, функций, вот это всё. Если во время выполнения теста посмотреть, чем она занята, то будет статус IDLE.
Извиняюсь, поздно заметил, что речь о сессиях теста, а не про EXA_ALL_SESSIONS. Комментарий уже не могу изменить.
Если сессии теста запускались синхронно, то первый результат 165 может объясняться тем, что каждая из восьми сессий строила собственные индексы в своей транзакции. Потом семь индексов из восьми выбросили, а один оставшийся был использован во втором запуске.
Если сессии теста запускались синхронно, то первый результат 165 может объясняться тем, что каждая из восьми сессий строила собственные индексы в своей транзакции. Потом семь индексов из восьми выбросили, а один оставшийся был использован во втором запуске.
Спасибо, лайкнуть не могу, т.к.… сам не знаю почему
P.S.: Буду очень благодарен, если ребята из Тинькофф Банк (@Kapustor) поделятся информацией о своём итоговом выборе
Привет!
Спасибо за статью, интересно!
Про наш выбор: сейчас начинаем второй этап PoC, ставим Exasol на боевые машины с 3 Тб памяти и даём бизнесу новую игрушку. По результатам могу отписаться здесь, например.
Будем ждать, спасибо!
Как оно? Взлетело?)
Взлетает пока, но не без проблем)
1) Вендору пришлось пересобирать БД под наш объём памяти в кластере (6 Тб), были какие-то ограничения в коде из-за которых БД падала;
2) Были проблемы с таймзоной, вендор тоже правил в коде БД что-то и пересобирал под нас;
3) Пока не научились грузить данные параллельно из Greenplum в Exasol без промежуточного приземления на диск — при запуске параллельной вычитки из сегментов GP через множество jdbc-соединений лоадер Экзасола падает и валит за собой всю базу.
Вобщем, проблемы есть, но поддержка адекватная, реагирует быстро, работаем :)
1) Вендору пришлось пересобирать БД под наш объём памяти в кластере (6 Тб), были какие-то ограничения в коде из-за которых БД падала;
2) Были проблемы с таймзоной, вендор тоже правил в коде БД что-то и пересобирал под нас;
3) Пока не научились грузить данные параллельно из Greenplum в Exasol без промежуточного приземления на диск — при запуске параллельной вычитки из сегментов GP через множество jdbc-соединений лоадер Экзасола падает и валит за собой всю базу.
Вобщем, проблемы есть, но поддержка адекватная, реагирует быстро, работаем :)
Без проблем тоже скучно :).
А оценивали, как Exasol справляется с запросами, когда данные читаются с диска (например, относительно Greenplum)?
Удачи!
А оценивали, как Exasol справляется с запросами, когда данные читаются с диска (например, относительно Greenplum)?
Удачи!
Про память интересно. У нас чуть больше даже, но взлетает без патчей пока. Видимо, вопрос не только в объёме.
А попробуйте загружать без JDBC, он тормоз) В постгресе есть выгрузка в STDOUT в формате CSV. Пустите пару десятков таких, соберите вместе через fdlinecombine (https://github.com/vi/fdlinecombine) и отправьте общим потоком в exajload. Там можно из STDIN читать, если передать файл /dev/stdin. Без промежуточных файлов.
Или можно набросать простой скрипт, в котором сделать штук сто staging таблиц, залить в каждую из них данные из отдельной связки postgres -> exajload, а затем их вместе собрать в одну мега-таблицу через INSERT… SELECT. Так совсем параллельно будет.
А попробуйте загружать без JDBC, он тормоз) В постгресе есть выгрузка в STDOUT в формате CSV. Пустите пару десятков таких, соберите вместе через fdlinecombine (https://github.com/vi/fdlinecombine) и отправьте общим потоком в exajload. Там можно из STDIN читать, если передать файл /dev/stdin. Без промежуточных файлов.
Или можно набросать простой скрипт, в котором сделать штук сто staging таблиц, залить в каждую из них данные из отдельной связки postgres -> exajload, а затем их вместе собрать в одну мега-таблицу через INSERT… SELECT. Так совсем параллельно будет.
Возможно, там было ограничение не на объём памяти в кластере, а на объём на одной машине (3 ТБ в нашем случае).
Идея с STD[IN, OUT] хорошая, спасибо. JDBC хотели использовать, потому что Greenplum по сути представляет собой множество инстансов постгреса на серверах-сегментах, соответственно, можно читать в параллель со всех серверов ГП. Если отказаться от идеи не использовать мастер-сервер ГП, то можно читать в несколько потоков с мастера, разделяя данные по служебному полю с номером сегмента (есть в каждой таблице в ГП). Вобщем, будем думать, проблема не выглядит тупиковой, надо пробовать :)
Идея с STD[IN, OUT] хорошая, спасибо. JDBC хотели использовать, потому что Greenplum по сути представляет собой множество инстансов постгреса на серверах-сегментах, соответственно, можно читать в параллель со всех серверов ГП. Если отказаться от идеи не использовать мастер-сервер ГП, то можно читать в несколько потоков с мастера, разделяя данные по служебному полю с номером сегмента (есть в каждой таблице в ГП). Вобщем, будем думать, проблема не выглядит тупиковой, надо пробовать :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Сравнение производительности аналитической СУБД Exasol и Oracle In-Memory Option