например select count() as raw, sum(uniq_weekly), sum(uniq_daily) from idstats where country_name = 'us' дает что-то вроде 147933 │ 17636 │ 59033 но select count(*) as raw, sum(uniq_weekly) as uniq_weekly, sum(uniq_daily) as uniq_daily, count(substep) as download from idstats any left join events using uid where substep = 'Download' and country_name = 'us' дает 5735 │ 684 │ 2303 │ 5735

что как бы вообще не верно

Возможно, раньше не проявлялось по другой причине. Или я ошибаюсь. Поставить версию из master будет нормально. Мы как раз сейчас из неё собираем релиз. Но ещё не факт, что она пойдёт в stable.

Версия из мастера помогла, спасибо. Но вообще конечно повезло что уже пофиксили. Иначе не было бы дороги ни вперед, ни назад :(

например select count() as raw, sum(uniq_weekly), sum(uniq_daily) from idstats where country_name = 'us' дает что-то вроде 147933 │ 17636 │ 59033 но select count(*) as raw, sum(uniq_weekly) as uniq_weekly, sum(uniq_daily) as uniq_daily, count(substep) as download from idstats any left join events using uid where substep = 'Download' and country_name = 'us' дает 5735 │ 684 │ 2303 │ 5735

Почитай в документации про разницу any/all join

Почитай в документации про разницу any/all join

оба варианта возвращают одно и то же точнее разница там в пару единиц

Да, действительно тут дело не в этом. Возможно, разные условия в where?

Подскажите плиз, что не так CREATE TABLE default.uri_stat_cache_new ( date Date, week_num UInt32, hash1 UInt64, hash2 UInt64, modify_date AggregateFunction(max, DateTime), url AggregateFunction(argMax, String, DateTime), domain AggregateFunction(argMax, String, DateTime), title AggregateFunction(argMax, String, DateTime), site_id AggregateFunction(argMax, UInt32, DateTime), count AggregateFunction(sum, UInt32) ) ENGINE = AggregatingMergeTree(date, (hash1, hash2, week_num), 8192) INSERT INTO uri_stat_cache_new(date, week_num, hash1, hash2, modify_date, url, domain, title, site_id, count) SELECT date, week_num, hash1, hash2, maxState(event_date), argMaxState(url, event_date), argMaxState(domain, event_date), argMaxState(title, event_date), argMaxState(site_id, event_date), sumState(count) FROM uri_stat_cache GROUP BY date, week_num, hash1, hash2; Данные заливает, но вот этот запрос SELECT week_num, hash1, hash2, update_date, count, argMaxMerge(url, update_date) FROM (SELECT week_num, hash1, hash2, maxMerge(modify_date) AS update_date, argMaxState(url, modify_date) AS url, sumMerge(count) AS count FROM uri_stat_cache_new GROUP BY week_num, hash1, hash2) LIMIT 10; выдает: DB::Exception: Incorrect number of arguments for aggregate function argMaxMerge. если убираю argMaxMerge(url, update_date) все ОК

Все функции -Merge принимают один аргумент - состояние агрегатной функции. Для функции argMax, состояние уже содержит запомненные аргументы arg и max, и для объединения состояний (как и для любых других агрегатных функций) ничего больше не нужно.

Мда, через native скорость упала ещё в разы, до ~20 в секунду. Может дело в библиотеке клиента - не знаю. Так как cpu почти не загружен. ... компрессия ... отключена.

Нет никакого смысла отправлять по одной строке в формате Native. Этот формат ориентирован именно на пачки данных.

Хочется lowlatency

Вчера оказалось что post тоже не подходит по причине того что там каждый раз шифруется пароль.

Но что-то в 25 строк в секунду верится с трудом. Да, у native немного больше оверхед на мету, но 25/с тут явно не в этом дело.

Latency вставки - от сотен мс. Latency чтения от единиц мс. в самых простых случаях.

Но тем не менее http+rowbinary всё же около 3000 выдаёт. Понимаю что не особо рекомендуемое использование, но всё же.

Но тем не менее http+rowbinary всё же около 3000 выдаёт. Понимаю что не особо рекомендуемое использование, но всё же.

Делая вставки по 1 просто потом огребешь веселые мержи.

А чем буфер таблица не угодила?

Так я в Buffer и вставляю. Я так понимаю он и должен собрать данные чтобы потом не было очень много мерджей.

@inv2004 в общем случаи нельзя оптимизировать под latency и скорость вставки пачками одновременно. Кх оптимизирован под последнее

И не надо из него делать то к чему он не предназначен

Да, Я понимаю, просто хотел понять предел какой возможный. В данный момент он не ясен: при вставке post - упирается в sha пустого пароля но все же 3к, а вот с native не считает пароль, но производительность всё равно упала аж в 100 раз.

Я просто объясню. Есть задача, на которую неплохо ложится кдб, которая имеет ~ аналогичную векторную структуру, при этом является довольно универсальной. У КХ тоже есть преимущества, но просто хочется понять основные моменты которые он сможет покрыть, а что не сможет. При этом, КХ и кдб кажутся довольно близкими родственниками.

Добрый день! Подскажите пожалуйста, каким образом можно указывать таймзону в виде смещения от UTC вместо использования имён часовых поясов при работе с датами?

Например, найти имена поясов, соответствующих смещению

Таймзона — это же больше, чем смещение по utc

вот с апдейтами самая грустная ситуация в вещах типа user agent

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

апдейтить её нельзя

Useragent можно писать в рядом стоящую sql базу, а в CH вытаскивать через словарь например

Ну так да

Или сделать внешний словарь в кх в памяти на цсв

сейчас у нас 275961 разных useragent

Немного

сейчас у нас 275961 разных useragent

ну это ж вообще не о чем.

Поместится во что угодно

а если я захочу сделать распределение по операционным системам, то это будет норм?

А почему это должно стать не норм?

кликхаус сделает 270 тыс лукапов к словарю, приклеит и всё агрегирует?

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

Э

а тут будет снаружи

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

ну словарь же по факту С++ ный хэш

а это ОЧЕНЬ БЫСТРО

Кликхаус внешние словари подтягивает в память с некоторой частотой. Это хэш-таблица

оок

звучит что надо именно так делать

Только правильно настройте частоту обновления и всё такое

std::unordered_map C++11: 2.0 mega ops per second

ну вот как-то так в синтетических тестах оно работает :)

