• Когда у вас сберовские масштабы. Использование Ab Initio при работе с Hive и GreenPlum
    0

    Понятно, спасибо. Хорошо, если хватает пропускной способности мастера, но в случае масштабирования нагрузки и самого кластера крайне рекомендую вложиться в загрузчик на gpfdist :)

  • Когда у вас сберовские масштабы. Использование Ab Initio при работе с Hive и GreenPlum
    0
    Использовался ли при загрузке в Greenplum параллельный загрузчик gpfdist, или заливали через JDBC/ODBC? В последнем случае все данные льются через мастер, это плохой способ загрузки в Greenplum.
  • Управление внешним устройством в автомобиле с помощью кнопок на руле
    0
    Создатель канала не захотел наплыва пользователей в канал и изменил ссылку(
    Не буду из-за этого давать прямую ссылку, но вот его оригинальная статья на драйве, там внизу есть правильная ссылка на канал: www.drive2.ru/l/485801071864709696
  • Управление внешним устройством в автомобиле с помощью кнопок на руле
    0
    Вот тут интересный опыт управления Bluetooth плеером штатными кнопками на руле Opel Astra.
    А вот тут ТГ-сообщество CAN-хакеров семейства авто Opel (Astra, Corsa, Zafira и тд). Там есть и более интересные проекты — с выводом своей инфы на дисплей, изменением логики поведения авто, автозапуском и так далее.
  • Забавные патенты из автомобильной промышленности
    +8

    От Nestea. Горлышко шире :)

  • Greenplum 6: обзор новых фич
    0
    О, с RLE ситуация интересная. Действительно, RLE даёт фантастическую степень сжатия (в моей практике доходило до 60-70 раз). Иногда. Если быть точным, при соблюдении нескольких условий:
    1. Дельта между данными (строками) небольшая и одинаковая
    2. Таблица отсортирована (в случае с ГП это INSERT… SELECT… ORDER BY… )
    На практике RLE выстреливает ОЧЕНЬ редко. Всегда надо пробовать и смотреть, что оно даст. Обычно получается использовать RLE для подневных витрин или таблиц фактов.

    Про метаданные — всё так. Другой вопрос, что если у вас настолько много метаданных, что они реплецируются по интерконнекту часами, то, возможно, стоит пересмотреть модель? В нашей практике есть только один заказчик с действительно раздутыми каталогами.

    gp_upgrade — да, пока не доделан. Кстати, наша команда (Arenadata) принимала активное участие в его разработке этим летом, надеемся к нему вернуться. Минусы бекапа и рестора понятны, но есть разные методики, ускоряющие миграцию, мы в том числе и этим помогаем нашим заказчикам.
  • Greenplum 6: обзор новых фич
    0
    В целом, правильно, но есть нюанс: один запрос утилизирует максимум одно ядро на один сегмент. То есть, если, например, в вашем примере 6 сегментов и 16 ядер на сегмент-сервер, то один запрос утилизирует максимум 6 ядер, два запроса — 12 ядер, и так далее. Так как обычно в аналитической СУБД работает 20-100 запросов, то проблем с утилизацией не возникает почти никогда (если, конечно, совсем не жестить и не делать по одному сегменту на сервер).
  • Greenplum 6: обзор новых фич
    0
    Так вот же в официальной документации PostgreSQL 9.4:

    GRANT { { SELECT | INSERT | UPDATE | REFERENCES } ( column_name [, ...] )
    [, ...] | ALL [ PRIVILEGES ] ( column_name [, ...] ) }
    ON [ TABLE ] table_name [, ...]


    И там же пример:

    GRANT SELECT (col1), UPDATE (col1) ON mytable TO miriam_rw;
  • Greenplum DB
    +1
    Каааак?? Как вы это делаете? :)
    Вышел Greenplum 6 — только что опубликовал статью про новые фичи.
    А так всё прекрасно, Greenplum в России становится всё больше и это очень приятно.
  • Как мы строим систему обработки, хранения и анализа данных в СИБУРе
    0

    На всякий случай, в Greenplum есть транзакции (ACID + ANSI SQL). С нагрузкой тоже все ок, эксплуатируем очень жёсткие кластера по 20+ нод :)
    Но Вертика тоже отличная система и у вас грандиозные планы, так держать!

  • Импортозамещённый дистрибутив Hadoop
    0
    Не поделитесь инфой про ORC? Очень интересно.
  • Импортозамещённый дистрибутив Hadoop
    –1
    Да, LLAP есть, но, со слов нашей поддержки, вам очень повезло что он работает хорошо. У нас были кейсы с ним, используем очень осторожно.
  • Импортозамещённый дистрибутив Hadoop
    +9
    Всем привет.
    Я отвечаю за продуктовое наполнение платформы в Arenadata. Попробую ответить на вопросы в статье и в комментариях. В нашей платформе я технически больше погружен в Greenplum и Clickhouse, чем в Hadoop, но постараюсь использовать экспертизу коллег. Боюсь, правда, получится очень много букв :)

    Для начала, кто мы такие. Команда Arenadata (AD) формировалась в 2014-2017 году. Все мы (на тот момент около 5 человек, сейчас уже больше 40) до AD многие годы занимались корпоративными хранилищами данных (КХД) — кто-то разрабатывал Hadoop и Greenplum (CEO и CTO пришли из Pivotal), кто-то внедрял в интеграторах (Glowbyte), кто-то поддерживал на местах (я занимался эксплуатацией Greenplum и Hadoop в Tinkoff). В какой-то момент мы поняли, что объединившись мы сможем улучшить те open-source проекты, с которыми до этого работали, объединив их в единую платформу и наделив её enterprise-фичами — глубоким саппортом, единым мониторингом и управлением, обучающими программами для спецов заказчика и возможностью менять код под заказчиков.

    При этом мы не просто собираем open-source на коленке и продаём:
    1) Большинство наших разработок мы отдаём в open-source (комитим в проекты, больше всего в Greenplum, в Hadoop поменьше)
    2) Мы разрабатываем собственную систему управления кластерами (вот тут и тут можно посмотреть как это выглядит), и она доступна абсолютно бесплатно на нашем сайте. Код также скоро будет открыт. Мы берём деньги лишь за техподдержку.

    Да вы же просто слизали всё у Хортона! DrunkBear
    И да, и нет. Мы никогда не ставили себе целью сильно отличаться от Hortonworks (точнее, от Bigtop) — это банально вопрос совместимости, заказчики не хотят vendor lock-in. Более того, специально для того, чтобы не отличаться от Хортон и Клаудеры, в 2015-м году мы прошли сертификацию нашего дистрибутива в ODPi — часть Linux Foundation (и каждый год проходим её снова) — это гарантия того, что мы не делаем наколеночного, закрытого и несовместимого ни с чем решения.
    Также, мы никогда не будем сильно отличаться от Bigtop ещё и потому, что более-менее серьёзные изменения в коде мы комитим в сам Bigtop и другие репы. Кстати, один из наших PR принял лично Alan Gates.
    С другой стороны, мы видим слабые стороны у дистрибутивов Хортона и Кладудеры (хотя теперь уже не разберёшь кто есть кто), которые мы смогли сделать своими преимуществами:
    1) Сильное отставание версий компонентов от upstream
    2) Невозможность обновлять компоненты по отдельности (по краней мере без танцев с бубном, но мы же говорим об Enterprise, верно?)
    Поэтому версии компонентов у нас всегда немного впереди (про 3.0 чуть дальше), а благодаря нашему Cluster Manager заказчики могут обновлять компоненты по отдельности.

    Когда наконец будет 3.х? DrunkBear
    Ох, тоже самое спрашивают наши заказчики) С 3.х есть два нюанса:
    1) Недавно было объявлено, что Ambari — deprecated и скоро умрет, поэтому мы решили полностью отказаться от Ambari в нашем 3.х и перевести всё управление в Arenadata Cluster Manager, чем сейчас и занимаемся. Это займёт ещё несколько месяцев, дальше будет проще.
    2) По мнению наших спецов, 3.х ещё всё-таки не настолько стабилен, чтобы брать его на саппорт.

    Что с саппортом? Можете ли вы соответствовать уровню хортона? DrunkBear
    Да, можем, а за счёт 3-го пункта мы даже немного лучше:
    1) У нас саппорт 24х7, за счёт того что наши специалисты находятся в разных часовых поясах в России
    2) За этот год мы очень сильно нарастили ресурсы на саппорт — сейчас это самый многочисленный отдел в AD (9 человек + подключаем разработчиков на сложные кейсы)
    3) В отличии от Хортона и Клаудеры, мы готовы адаптировать дистрибутив под адекватные хотелки заказчиков — в том числе вносить (комитить) изменения в основные OS-репы. Мы здесь, в России, с нами можно и нужно встречаться, договариваться и развивать продукты вместе.

    Ваше импортозамещение — это переклеенная этикетка DrunkBear
    Вот тут будет сложно, но я попробую.
    1) В первую очередь, в нашу платформу входят дистрибутивы продуктов (Hadoop, Greenplum, Clickhouse), а не их аналоги или свои разработки с нуля. Мы нигде и никогда не скрывали, что используем OS-проекты. Разрабатывать с нуля свой аналог дистрибутива Hadoop в 2019-м году — безумие.
    2) Работать с open-source можно и нужно только одним способом — делиться ресурсами, отдавая свои наработки в open-source. Это не просто (куча бюрократии, согласований, общения с сообществом и тд), но мы это знаем и умеем. Это значит, что у нас (надеюсь) никогда и не будет своего отдельного форка Hadoop или Greenplum. При этом, мы делаем много дополнительного функционала (коннеткоры, управлялки и тд).
    3) Рискую отхватить за политику, но я попробую.
    Откуда растут ноги у импортозамещения? Всё просто: большие государственные (иногда и частные) предприятия опасаются, что в какой-то момент они не смогут использовать зарубежное ПО из-за:
    — санкций с нашей стороны
    — санкций с той стороны
    — валютных изменений
    — ухода экспертизы по этому ПО с нашего рынка
    Мы закрываем эти риски. Более того, в случае глобального экстерминатуса (т-т-т), мы сможем поддерживать и развивать эти OS-проекты независимо (повторюсь, это не является целью).
    4) Импортозамещение — не основной драйвер нашего бизнеса, так как большинство наших заказчиков — частные компании, которые в первую очередь ценят экспертизу (Х5 Retail Group, IQ Option, Touch Bank и другие). Потребность в импортозамещении у госов — приятный бонус, не более.

    А Pivotal и Hortonworks вообще знают, чем вы тут занимаетесь?
    Не просто знают, а ещё и помогают нам. Вот тут к нам на митап приехал Pivotal Director of Data Engineering, а вот тут я выступал на Greenplum Day в Нью-Йорке вместе с CIO Morgan Stanley — крупнейшим пользователем Greenplum в мире. Так работает open-source — рынок захватывает технлология, а уже потом его делят вендоры.

    Где Ranger и Zeppelin? sshikov
    Ranger есть в платформе, на сайте, увы, сильно устаревшая информация. Мы использовали его в двух проектах, всё ок. Sentry действительно похоже умирает.
    А вот от Hue мы отказались в пользу Zeppelin (он у нас выделен в отдельный продукт, как и Kafka) — кстати, рекомендую, новый Zeppelin 0.8 стал очень крутым.

    Код полностью скопирован с hdp и hdf с минимальными допилами loltrol
    Выше я ответил, почему это так и почему это правильно.

    Взяли за основу древнюю версию. loltrol
    Вот тут не очень понял — можете указать на версии компонентов, которые по вашему мнению устарели? Уточню у наших ребят.

    Сайт у вас отстой.
    Мы знаем :( Этот сайт создавался когда нас было 5 человек, мы вообще плохо умеем в дизайн и сайты. Этим летом хотим переделать, если у вас есть контакты студии, которая сможет сделать сайт не хуже pivotal.io — поделитесь в ЛС плз.

    Почему у вас нет блога на хабре? Почему так мало информации?
    Блога нет, потому что дорого :)
    Информации о нас в открытом доступе мало, потому что рынок очень узкий, и мы своих потенциальных заказчиков знаем и так.
    Ну и плюс мы активно участвуем в конференциях, организуем митапы и т.д.

    А ещё...
    А ещё мы:
    1) Раз в квартал проводим митапы по распределённым системам — присоединяйтесь, следующий будет в сентябре, сможете спросить и высказать нам всё лично :)
    2) Ведём чат в ТГ по Greenplum, там есть почти все наши заказчики — можете спросить их о качестве нашего сервиса
    3) Сейчас совместно с Яндекс запускаем продукт на базе Clickhouse — детали сможем опубликовать чуть позже, но получается круто!

    Мне кажется, получилось очень много информации для комментария. Есть ли смысл оформить отдельную статью, где рассказать о нас подробней?
  • Greenplum DB
    0
    А вы точно не бот?)
    На самом деле очень много что появилось и изменилось, но если по верхам:
    • Готовится к выходу Greenplum 6 — Postgres версии 9.4, Replicated-таблицы, новый алгоритм хеширования, новый сетевой протокол и ещё куча новых фич
    • В нашем дистрибутиве Greenplum — Arenadata DB — добавлена (и уже работает у наших заказчиков) компрессия ZSTD — arenadata.tech/products/db
    • Наша же команда реализовала графический инсталятор для open-source data-сервисов — Arenadata Cluster Manager, и первым продуктом в нём конечно же стал Greenplum — docs.arenadata.io/adb/install/adcm/ru/index.html
    • Присоединяйтесь в чат Greenplum Russia, почти все экплуатанты Greenplum в России сидят там, стараемся помогать друг другу — t.me/greenplum_russia
  • Greenplum 5: первые шаги в Open Source
    0
    Люблю такие развёрнутые и подробные комментарии, спасибо.

    Такой подход (портирование фич вместо постоянного rebase'а) имеет свои плюсы и минусы.

    Надо понимать, что Greenplum имеет очень много концептуальных и архитектурных отличий от PostgreSQL (свой планировщик, column-storage, шардирование, партиционирование, своя WAL-репликация, компрессия и т.д). В таких условиях rebase на более новую версию PostgreSQL — очень сложная, дорогая и долгая процедура. Например, rebase на версию 8.4 (сейчас 8.3) продолжается уже c полгода.

    Как показывает практика других похожих по функционалу проектов (Citus Data, PostgresXL), построить полноценную аналитическую колоночную СУБД для DWH просто добавляя простенькую реализацию шардирования к PostgreSQL не получается. Хорошее распределённое OLTP-хранилище — да, OLAP RDBMS — нет.

    Выдержка из поста представителя Citus Data на одном из форумов:
    Сitus is not a traditional data warehouse. We position Citus as the real-time, scalable database that serves your application under a mix of high- concurrency short requests and ad-hoc SQL analytics (i.e. think both random and sequential scans for a customer-facing analytics app). The default storage engine for Citus is the PostgreSQL storage engine, which is row-based. This is in contrast to many data warehouses, which often use a column store and/or batch data loads, and are focused purely on analytics. The trade-offs you get are: — Citus vs. DWH performance: DWH and Citus both have a similar parallelization for analytics queries (multi-core, multi-machine), but most data warehouses typically use a columnar storage engine instead of a row-based one. Columnar storage is designed for faster analytics queries, so that makes columnar DWH generally faster on longer running analytics queries. However, this comes at the expense of (1) concurrency and (2) short-request performance (think simple lookups, updates, real-time data ingest) vs. Citus' row-based storage.


  • Greenplum DB
    0
    Зависит от числа ядер, памяти и среднего количества одновременных запросов. Очень грубо — если вы знаете, что у вас в системе будет 1-2 параллельных запроса, берите число сегментов=число ядер/потоков на сервер. Если одновременных запросов, наоборот, ожидается много, можно снизить число сегментов на сервер.

    У вас 6 сегментов на весь кластер или 6 сегментов на машину? Я не знаю, что у вас за машины, но 2 сегмента на сервер выглядит очень маленьким значением.
  • Greenplum DB
    0
    Виден системный подход к комментированию :)
    Да, и добавить есть много чего, информации слишком много для одного комментария:
    • Greenplum теперь полноценный Open-source дистрибутив, 09.2017 был первый OS-релиз 5.0.0 (сейчас уже 5.1.0 + через пару дней будет 5.2.0 + появились первые наброски 6.0.0);
    • в 5.0.0 появилось очень много нового: новый способ взаимодействия с Hadoop (Hive, HDFS), новый SPARK-коннектор, много новых фич (dblink, Anonymous blocks и т.д.);
    • По части эксплуатации системы в Тинькофф могу сказать, что до июля 2017-го года GP показывал себя хорошо и каких либо эксцессов не было, после чего я начал работу в другой компании — Arenadata. Мы разрабатываем, внедряем и поддерживаем свой корпоративный дистрибутив Greenplum с учётом уже имеющихся best practices.
  • В поисках идеального мониторинга
    +1
    Спасибо, пофиксили старые ссылки, теперь всё работает.
  • Сравнение аналитических in-memory баз данных
    +1
    Ignite (aka GridGain) сейчас тестируем для немного другой задачи. Сейчас, к сожалению, не могу рассказать подробности, надеюсь, со временем напишем отдельную статью.
    С Ignite пока есть неопределённость как минимум с выбором persistent-движка.
  • Сравнение производительности аналитической СУБД Exasol и Oracle In-Memory Option
    0
    Возможно, там было ограничение не на объём памяти в кластере, а на объём на одной машине (3 ТБ в нашем случае).

    Идея с STD[IN, OUT] хорошая, спасибо. JDBC хотели использовать, потому что Greenplum по сути представляет собой множество инстансов постгреса на серверах-сегментах, соответственно, можно читать в параллель со всех серверов ГП. Если отказаться от идеи не использовать мастер-сервер ГП, то можно читать в несколько потоков с мастера, разделяя данные по служебному полю с номером сегмента (есть в каждой таблице в ГП). Вобщем, будем думать, проблема не выглядит тупиковой, надо пробовать :)
  • Сравнение производительности аналитической СУБД Exasol и Oracle In-Memory Option
    0
    wildraid правильно заметил, пока тяжело добиться чтения с диска) Мы проводили сравнительное тестирование на меньших объёмах памяти, но там и данных тоже было меньше, результаты есть в статье.
  • Сравнение производительности аналитической СУБД Exasol и Oracle In-Memory Option
    +1
    Взлетает пока, но не без проблем)

    1) Вендору пришлось пересобирать БД под наш объём памяти в кластере (6 Тб), были какие-то ограничения в коде из-за которых БД падала;
    2) Были проблемы с таймзоной, вендор тоже правил в коде БД что-то и пересобирал под нас;
    3) Пока не научились грузить данные параллельно из Greenplum в Exasol без промежуточного приземления на диск — при запуске параллельной вычитки из сегментов GP через множество jdbc-соединений лоадер Экзасола падает и валит за собой всю базу.

    Вобщем, проблемы есть, но поддержка адекватная, реагирует быстро, работаем :)
  • Сравнение производительности аналитической СУБД Exasol и Oracle In-Memory Option
    +2
    P.S.: Буду очень благодарен, если ребята из Тинькофф Банк (@Kapustor) поделятся информацией о своём итоговом выборе

    Привет!
    Спасибо за статью, интересно!
    Про наш выбор: сейчас начинаем второй этап PoC, ставим Exasol на боевые машины с 3 Тб памяти и даём бизнесу новую игрушку. По результатам могу отписаться здесь, например.
  • Greenplum DB
    0
    Скорее нет, чем да. Серьёзных происшествий не было (т-т-т), найдено пара багов, отправлены в саппорт и уже даже исправлены в новой (4.3.10) версии. Установили во все сервера продуктовых кластеров PCI-SSD диски, вынесли туда некоторые особо критичные к скорости таблицы и ворк-схемы SAS-джобов. Готовимся к очередному экспанду (упираемся и в место на кластере, и в производительность).
  • Сравнение аналитических in-memory баз данных
    0
    Интересно. Можете привести данные, которые это доказывают? Действительно, нигде в документации прямо не указывается о наследовании, но это и не опровергается (не нашёл, по крайней мере).
  • Сравнение аналитических in-memory баз данных
    0
    1) Версии указаны в статье в таблице. Memsql — 5.1.0. Версию 5.5 не тестировали, она вышла уже после завершения тестирования, когда машины у нас забрали.
    2) Характеристики машин указаны в начале статьи (две машины на каждую БД).
    3) Везде, где возможно, использовали Columnstore.
    4) Использовали MONTH() и YEAR().
  • Сравнение аналитических in-memory баз данных
    0
    Тогда неудивительны, как минимум, хорошие показатели SAP HANA в вашем тесте — у нас к ней претензии именно в неспособности грамотно утилизировать все ресурсы кластера.
    Распределённость добавляет тестированию остроты :)
  • Сравнение аналитических in-memory баз данных
    0
    А БД из списка были установлены в кластерной конфигурации или single-node?
  • Сравнение аналитических in-memory баз данных
    0
    Инженеры HANA проводили тестирование на нашем железе, да и некие официальные договорённости у нас с ними есть (сотрудничаем с этой компанией и по другому софту SAP).
    Про деперсонализацию — обещаю в ближайшее время проработать вопрос (нужно согласие руководства + оценить объём работ по деперсонализации, там не только номера счетов), напишу в личку заинтересовавшимся :)
  • Сравнение аналитических in-memory баз данных
    0
    Увы, выложить данные не можем, среди них есть персональные данные :(
  • Сравнение аналитических in-memory баз данных
    +1
    Спасибо!

    Про преимущества той или иной ФС для GP не могу сказать, подробно не изучал вопрос (полагался на вендора:) ). Однако, в моём комментарии выше я был немного неправ, ZFS поддерживается для GP on Solaris.
    Вот тут немного информации о ZFS <> XFS для GP:
    https://discuss.pivotal.io/hc/en-us/community/posts/200796448-Solaris-ZFS-v-Linux-XFS
  • Сравнение аналитических in-memory баз данных
    +1
    Вендор рекомендует XFS или ext4. Наверно, можно попробовать ZFS, то надо много тестировать перед выводом в прод, оффициально такая конфигурация не поддерживаются. Ещё потом возможны проблемы с поддержкой (она у нас есть для ГП).
  • Сравнение аналитических in-memory баз данных
    0
    Для этой задачи нет, не пробовали, но в ближайших планах есть желание присмотреться к нему повнимательней.
  • Сравнение аналитических in-memory баз данных
    0
    Спасибо, выглядит интересно. Странно, что про неё так мало информации. А вы её сравнивали с Exasol вживую?
  • Сравнение аналитических in-memory баз данных
    0
    2) Абсолютно согласен, однако больше данных не влезло в HANA, она падала с OOM при выполнении запросов N1-N3 :) А так как тестирование должно быть равнозначным на всех БД, пришлось довольствоваться малым.
  • Сравнение аналитических in-memory баз данных
    0
    Привет, спасибо!

    Про не-in-memory — отчасти согласен, GP и Impala — не in-memory-решения, о чём и упомянул в статье. memSQL и HANA — классические in-memory, memSQL, например, при запуске загружает с диска вообще всё в память и работает только с ней. C Exasol и Clickhouse уже зависит от точки зрения :)

    Про VoltDB — изначально рассматривали, однако это не совсем SQL-совместимая БД, с этим скорее всего будут сложности — нам нужна прозрачная интеграция с SAP BO. Кроме того, она и не позиционируется как аналитическая (выросла из H-Store, что есть OLTP-решение).

    Про число запусков тестовых запросов: везде бралось первое выполнение запроса, при этом экспериментально выяснили, что первое и второе выполнения по времени значительно отличаются только у Exasol — второй раз он отрабатывает значительно быстрее за счёт построенных при первом запуске индексов (впрочем даже время первого выполнения в Exasol всегда значительно меньше, чем второго всех остальных баз). Пример:

    Запрос 1-ый 2-ой
    T1 1.8 0.1
    T2 4.2 0.1

    Правильней, конечно же, было выполнить каждый запрос 5-10 раз, отбросить лучшее и худшее и взять среднее от оставшегося, однако тогда тестирование бы затянулось. Кроме того, так как мы рассчитываем на этой базе выполнять в том числе и ad-hoc запросы пользователей, время первого выполнения нам интересней.
  • Сравнение аналитических in-memory баз данных
    +1
    Aerospike — это key-value noSQL БД, нам нужна полная поддержка SQL (вплоть до оконных функций).
    Но он у нас есть и используется для других задач, да.
  • Сравнение аналитических in-memory баз данных
    0
    Про затраты: да, несмотря на 7-ми кратное преимущество в скорости, можно добиться преимущества покупкой большего числа серверов за те же деньги. Однако нужно помнить, что:
    — большее число серверов влечёт за собой бОльшие накладные расходы в кластере;
    — возрастает сложность поддержки и администрирования;
    — ЦОД не резиновый и тд и тп.
    Да и помимо скорости есть и другие параметры, надо оценивать всё в сумме.

    Про MemSQL — блин, как вовремя они подсуетились :( Новая версия (5.5, релиз 03.10.2016) обещает "...a new hash table design which combined with Bloom filters delivers up to 3x-5x performance improvements for hash joins".
    Сейчас стенды уже разобрали, протестировать не сможем.
  • Сравнение аналитических in-memory баз данных
    0
    1) Нет, узнал о проекте от Вас :) Почитал кратко — проект интересный. Однако, пока настораживают:
    — ограниченная поддержка timestamp и decimal
    — необходимость наличия Импалы
    Что радует, изначально заложена правильная дистрибюция таблиц по интервалу поля/полей.

    2) Есть, но рассказать, увы, не смогу. Могу только сказать, что примерно затраты пропорциональны результатам теста производительности в статье :)
  • Сравнение аналитических in-memory баз данных
    0
    Vertica не является в полном смысле in-memory DB. Подозреваем, что она, как и Greenplum, при достаточном объёме памяти в кластере умеет держать все или почти все данные в памяти, но предпочтение при выборе кандидатов отдавалось именно тем, кто позиционирует себя как in-memory.