Оно как раз для похожих задач сделано.

Всем привет! Подскажите пожалуйста, а выражение "... not in ( select ... from table)" рабочее? Что-то у меня не получается заставить это работать.

А как можно осуществлять эффективный поиск по многомерным массивам ?

Ну вариантов немного на самом деле - или функции высшего порядка или array join. Как вариант - их сочетание.

Ну вариантов немного на самом деле - или функции высшего порядка или array join. Как вариант - их сочетание.

Звучит как костыль, на самом деле многомерная Nested структура бы решила все проблемы, интересно все таки услышать от мейнтейнеров будет ли все таки реализована это фича

Всем привет! Подскажите пожалуйста, а выражение "... not in ( select ... from table)" рабочее? Что-то у меня не получается заставить это работать.

Привет! CREATE TABLE test ENGINE = Log AS SELECT arrayJoin([1, 2, 3]) AS a SELECT b, b NOT IN ( SELECT * FROM test ) FROM ( SELECT arrayJoin([1, 2, 3, 4]) AS b ) ┌─b─┬─notIn(b, _subquery1)─┐ │ 1 │ 0 │ │ 2 │ 0 │ │ 3 │ 0 │ │ 4 │ 1 │ └───┴──────────────────────┘

Всем привет! Подскажите пожалуйста, а выражение "... not in ( select ... from table)" рабочее? Что-то у меня не получается заставить это работать.

Должно быть рабочее. Если какой-то конкретный кейс не работает - покажите запрос. (там относительно недавно допиливали оптимизации, чтобы primary key использовался).

Звучит как костыль, на самом деле многомерная Nested структура бы решила все проблемы, интересно все таки услышать от мейнтейнеров будет ли все таки реализована это фича

Не понимаю в чем проблема :)

Привет! CREATE TABLE test ENGINE = Log AS SELECT arrayJoin([1, 2, 3]) AS a SELECT b, b NOT IN ( SELECT * FROM test ) FROM ( SELECT arrayJoin([1, 2, 3, 4]) AS b ) ┌─b─┬─notIn(b, _subquery1)─┐ │ 1 │ 0 │ │ 2 │ 0 │ │ 3 │ 0 │ │ 4 │ 1 │ └───┴──────────────────────┘

Спасибо за ответ! Мария, можете уточнить, а как not in использовать в секции where?

Спасибо за ответ! Мария, можете уточнить, а как not in использовать в секции where?

Также SELECT b FROM ( SELECT arrayJoin([1, 2, 3, 4]) AS b ) WHERE b NOT IN ( SELECT * FROM test ) ┌─b─┐ │ 4 │ └───┘

Также SELECT b FROM ( SELECT arrayJoin([1, 2, 3, 4]) AS b ) WHERE b NOT IN ( SELECT * FROM test ) ┌─b─┐ │ 4 │ └───┘

Супер! И последний вопрос, могут ли в массиве быть строки, а не числа?

Да, конечно

Не понимаю в чем проблема :)

Мне не очень нравится привязка данных к позиции, у меня планируется около 70 полей для вложенной структуры, смекаете ?)

А может вам подошел бы GraphiteMergeTree?

Сейчас почитаю Спсб

Мне не очень нравится привязка данных к позиции, у меня планируется около 70 полей для вложенной структуры, смекаете ?)

CREATE TABLE sessions ( sessionid UInt32, hits_hitid Array(UInt32), hits_productids Array(Array(UInt32)) ) Engine = MergeTree ORDER BY sessionid; INSERT INTO sessions VALUES ( 10, [101,102,103], [ [1011,1012,1013,1014], [1021,1022], [] ] ); INSERT INTO sessions VALUES ( 20, [201,202,203], [ [2011,2012,2013,2014], [2021,2022], [] ] ); SELECT sessionid, hitid, productid FROM ( SELECT sessionid, hitid, productids FROM sessions ARRAY JOIN hits_hitid as hitid, hits_productids as productids ) ARRAY JOIN productids as productid;

Мне не очень нравится привязка данных к позиции, у меня планируется около 70 полей для вложенной структуры, смекаете ?)

вам все равно надо будет разложить их в 70 колонок

Мне не очень нравится привязка данных к позиции, у меня планируется около 70 полей для вложенной структуры, смекаете ?)

Это диалог из жанра "ехать или шашечки". :)

вам все равно надо будет разложить их в 70 колонок

+1. Чтобы записать Nested-структуру по http, фактически формируется инсерт с несколькими колонками на каждую nested-колонку

Да, конечно

