А можете пример такого запроса показать? Пытаюсь повторить примерно так: seq 0 999999 | parallel -j10 'clickhouse-client --query "SELECT nonexistent{}();"' 2>/dev/null, память значимо не растёт. То есть, нужно что-то посложнее.

Вот почти точный (за исключением имени таблицы и конкретных значений) запрос, который мы шлем (который ошибочный): SELECT floor((toUInt32(time) + 10800) / 86400 + 1) * 86400 - 10800 AS `timestamp`,HLL_maxMerge(hll, 256) AS `HLL_MAX(hll, 256)` FROM table_name WHERE stats=123 AND (time BETWEEN 1537909200 AND 1540587599) AND (date BETWEEN '2018-09-26' AND '2018-10-26') AND (timestamp != 1540512000) GROUP BY timestamp ORDER BY timestamp LIMIT 3000000 Поле time это DateTime, hll — это String, stats — Int32

table_name — распределенная таблица (на 3 шарда) над MATERIALIZED VIEW

А HLL_maxMerge это как раз несуществующая функция?

да

это всё, что мне приходит в голову в плане того, чем этот кластер отличается от других

Всем привет, есть вопрос по сырым данным из Google analytics Читаю сейчас статью где сказано что можно вытянуть эти данные и залить их в clickhouse Может кто знает как вытащить данные из Google analytics в сыром виде?

это всё, что мне приходит в голову в плане того, чем этот кластер отличается от других

Попробовал с похожим (насколько это возможно) запросом - всё равно не получается повторить. А с какой версии вы обновлялись? И что это за функции вообще? Это у вас какие-то самописные?

Всем привет, есть вопрос по сырым данным из Google analytics Читаю сейчас статью где сказано что можно вытянуть эти данные и залить их в clickhouse Может кто знает как вытащить данные из Google analytics в сыром виде?

Транзитом через BQ с помощью Авокса

Попробовал с похожим (насколько это возможно) запросом - всё равно не получается повторить. А с какой версии вы обновлялись? И что это за функции вообще? Это у вас какие-то самописные?

Обновлялись с версии 18.4.0 до 18.12.17 Этой функции у нас в ClickHouse нет, она есть в другом движке (сервисе), и это баг, что мы отправляем такой запрос в ClickHouse :). Ещё из того, чем этот кластер отличается от остальных: 1. Используется 3 MATERIALIZED VIEW над Null-движком 2. Используется AggregatingMergeTree с колонками AggregateFunction(…, Int64) c функциями sum,min,max,uniq Пока ч о больше ничего в голову не приходит :).

А есть возможность на релизной сборке как-то посмотреть, на что тратится память? Может быть мы можем обновиться обратно (на какое-то время) и посмотреть чем-нибудь :)? Вопрос только чем.

Простого способа с неинструментированным бинарником из пакета вроде бы нет.

А есть где-нибудь инструментированные бинарники :)?

или они дают сильную просадку по производительности?

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

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

Спасибо!

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

допишите в конец SETTINGS max_memory_usage = 100000 :))

допишите в конец SETTINGS max_memory_usage = 100000 :))

методом последовательных приближений

если серьезно, то я думаю, что нет

SET max_memory_usage=<N>

Можно прямо у запроса

но это какой-то совсем неудобный способ

типа SELECT … FROM … SETTINGS max_memory_usage = …

так я уже делал, мне не понравилось

а если не секрет, для чего вы хотите заранее знать потребение памяти запросом?

насколько я понимаю, ClickHouse сейчас не умеет даже просто в EXPLAIN запроса, но над этим ведется работа

а если не секрет, для чего вы хотите заранее знать потребение памяти запросом?

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

для худших случаев, офк

обычно более-менее очевидно, сколько памяти потребуется для запроса (примерно)

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

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

обычно более-менее очевидно, сколько памяти потребуется для запроса (примерно)

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

т.е. для оценки памяти можно делать что-нибудь типа count() и умножить на ~90 Кб для uniq функций, и на пару килобайт для остальных функций

но это можно прямо измерить точно, если есть желание

в рамках одиночных запросов это так и работает

