Нет

это печально, синтаксис, когда хост отдельно, а порт отдельно полностью инопланетянский и неудобный

@proller а ты не задокументировал свои добавления к distributed, чтобы пользоваться им через ssl?

это печально, синтаксис, когда хост отдельно, а порт отдельно полностью инопланетянский и неудобный

так исторически сложилось, но сделать новый вариант не сложно

@proller а ты не задокументировал свои добавления к distributed, чтобы пользоваться им через ssl?

в Changelog нашел, а в документации нет

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

это очень облегчает жизнь

@proller а ты не задокументировал свои добавления к distributed, чтобы пользоваться им через ssl?

Нет

Привет! Где-нибудь можно почитать сравнение реализации SQL в CH со стандартом ANSI SQL 2008 (или другого года)?

Привет! Где-нибудь можно почитать сравнение реализации SQL в CH со стандартом ANSI SQL 2008 (или другого года)?

Я думаю что сравнивать бесполезно, т.к. в CH слишком "своя" реализация напоминающая SQL. Тут больше подойдет название "SQL подобный" синтаксис запросов

Понятно. Вот в особенностях в доках написано "отсутствие полноценных транзакций". А что, какие-то подобия есть?

В ClickHouse нет полноценных транзакций, тем не менее, есть свойства транзакционности, которые позволяют записывать данные надёжно. Так, каждый INSERT атомарен (с размером батча до 1 млн. строк по-умолчанию).

Алексей, то есть если будет в батче больше 1млн строк, то атомарность INSERT-а не будет работать? Тут не совсем понятно

Алексей, то есть если будет в батче больше 1млн строк, то атомарность INSERT-а не будет работать? Тут не совсем понятно

Будет, размер блока может быть любым

Можно ли как-то организовать вставку в Distributed таблицу не перечисляя все поля таблицы (для некоторых есть DEFAULT)? Перестало работать после определения insert_distributed_sync=1 Сейчас выдает Code: 171. DB::Exception: Received from localhost:9001, 127.0.0.1. DB::Exception: Block structure mismatch in RemoteBlockOutputStream stream: different number of columns:

Будет, размер блока может быть любым

Спасибо, но всё равно непонятно, к чему там в реплае оговорка про 1 млн строк... Типа SELECT по умолчанию может отставать на 1млн записей, ещё не подтверждённой записи недавних данных?

подскажите, мутации поддерживаются для SummingMergeTree? если да, то с какой версии?

Да, поддерживаются (никакой специальной логики для Summing нет). DELETE с версии 18.1.0, UPDATE с 18.12.14.

Коллеги, всем привет! Недавно начали только использовать ClickHouse ищем специалиста который может поконсультировать на платной основе нашу разработку на предмет правильности использования и тонкостей настройки

Спасибо, но всё равно непонятно, к чему там в реплае оговорка про 1 млн строк... Типа SELECT по умолчанию может отставать на 1млн записей, ещё не подтверждённой записи недавних данных?

потому что параметр по умолчанию раверн 1млн t.me/clickhouse_ru/63449

Коллеги, всем привет! Недавно начали только использовать ClickHouse ищем специалиста который может поконсультировать на платной основе нашу разработку на предмет правильности использования и тонкостей настройки

www.altinity.com

А CH поддерживает вертикальное партицирование по полям? DBA зачем-то спрашивают

каждая колонка это отдельный файл