Мария, вот такой запрос не работает(отрабатывает, но в таблице есть дубликаты), вы не могли бы подсказать что я делаю не правильно: insert into table1 select ... from table2 where table2.id not in (select id from table1) group by table2.id

Мне не очень нравится привязка данных к позиции, у меня планируется около 70 полей для вложенной структуры, смекаете ?)

Кстати, попробуйте выполнить SHOW CREATE TABLE для таблицы содержащей Nested колонку :)

Это диалог из жанра "ехать или шашечки". :)

Не соглашусь с вами) сейчас у меня вся древовидная структура просто сложена в большую плоскую таблицу, и в принципе меня это устраивает , но меня мучает сомнения что nested структура будет работать быстрее

ну залейте так и так и проверьте

Не соглашусь с вами) сейчас у меня вся древовидная структура просто сложена в большую плоскую таблицу, и в принципе меня это устраивает , но меня мучает сомнения что nested структура будет работать быстрее

А как у вас получилось древовидную струкутуру запихать в большую плоскую таблицу? Т.е. в этом примере с сессиями-хитами-продуктами у вас столько строк сколько продуктов во всех хитах каждой сессии? Или как?

А как у вас получилось древовидную струкутуру запихать в большую плоскую таблицу? Т.е. в этом примере с сессиями-хитами-продуктами у вас столько строк сколько продуктов во всех хитах каждой сессии? Или как?

Все верно

Мария, вот такой запрос не работает(отрабатывает, но в таблице есть дубликаты), вы не могли бы подсказать что я делаю не правильно: insert into table1 select ... from table2 where table2.id not in (select id from table1) group by table2.id

А что значит "не работает"? Какой exception отдает БД?

Кстати, попробуйте выполнить SHOW CREATE TABLE для таблицы содержащей Nested колонку :)

Очень интересный момент

А что значит "не работает"? Какой exception отдает БД?

Никакой. Все вставляет, только в таблице есть дубликаты, а их быть не должно исходя из запроса.

Кстати, попробуйте выполнить SHOW CREATE TABLE для таблицы содержащей Nested колонку :)

Не буду вас пытать, почему для всех полей в Nested структуре у них тип array

Все верно

Тут все зависит от запросов. Если у вас для большинства запросов нужен самый глубокий элемент вашей древовидной структуры (т.е. в том примере - продукты), и база с этим справляется - то ничего менять не нужно. "Работает? - не трогай!".

У нас например значительно больше запросов выполняются на более высоких элементах этой структуры, и если бы мы попробовали все сделать плоско - то это требовало бы постоянных GROUP BY, и увеличивало бы количество строк раз в 10. Т.е. было бы больше данных, медленнее процессинг. Для нас такой вариант ну вообще никак не подходит.

Тут все зависит от запросов. Если у вас для большинства запросов нужен самый глубокий элемент вашей древовидной структуры (т.е. в том примере - продукты), и база с этим справляется - то ничего менять не нужно. "Работает? - не трогай!".

Это позиция на текущий момент, но с ростом количества данных, думаю не лучший вариант

У нас например значительно больше запросов выполняются на более высоких элементах этой структуры, и если бы мы попробовали все сделать плоско - то это требовало бы постоянных GROUP BY, и увеличивало бы количество строк раз в 10. Т.е. было бы больше данных, медленнее процессинг. Для нас такой вариант ну вообще никак не подходит.

Вы читаете мои мысли) поэтому и пришёл сюда с этим вопросом

Не буду вас пытать, почему для всех полей в Nested структуре у них тип array

Потому что Nested - это просто syntax sugar для набора таблиц, размер которых совпадает.

У нас например значительно больше запросов выполняются на более высоких элементах этой структуры, и если бы мы попробовали все сделать плоско - то это требовало бы постоянных GROUP BY, и увеличивало бы количество строк раз в 10. Т.е. было бы больше данных, медленнее процессинг. Для нас такой вариант ну вообще никак не подходит.

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

Потому что Nested - это просто syntax sugar для набора таблиц, размер которых совпадает.

Наконец то я понял о чем вы говорите) благодарю )

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

Ну вот на таком уровне где у вас большинство запросов и оставляйте стуктуру плоской. Т.е. просто добавить к хитам sessionid а продукты храните в массиве. И никаких проблем со вложенностью не будет.

Ну вот на таком уровне где у вас большинство запросов и оставляйте стуктуру плоской. Т.е. просто добавить к хитам sessionid а продукты храните в массиве. И никаких проблем со вложенностью не будет.

+1

Ну рандом всегда остается как запасной вариант, для него в принципе и SAMPLE BY не нужен (правда результаты будут недетерминированные если этот rand не хранить физически). Но часто например можно отсеять по какому-то иному признаку, например id пользователя.

