меня бы спас обычный LEFT JOIN, если бы можно было как-то к массиву присоединять результат запроса, а не наоборот

ну или RIGHT ARRAY JOIN видимо

если бы он был

Можете кстати запустить этот скрипт из тестов https://github.com/yandex/ClickHouse/tree/master/dbms/tests/integration/test_distributed_ddl Он создает в докере настроенный кластер на 4 хоста. Можете помучать его. Только для скрипта нужны prerequisites: https://github.com/yandex/ClickHouse/blob/master/dbms/tests/integration/README.md

Спасибо за идею ) А почему может возникать ошибка AttributeError: ClickHouseCluster instance has no attribute 'pm_random_drops'

test_distributed_ddl/test.py:124: AttributeError

Спасибо за идею ) А почему может возникать ошибка AttributeError: ClickHouseCluster instance has no attribute 'pm_random_drops'

Заккоментите эту строчку. У вас кластер почему-то не инициализируется

Всем привет. Подскажите, можно ли как-то сделать LEFT JOIN с массивом? Если более конкретно, то нужно вывести результат группировки например за каждый час. Понятно, что если в каком-то часе не было событий, то в результате запроса не будет этого часа, а нужно вернуть для него 0. Как вариант пытаюсь приджойнить результат запроса к массиву всех часов, но не понимаю как это правильно сделать. ARRAY JOIN делает судя по всему только INNER JOIN, и поэтому результат получается одинаковый что с ним, что без него.

если у вас в сутках 24 часа, то можно сделать так SELECT toDateTime('2017-08-01 00:00:00') + h*3600 AS h FROM ( SELECT number AS h FROM system.numbers LIMIT 48 )

если у вас в сутках 24 часа, то можно сделать так SELECT toDateTime('2017-08-01 00:00:00') + h*3600 AS h FROM ( SELECT number AS h FROM system.numbers LIMIT 48 )

спасибо, похоже то, что нужно

в общем мне нужен был не массив, а system.numbers)

хм, выж про join спрашивали :) но вообще можно вот так ещё SELECT toDateTime('2017-08-01 00:00:00') + (arrayJoin(range(48)) * 3600) AS h;

ну так я сделаю запрос к system.numbers и приджойню к результату результат своего запроса

всё получилось, супер, @orantius спасибо огромное еще раз!

Кстати, а добавьте плиз, про FREEZE PARTITION в доку по миграции с MergeTree в ReplicatedMergeTree. нам очень повезло, что мы этот баг поймали на маленькой тестовой табличке.

Попробовали перенести покрупнее табличку с использыванием freeze partition, и опять задублировались данные за последние сутки

Лог скрипта Move parts: - /var/lib/clickhouse/shadow/3/data/Web/Stats/20170703_20170731_2_15156_426 - /var/lib/clickhouse/shadow/3/data/Web/Stats/20170801_20170816_15158_23321_253 - /var/lib/clickhouse/shadow/3/data/Web/Stats/20170816_20170821_23322_24919_138 - /var/lib/clickhouse/shadow/3/data/Web/Stats/20170821_20170824_24920_25784_102 - /var/lib/clickhouse/shadow/3/data/Web/Stats/20170824_20170825_25785_26029_82 - /var/lib/clickhouse/shadow/3/data/Web/Stats/20170824_20170825_25785_26030_83 - /var/lib/clickhouse/shadow/3/data/Web/Stats/20170825_20170825_26030_26030_0 - /var/lib/clickhouse/shadow/3/data/Web/Stats/20170825_20170825_26031_26031_0 - /var/lib/clickhouse/shadow/3/data/Web/Stats/20170825_20170825_26032_26032_0 - /var/lib/clickhouse/shadow/3/data/Web/Stats/20170825_20170825_26033_26033_0 - /var/lib/clickhouse/shadow/3/data/Web/Stats/20170825_20170825_26034_26034_0 Attach parts: - /var/lib/clickhouse/data/Web/Stats/20170703_20170731_2_15156_426 - /var/lib/clickhouse/data/Web/Stats/20170801_20170816_15158_23321_253 - /var/lib/clickhouse/data/Web/Stats/20170816_20170821_23322_24919_138 - /var/lib/clickhouse/data/Web/Stats/20170821_20170824_24920_25784_102 - /var/lib/clickhouse/data/Web/Stats/20170824_20170825_25785_26029_82 - /var/lib/clickhouse/data/Web/Stats/20170824_20170825_25785_26030_83 - /var/lib/clickhouse/data/Web/Stats/20170825_20170825_26030_26030_0 - /var/lib/clickhouse/data/Web/Stats/20170825_20170825_26031_26031_0 - /var/lib/clickhouse/data/Web/Stats/20170825_20170825_26032_26032_0 - /var/lib/clickhouse/data/Web/Stats/20170825_20170825_26033_26033_0 - /var/lib/clickhouse/data/Web/Stats/20170825_20170825_26034_26034_0