Добрый день! Есть запрос вида: SELECT ... FROM ... WHERE ... AND test_id IN ( SELECT test_id... ) GROUP BY ... ANY LEFT JOIN ( SELECT ... FROM ... WHERE ... AND test_id IN ( SELECT test_id... ) GROUP BY ... ANY LEFT JOIN ( SELECT ... FROM ... WHERE ... AND test_id IN ( SELECT test_id... ) ) USING test_id LIMIT ... в нём все три подзапроса SELECT test_id... совершенно одинаковы; будут ли они вычислены в CH только один раз?

Насколько я помню, всё-таки будут выполнены несколько раз.

Алексей, то есть если будет в батче больше 1млн строк, то атомарность INSERT-а не будет работать? Тут не совсем понятно

Это определяется настройкой max_insert_block_size. Её можно указать как в clickhouse-client, так и в HTTP интерфейсе. Блоки будут собираться такого размера из строк, и вставка каждого блока будет атомарной.

Привет! Где-нибудь можно почитать сравнение реализации SQL в CH со стандартом ANSI SQL 2008 (или другого года)?

Не видел пока текста с подробной сводкой.

Коллеги, всем привет! Недавно начали только использовать ClickHouse ищем специалиста который может поконсультировать на платной основе нашу разработку на предмет правильности использования и тонкостей настройки

Возможно, Altinity сможет помочь. https://www.altinity.com/ Хотя я даже не знаю, начиная с какого размера, они заинтересованы.

Во VIEW можно же можно столбцы любых типов данных использовать? Не нашёл в доках

Во VIEW можно же можно столбцы любых типов данных использовать? Не нашёл в доках

Да.

Добрый день. Подскажите, как быть. Впритык не вижу в чем проблема. Есть основная таблица stat (MergeTree). Также есть view_general (VIEW над stat). Далее выполняю последовательно запросы над view_general: 1) Вытягиваю данные за последнюю неделю - данные отдаются в полной мере. 2) Затем тащу данные за последние сутки - данные отдаются в полной мере. 3) Пробую вновь вытащить данные за неделю - отдаются данные лишь за последние сутки. Проблема наблюдается и в запросах через веб и в cli.

а на 4й раз как?

view обычная, не материальная?

а на 4й раз как?

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

view обычная, не материальная?

обычная

а версия КХ последняя? тогда enable_optimize_predicate_expression = 0 и пересоздать view

а версия КХ последняя? тогда enable_optimize_predicate_expression = 0 и пересоздать view

v18.12.17, спасибо, работает*

@proller а ты не задокументировал свои добавления к distributed, чтобы пользоваться им через ssl?

https://github.com/yandex/ClickHouse/blob/master/docs/en/operations/table_engines/distributed.md

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

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

В Яндекс.Облаке тоже нет внутрияндексовской геобазы. (если бы была - тогда можно было бы легко выгрузить её целиком)

Понял, спасибо

После пары последних обновлений заметил странный баг с вьюхами: запрос ко вьюхе (обычная, не матвью) отдает меньше данных, чем в исходной таблицы. Схема такая: 1. исходная таблица (в mysql) 2. таблица с движком mysql (в КХ) 3. вьюха на таблицу (в КХ) Запрос count для первых друх таблиц возвращает правильное значение, а к третьей - где-то процентов 10. Но стоит пересоздать вьюху - запрос с count ко вьюхе начинает отдавать правильное значение. И такое уже второй раз за день

а версия КХ последняя? тогда enable_optimize_predicate_expression = 0 и пересоздать view

После пары последних обновлений заметил странный баг с вьюхами: запрос ко вьюхе (обычная, не матвью) отдает меньше данных, чем в исходной таблицы. Схема такая: 1. исходная таблица (в mysql) 2. таблица с движком mysql (в КХ) 3. вьюха на таблицу (в КХ) Запрос count для первых друх таблиц возвращает правильное значение, а к третьей - где-то процентов 10. Но стоит пересоздать вьюху - запрос с count ко вьюхе начинает отдавать правильное значение. И такое уже второй раз за день

А точно обычная вьюха, а не матвью? А то поведение очень уж похоже на мержи. Сразу после создания еще ничего не помержилось, вот и отдается полностью, а потом по прошествии мержей остается 10 процентов данных.

Точно. Эта вьюха нужна чтобы запросы к таблице с mysql-движком не падали

да, странный баг, когда на марсе температура через 0 переходит, вьюхи начинают возвращать 10% строк. и вроде исправлен https://github.com/yandex/ClickHouse/commit/13779bc75d85a3f52299c4df34a741208ebf4cf7