std::map: 0.8 mega ops per second

ну и это на 1 поток процессора, ессна

Добрый день! Подскажите пожалуйста, каким образом можно указывать таймзону в виде смещения от UTC вместо использования имён часовых поясов при работе с датами?

Обычно в базе таймзон есть набор псевдотаймзон типа Etc/GMT-3, только там оффсеты идут в другую сторону - например Etc/GMT-3 это сейчас как раз московское время.

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

Обычно в базе таймзон есть набор псевдотаймзон типа Etc/GMT-3, только там оффсеты идут в другую сторону - например Etc/GMT-3 это сейчас как раз московское время.

Спасибо! Этот вариант мне подходит.

Такой вопрос, нормально ли кликхаус скушает такую выборку в селекте - concat(toString(round(click/show*100)), '%') as CTR, или лучше такие вычисления делать уже в коде? (на тестовом стенде, естественно всё работает прекрасно, интерсно именно не будут ли тупить вычисления на больших объёмах данных)

Если я мигрирую zookeeper с трёх нод на другие три в несколько этапов: 0. Машинки 1, 2 и 3 надо перевезти на 1, 4 и 5 с переналивкой первой. 1. Наливаю машины 4 и 5, добавляю их в кластер, жду, пока догонится ZK 2. Переналиваю машину 1, восстанавливаю на ней ЗК 3. Убираю ноды 2 и 3 Если я в этот момент пропишу в clickhouse все 5 нод, то он себя будет нормально чувствовать при пертурбациях? Если прописать дополнительные две ноды до того, как они станут доступны, как он поведёт себя в этом случае?

столкнулся вот с таким багом, который уже в статусе “закрыт” https://github.com/yandex/ClickHouse/issues/246 мои комментарии внизу тикета. кто может что посоветовать?

Только правильно настройте частоту обновления и всё такое

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

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

Ага, вот я об этом

Если я мигрирую zookeeper с трёх нод на другие три в несколько этапов: 0. Машинки 1, 2 и 3 надо перевезти на 1, 4 и 5 с переналивкой первой. 1. Наливаю машины 4 и 5, добавляю их в кластер, жду, пока догонится ZK 2. Переналиваю машину 1, восстанавливаю на ней ЗК 3. Убираю ноды 2 и 3 Если я в этот момент пропишу в clickhouse все 5 нод, то он себя будет нормально чувствовать при пертурбациях? Если прописать дополнительные две ноды до того, как они станут доступны, как он поведёт себя в этом случае?

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

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

Увеличивать гранулированность индекса (делать больше 8192) почти никогда не стоит. Изредка имеет смысл уменьшить.

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

Я про ноды зк, кх никуда не едет и только меняется конфиг, который относится к zookeeper

Гранулированность индекса влияет на время обработки коротких запросов (уменьшение index_granularity приводит к уменьшению latency) и на потребление оперативки (уменьшение index_granularity приводит к кратному увеличению потребления оперативки). Текущее потребление оперативки можно посмотреть в таблице system.parts - столбцы, относящиеся к primary key.

