Найс, спасибо

И как у Александра дела — закончил он миграцию с Вертики на КХ?

https://mariadb.com/products/mariadb-columnstore

http://greenplum.org/ еще есть на основе постгреса

Мужчина из крупной мебельной компании задаёт жёсткие вопросы )

А что случилось с DELETE? Его сломали?

его не было

угу. есть только ALTER TABLE DROP PARTITION

И как у Александра дела — закончил он миграцию с Вертики на КХ?

так на highload же рассказывал, вот только там много НО было

роадмап скромный, были же еще апдейты заявлены, оконные функции )

вообще, до сих пор вроде видео нет, а очень бы хотелось посмотреть

вообще, до сих пор вроде видео нет, а очень бы хотелось посмотреть

Видео с предыдущего митапа технически готово. Должны скоро выложить наружу.

Видео с предыдущего митапа технически готово. Должны скоро выложить наружу.

спасибо вам за все! :3

И как у Александра дела — закончил он миграцию с Вертики на КХ?

Пока нет, по не зависящим от Кликхауса причинам.

так на highload же рассказывал, вот только там много НО было

Эти "но" для неофитов. Они усложняют работу с КХ для людей, привыкших к полноценным RDBMS. Приходится изобретать. Но непреодолимых "но" как не было, так и нет

Чем можно объяснить, что фулскан селект (в запросе нет where) по полям, которых нет в ключе, выполняется дольше на более жирном ключе, чем на коротком, хотя по данным из гугл.групс длина ключа тут вообще никак не должна влиять? Есть две одинаковые по данным таблицы, разница только в ключе - в первой он (advertiser_id, date, sample_id), во второй - (advertiser_id, sample_id). Запрос выглядит так: select argMax(pad_id, u), max(u) from (select pad_id, uniq(user_id) as u from events group by pad_id). На первой таблице он выполняется за 29 сек, на второй - за 20. Кэш прогрет, беру времена самого быстрого из трех запросов, после первого запроса чтения с диска уже не производится. Аналогичные результаты и в случае, если pad_id заменить здесь на advertiser_id, т.е. использовать поле из ключа, но только первое.

Данные занимают одинаковый размер на диске? Возможно (хотя и маловероятно), что после сортировки по одному из вариантов ключа, данные сжались лучше. Таблицы на одном сервере? Насколько отличается разбиение на "куски": SELECT * FROM system.parts WHERE active AND table = '...'

Данные занимают разный размер. Таблица с более жирным ключом занимает 161 Гб, с коротким - 81 Гб. OPTIMIZE TABLE делал обеим таблицам. Разница выглядит слишком большой, а полей в таблице много. Загляну-ка, что там внутри. Таблицы на одном сервере. В каждой упомянутый селект выдает по одной записи (по одной партиции), данных там неделя, лежат в пределах одного месяца.

В данных странное - колонки advertiser_id одинакового размера, а вот все остальные колонки в первой жирной таблице раза в два больше, чем во второй.

Особенно sample_id.bin отличается - 27450М против 4777M.

А date.bin - единственное поле, которое в первой таблице на порядок меньше, чем во второй - видимо, как раз за счет отсортированности в ключе.

Данные в таблицах реально одинаковые или разные? Количество строк, хотя бы.

Данные одинаковые. Обе таблицы наливались через INSERT into SELECT * FROM - из третьей таблицы. Количество строк одинаково, все запросы выдают одинаковые результаты.

Еще интересный, с моей точки зрения, момент, что изначально у меня была таблица на 1 день, и занимала она 20 Гб. Я ее размножил в 7 раз, делая 7 раз в другую таблицу с идентичным описанием запросом insert from (select ...) из исходной, где при селекте к timestamp прибавлял N * 86400, и полученная таблица стала занимать 192 Гб (сама, после всех мерджей, и такой же размер остался после OPTIMIZE TABLE), т.е. она выросла более, чем в 7 раз.

В первом случае, если sample_id - довольно тяжёлый столбец, то он лучше сожмётся в случае ключа (advertiser_id, sample_id) чем (advertiser_id, date, sample_id) из-за более локального расположения.