Ребят, а есть возможность делать инклуд какого-то своего файла в конфиг? Т.е. если я некоторую часть config.xml хочу вынести в отдельный файл, как сказать CH чтобы он ее тоже почитал?

ну мы вообще стандартные конфиги не изменяем, все свое складываем в clickhouse/conf.d https://clickhouse.yandex/docs/en/operations/configuration_files/

ну мы вообще стандартные конфиги не изменяем, все свое складываем в clickhouse/conf.d https://clickhouse.yandex/docs/en/operations/configuration_files/

Воооо, юзеры. То что нужно. Спасибо!!

Доброго утра! Нет ли штатной функции отображения seconds(UintX) в формате HH:MM:SS? Я знаю что типа time нет в CH

меньше суток наверное можно выкрутиться SELECT substring(toString(toDateTime(36000)), 12, 8 ) 10:00:00 SELECT substring(toString(toDateTime(3600)), 12, 8 ) 01:00:00

select 360001 s, intDiv(s, 3600) h, intDiv(s-3600*h, 60) m, s-3600*h-m*60 ss ┌──────s─┬───h─┬─m─┬─ss─┐ │ 360001 │ 100 │ 0 │ 1 │ └────────┴─────┴───┴────┘

Доброго утра! Нет ли штатной функции отображения seconds(UintX) в формате HH:MM:SS? Я знаю что типа time нет в CH

если я правильно понял - скоро должно быть ) https://github.com/yandex/ClickHouse/pull/2770#issuecomment-422466974

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

А что такое "геобаза" ?

А что такое "геобаза" ?

https://clickhouse.yandex/docs/ru/query_language/functions/ym_dict_functions/

А что такое "геобаза" ?

обычно база данных, в которой ip связан с герлокацией

можно самим наколхозить, но лучше бы родную.

Это лучше до КХ определять, так как в зависимости от версии самой базы будут и разные значения на один и тотже IP

есть еще всякие spatial опции в традиционных базах, запрос по координатам, пересечение областей на карте

Это лучше до КХ определять, так как в зависимости от версии самой базы будут и разные значения на один и тотже IP

именно так

несколько вендоров баз geoIP. за деньги и нет

Даже от одного и того же вендора (например digital element) от версии к версии будут меняться значения

Даже от одного и того же вендора (например digital element) от версии к версии будут меняться значения