Еще как вариант думаю завести materialized view и вставлять туда только 10% данных. На размере диска почти не скадется зато можно будет тяжелый запросы для которых точность не критична перенапрявлять туда. Норм идея?

Еще как вариант думаю завести materialized view и вставлять туда только 10% данных. На размере диска почти не скадется зато можно будет тяжелый запросы для которых точность не критична перенапрявлять туда. Норм идея?

Ну или matview в таблицу с GraphiteMergeTree :D

GraphiteMergeTree как я понял требует определенной структуры таблицы + материализованное представление мне понятнее и управление тем что туда должно вставляться как то через ДДЛ нагляднее

А массивы в аттрибутах внешних словарей не поддерживаются, я правильно понимаю?

А массивы в аттрибутах внешних словарей не поддерживаются, я правильно понимаю?

Правильно. См. https://github.com/yandex/ClickHouse/issues/2135

спасибо

люди, .NET-овский драйвер падает с ошибкой "Max query size exceeded"

где в доках прочитать про ограничение?\

https://github.com/yandex/ClickHouse/issues/2529#issuecomment-399884381

А materialized views можно из старых данных делать?

День добрый, Что может означать вот эта ошибка? И как с ней бороться? И если она происходит, то что происходит с данными? <Error> HTTPHandler: Code: 354, e.displayText() = DB::Exception: inflate failed: buffer error, e.what() = DB::Exception, Stack trace

А materialized views можно из старых данных делать?

Да, если добавить в команду создания MV слово POPULATE (пока MV будет создаваться, вставляемые в исходную таблицу данные не попадут в MV)

Да, если добавить в команду создания MV слово POPULATE (пока MV будет создаваться, вставляемые в исходную таблицу данные не попадут в MV)

О, спасибо!

Советую при использовании MV сначала создать обычную таблицу MergeTree со структурой запроса. И прицепить MV к этой таблице

Тогда вы сможете например отцепить MV, изменить таблицу и обратно прицепить MV

Угу, именно так и делаем, спасибо!

есть где подробные примеры по sequenceMatch и windowFunnel?

есть где подробные примеры по sequenceMatch и windowFunnel?

https://github.com/yandex/ClickHouse/search?l=SQL&q=sequenceMatch

спасибо, но мало ?

Господа, просто на всякий случай - а Кликхаус словари с сорсом в монгодб нормально работает с кластером?

есть где подробные примеры по sequenceMatch и windowFunnel?

https://docviewer.yandex.ru/view/159944842/?*=GTov%2FjRL1jAKOc7uWmTO0bmXRdB7InVybCI6InlhLWRpc2stcHVibGljOi8vbDdvd1hVaGw5bXdFUDlDTkU0YTBwNWhmYnRFaXVNTEQ1OGg4RzFsVHd1bz0iLCJ0aXRsZSI6IkNsaWNrSG91c2UgQmVybGluIDUuMTAuMjAxNyBNYW5zdXJvdmEucGRmIiwidWlkIjoiMTU5OTQ0ODQyIiwieXUiOiIyODU5MzIwMjIxNTI5MzI5Njc1Iiwibm9pZnJhbWUiOmZhbHNlLCJ0cyI6MTUyOTk4Nzg2NjM3Nn0%3D Здесь есть несколько примеров

спасибо

А скажите пожалуйста почему таймстампы в примерах хрянятся как числа а не как честные datetime. Есть какая-то хитрость?

ну таймстемп потому что число

ну таймстемп потому что число

А технически в этом есть преимущество какое-то? Просто я только учусь мыслить кликхаусом, у меня сейчас даты честные...

Ну таймстемп это число, везде, о каких преимуществах может идти речь?

очень удобно и нативно можно даты сортировать и вычитать. Это unixtime. И как бы, вы сами спрашиваете о таймстампе, это именно число

очень удобно и нативно можно даты сортировать и вычитать. Это unixtime. И как бы, вы сами спрашиваете о таймстампе, это именно число

Они и типизированные также сортируются а при вычитании секунды получаются...

Они и типизированные также сортируются а при вычитании секунды получаются...

unixtime можно в любом языке складывать и вычитать и не париться о тонкостях парсинга даты или ещё чему. Жизнь не только в кликхаусе существует

кликхаузный datetime всё равно инфу о часовых поясах не хранит, зато вы можете поиметь проблем, о чём в доке написано То есть, при работе с датой в виде текста (например, при сохранении текстовых дампов), следует иметь ввиду о проблемах с неоднозначностью во время перевода стрелок назад, и о проблемах с соответствием данных, при смене часового пояса.

