Добрый вечер. SELECT sum(preland_uniques) AS preland_uniques, sum(transit_uniques) AS transit_uniques, (1 - sum(transit_uniques) / sum(preland_uniques)) AS bounce_rate DB::Exception: Aggregate function sum(transit_uniques) is found inside another aggregate function in query Не могли бы вы подсказать, каким образом можно разрешить данную ситуацию?

SELECT sum(preland_uniques) AS sum_preland_uniques, sum(transit_uniques) ASsum_ transit_uniques, (1 - sum_transit_uniques / sum_preland_uniques) AS bounce_rate

обычный sql так не позволяет

а clickhouse позволяет?)

или пробуй подзапрос

а clickhouse позволяет?)

Да.

благодарю)

Нет, у нас в КХ "ручками" только аналитик ходит, обычные пользователи через API. Соответственно есть 3-и профиля: api, worker (тот кто пишет и пересчитывает стату) и analytics. У всех разные лимиты.

А какая у вас БД для вставки данных (транзакционная)?

привет. Подскажите, баг ли это :) SELECT 0/0 between 0 and 1; 1

привет. Подскажите, баг ли это :) SELECT 0/0 between 0 and 1; 1

SELECT nan >= 0 возвращает 1. Это не выглядит как корректно. Может быть связано с SSE, надо посмотреть.

а SELECT nan > 0 уже 0 ?

SELECT nan >= 0.0 - тоже Ок.

Это баг в коде. @vludv Написано template <typename A, typename B> inline bool_if_not_safe_conversion<A, B> greaterOrEqualsOp(A a, B b) { return !greaterOp(b, a); } что не верно как раз для случая nan-ов.

А какая у вас БД для вставки данных (транзакционная)?

КХ у нас) Изначально все события пишутся в Kafka, в этом месте есть некоторая гарантия сохранности данных, после чего воркеры перекидывают события из Kafka в ClickHouse батчами примерно по 40-50 к если все нормально, если событий накопилось много размер батча увеличивается

Привет! Подскажите, пожал. какая настройка отвечает за удаление устаревших данных в кх? Если я ее изменю, у меня старые данные попавшие под критерий очистятся или только все новозаписанные будут учитываться?

А что такое устаревшие данные?

Допустим, для экономии места я готов удалять все, что старше N месяцев

ну напишите скрипт котоырй удаляет старые партиции

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

там буквально пару тройку строчек кода

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

Спасибо

ну напишите скрипт котоырй удаляет старые партиции

Пока не уверен, что данные партицированы. Я не админ, лишь пользователь продукта, где юзается кх. А скрипт в кроне системы или в кх есть шедулер?

В кроне

Кх удаляет данные с задержкой, учитывайте это

Пока не уверен, что данные партицированы. Я не админ, лишь пользователь продукта, где юзается кх. А скрипт в кроне системы или в кх есть шедулер?

они по дефолту партицированы

они по дефолту партицированы

А с какой дельтой? Месяц, день?

ну как задали при создании таблицы

А с какой дельтой? Месяц, день?

Если не меняли дефолтную настройку при создании таблицы, то месяц

Если не меняли дефолтную настройку при создании таблицы, то месяц

Спасибо!

Можно каким-то образом оценить, сколько сервер потянет записей на вставку в секунду? Ситуация такая: Есть много событий, в день около 1ккк События вставляются батчами по 20к с 9 машин в один сервер hdd_util% на сервере с КХ достигает 80-100% при одной вставке Увеличить размер батча не могу - падает скорость вставки и данные перестают успевать переливаться в кх с машин, что приводит к их переполнению и потере данных Как рассчитать сколько инстансов кх мне необходимо, если я хочу при такой вставке выполнять простую квери по суммированию двух столбцов из 15 меньше, чем за 5с?

nvme ssd ?)

3гб/с последовательной записи

nvme ssd ?)

Если бы) sas стоят

ну тогда бери 9 машин

раз 1 вставка 1 машину грузит на 100%

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

бери 81)

Часом нет лекарства от всех бед в виде формулы для расчета железа под данные??)

бери 81)

Это оверхед, я же не яндекс :)

просто sas это уже устарело

сейчас впски с ссд не дорого стоят

Дело в том, что не я серв приобретал и вообще не под эту цель Мы изменили формат событий для онлайн аналитики и перешли с Оракла на КХ, но сервер был к этому не готов :)

а оракл справлялся с такой нагрузкой?

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

С такой - нет, раньше был агрегированный формат событий, их было в 20 раз меньше

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

Все так, просто у вас всей информации не было

Оракл на таких данных просто бессмысленно пользовать

может кафку поставить

и в нее пихать все

а кх будет из кафки большие объемы разом брать

а сколько у вас втавок в секунду по 20к ?

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