так вот это не очень критично все-равно оно никогда не дает 100% попадания (всегда есть мобильные операторы/vpn'ы и т.п.), всегда важнее срез "в общем" можно и свою наколхозить, есть вендоры конечно. но то как устроена яндексовая (иерархично, с областями) - для СНГ идеально

так вот это не очень критично все-равно оно никогда не дает 100% попадания (всегда есть мобильные операторы/vpn'ы и т.п.), всегда важнее срез "в общем" можно и свою наколхозить, есть вендоры конечно. но то как устроена яндексовая (иерархично, с областями) - для СНГ идеально

Смотря где, если мы продали трафик как трафик с США, то он потом не долже внезапно светиться как трафик с Канады

так вот это не очень критично все-равно оно никогда не дает 100% попадания (всегда есть мобильные операторы/vpn'ы и т.п.), всегда важнее срез "в общем" можно и свою наколхозить, есть вендоры конечно. но то как устроена яндексовая (иерархично, с областями) - для СНГ идеально

Там простой формат, легко сделать, она там вообще к IP не привязана

https://clickhouse.yandex/docs/ru/query_language/functions/ym_dict_functions/

я чё-то про аналог OSM подумал

Более того, на ней можно сделать что угодно, даже классификатор матрешек или что там в голову взбредет )

Там простой формат, легко сделать, она там вообще к IP не привязана

я понимаю что иерархия не связана с IP можно конечно этим заниматься, это муторно и долго. и все время будет расхождение с тем трафиком который люди покупают (к примеру в яндекс.директе, с геотаргетингом) и тем что мы показываем хотелось хоть с одним крупным вендором (яндекс/google/вк) совпадать (хотя-бы по набору регионов) просто подумалось что может быть в Яндекс.Облаке есть подключенный словарь который не дают наружу потом уже после ответа Алексея стало понятно что да, если бы был - можно бы было получить и саму базу

Привет всем! Мы тут на клике решили считать воронку, но вопрос не про неё. Упрощённо у нас есть таблица, содержащая колонки (uid, date, event), мы группируем по uid и с помощью groupArray получаем две колонки (uid, [event1,event2,event3]), далее делаем расчёты. Чтобы не группировать при каждом запросе, решили сгруппировать единожды и положить в отдельную таблицу. Но когда делаем запросы к заранее сгруппированной таблице, то вылетает по лимиту памяти, тогда как тот же самый запрос с группировкой в памяти отрабатывает на отлично. Вроде бы делаем то же самое, даже выбросили лишний шаг.. С чем может быть связано такое поведение?

Привет всем! Мы тут на клике решили считать воронку, но вопрос не про неё. Упрощённо у нас есть таблица, содержащая колонки (uid, date, event), мы группируем по uid и с помощью groupArray получаем две колонки (uid, [event1,event2,event3]), далее делаем расчёты. Чтобы не группировать при каждом запросе, решили сгруппировать единожды и положить в отдельную таблицу. Но когда делаем запросы к заранее сгруппированной таблице, то вылетает по лимиту памяти, тогда как тот же самый запрос с группировкой в памяти отрабатывает на отлично. Вроде бы делаем то же самое, даже выбросили лишний шаг.. С чем может быть связано такое поведение?

а потом что именно вы с этими массивами делаете?

Привет всем! Мы тут на клике решили считать воронку, но вопрос не про неё. Упрощённо у нас есть таблица, содержащая колонки (uid, date, event), мы группируем по uid и с помощью groupArray получаем две колонки (uid, [event1,event2,event3]), далее делаем расчёты. Чтобы не группировать при каждом запросе, решили сгруппировать единожды и положить в отдельную таблицу. Но когда делаем запросы к заранее сгруппированной таблице, то вылетает по лимиту памяти, тогда как тот же самый запрос с группировкой в памяти отрабатывает на отлично. Вроде бы делаем то же самое, даже выбросили лишний шаг.. С чем может быть связано такое поведение?

на всякий случай про то как считать воронки в ClickHouse: https://www.youtube.com/watch?v=YpurT78U2qA

а потом что именно вы с этими массивами делаете?

Дальше делается полнейшая жесть с arrayFilter, чтобы найти индексы ивентов входа в воронку (их может быть несколько), arrayJoin, чтобы размножить последовательность шагов на отдельные записи на каждый вход в воронку, и в итоге arraySlice, чтобы оставить в каждой записи только одно прохождение. Но эта жесть с группировкой в памяти отрабатывает и скорее вопрос, в чём принципиальная разница, группировать в памяти или брать из заранее сгруппированной таблицы..

на всякий случай про то как считать воронки в ClickHouse: https://www.youtube.com/watch?v=YpurT78U2qA

Ага, это видела. По сути на основе этого и делается, там просто не простая воронка, поэтому появляется всякая жесть))

Дальше делается полнейшая жесть с arrayFilter, чтобы найти индексы ивентов входа в воронку (их может быть несколько), arrayJoin, чтобы размножить последовательность шагов на отдельные записи на каждый вход в воронку, и в итоге arraySlice, чтобы оставить в каждой записи только одно прохождение. Но эта жесть с группировкой в памяти отрабатывает и скорее вопрос, в чём принципиальная разница, группировать в памяти или брать из заранее сгруппированной таблицы..

для отладки удобнее из таблицы, как мне кажется

для отладки удобнее из таблицы, как мне кажется

Мне тоже так кажется) Но запросы из таблицы вылетают по памяти и пока не понятно, почему..