- /var/lib/clickhouse/shadow/3/data/Web/Stats/20170824_20170825_25785_26029_82 - /var/lib/clickhouse/shadow/3/data/Web/Stats/20170824_20170825_25785_26030_83

Опять дубль

т.е. получается даже бекапы делать не безопасно при включенном КХ?

A call to function range would produce 325119609 array elements, which is greater than the allowed maximum of 100000000. - подскажите плиз а вот этот лимит можно как-то поднять? Не увидел в конфиге опции, может плохо смотрел.

а вы поодиночке парты аттачили?

да

Сейчас devops Сергей подробнее все расскажет.

Это я, всем привет

Попробуйте сразу сделать ATTACH PARTITION 201708, а не поодиночке ATTACH PART. Он должен сам разобраться, в каких партах дублируются данные и всё сделать правильно.

А год сразу можно?

нет, только по одной партиции

Хорошо, спасибо, будем пробовать

zookeeper то стоит?

Стоит

и в логах не орет что он анричебл

Все хорошо в логах

Просуммирую Есть, очень грубо говоря, биржевые котировки Они образуют четырехмерное пространство 1. Ось времени 2. Ось - id грубо говоря акции 3. Ось - название поля (цена, цена открытия, цена закрытия) 4. Ось - resolution (по определенным причинам нужно их хранить раздельно, можете считать это просто категориальным признаком) cardinaliry оси 1 - сотни-тысяч - единицы миллионов cardinality оси 2 - порядка 200-300 тысяс cardinality оси 3 - меньше тысячи (сотни) cardinality оси 4 - около десятка Значения - integer, float, string, зависит от оси (3) Нужно придумать схему хранения в clickhouse, с учетом ее сильных и слабых сторон Судя по всему, заводить отдельную табличку на каждое значение оси (4) - хорошая идея, отлично, минус одно измерение Дальше можно ось (3) развернуть в колонки - отлично, минус еще одно измерение Остаются ось времени и ось инструмента, их я не понимаю как разложить правильно Складывать тройками (timestamp, security_id, value)?

Запросы - запись серии в точке (security_id, field_name, resolution), т.е. доливается timeseries (date_from, date_to) пар (timestamp, value)

Чтение профиль 1 - выборко по множеству security_id (от 1 до 20-50 штук в запросе), один field_name, time_from, time_to

Чтение профиль 2 - выборка по множеству security_id (от 1 до 20-50 штук в запросе), по множеству field_name (1-пара сотен), timestamp - узкий диапозон

Вроде все важное описал, если каких-то данных не хватает, спрашивайте ?

Есть дубовый вариант - одну табличку, в нее положить колонками (timestamp NOT NULL, security_id NOT NULL, filed_name NOT NULL, string_value, float_value, integer_value) Либо три таблички (timestamp NOT NULL, security_id NOT NULL, filed_name NOT NULL, value string NOT NULL) (timestamp NOT NULL, security_id NOT NULL, filed_name NOT NULL, value float NOT NULL) (timestamp NOT NULL, security_id NOT NULL, filed_name NOT NULL, value integer NOT NULL)

Моего понимания и опыта clickhouse для принятия взвешенного решения не хватает, прошу помощь зала ?