Еще интересный, с моей точки зрения, момент, что изначально у меня была таблица на 1 день, и занимала она 20 Гб. Я ее размножил в 7 раз, делая 7 раз в другую таблицу с идентичным описанием запросом insert from (select ...) из исходной, где при селекте к timestamp прибавлял N * 86400, и полученная таблица стала занимать 192 Гб (сама, после всех мерджей, и такой же размер остался после OPTIMIZE TABLE), т.е. она выросла более, чем в 7 раз.

Здесь возможно, если данные почему-то оказались больше перемешаны для каждого фиксированного значения первичного ключа. То есть, сжатие всё объясняет. Но на реальных кейсах такое поведение встречается редко.

Вероятно, это может все объяснить. Спасибо.

Чем вам zk не нравится то всем?

Всерьёз спрашиваю

ZK в кликхаусе много для чего. Leader election, распределённый транзакционный kv, всякие listeners

У нас в Метрике огромные zk и особл проблем с ними нет

Немного неудобно, это правда, свои проблемы есть

Но надежность как у гаечного ключа хорошего

Соглашусь, zk норм, работает.

Устанавливается тяжело. И неудобно, да. И религиозные соображения - из исходников его трудно собрать (на грани невозможного).

Витя, насколько я понял zk сложнее настроить у некоторых с этим проблемы. Просили даже показать как вы в метрике его используете, с какими опциями.

У нас тоже никаких проблем с ZK. Тонкости есть, скажем, cross-dc, но сам ZK работает замечательно

ну наверное проблема в том, что он не модный не молодежный

вот если бы на GO

ну крайняк на Rust, то может быть

у меня связка ZK+Kafka+Flink+ES молотит > 15000 документов в секунду

на 3-ех узлах невыдающихся

Flink сам консьюмит с кафки? У него нормально с ребалансингом и коммитами?

Пока нет, по не зависящим от Кликхауса причинам.

Александр, вы, оказывается, уже в этом чатике! А какой tool используют ваши аналитики для собственного ad hoc анализа данных в КХ? Они освоили его SQL?

ну наверное проблема в том, что он не модный не молодежный

Кстати о птичках — на zk работает кластеризация вполне коммерческого софта — Tableau Server. Но zk там хорошо скрыт под капотом, практически не требует администрирования. Так что наверное дело не в молодежности, а в необходимости разбираться в дополнительной софтине с собственной логикой и скелетами в шкафу. https://onlinehelp.tableau.com/current/server/en-us/server_process_coordination.htm #tableau

Flink сам консьюмит с кафки? У него нормально с ребалансингом и коммитами?

Да сам. Пока проблем не замечали в этой части.

> @roman_kolchin Александр, вы, оказывается, уже в этом чатике! А какой tool используют ваши аналитики для собственного ad hoc анализа данных в КХ? Они освоили его SQL? У нас собственный middleware (на Scala), который генерирует SQL запросы. Его пришлось полностью переписать под КХ, чтобы заменить обычные SQL-джойны на вложенные и словари.

> @roman_kolchin Александр, вы, оказывается, уже в этом чатике! А какой tool используют ваши аналитики для собственного ad hoc анализа данных в КХ? Они освоили его SQL? У нас собственный middleware (на Scala), который генерирует SQL запросы. Его пришлось полностью переписать под КХ, чтобы заменить обычные SQL-джойны на вложенные и словари.

Спасибо. Он у вас чисто графический? График -> SQL -> КХ?

Нет, больше как раз таблицы. middleware выдает клиенту json или csv (несколько форматов), который дальше используется UIем или напрямую другими системами

Графики тоже, конечно, можно построить, но это уже мелочи

А каким образом клиенты запросы формируют? У вас есть какой-то птичий язык для этих целей?

Или вручную заранее настроенные sql запросы, которые зашиты в middleware?

Ну можно скзать, что птичий язык. Есть API, через который передаются набор измерений, метрик, фильтров и проч

Если Scala/JVM, то olap4j случайно не используете?

Нет, все самописное

Нет, все самописное

Молодцы вы. А я все мечтаю, что MDX когда-нибудь над КХ появится :) Через Mondrian хотя бы, но с блэкджеком, словарями и использованием массивов в запросах чтоб все очень быстро :)

Вчера на митапе звучало предложение об MDX. Но это после нормальных джойнов

Вчера на митапе звучало предложение об MDX. Но это после нормальных джойнов

Очень интересно! Кто-то уже пытается сделать? Или это был запрос к разработчикам КХ?