Привет всем! Мы тут на клике решили считать воронку, но вопрос не про неё. Упрощённо у нас есть таблица, содержащая колонки (uid, date, event), мы группируем по uid и с помощью groupArray получаем две колонки (uid, [event1,event2,event3]), далее делаем расчёты. Чтобы не группировать при каждом запросе, решили сгруппировать единожды и положить в отдельную таблицу. Но когда делаем запросы к заранее сгруппированной таблице, то вылетает по лимиту памяти, тогда как тот же самый запрос с группировкой в памяти отрабатывает на отлично. Вроде бы делаем то же самое, даже выбросили лишний шаг.. С чем может быть связано такое поведение?

А какой движок таблицы и настройки? И как выбираете из таблицы (по сравнению с прямым селектом)? (Например не используете ли повторно GROUP BY?)

т.е. я так понимаю что делаете что-то типа CREATE TABLE ... Engine=... AS SELECT uid, groupArray(event) FROM (SELECT uid, event FROM table ORDER BY date) GROUP BY uid ?

А потом простой селект (без дополнительных группировок) из получившейся таблицы?

Вроде бы не должно "отваливаться"...

А какой движок таблицы и настройки? И как выбираете из таблицы (по сравнению с прямым селектом)? (Например не используете ли повторно GROUP BY?)

Движок MergeTree. Какие настройки интересуют? Запросы различаются лишь секцией from - либо таблица, в которой уже сгруппированные данные, либо запрос из исходной таблицы и группировка (ровно то, чем заполнена сгруппированная таблица).

т.е. я так понимаю что делаете что-то типа CREATE TABLE ... Engine=... AS SELECT uid, groupArray(event) FROM (SELECT uid, event FROM table ORDER BY date) GROUP BY uid ?

Почти, только groupArray(event) вместо просто event

А потом простой селект (без дополнительных группировок) из получившейся таблицы?

Да, никаких доп группировок, но своё слово вносит arrayJoin, я думаю. Так что не такой уж простой)

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

А если вы в том селекте где используете данные записанные в таблицу замените прямое использование таблицы на подзапрос типа FROM (SELECT * FROM table) ?

А если вы в том селекте где используете данные записанные в таблицу замените прямое использование таблицы на подзапрос типа FROM (SELECT * FROM table) ?

Попробовала только что - тот же результат. Кстати, по памяти вылетает достаточно быстро, прогресс бар в клиенте замирает на 2% и через 4 секунды выкидывает ошибку. Может он заранее пытается прикинуть нужный размер и падает из-за некоторого вычисленного значения? Потому что просто сделать какой-нибудь каунт из сгруппированной таблицы можно, не отрабатывают сложные запросы с arrayJoin и arraySlice.

Попробовала только что - тот же результат. Кстати, по памяти вылетает достаточно быстро, прогресс бар в клиенте замирает на 2% и через 4 секунды выкидывает ошибку. Может он заранее пытается прикинуть нужный размер и падает из-за некоторого вычисленного значения? Потому что просто сделать какой-нибудь каунт из сгруппированной таблицы можно, не отрабатывают сложные запросы с arrayJoin и arraySlice.

объём используемой памяти видно в логах сервера

Привет всем! Возник вопрос про механизм обновление кластера. Есть кластер из 25 машин. Кластер находится под нагрузкой. Могу ли я обновлять ноды одна за другой без простоя кластера? Тоесть будет ли работать кластер с нодами разной версии, не возникнит ли конфликт. Или необходимо выполнять остановку всех нод, обновлять, а потом продолжать работу. Если есть мануал по данному вопросу скинте ссылочку, а то я както не нашел

объём используемой памяти видно в логах сервера

Интересненько, MemoryTracker из логов: группировка в памяти 2.15 GiB, чтение из заранее сгруппированной таблицы остановилось на 8.05 GiB (упёрлось в лимит). Значит, это реально не какое-то вычисленное значение..

Code: 159, e.displayText() = DB::Exception: Timeout exceeded: elapsed 5.079963156 seconds, maximum: 5, e.what() = DB::Exception как то обойти можно? а то не пересортировать

есть настройка http_connection_timeout

есть настройка http_connection_timeout

да я через tabix.io пока