Заккоментите эту строчку. У вас кластер почему-то не инициализируется

Собрал тестовый кластер (из теста ) - на нем все хорошо отрабатывает DROP TABLE IF EXISTS default.asdasdasd ON CLUSTER cluster и не падает )

Собрал тестовый кластер (из теста ) - на нем все хорошо отрабатывает DROP TABLE IF EXISTS default.asdasdasd ON CLUSTER cluster и не падает )

Там скорее всего проблема в том, что сама таблица имеет сложную конфигурацию (например temporary + MV, смотрящий на другой MV) и при удалении что-то неправильно обрабатывается

Там скорее всего проблема в том, что сама таблица имеет сложную конфигурацию (например temporary + MV, смотрящий на другой MV) и при удалении что-то неправильно обрабатывается

Получилось ) Тест отправляем в цикле раз 100 запрос с DROP TABLE с таймаутом в curl 0.01 sec - т/е не дожидаемся ответа от CH

Сейчас одна тестовая нода вылетела

погоняю, соберу ошибки - сделаю issue

Там скорее всего проблема в том, что сама таблица имеет сложную конфигурацию (например temporary + MV, смотрящий на другой MV) и при удалении что-то неправильно обрабатывается

идея в том что таблицы никогда не было, т.е ее не создавал я и отправляю drop как бы в пустоту

Просуммирую Есть, очень грубо говоря, биржевые котировки Они образуют четырехмерное пространство 1. Ось времени 2. Ось - id грубо говоря акции 3. Ось - название поля (цена, цена открытия, цена закрытия) 4. Ось - resolution (по определенным причинам нужно их хранить раздельно, можете считать это просто категориальным признаком) cardinaliry оси 1 - сотни-тысяч - единицы миллионов cardinality оси 2 - порядка 200-300 тысяс cardinality оси 3 - меньше тысячи (сотни) cardinality оси 4 - около десятка Значения - integer, float, string, зависит от оси (3) Нужно придумать схему хранения в clickhouse, с учетом ее сильных и слабых сторон Судя по всему, заводить отдельную табличку на каждое значение оси (4) - хорошая идея, отлично, минус одно измерение Дальше можно ось (3) развернуть в колонки - отлично, минус еще одно измерение Остаются ось времени и ось инструмента, их я не понимаю как разложить правильно Складывать тройками (timestamp, security_id, value)?

мне кажется что неплохим вариантом для начала будет таблица security_id time field_1 field_2 ...т.е. "широкая" таблица с типизированной схемой, если у вас количество полей более менее стабильная величина. date(time) добавить в mergetree в то место, где требуется дата, и (security_id, time) в ключ.

@orantius проблема в том, что у нас разные типы security (они внутри бьются еще на двадцать классов) работают с разными полями - во-первых, набор полей, нужных для работы (добавляемых и удаляемых) достаточно активно меняется

Идеальная модель - четырехмерный гиперкубик

Вот prometheus хранит данные почти как нужно https://github.com/s4z/prom2click

Но там в качестве тэгов используется Array(String), а документация clickhouse говорит о том, что это не самый поддерживаемый тип данных

Вопрос можно так переформулировать: каким образом мне четырехмерный кубик засунуть в одну табличку в clickhouse? ?

Но там в качестве тэгов используется Array(String), а документация clickhouse говорит о том, что это не самый поддерживаемый тип данных

По нему вроде индекс сделать нельзя :)

А мне без индексов смерть будет ?

Или можно но будет как то не очень

Вопрос можно так переформулировать: каким образом мне четырехмерный кубик засунуть в одну табличку в clickhouse? ?

Четыре колонки. Ваш кэп

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

Данных то сколько

@orantius проблема в том, что у нас разные типы security (они внутри бьются еще на двадцать классов) работают с разными полями - во-первых, набор полей, нужных для работы (добавляемых и удаляемых) достаточно активно меняется

тогда я бы перешел к "дубовый вариант - одну табличку"

