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

я уже ничего не вставлял, там репликации кажись чото шуршали :) вьюх было 5 штук, а на серверах по 128ГБ :)

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

сказали что вьюха называется test и у неё такой-то запрос. или как эта штука работает

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

значит надо вставки делать голые в разные таблицы

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

потому что кх не справляется с 600 млн таблицей

select toDate(eventTime) as period, toStringCutToZero(country) as country, toStringCutToZero(region) as region, toStringCutToZero(city) as city, toStringCutToZero(gender) as gender, toString(applicationName) as app, age as group_age, SUM(requests_count) AS requests from `audience_statistic_segments` where `eventTime` between '2017-05-21 00:00:00' and '2017-06-19 23:59:59' group by `period`, `country`, `region`, `city`, `gender`, `app`, `group_age` order by `period` asc, `country` asc, `region` asc, `city` asc, `gender` asc, `app` asc, `group_age` asc

вешает сервак и время ответа на этот запрос 55 сек в среднем

select toDate(eventTime) as period, toStringCutToZero(country) as country, toStringCutToZero(region) as region, toStringCutToZero(city) as city, toStringCutToZero(gender) as gender, toString(applicationName) as app, age as group_age, SUM(requests_count) AS requests from `audience_statistic_segments` where `eventTime` between '2017-05-21 00:00:00' and '2017-06-19 23:59:59' group by `period`, `country`, `region`, `city`, `gender`, `app`, `group_age` order by `period` asc, `country` asc, `region` asc, `city` asc, `gender` asc, `app` asc, `group_age` asc

уверены что запросом хотели по всему массиву данных пройтись? Точно по датам ничего ограничить не надо?)

если сделать нормализацию и вынести строки в словари. будет ли существенный прирост скорости?

если сделать нормализацию и вынести строки в словари. будет ли существенный прирост скорости?

по памяти будет

уверены что запросом хотели по всему массиву данных пройтись? Точно по датам ничего ограничить не надо?)

600 млн это диапазон за where eventTime - меньше месяца

и читаться колонки будут более короткие.

если сделать нормализацию и вынести строки в словари. будет ли существенный прирост скорости?

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

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

и почитайте документацию про view.

вешает сервак и время ответа на этот запрос 55 сек в среднем

А что конкретно значит "вешает сервак"? Посмотрите top -d0.5 dstat iostat -dmx 1 sudo perf top во время выполнения запроса.

Вы про нормализацию?

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

View жрет много памяти может это не мой вариант, упирется в ситуацию выше

perf top не стоит на сервере

perf top не стоит на сервере

Поставь :) linux-tools по-моему пакет

Сорри за большое количество скринов

Декомпрессия

Возвращаюсь к вопросу выше - типы данных в студию

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

create table покажи, хотя бы кусок где описаны типы которые в запросе

create table покажи, хотя бы кусок где описаны типы которые в запросе

Строки там в основном

А. Ну, не надо так делать :)

IP хранить лучше, как UInt32 или String?

если ipv4, то uint32, если ipv6, то fixedstring(16)

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

спасибо большое за ответ, остановлюсь на числах

Сорри я за рулём

Там строки

Раз такая возня, кто-то в курсе можно ли запросом посчитать средне арифметическое по дереву? Снизу вверх

Может формула какая есть? )

С листьев берутся значения и вверх по структуре считается

оО

:) да, звучит дико )

а как у вас это дерево хранится

Таблица где parent_id указан

Лежит в mysql

Можно как угодно переделать

иерархических запросов нет, так что если и можно, то это будет интересно

Мне никто не подскажет?(

Строки там в основном

А. Ну, не надо так делать :)

Если чего придумаю - дам знать :)

Мне никто не подскажет?(

Избавляйся от строк и будет тебе счастье.

Через словари?

Ну словарь подключен, иерархия есть

Просто я беру прогресс по листьям

И мне надо вверх по дереву посчитать прогресс по листьям

Леша сейчас тоже в некотором смысле за рулем, чуть позже может посмотрит в картинки.

Спасибо вам) буду ждать

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

Структура глубокая, в 4 уровня. Надо попробовать

вы тут все наркоманы

?

вы тут все наркоманы

Люди творческие :)

и не говорите

не чат читаю как детективный роман

?

Блин...не получится со структурой в запросе ) У меня там еще дата прокидывается. Есть эвент прохождения задания. Структура используется как логическая группировка заданий. Прогресс прохождения, например подраздела - сумма прогресса по заданиям / кол-во заданий, ну и у раздела сумма прогресса подразделов / кол-во подразделов. И получается, что дата прохождения подраздела - дата завершения последнего задания в подразделе.

Короче мутная схема. Приходится выбирать все эвенты из БД и в коде по дереву пробегаться )

а нормальная ли практика (и возможно ли вообще) в MATERIALIZED колонке таблицы читать данные из внешнего словаря?

Интересный вопрос, кстати :)

а нормальная ли практика (и возможно ли вообще) в MATERIALIZED колонке таблицы читать данные из внешнего словаря?

Кажется видел такое работающим.

спасибо. протестирую отпишусь.

Спасибо вам) буду ждать

1. Непонятно, зачем используется функция toStringCutToZero.

toDate(eventTime) as period, - столбец с датой-временем обычно тяжелее, чем просто с датой. А MergeTree требует, чтобы был отдельный столбец с датой. Наверное, можно написать: eventDate as period,

country, region, city можно сделать числами gender тем более.

Вместо трёх столбцов country, region, city можно сделать один - region_id - число, идентификатор региона самого нижнего уровня (город, деревня). Отдельно подключить справочник с иерархией регионов. https://clickhouse.yandex/docs/en/functions/ym_dict_functions.html?highlight=regiontocity

https://clickhouse.yandex/docs/en/dicts/internal_dicts.html

where eventTime between '2017-05-21 00:00:00' and '2017-06-19 23:59:59' Для MergeTree требуется, чтобы кроме условия на первичный ключ, было ещё условие на ключ даты. Это влияет на пропуск ненужных кусков данных при чтении. Оно не может быть выведено автоматически из условия на eventTime. А в конкретном случае видно, что можно оставить условие только на eventDate.

А ещё не помешает посмотреть вывод: SELECT * FROM system.parts WHERE active AND table = 'audience_statistic_segments' SELECT * FROM system.columns WHERE table = 'audience_statistic_segments' cat /proc/cpuinfo

Коллеги, что-то сломал всю голову. Вдруг подскажете что-то этакое. В общем есть необходимость значения получаемые в WITH TOTALS использовать в вычислениях в SQL. Какие есть тут варианты?

надо посчитать долю каждой размерности от общего

т.е. есть хочется что-то вроде SELECT LAC, count()/<total> FROM table GROUP BY LAC

может так SELECT LAC, cnt/total_cnt FROM (SELECT 1 t LAC, count() cnt FROM table GROUP BY LAC) ALL INNER JOIN (SELECT 1 t count() total_cnt FROM table) USING t

хотелось бы обойтись одним проходом по таблице. Ибо данных хватает в первой выборке. И на стороне приложения такое посчитать можно (и, как я понял модификатор WITH TOTALS делаем именно так).

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