сколько каждой функции требуется

количество уникальных комбинаций ключей считается с помощью uniq(key1, …, keyN)

это всё я знаю, я думал, кто-то уже за меня это сделал :)

но, если эксплейн пока в планах, то увы

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

EXPLAIN всё равно не знает, сколько у вас данных и какая у них кардинальность

а от этого может очень сильно зависеть ответ

это-то так.

т.е. оценку с погрешностью в 10-100 раз, я думаю, дать можно

точнее — нужно выполнять запрос ?

т.е. оценку с погрешностью в 10-100 раз, я думаю, дать можно

ну такую можно и с потолка взять, вообще говоря =\

но это я говорю с точки зрения того, как бы я делал

вроде ребята, которые разрабывают ClickHouse, поумнее меня будут, поэтому можете дождаться, пока они ответят ?

в общем пока я брал запрос и менял max_memory_usage =) способ очевдино идиотский, но в голову ничего лучше на тот момент не пришло

в общем пока я брал запрос и менял max_memory_usage =) способ очевдино идиотский, но в голову ничего лучше на тот момент не пришло

ИМХО, самый нормальный способ ?

методом дихотомии за log2(N) найдете ответ ?

version был равен 0 по умолчанию

Господа, а кто-нибудь пробовал запустить кликхаус с cifs в качестве storage?

а какой смысл в этом ?

да так, развлечься захотелось. Может есть поддержка, знает кто-нибудь?

ну причем тут поддержка оно просто на диске

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

Привет. Что лучше использовать для обновления данных: ReplacingMergeTree или ALTER TABLE UPDATE?

Code: 1000. DB::Exception: Received from clickhouse:9000, {ip}. DB::Exception: Access to file denied: insufficient permissions: {path/table/tmp_**} - причём временный кусок на диске создается, а дальше отказ. Файловая система cifs. Надо думать ...

Ребята! А что если данные хранятся в одной зоне, а нужно сгруппировать по другой данные по дням

Из коробки сгруппирует?

Временной зоне*

Select .. group by executedDate но с отличной от сервера таймзоной

насколько я понимаю, в ClickHouse поле date уже не имеет никакой временной зоны

DateTime колонка нужна для этого

только поле DateTime можно привести к другой

Date - не хранит время. И идет по поясу сервера

Datetime есть

тогда группируйте по этому полю

Но это я так понял будет намного дольше выполняться

Ок

Но это я так понял будет намного дольше выполняться

да

Что лучше использовать для обновления данных: ReplacingMergeTree или ALTER TABLE UPDATE?

Но это я так понял будет намного дольше выполняться

Разница будет примерно такая: Date: 25 rows in set. Elapsed: 6.869 sec. Processed 14.51 billion rows, 29.01 GB (2.11 billion rows/s., 4.22 GB/s.) toDate(time): 25 rows in set. Elapsed: 12.893 sec. Processed 14.51 billion rows, 87.04 GB (1.13 billion rows/s., 6.75 GB/s.)

То есть, благодаря тому, что поле date лучше сжимается и меньше по размеру в принципе, группировка по нему будет идти в ~2 раза быстрее, чем просто по time

но, как видите, разница не то, чтобы прямо очень большая, это самый худший случай, когда я делаю просто “select date, count() group by date”

Привет, как можно посмотреть индексы таблицы ?

Привет, как можно посмотреть индексы таблицы ?

Show create table tablename

Show create table tablename

спасибо

но, как видите, разница не то, чтобы прямо очень большая, это самый худший случай, когда я делаю просто “select date, count() group by date”

В 2 раза для фичи "по другому поясу" менеджеры не поймут) будем подумать

То есть, благодаря тому, что поле date лучше сжимается и меньше по размеру в принципе, группировка по нему будет идти в ~2 раза быстрее, чем просто по time

Вариант, что половина времени проводится в функции toDate() не рассматривается?

И в 2 раза больше памяти врядли

Там хранятся данные по датам

Поэтому группировки быстрые

Утверждение про компрессию будет корпектным, если такой результат будет получен на сравнении группировки по Date и DateTime, выровненому по границе дней.