кликхаузный datetime всё равно инфу о часовых поясах не хранит, зато вы можете поиметь проблем, о чём в доке написано То есть, при работе с датой в виде текста (например, при сохранении текстовых дампов), следует иметь ввиду о проблемах с неоднозначностью во время перевода стрелок назад, и о проблемах с соответствием данных, при смене часового пояса.

Вот с этим ужо воюю, вроде бы победил...

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

Вот я тоже все в utc. Только как datetime...

https://docviewer.yandex.ru/view/159944842/?*=GTov%2FjRL1jAKOc7uWmTO0bmXRdB7InVybCI6InlhLWRpc2stcHVibGljOi8vbDdvd1hVaGw5bXdFUDlDTkU0YTBwNWhmYnRFaXVNTEQ1OGg4RzFsVHd1bz0iLCJ0aXRsZSI6IkNsaWNrSG91c2UgQmVybGluIDUuMTAuMjAxNyBNYW5zdXJvdmEucGRmIiwidWlkIjoiMTU5OTQ0ODQyIiwieXUiOiIyODU5MzIwMjIxNTI5MzI5Njc1Iiwibm9pZnJhbWUiOmZhbHNlLCJ0cyI6MTUyOTk4Nzg2NjM3Nn0%3D Здесь есть несколько примеров

Ещё интересные статейки есть? Очень интересный пример, показано чем заменить оконные функции...

Коллеги, точно помню, что была функция вычисления гистограммы, но не могу найти ее

bar? https://clickhouse.yandex/docs/ru/functions/other_functions/#bar

да!

Всем привет. А как можно посмотреть, что именно тормозит insert? вставляю по http порциями по 600к строк. В логе межу событием <Debug> executeQuery: и следующим проходит около 20 секунд

так и не нашел где выставить max_query_size в настройках. в config.xml доавляю в корневой элемент yandex, рестартую клинхаус и пофиг

так и не нашел где выставить max_query_size в настройках. в config.xml доавляю в корневой элемент yandex, рестартую клинхаус и пофиг

нашел - надо в users

Всем привет! Начала расти память и пул-таски на кластере Кликхауса - вот скрин https://yadi.sk/i/RwkO1fqZ3YhuXg - а после и ноды начали падать совсем, и перестает отвечать БД. Нагрузка на кластер не выростала извне, количество запросов было такое же, как и примерно последние два месяца. Но вот сегодня что-то случилось непонятное. Может кто-то с таким сталкивался или есть примерные причины происходящего роста графиков и падений нод?

посмотрите логи и топ на сервере

Кстати, а вот чем можно объяснить такое:

Запросы на узлы раскидываются равномерно, объём места в этих репликах также изменяется синхронно, как и нагрузка на процессор.

Да, версия - 1.1.54381

После рестарта проблемного узла какое-то время всё нормально, потом снова начинается жор.

Регулярно с такой же проблемой сталкиваемся, и решения не нашли.

Выжирает память в ноль и падает

Регулярно с такой же проблемой сталкиваемся, и решения не нашли.

А какие настройки меняли?

Может какой то unlimit uncompressed cache стоит..

При попытки использовать DELETE для таблицы MergeTree пишет такую ошибку Received exception from server (version 1.1.54388): Code: 48. DB::Exception: Received from localhost:9000, ::1. DB::Exception: Mutations are not supported by storage MergeTree. Тогда вопрос: а для каких движков поддерживается DELETE?

ReplicatedMergeTree

А почему для MergeTree не поддерживается? Всмысле разве MergeTree и ReplicatedMergeTree не одного семейства?

А почему для MergeTree не поддерживается? Всмысле разве MergeTree и ReplicatedMergeTree не одного семейства?

Возможно он сохраняет данные в зукипере

в процессе удаления

Лично у меня настройки дефолтные в смысле кешей. То есть, лежит себе config.xml, а что надо - меняю в config.d Пока понадобилось поменять - listen, логирование, макросы и вообще репликацию и зукипер. Для пользователей поменял лимит по-умолчанию, чтоб запросы влазили в память.

Лично у меня настройки дефолтные в смысле кешей. То есть, лежит себе config.xml, а что надо - меняю в config.d Пока понадобилось поменять - listen, логирование, макросы и вообще репликацию и зукипер. Для пользователей поменял лимит по-умолчанию, чтоб запросы влазили в память.

А что поводу словарей? Может там утечка

Я к тому, что у нас когда то словари порождали зомби процессы

словарей нет