День добрый. При LEFT JOIN в правой таблице значение поля може быть 0, а может не быть записи. Подскажите, как-то можно различить, когда выводится значение "по умолчанию", а когда - реальное?

День добрый. При LEFT JOIN в правой таблице значение поля може быть 0, а может не быть записи. Подскажите, как-то можно различить, когда выводится значение "по умолчанию", а когда - реальное?

Можно попробовать использова null-столбцы. Правда не уверен что можно через ALTER TABLE изменить тип уже существующиего столбца.

Можно попробовать использова null-столбцы. Правда не уверен что можно через ALTER TABLE изменить тип уже существующиего столбца.

а можно ссылку на документацию по null-столбцам? На оф. сайте что-то найти не смог.

Можно каким-то образом оценить, сколько сервер потянет записей на вставку в секунду? Ситуация такая: Есть много событий, в день около 1ккк События вставляются батчами по 20к с 9 машин в один сервер hdd_util% на сервере с КХ достигает 80-100% при одной вставке Увеличить размер батча не могу - падает скорость вставки и данные перестают успевать переливаться в кх с машин, что приводит к их переполнению и потере данных Как рассчитать сколько инстансов кх мне необходимо, если я хочу при такой вставке выполнять простую квери по суммированию двух столбцов из 15 меньше, чем за 5с?

Уточните параметры вставки: кол-во столбцов, размер батча в байтах, характеристики сервера

а можно ссылку на документацию по null-столбцам? На оф. сайте что-то найти не смог.

В доке действительно нет, вот примеры из гитхаба https://github.com/yandex/ClickHouse/search?l=SQL&q=Nullable

В доке действительно нет, вот примеры из гитхаба https://github.com/yandex/ClickHouse/search?l=SQL&q=Nullable

Ага, спасибо.

Но нужно быть аккуратным, null-столбцы до сих пор работают с сюрпризами (я не использую их)

Но нужно быть аккуратным, null-столбцы до сих пор работают с сюрпризами (я не использую их)

Понятное дело, раз это все-еще "недокументированная возможность"

Понятное дело, раз это все-еще "недокументированная возможность"

Есть хорошо работающее, но тоже недокументированое?

Уточните параметры вставки: кол-во столбцов, размер батча в байтах, характеристики сервера

2xE5-2690v4, 128GB RAM, RAID6 из 20х1.2TB SAS 10k rpm для данных (КХ тут), RAID1 из SAS 2x300GB для ОС, RAID Controller HP батч в 20к событий, 21 столбец , размером около 5МБ, батчей в секунду прилетает около 50 в КХ

2xE5-2690v4, 128GB RAM, RAID6 из 20х1.2TB SAS 10k rpm для данных (КХ тут), RAID1 из SAS 2x300GB для ОС, RAID Controller HP батч в 20к событий, 21 столбец , размером около 5МБ, батчей в секунду прилетает около 50 в КХ

Если, как вы пишите, в диск уперлись то варианта у вас 2-а: увеличение поизводительности диска на сервере, больше серверов в которые можно писать. В любом случае нужно уменьшать количество батчей в секунду. КХ при большом (по умолчанию 150) количестве кусков в партиции сначала будет писать медленнее, а при 300 вообще откажеться что-то делать.

Если, как вы пишите, в диск уперлись то варианта у вас 2-а: увеличение поизводительности диска на сервере, больше серверов в которые можно писать. В любом случае нужно уменьшать количество батчей в секунду. КХ при большом (по умолчанию 150) количестве кусков в партиции сначала будет писать медленнее, а при 300 вообще откажеться что-то делать.

думаю, что это единственный вариант, вывод iostat за 20 секунд при вставке без каких либо запросов: Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util sda 0,00 3,25 1,05 105,35 0,11 3,08 61,35 0,63 3,35 183,81 1,55 1,81 19,29 sdb 45,10 204,05 61,65 1602,75 80,62 204,48 350,82 60,32 34,50 68,82 33,18 0,49 82,23 sdc 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 sdb - это RAID6 для данных КХ

82% util

Ещё перейти на RAID10, будет быстрее сильно запись для случайной записи

Ещё перейти на RAID10, будет быстрее сильно запись для случайной записи

пересобирать рейд долго, все равно нужно куда то данные слить будет :)

RAID Controller HP - он с батарейкой и кешированием Write Back ? Это тоже сильно ускорит

Да, с батарейкой и write-back, по умолчанию на хранилищах так настраиваем

Да, с батарейкой и write-back, по умолчанию на хранилищах так настраиваем

По рейду тут есть рекомендации https://clickhouse.yandex/docs/en/operations/tips/

Читал в первую очередь, но у вас, кажется, софтовый рейд описан

Мне кажется прроще кафку воткнуть

50 ставок может быть многовато

Ну или батч увеличить он же у вас есть мегабайт не очень понятно что у вас может переполняться там

Ну или батч увеличить он же у вас есть мегабайт не очень понятно что у вас может переполняться там