Я изучал этот вопрос _теоретически_ — на первый взгляд сейчас уже всего хватает (словари + словарные функции + массивы), чтобы сделать эффективную трансляцию. Эффективную — в смысле трансляции развезистой клюквы большого mdx-запроса в единственный однопроходный запрос к базе, без лишних union'ов. Но транслятор нужен именно под синтаксис КХ.

Join'ы не помогут сами по себе. Синтаксически мб и заработает, но лагать будет дико из-за большого количества вложенных запросов и кучи union'ов.

Это был вопрос к Яндексу. Странслировать MDX в CH-SQL (назовем это так) не должно быть слишком сложно

ERROR: S client not available

Это был вопрос к Яндексу. Странслировать MDX в CH-SQL (назовем это так) не должно быть слишком сложно

Вопрос бюджета времени :) У меня его нет, к сожалению.

Это тоже один из вопросов, которые обсуждали :) Все просят Яндекс, сделайте то, сделайте это, но мало кто контрибьютит сам

Посмотрите, вот интересный продукт: https://github.com/Wondersoft/olaper Автор говорит, что есть желание сделать интеграцию с ClickHouse.

Это тоже один из вопросов, которые обсуждали :) Все просят Яндекс, сделайте то, сделайте это, но мало кто контрибьютит сам

С++ сложно. Чтобы контрибьютить кто-то должен на нем писать и одновременно решать задачи анализа в рамках своей работы или долгоиграющего хобби :)

Посмотрите, вот интересный продукт: https://github.com/Wondersoft/olaper Автор говорит, что есть желание сделать интеграцию с ClickHouse.

Я общался с ним на прошлом митапе. В тои числе уговаривал сделать трансляцию :)

Насколько я его понимаю, ему нужен клиент, под которого это можно изначально сделать, а потом отдать всем. Так как проект не самый простой, а ресурсов работать забесплатно у его компании нет.

Посмотрите, вот интересный продукт: https://github.com/Wondersoft/olaper Автор говорит, что есть желание сделать интеграцию с ClickHouse.

Кстати, если к КХ появится интерфейс XMLA (то, что дает olaper), то после этого с помощью http://www.arquery.com/ArqueryXMLAConnector можно будет работать с КХ из сводных таблиц Excel.

Насколько я его понимаю, ему нужен клиент, под которого это можно изначально сделать, а потом отдать всем. Так как проект не самый простой, а ресурсов работать забесплатно у его компании нет.

Это всегда ключевое условие — вопрос и финансирования ну и отладки на реальной задаче. Разработчик olaper'а использует его в своей компании в качестве middleware под Saiku или чем-то подобным. Но с его же слов там реализован минимальный набор лексики MDX. Поэтому olaper нужно будет сильно допиливать не только для поддержки КХ, но и для увеличения возможностей MDX.

Насколько я его понимаю, ему нужен клиент, под которого это можно изначально сделать, а потом отдать всем. Так как проект не самый простой, а ресурсов работать забесплатно у его компании нет.

А в вашей конторе не нужен такой olaper? Как я понимаю, Алексей (разработчик olaper'а) — ваш бывший коллега :) Договоритесь :)

Нет, нам не нужен, мы не используем MDX

Коллеги, привет. У нас внешние словари имеют ключи guid'ы. Можно ли как-то их подключить?

Кстати об аналитике. Тут проскакивало про поддержку clickhouse в redash. Кто-нить пробовал? Я попробовал кучу разных ревизий (после той, в которой вмерджили КХ). Везде все разломано (ошибки js, неработающий функционал и тд.). Может только у меня такие проблемы?

Пока там все кривовато и в каждой ревизии что-то может не работать. Я себе оставил коммит после мержа поддержки clickhouse на время фиксов. Полностью туда мы перейдем после появления функционала склейки запросов из разных источников. )

Коллеги, привет. У нас внешние словари имеют ключи guid'ы. Можно ли как-то их подключить?

Есть незадокументировнный способ :) Но раскрытие незадокументированных возможностей -- это почетная обязанность Алексея

мы для uuid-ов воткнули две строчки, которые превращают uuid в FixedString(16) и обратно

но вот для primary key — эт нет

Коллеги, привет. У нас внешние словари имеют ключи guid'ы. Можно ли как-то их подключить?