Виктор, я там выше написал 1. Ось времени 2. Ось - id грубо говоря акции 3. Ось - название поля (цена, цена открытия, цена закрытия) 4. Ось - resolution (по определенным причинам нужно их хранить раздельно, можете считать это просто категориальным признаком) cardinaliry оси 1 - сотни-тысяч - единицы миллионов cardinality оси 2 - порядка 200-300 тысяс cardinality оси 3 - меньше тысячи (сотни) cardinality оси 4 - около десятка Значения - integer, float, string, зависит от оси (3)

Я видел, это не ответ

Сколько уникальных ключей по этим четырём осям?

Если перемножить cardinality - вы получите суммарную мощность множества

Ну по факту это же не так

Плюс-минус так

Фактически - сколько?

а сотни тысяч - единицы миллионов - это количество секунд в году, или там какая частота?

минут в течении рабочего дня биржи - 60*8*255 в год тут по-разному, от года до 30 лет

Виктор, вы в каких единицах ответ хотите услышать? Я считал суммарный объем данных - получается в бинарном пожатом виде будет от 10 до 50-70 терабайт

Такая волатильность потому, что эту подсистему активно развивают

Во, отлично, спасибо

Это будет кластеризованных совершенно точно

Тогда 1 и 2 в столбцы в ключ, 3 и 4 в разные колонки, думаю так

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

То есть под каждое значение 3 сделать колонку

Я бы так попробовал залить и посчитать типичные запросы

значения из оси три часто добавляются и исчезают

Мне бы тут family columns

Залить данные там отдельная история... Например, их высосать денег стоит, и хранить их где-то в сыром виде тоже нужно для экспериментов...

Понятно, что будут испытания

Тогда сделайте 1,2,3 в столбцы

Попробуйте так

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

Да, вы правы. Я понял, в качестве эксперименат попробую семплированную выборку с (1,2,3) в столбцах и 4 в виде колонок (либо даже таблиц разных, его так можно)

Спасибо большое за советы!

значения из оси три часто добавляются и исчезают

а как по ним тогда понять какого они типа? кардинальность сотни это типичное количество определенных атрибутов у одной точки или это исторически количество всех возможных атрибутов за какой-то диапазон времени?

"а как по ним тогда понять какого они типа?" У каждого field есть его тип данных, это тайное скаральное знание, которое достается из документации платного (очень платного) data provider Команда финансистов/математиков по этим данным считает всякие штуки, моя команда эти прототипы интегрируют в бой Математики играются на семплах, моя команда в проде - на полном множестве Ну т.е. у меня прописывается, что поле LAST_PRICE - это float, а поле VOLUME - это integer, и вот таких полей примерно 600-700 различных (у облигацией штук 500, у акций 200, у ETF'ов - 70-80, они частично пересекаются) "кардинальность сотни это типичное количество определенных атрибутов у одной точки или это исторически количество всех возможных атрибутов за какой-то диапазон времени?" Второе. Количество уникальных значений во всем множестве (не в одной точке)

Представьте четырехмерный кубик с указанными мною осями, он не dense, но и не sparse, точнее, в нем есть несколько dense областей, в зависимости от типа инструмента

В каждой точке кубика - типизированное знаение - float, integer либо string

Можно так еще сказать: есть APPL US EQUITY (компания Apple), и вот есть timeseries его цены на бирже с мининутным разрешением

Это срез кубика security_id=AAPL US EQUITY, field_name=LAST_PRICE, дальше для каждого timestamp (время наблюдения) есть float (значение цены)

то есть ваши 700 волшебных полей заранее известны и за ближайший год сильно не изменятся?

А, ну еще четвертый атрибут - resolution, в данном случае ONE_MINUTE

Поля известны заранее, но меняется в среднем 2-3 раза в неделю

По мере разработки

Т.е. альтерить таблицу несколько раз в месяц очень не хочется

Можно как-то организационно решить, это одна из опций - тогда действительно все колонками можно решить, НО!

Вот у корпоративных облигаций 500 полей

450 из них нужны только облигациям

Если их вытащить в табличку - она будет bloated, да, clickhouse хранит поколоночно и для акций, например, там будут null'ы

Но как-то все равно это неаккуратно