Импортер может тормозить из-за увеличения размера батча уже сам, есть вариант напрямую из плюсового приложения вставлять

2xE5-2690v4, 128GB RAM, RAID6 из 20х1.2TB SAS 10k rpm для данных (КХ тут), RAID1 из SAS 2x300GB для ОС, RAID Controller HP батч в 20к событий, 21 столбец , размером около 5МБ, батчей в секунду прилетает около 50 в КХ

20k событий на батч умножить на 50 батчей в секунду - выходит миллион событий а секунду. Это больше 80 миллиардов в сутки, а не миллиард, как говорилось раньше. У нас кликхаус выдерживал 300к событий в секунду на один сервак с persistent hdd в google cloud'е. Дальше начинались тормоза. Мы писали данные в Buffer-таблицу, которая сбрасывала данные в MergeTree раз в 10 секунд. У вас дисковая подсистема вроде мощнее, так что может и выдержит миллион записей в секунду, если правильно настроить Buffer-таблицу перед MergeTree таблицой

20k событий на батч умножить на 50 батчей в секунду - выходит миллион событий а секунду. Это больше 80 миллиардов в сутки, а не миллиард, как говорилось раньше. У нас кликхаус выдерживал 300к событий в секунду на один сервак с persistent hdd в google cloud'е. Дальше начинались тормоза. Мы писали данные в Buffer-таблицу, которая сбрасывала данные в MergeTree раз в 10 секунд. У вас дисковая подсистема вроде мощнее, так что может и выдержит миллион записей в секунду, если правильно настроить Buffer-таблицу перед MergeTree таблицой

Я говорил про пиковую нагрузку, только и всего

Не оценивали, какой прирост буфер дает?

Не оценивали, какой прирост буфер дает?

У buffer есть куча ограничений, я бы попробовал воткнуть kafka (или любой другой брокер сообщений) и писать в 50 потоков в ней. А уж она сама вставит. 50 вставок в секунду - очень плохо

И такой вопрос, есть c++ клиент от Я? Или только народное творчество?

Зависит от многих параметров. Буфер нужен, чтобы уменьшить частоту вставок в MergeTree таблицу до менее однойн в секунду, если не получается другими способами. У нас данные прилетали от большого количества воркеров, поэтому буфер нам лучше всего подошел. Каждый воркер накапливал пачку событий перед отправкой

И такой вопрос, есть c++ клиент от Я? Или только народное творчество?

Есть c++ клиент от работника Я. Точно не могу сказать как называется, можно погуглить

Зависит от многих параметров. Буфер нужен, чтобы уменьшить частоту вставок в MergeTree таблицу до менее однойн в секунду, если не получается другими способами. У нас данные прилетали от большого количества воркеров, поэтому буфер нам лучше всего подошел. Каждый воркер накапливал пачку событий перед отправкой

Согласно документации https://clickhouse.yandex/docs/ru/table_engines/buffer/ buffer есть куча неявных ограничений. Оно вам надо?

Не оценивали, какой прирост буфер дает?

Он нужен только если вы сами не можете уменьшить количество пишущих в КХ, если коротко то да, помогает. Если можете сами то лучше делать самим, будет шустрее. У нас в пике размер батча может достигать 200MB, при этом у нас диски 7,2к в софтварном рейде 10

У buffer есть куча ограничений, я бы попробовал воткнуть kafka (или любой другой брокер сообщений) и писать в 50 потоков в ней. А уж она сама вставит. 50 вставок в секунду - очень плохо

Я можете чуть больше слов написать почему через кафку вставлять быстрее чем самому? Нубираю просто

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

ребят а кто какой драйвер под NODE юзает?

Всем спасибо за пищу для размышлений, настало время крепко задуматься :)

ребят а кто какой драйвер под NODE юзает?

Go :)

второй вопрос вдогонку - КХ решил проблему с JOIN с подзапросами?

Есть c++ клиент от работника Я. Точно не могу сказать как называется, можно погуглить

Для C++ сейчас можно клиент из самого КХ "оторвать", если количество зависимостей не пугает

второй вопрос вдогонку - КХ решил проблему с JOIN с подзапросами?

А что с ними не так?)

А что с ними не так?)

использовать результат подзапрос as ..

Я можете чуть больше слов написать почему через кафку вставлять быстрее чем самому? Нубираю просто

У меня нет опыта использования связки kafka+ch, но судя по тому, как оно сделано, плюсы вот в чем: - можно писать в kafka хоть по одной записи, хоть пачками, хоть в 1000 потоков или серверов. Проблема масштабирования записи берёт на себя kafka. Если что - можно спросить в интернетах что не так. - натравив kafka-таблицу на обычную таблицу - решается проблема записи данных в КХ

использовать результат подзапрос as ..

Вроде в roadmap был 2018 год.