• На пути к бессерверным базам данных — как и зачем
    0

    Отличная вводная статья, но я бы выделил Snowflake в отдельную статью. SF не называют свой продукт serverless, по сути — это managed analytical db, т.к. вы указываете какие вычислительные ресурсы использовать. При этом есть serverless фичи, например — Snowpipe. Вот, например, они сравнивают SF с serverless аналогами:
    https://www.snowflake.com/blog/snowflake-versus-query-engines/


    А вот Google BigQuery является serverless analytical db, в ней вы вычислительными ресурсами не управляете.

  • Куда движется рынок BI-аналитики в 2019 году
    0

    Дополню вашу аналитику парой фактов про упомянутые компании. В 2019 Sisense объединились с Periscope Data, а у Амазона есть QuickSight.
    Ну и облака с AI можно сказать наступают в России, а в мире уже наступили :).

  • Технические отличия BI систем (Power BI, Qlik Sense, Tableau)
    0
    Да, но если речь именно о «больших данных» :). Но с действительно «большими» и Extract не пройдет :). Кстати, упоминая большие данные, вы примерно какой объем подразумевали?
  • Технические отличия BI систем (Power BI, Qlik Sense, Tableau)
    0
    когда речь идет о больших данных работать с LIVE соединением становится просто невозможно. А BI в большинстве случаев и нужно для больших данных.

    Скорее как раз наоборот, хотя и понятно, что вы имели ввиду. С производительностью в LIVE/DIRECT всё будет хорошо при условии, что запросы идут в хранилище на аналитической БД с «правильной» моделью данных.
  • Технические отличия BI систем (Power BI, Qlik Sense, Tableau)
    0
    Вы почти в каждом пункте упоминаете ограниченные возможности Tableau по подготовке данных. А о Tableau Prep знаете?

    Tableau и Power BI поддерживают LIVE соединение к ряду источников, в отличие от Qlik.

    А Direct Query в Qlik?
  • Разгоняем обработку событий до 1,6 миллионов в секунду
    0
    А нету у вас планов задачи, которые решаются в Exasol, постепенно переносить в CH (из соображений экономии на лицензиях)?
  • Архитектура хранилищ данных: традиционная и облачная
    0
    IMHO, оригинальная статья — неудачный верхнеуровневый обзор по теме. Как было замечено выше, тот кто не в теме, вряд ли что-то поймёт или поймёт неправильно.

    Перевод нет смысла комментировать, т.к. вопросы в основном к оригиналу.

    По ETL вопрос не в том, из каких иточников данные извлекаются. Про ETL написано «Данные хранятся во временной промежуточной базе данных.», а про ELT «Промежуточная база данных отсутствует». Можете на примере пояснить, что это за база такая и зачем она?

    Если вам интересно, могу другие неудачные интерпретации прокомментировать.
  • Архитектура хранилищ данных: традиционная и облачная
    0
    «Как-то все в кучу, начали про Кимбала, закончили про упокой...»
    Это точно… Похоже на то, как будто студента попросили сделать доклад по теме хранилищ данных. Помимо «в кучу» ещё хватает либо некорректных либо спорных интерпретаций различных понятий (например, ETL), плюс перевод ещё больше местами путает.
    Я бы не рекомендовал статью для тех, кто хочет предметно разобраться в этой теме.
  • Сравнение топ-4 популярных BI платформ. Какую выбрать?
    0
    приводя в качестве аргумента сотни субъективных обзоров, заполонивших Интернет. Если же вы хотите разобраться, какой инструмент подходит именно вашей компании, не пролистывая сотни страниц “честных” мнений, то ниже будет то, что нужно.

    Извините, но это сравнение — еще 1 крайне субъективный и поверхностный обзор. Плюс есть существенные ляпы, которые вводят интересующих в заблуждение…
  • Data Modeling Zone EU 2017
    0
    Павел, отличный обзор, спасибо!
    А есть где-то записи докладов и материалы этой франшизы?
  • Vertica+Anchor Modeling = запусти рост своей грибницы
    0
    «Когда первый раз читаешь про Anchor Modeling, становится страшно.»
    Это точно :). Очень смелое решение, учитывая масштаб проекта. Смотрел видео вашего доклада на конференции HPE и судя по вопросам, присутствующие там дядьки были весьма удивлены :). Респект!
    Пару вопросов:
    1) Витрины для Tableau у вас по Кимбаллу или другой подход? И сколько в них примерно таблиц и Тб?
    2) Учитывая поддержку историчности для атрибутов, как аналитики пишут запросы, когда нужно получить срез на заданную дату (в срезе, например, несколько десятков полей). В Data Vault для этого можно использовать PIT таблицы. Интересно посмотреть на такой SQL запрос.
  • Сравнение производительности аналитической СУБД Exasol и Oracle In-Memory Option
    0
    Без проблем тоже скучно :).
    А оценивали, как Exasol справляется с запросами, когда данные читаются с диска (например, относительно Greenplum)?
    Удачи!
  • Сравнение производительности аналитических СУБД HPE Vertica и Exasol с использованием TPC-H Benchmark
    0
    Алексей, спасибо за ваши интересные мысли тут! По этому поводу добавлю своих :).

    У всех свои объёмы и свои запросы и нужно тестировать именно на своём кейсе. У кого-то 100 Тб, а кому-то и 2-х Гб достаточно. В данном тесте чеки с 12 млн. строк, допустим, это объём для какой-то локальной сети, торгующей бытовой техникой. Если делать аналитикуи на перспективу сразу ставить БД (хотя можно и без), то чем бесплатная неприхотливая Vertica CE на 1 ноде плохой вариант (также как и Exasol)?

    "..MPP обычно имеют некий предел..."
    Согласен, например, хорошо знакомый вам Sybase IQ.

    «сравнивать Вертику с СУБД, заточенными на анализ небольшого объема горячих данных при хранении большого числа данных»
    Почему Exasol заточен на анализ небольшого объёма горячих данных? Я этого не писал. На сайте TPC-H есть результаты бенчмарка для 100 Тб (это максимум для tpc-h), в Badoo сейчас около 40 Тб, Тинькофф начинают 2-й этап пилота на десятках Тб (написали в параллельной ветке).

    «Вот пример — у телекомов «горячие данные»...»
    Успешно внедрённый вами проект на Vertica, вопросов нет.

    Здесь inmemory и в частности Exasol выглядят не очень подходящим решением и если смоделировать тесты по задачам под данное направление, то они проиграют в нагрузочных тестах и по скорости загрузки и по скорости выполнения параллельных запросов.
    А кто тестировал? Мне, например, не очевидны такие выводы.

    "… класс задач не тот для Вертики."
    А я бы так не ограничивал задачи для Vertica.В данном тесте переделать модель и соответственно переписать запросы и картина сильно поменяется.

    Но оставим объёмы и производительность. В статье ещё внимание уделяется другим моментам. Например, модели данных, которая оказалась не «удобной» для Vertica в данном кейсе. Ещё я оставил за рамками статьи утилизацию ресурсов при выполнении теста. Vertica на джоины и агрегации кушала больше оперативной памяти чем сами данные и в определённых прогонах я получил:
    ERROR 3587: Insufficient resources to execute plan on pool general [Timedout waiting for resource request: Request exceeds limits: Memory(KB)...
    Движки у Vertica и Exasol явно сильно отличаются и как минимум в определённых случаях Exasol оптимальнее использует ресурсы. Exasol прямо в документации пишут, что не бойтесь нормализации модели, а в Vertica надо с этим аккуратно.

    В итоге, я не делал выводов о том, какая БД лучше. Vertica и Exasol — отличные варианты для DWH и аналитики при правильном их использовании, иначе я не писал бы про них столько :).

  • Сравнение производительности аналитической СУБД Exasol и Oracle In-Memory Option
    0
    Будем ждать, спасибо!
  • Сравнение производительности аналитических СУБД HPE Vertica и Exasol с использованием TPC-H Benchmark
    0
    Про апельсины и лимоны не соглашусь. Это 2 БД для DWH и аналитики. И если Vertica не IM DB, то Exasol не только IM DB (данные не обязательно должны помещать в память).
  • Сравнение производительности аналитических СУБД HPE Vertica и Exasol с использованием TPC-H Benchmark
    0
    Привет! Согласен, что тест на 3 нодах, который можно выполнить, используя Vertica Community Edition, был бы интереснее. Но я не смог бы тогда сравнивать с другими БД из моего списка. Exasol, к сожалению, предлагает для бесплатного использования только single node (trial cloud не считаю), Teradata Developer Edition тоже.
    Также я не считаю, что 1 нода — это критическое ограничение в моём тесте. Возможно, я продолжу данный тест Vertica на 3-х нодах (например, + 2 ноды и объём данных * 3). В итоге у меня либо получится примерно то же время выполнения, либо худшее, т.к. для данного теста возможно будет сложно подобрать хороший ключ для сегментирования.

    Кстати, пользуясь случаем, нигде не находил информации, какую модель (подход) для DWH вы используете в своих проектах (Yota и др.)?
  • Сравнение производительности аналитической СУБД Exasol и Oracle In-Memory Option
    0
    Спасибо alexxz, очень интересен ваш опыт.
    Можете ещё поделиться, какой подход используете для модели DWH (3NF, DataVault, Kimball, Anchor,...)?
    Меня в Exasol очень заинтересовало то, что они рекомендуют использовать полностью нормализованную модель (например, Data Vault), не опасаясь проблем с производительностью запросов при соединении множества таблиц. Планирую это проверить.
  • Сравнение производительности аналитической СУБД Exasol и Oracle In-Memory Option
    0
    Ещё можно ориентироваться на спец. предложение для Tableau:
    до 100 Gb of raw data — 12 000 Евро
    до 500 Gb — 26 000
    до 2 Тб — 45 000
    Не думаю, что итоговая договорная стоимость для других кейсов, будет значительно дороже.
  • Сравнение производительности аналитической СУБД Exasol и Oracle In-Memory Option
    0
    Нету тут противоречия, по указанной ссылке просто нет результатов для других объёмов. Указал диапазон, чтобы была понятней область применения СУБД. К слову, 100 Тб — максимальный scale factor для tpc-h согласно спецификации.
  • Сравнение производительности аналитической СУБД Exasol и Oracle In-Memory Option
    0
    del
  • Тестирование производительности Oracle In-Memory Option c использованием TPC-H Benchmark
    0
    Вышлю AWR'ы, только e-mail не нашёл.
    Я использовал Benchmark Factory for Databases Freeware v7.0.0.221 (не триал на 15 дней), но не думаю, что это принципиально.
    IM у меня был существенно быстрее (в 2-3 раза), когда не хватало памяти (итоговые параметры указаны в статье).
  • Тестирование производительности Oracle In-Memory Option c использованием TPC-H Benchmark
    0
    Про индексы. Конечно же каждый кейс (таблица, конкретный индекс, характерные запросы,...) нужно рассматривать индивидуально. Если после включения IM необходимость в индексе пропадает, то удаляем, нет — оставляем. Например, в случае факт таблицы для аналитики актуальность большинства индексов скорее пропадёт.
    Аналогичный тест на Vertica есть в планах. SAP HANA в ближайшее время вряд ли.
    Результаты теста на MS SQL будет интересно почитать, особенно в части IM и column store.
  • Тестирование производительности Oracle In-Memory Option c использованием TPC-H Benchmark
    0
    Я не писал, что индексам места в памяти не хватало. Я для column store в In-Memory индексов нет в принципе.
  • Тестирование производительности Oracle In-Memory Option c использованием TPC-H Benchmark
    0
    В бенчмарке TCP-H 22 запроса различной сложности как раз для DSS/OLAP систем. Ваши выводы будут интересны на конкретном примере.

    Первое, что я лично ожидал увидеть от Oracle IM на своих кейсах — это значительное ускорение аналитических запросов за счёт compressed column store. Допустим, есть fact таблица из 30 полей и XXX млн. строк, выбираю XX млн. строк и 3 поля. К примеру, СУБД Vertica ускоряет такие запросы минимум на порядок с 1 нодой.
  • Тестирование производительности Oracle In-Memory Option c использованием TPC-H Benchmark
    0
    50 Гб конечно интереснее. На какой конфигурации сервера тестировали? Как в буферный кэш все данные отправляли? У меня разница в разы получалась только тогда, когда памяти на кэш не хватало.

    Результаты для Q1:
    no IM no parallel — 6.62 сек.
    no IM parallel(4) — 5.88 сек.
    IM no parallel — 6.47 сек.
    IM no parallel(4) — 3.15 сек

    Планы и статистика по ссылке.

    Но по сумме всех запросов IM+parallel мне не давал выигрыш в 2 раза.

  • Тестирование производительности Oracle In-Memory Option c использованием TPC-H Benchmark
    0
    AWR отчёты могу на почту выслать.

    Момент с количеством параллельных сессий учитывался. Для сравнения вариант с 2-мя сессиями и 12-ю запусками (те же 528 итоговых запуска):
    1) 14 мин 13 сек. без IM
    2) 13 мин 07 сек. с IM
    Разница менее 10%.
  • Тестирование производительности Oracle In-Memory Option c использованием TPC-H Benchmark
    0
    Есть ещё в планах выполнение аналогичного теста на полюбившихся мною СУБД Vertica и Exasol.
  • Тестирование производительности Oracle In-Memory Option c использованием TPC-H Benchmark
    0
    Я не совсем понял комментарий. Какие индексы в память не помещаются? Относительно чего не было выигрыша? И что понимаете под аналитическими индексами?
    Выше ссылки на ddl таблиц и запросы, просьба уточнить комментарий.
  • Тестирование производительности Oracle In-Memory Option c использованием TPC-H Benchmark
    0
    Поделюсь и запросами и ddl скриптами. Кому интересно, могу дать ссылку и на примерные планы выполнения запросов со статистикой.

    Bottleneck — CPU.

    Пробовал много дополнительных вариантов: несколько видов partitioning, без partitioning, c parallel и без, с компрессией вариант. При этом отдельные запросы специально не оптимизировались (индексами, хинтами,...). Делал это для того, чтобы показать ещё 1-2 быстрых способа оптимизации (например, parallel и/или db_big_table_cache_percent_target). Но на этом тесте и моём CPU интересных результатов не получилось и ограничился только IM Option.

    > Тесты на холодную базу запускали?
    Да, но так как каждый запрос выполнялся по 24 раза, это особой роли не играло. И 1-е выполнение не в разы было медленнее (диск SSD).
  • Тестирование производительности Oracle In-Memory Option c использованием TPC-H Benchmark
    0
    Нагрузку на сервер анализировал, используя Oracle AWR отчёт. И в обоих случаях узким местом был процессор, т.к. оперативной памяти было достаточно для кеширования всего объёма данных. Цель была — оценить, какой прирост производительности можно получить за счёт IM Option. И в этом смысле оба теста имели равные условия.