Можно использовать complex_key-словари. Они поддерживают произвольные типы ключей. Словари по составному ключу: Конфиг словаря с составным ключом отличается двумя вещами: В качестве layout указывается complex_key_hashed или complex_key_cache. Указывается несколько атрибутов в structure/key. Пример: <layout> <complex_key_hashed /> </layout> <structure> <key> <attribute> <name>uid</name> <type>UInt64</type> </attribute> <attribute> <name>order_id</name> <type>UInt32</type> </attribute> </key> <attribute> <name>has_access</name> <type>UInt8</type> <null_value>0</null_value> </attribute> </structure> Для использования словаря с составным ключём, в функции для работы со словарями, в качестве аргумента-ключа передаётся кортеж. Пример: dictGetString('dict', 'attr', (k1, k2)). В качестве элементов ключа, поддерживаются произвольные типы данных (в том числе, строки). Не смотря на название, complex_key_-словарь может иметь и один компонент в качестве ключа. То есть, не составной ключ. При этом, в отличие от обычных словарей, этот ключ может иметь любой тип. В этом случае, в функции для работы со словарями, нужно передавать кортеж из одного элемента. Пример: dictGetString('dict', 'attr', tuple(k)). - как видно, для описания кортежа из одного элемента, используется функция tuple. Для типов UInt32 и подобных, я не рекомендую использовать complex_-словари, так как это будет менее эффективно, чем обычные. А вот для типа String или составного - вполне.

Подскажите, а как можно посчитать median() в CollapsingMergeTree без использования модификатора FINAL ?

Можно использовать complex_key-словари. Они поддерживают произвольные типы ключей. Словари по составному ключу: Конфиг словаря с составным ключом отличается двумя вещами: В качестве layout указывается complex_key_hashed или complex_key_cache. Указывается несколько атрибутов в structure/key. Пример: <layout> <complex_key_hashed /> </layout> <structure> <key> <attribute> <name>uid</name> <type>UInt64</type> </attribute> <attribute> <name>order_id</name> <type>UInt32</type> </attribute> </key> <attribute> <name>has_access</name> <type>UInt8</type> <null_value>0</null_value> </attribute> </structure> Для использования словаря с составным ключём, в функции для работы со словарями, в качестве аргумента-ключа передаётся кортеж. Пример: dictGetString('dict', 'attr', (k1, k2)). В качестве элементов ключа, поддерживаются произвольные типы данных (в том числе, строки). Не смотря на название, complex_key_-словарь может иметь и один компонент в качестве ключа. То есть, не составной ключ. При этом, в отличие от обычных словарей, этот ключ может иметь любой тип. В этом случае, в функции для работы со словарями, нужно передавать кортеж из одного элемента. Пример: dictGetString('dict', 'attr', tuple(k)). - как видно, для описания кортежа из одного элемента, используется функция tuple. Для типов UInt32 и подобных, я не рекомендую использовать complex_-словари, так как это будет менее эффективно, чем обычные. А вот для типа String или составного - вполне.

Спасибо! Но все-таки guid является не строкой, а отдельным типом данных (да и места меньше занимает). Планируется ли их полноценная поддержка?

Как отдельного типа данных - нет. Но недавно добавили возможность удобного преобразования из бинарного вида FixedString(16) в текст и обратно.

ага, нашел. Спасибо. А вам лично удалось запустить кликхаус в докере?

У нас в докере работает

Если есть желание, можно здесь нажать на upvote: https://news.ycombinator.com/item?id=13183758 Мелочь, а может быть человеку будет приятно.

я думаю помочь ему в разработке, sqlalchemy всяко популярнее самописной clickhouse-orm

блин, а там она и используется %))

Подскажите, а как можно посчитать median() в CollapsingMergeTree без использования модификатора FINAL ?

Наверное, никак.

спасибо, тоже так думал- искал пути решения, но вдруг есть скрытый "ход") еще вопрос, про ЯМ, у нас хранится значение, допустим сколько пользователь провел времени на странице - аналогичное ЯМ, и каждые 15 секунд это значение схлопывается и увеличивается в рамках сессии, получается если в ЯМ тоже каллапс движек - вы считаете через "avg" т.е sum(sign).... ?

Да, через sum(x * sign) / sum(sign).

спасибо!

Вот это отличный вопрос кстати

Подскажите, а как можно посчитать median() в CollapsingMergeTree без использования модификатора FINAL ?

Выглядит так что действительно никак, но можно попробовать придумать