Если сильно уменьшить index_granularity, то latency сильно меньше не будет, но вот оперативки будет потребляться больше.

Я про ноды зк, кх никуда не едет и только меняется конфиг, который относится к zookeeper

Про ноды ZK не могу сказать - постоянно с 5 нодами не пробовали работать. Вроде бы наши админы один раз делали миграцию ZK как раз путём временного увеличения числа нод.

столкнулся вот с таким багом, который уже в статусе “закрыт” https://github.com/yandex/ClickHouse/issues/246 мои комментарии внизу тикета. кто может что посоветовать?

Зря закрыт. Видимо закрыли после сообщения "выставить вручную max_threads помогает". Придётся разбираться дальше. Можете дать мне ssh+sudo доступ к своей виртуалке, где воспроизводится проблема (пишите в личку). А то нам придётся заводить такую же виртуалку самим, а до этого ещё не дошли руки.

Выложили на сайт презентацию с митапа в Екатеринбурге: https://clickhouse.yandex/presentations/meetup6/# (пока доступна только первая, вступительная презентация) А также с конференции UWDC в Челябинске: https://clickhouse.yandex/presentations/uwdc/#cover

Про ноды ZK не могу сказать - постоянно с 5 нодами не пробовали работать. Вроде бы наши админы один раз делали миграцию ZK как раз путём временного увеличения числа нод.

спасибо, буду сапёром, значит

OPTIMIZE TABLE реплицируется?

да, проверил сам )

Если я мигрирую zookeeper с трёх нод на другие три в несколько этапов: 0. Машинки 1, 2 и 3 надо перевезти на 1, 4 и 5 с переналивкой первой. 1. Наливаю машины 4 и 5, добавляю их в кластер, жду, пока догонится ZK 2. Переналиваю машину 1, восстанавливаю на ней ЗК 3. Убираю ноды 2 и 3 Если я в этот момент пропишу в clickhouse все 5 нод, то он себя будет нормально чувствовать при пертурбациях? Если прописать дополнительные две ноды до того, как они станут доступны, как он поведёт себя в этом случае?

Незнаю как в С++, но в java client динамически менять состав ZK серверов нельзя было. Оно резолвило все при старте и потом работало только с ними.

Можно ли как-то сделать make install, но не собирая тесты?

cmake -DENABLE_TESTS=0

Выложили на сайт презентацию с митапа в Екатеринбурге: https://clickhouse.yandex/presentations/meetup6/# (пока доступна только первая, вступительная презентация) А также с конференции UWDC в Челябинске: https://clickhouse.yandex/presentations/uwdc/#cover

» Движок таблиц Dictionary, движок баз данных Dictionary То есть появятся словари на основе таблиц? Или словари будут видны как таблицы?

» Движок таблиц Dictionary, движок баз данных Dictionary То есть появятся словари на основе таблиц? Или словари будут видны как таблицы?

Было бы здорово, так как добавлять в словарь сейчас не совсем удобно.

» Движок таблиц Dictionary, движок баз данных Dictionary То есть появятся словари на основе таблиц? Или словари будут видны как таблицы?

Любые словари будут доступны в виде таблиц, позволяющих посмотреть содержимое словаря.

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

Просто для информации: дело было не в пароле: uuid генерился из random => прямая передача query_id позволила разогнать мелкие вставки в два раза. Теперь видно что всё упирается в new, что ок. На чём этот странный эксперимент и заканчиваю. :)

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

Пока нет. Если смотрели слайды митапа, там есть пункт - запрос SYSTEM - как раз для этого.

Просто для информации: дело было не в пароле: uuid генерился из random => прямая передача query_id позволила разогнать мелкие вставки в два раза. Теперь видно что всё упирается в new, что ок. На чём этот странный эксперимент и заканчиваю. :)

Забавно, что я как раз сейчас это исправляю.

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

Если не средствами SQL -- то самое простое touch файла с описанием словаря.

Если не средствами SQL -- то самое простое touch файла с описанием словаря.

спасибо

Всем привет! Ребята, подскажите пожалуйста правильный вариант запроса. Есть таблица с полями id, name, amount, created_at. Нужно сделать запрос на сумму по amount за последнюю неделю с гранулярностью 15 минут. как сделать??

https://clickhouse.yandex/reference_ru.html#toStartOfFiveMinute

Всем привет! Ребята, подскажите пожалуйста правильный вариант запроса. Есть таблица с полями id, name, amount, created_at. Нужно сделать запрос на сумму по amount за последнюю неделю с гранулярностью 15 минут. как сделать??

Если именно 15 минут надо, то можно так toDateTime(intDiv(toUInt32(created_at), 900)*900) вместо toStartOfFiveMinute

Если не средствами SQL -- то самое простое touch файла с описанием словаря.

А как можно обновить словарь средствами SQL?