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

нет

чтоб водопадом так обновить ряд табличек

а зачем?

нет

Хм. Не знал и не пробовал (особо вроде не за чем) но думал что такие каскады возможны.

чтоб водопадом так обновить ряд табличек

Можно весь водопад обновить несколькими mv из исходной таблицы

а зачем?

https://gist.github.com/lanwen/211f5a6dc7a463bdf364099850b8efcc есть эвент сурсинг над пользователями в виде эвентов. Есть админские вьюхи, чтобы дебажить и есть анонимные, для аналитики которые точные копии админских, ток с хешированными данными. Вот хочется в админских типа текущий стейт накапливать, и потом каждый раз последнюю версию разносить по анонимным

просто на 10 табличках многовато sql выходит

если все аггрегейты из оригинала делать - то конечно работает норм. Но там аля 5к строк sql на всех наших табличках выходит

А аналитиков не удовлетворит вариант "нажмите сюда" чтоб у вас появились такие-то данные? И копировать им хэшированные данные "по требованию"?

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

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

и вот ищу способы сделать это за счет CH пока

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

Подкажите, пожалуйста, с какой версии появилось это: `SELECT * FROM odbc('DSN=connection', 'table')` Это есть на сайте Альтинити, но нет в документации

По ченжлогу впервые появилось аж в 1.1.54337, но потом были исправления в 1.1.54388, и последние в 18.12.13.

https://gist.github.com/lanwen/211f5a6dc7a463bdf364099850b8efcc есть эвент сурсинг над пользователями в виде эвентов. Есть админские вьюхи, чтобы дебажить и есть анонимные, для аналитики которые точные копии админских, ток с хешированными данными. Вот хочется в админских типа текущий стейт накапливать, и потом каждый раз последнюю версию разносить по анонимным

FROM lanwen.aggregate FINAL, файнал не нужен я бы оставил source и aggregate, все остальное на лету, в select - х

FROM lanwen.aggregate FINAL, файнал не нужен я бы оставил source и aggregate, все остальное на лету, в select - х

без Final там пляшет выдача рандомно - name может быть 2, 3 или 4 в примере если много раз селект без FINAL поделать

Ну бывает, может быть Alexey расчитывает на Second Opinion. :)

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

без Final там пляшет выдача рандомно - name может быть 2, 3 или 4 в примере если много раз селект без FINAL поделать

? ну это интересная идея у вас, хранить anyLastState / anyLastMerge, а потом с помощью final случайно видеть стабильный результат напрягая КХ на каждом селекте, вместо того чтобы вычислить один раз с argMaxState? . наверное хотелось argMaxState(if( visitParamHas(event, 'name'), visitParamExtractString(event, 'name'), null ), timestamp) AS name SELECT subjectId, maxMerge(stateAt) as stateAt, minMerge(createdAt) as createdAt, maxMerge(updatedAt) as updatedAt, argMaxMerge(name) as name FROM lanwen.aggregate GROUP BY subjectId;

Подскажите пож, если я правильно понимаю, то нелзя сделать arrayJoin нескольких массивов сразу, а мне нужно приджойнить два столбца из двух массивов. Как это можно сделать? Оба столбца джойнятся 1 к 1 - дата заказа и номер заказа.

Подскажите пож, если я правильно понимаю, то нелзя сделать arrayJoin нескольких массивов сразу, а мне нужно приджойнить два столбца из двух массивов. Как это можно сделать? Оба столбца джойнятся 1 к 1 - дата заказа и номер заказа.

вроде бы можно

вроде бы можно

Говорит нельзя, ругается - мол тоглько один аргумент можно.

Говорит нельзя, ругается - мол тоглько один аргумент можно.

SELECT * FROM (SELECT [1, 2, 3] AS src, [4, 5, 6] AS src2 ) ARRAY JOIN src,src2

Подскажите пож, если я правильно понимаю, то нелзя сделать arrayJoin нескольких массивов сразу, а мне нужно приджойнить два столбца из двух массивов. Как это можно сделать? Оба столбца джойнятся 1 к 1 - дата заказа и номер заказа.

Попробуйте комбинацию из функций arrayJoin(arrayMap((x, y) -> [x, y], arr1, arr2)) AS arr3 И дальше для работы с отдельными столбцами arr3[1] arr3[2]

SELECT * FROM (SELECT [1, 2, 3] AS src, [4, 5, 6] AS src2 ) ARRAY JOIN src,src2

Прикольно, так работает

а ясно, меня смутил кусок в ответе task.Reports(logger), task.ClearColumns(logger), task.DropPartitions(logger),

В этом месте оно используется ровно по назначению, дропает ненужные колонки в сырых данных. Для схлопывания тоже используем, графит чего-то там не подходит так как нужно складывать Nested структуры.

привет, подскажите пожалуста, таблицу типа CollapsingMergeTree можно создать новым синтаксисом? ENGINE CollapsingMergeTree() PARTITION BY toYYYYMM(date) ORDER BY (name, date) SETTINGS index_granularity=8192

привет, подскажите пожалуста, таблицу типа CollapsingMergeTree можно создать новым синтаксисом? ENGINE CollapsingMergeTree() PARTITION BY toYYYYMM(date) ORDER BY (name, date) SETTINGS index_granularity=8192

Можно CollapsingMergeTree(Sign) PARTITION BY .. ORDER BY (...)

Можно CollapsingMergeTree(Sign) PARTITION BY .. ORDER BY (...)

спасибо

еще вопрос, я правильно понимаю что в CollapsingMergeTree нельзя пачками (по несколько тысяч) вставлять изменения?

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

Да, ничем от остальных *MergeTree вставка не отличается

А есть какой-то бестпрэктис по миграции тяжелых(овер 2т) табличек? Кажется что быстрая репликация опасна из-за медленного процесса слияния parts.

Да, ничем от остальных *MergeTree вставка не отличается

то есть можно делать такие запросы insert into sessions values (today(), 'perchik3', 10, 1), (today(), 'perchik3', 10, -1), (today(), 'perchik3', 20, 1), (today(), 'perchik3', 20, -1), (today(), 'perchik3', 30, 1), главное чтобы порядок сохранялся?

то есть можно делать такие запросы insert into sessions values (today(), 'perchik3', 10, 1), (today(), 'perchik3', 10, -1), (today(), 'perchik3', 20, 1), (today(), 'perchik3', 20, -1), (today(), 'perchik3', 30, 1), главное чтобы порядок сохранялся?

today() будет сильно замедлять вставку

today() будет сильно замедлять вставку

ну это я для примера

то есть можно делать такие запросы insert into sessions values (today(), 'perchik3', 10, 1), (today(), 'perchik3', 10, -1), (today(), 'perchik3', 20, 1), (today(), 'perchik3', 20, -1), (today(), 'perchik3', 30, 1), главное чтобы порядок сохранялся?

При желании можно, но зачем? )

у меня данные вставляются большими пачками по мере накопления

а данные только при вставке схлорываются или с течением времени тоже?

Подскажите а разве FINAL нельзя использовать в конструкции INSERT INTO SELECT ?

а данные только при вставке схлорываются или с течением времени тоже?

или вообще никогда не схлопываются ?

а данные только при вставке схлорываются или с течением времени тоже?

при вставке ничего не схлопывается, схлопывается асинхронно в фоне. Можно форсировать схлопывание с помощью OPTIMIZE.

при вставке ничего не схлопывается, схлопывается асинхронно в фоне. Можно форсировать схлопывание с помощью OPTIMIZE.

А когда это примерно происходит (по мере накопления данных, по таймеру, в полнолуние)?

не могу найти в доке про это ничего

А когда это примерно происходит (по мере накопления данных, по таймеру, в полнолуние)?

Приверно так: примерно каждый 8 минут стартуем процесс фоновых слияний, как-то выбираются партиции для слияния - сливаются.

Так что не стоит ожидать что данные будут консистенты. Чтобы получить итоговое значение, используйте в запросе FINAL (итоговое значение будет только в результате запроса). Но FINAL сильно тормозит запрос, даже если все данные смерджены (слопнуты)

Так что не стоит ожидать что данные будут консистенты. Чтобы получить итоговое значение, используйте в запросе FINAL (итоговое значение будет только в результате запроса). Но FINAL сильно тормозит запрос, даже если все данные смерджены (слопнуты)

спасибо

Так что не стоит ожидать что данные будут консистенты. Чтобы получить итоговое значение, используйте в запросе FINAL (итоговое значение будет только в результате запроса). Но FINAL сильно тормозит запрос, даже если все данные смерджены (слопнуты)

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

Всё зависит от данных. как часто появляются дубли и что за запросы. У нас есть часто меняющиеся данные, мы их обновляем раз в минуту. И после вставлки дублей делаем OPTIMIZE (таблица ReplacingMergeTree). Да, в какой-то момент могу быть записи с дублями. Но, в запросах как правило нужны агрегаты, а там мы обычно пишем uniq(id) - т.е. это нивелируется

А можно как то увеличить длину запроса в кх через хттп , а то когда он очень длинный возвращает 400 ответ

@stufently клади запрос в body: "You can send the query itself either in the POST body, or in the URL parameter."

А можно как то увеличить длину запроса в кх через хттп , а то когда он очень длинный возвращает 400 ответ

https://clickhouse.yandex/docs/en/operations/settings/settings/#max_query_size

Подскажите как корректно обновлять значения счетчика в таблице? Пробую так CREATE TABLE msg_log ( created_at DateTime DEFAULT now(), pid String, psid String, mid String, is_delivered UInt8 DEFAULT CAST(0, 'UInt8'), is_read UInt8 DEFAULT CAST(0, 'UInt8') ) ENGINE = ReplacingMergeTree() PARTITION BY toYYYYMM(created_at) ORDER BY (pid, psid, mid) SETTINGS index_granularity = 8192; INSERT INTO msg_log(pid,psid,mid) VALUES('AB','CD','EF'); INSERT INTO msg_log SELECT created_at, pid, psid, mid, 1, is_read FROM msg_log WHERE pid = 'AB' AND psid = 'CD' AND mid = 'EF'; INSERT INTO msg_log SELECT created_at, pid, psid, mid, is_delivered, 1 FROM msg_log WHERE pid = 'AB' AND psid = 'CD' AND mid = 'EF'; В итоге при запросе SELECT * FROM msg_log FINAL ожидаю что is_delivered = 1 и is_read = 1 а по факту вижу только is_read = 1

всем привет, вопрос такой. Как вычесть из текущего элемента массива предыдущий?

SELECT arrayDifference(...)(

SELECT arrayDifference(...)(

Это разница между массивами

нет

Требуется что-то типа array[2] - array[1]?

SELECT arrayDifference(values) FROM ( SELECT [3, -1, -1, -1, -1, -1, 3, -10, 1] AS values ) ┌─arrayDifference(values)─┐ │ [0,-4,0,0,0,0,4,-13,11] │ └─────────────────────────┘

Подскажите как корректно обновлять значения счетчика в таблице? Пробую так CREATE TABLE msg_log ( created_at DateTime DEFAULT now(), pid String, psid String, mid String, is_delivered UInt8 DEFAULT CAST(0, 'UInt8'), is_read UInt8 DEFAULT CAST(0, 'UInt8') ) ENGINE = ReplacingMergeTree() PARTITION BY toYYYYMM(created_at) ORDER BY (pid, psid, mid) SETTINGS index_granularity = 8192; INSERT INTO msg_log(pid,psid,mid) VALUES('AB','CD','EF'); INSERT INTO msg_log SELECT created_at, pid, psid, mid, 1, is_read FROM msg_log WHERE pid = 'AB' AND psid = 'CD' AND mid = 'EF'; INSERT INTO msg_log SELECT created_at, pid, psid, mid, is_delivered, 1 FROM msg_log WHERE pid = 'AB' AND psid = 'CD' AND mid = 'EF'; В итоге при запросе SELECT * FROM msg_log FINAL ожидаю что is_delivered = 1 и is_read = 1 а по факту вижу только is_read = 1

Как я понимаю такие апдейты это не кликхаус вей?

спасибо! я не нашел в документации, только *runningDifference*

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

в system.mutations

будет признак завершения

is_done и parts_to_do

ага спасибо еще идет значит все ок

Подскажите пожалуйста по поводу настроек RAID: В документации в https://clickhouse.yandex/docs/ru/operations/tips/ говорится такое: > Включите NCQ с длинной очередью. Для HDD стоит выбрать планировщик CFQ, а для SSD — noop. Не стоит уменьшать настройку readahead. На HDD стоит включать кеш записи. Что подразумевается под кешом записи? SSD с writeback? RAID с батарейкой? Но это же означает аппаратный рейд, а чуть выше там рекомендуют mdadm

Спрашиваю потому, что у нас при отностительно невысокой (как мне кажется) нагрузке на чтение в 150 мбайт/сек (наливка новой реплики) начинает существенно деградировать производительность диска. Хотелось бы понять, что с этим можно сделать.

Коллеги, можно очень общий вопрос по производительности кликхауса. Надо писать около 200 000 метрик в секунду. Размер метрики около 50 байт. На что по железу надо рассчитывать?

10МБ/сек

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

Подскажите пожалуйста по поводу настроек RAID: В документации в https://clickhouse.yandex/docs/ru/operations/tips/ говорится такое: > Включите NCQ с длинной очередью. Для HDD стоит выбрать планировщик CFQ, а для SSD — noop. Не стоит уменьшать настройку readahead. На HDD стоит включать кеш записи. Что подразумевается под кешом записи? SSD с writeback? RAID с батарейкой? Но это же означает аппаратный рейд, а чуть выше там рекомендуют mdadm

у hdd дисков можно включить / выключить кеш записи через hdparm https://linuxconfig.org/improve-hard-drive-write-speed-with-write-back-caching нагрузке на чтение в 150 мбайт/сек -- это макс. скорость которую может выдать hdd, у вас надо головы туда сюда двигать для разных операций, но проблема может быть и очередях блочных устройств -- слишком длинные, а операции io -- непрерываемые.

write-back caching

то есть барьеры записи того

и данные в теории тоже

но всё равно спасибо

скорее всего ваша проблема не в этом, попробуйте померяте iops (с помощью fio) 100% чтения, 100% записи, 80% чтения 20% записи.

Подскажите как корректно обновлять значения счетчика в таблице? Пробую так CREATE TABLE msg_log ( created_at DateTime DEFAULT now(), pid String, psid String, mid String, is_delivered UInt8 DEFAULT CAST(0, 'UInt8'), is_read UInt8 DEFAULT CAST(0, 'UInt8') ) ENGINE = ReplacingMergeTree() PARTITION BY toYYYYMM(created_at) ORDER BY (pid, psid, mid) SETTINGS index_granularity = 8192; INSERT INTO msg_log(pid,psid,mid) VALUES('AB','CD','EF'); INSERT INTO msg_log SELECT created_at, pid, psid, mid, 1, is_read FROM msg_log WHERE pid = 'AB' AND psid = 'CD' AND mid = 'EF'; INSERT INTO msg_log SELECT created_at, pid, psid, mid, is_delivered, 1 FROM msg_log WHERE pid = 'AB' AND psid = 'CD' AND mid = 'EF'; В итоге при запросе SELECT * FROM msg_log FINAL ожидаю что is_delivered = 1 и is_read = 1 а по факту вижу только is_read = 1

вам FINAL надо всегда INSERT INTO msg_log SELECT created_at, pid, psid, mid, 1, is_read FROM msg_log FINAL WHERE pid = 'AB' AND psid = 'CD' AND mid = 'EF'; INSERT INTO msg_log SELECT created_at, pid, psid, mid, is_delivered, 1 FROM msg_log FINAL WHERE pid = 'AB' AND psid = 'CD' AND mid = 'EF'; SELECT created_at, pid, psid, mid, is_delivered, 1 FROM msg_log FINAL :-] WHERE pid = 'AB' AND psid = 'CD' AND mid = 'EF'; ┌──────────created_at─┬─pid─┬─psid─┬─mid─┬─is_delivered─┬─1─┐ │ 2018-09-27 12:26:19 │ AB │ CD │ EF │ 1 │ 1 │ └─────────────────────┴─────┴──────┴─────┴──────────────┴───┘ на миллиардах все это не заработает. вам надо summingmergetree использовать, и только insert ... без всяких селект из самой таблицы

вам FINAL надо всегда INSERT INTO msg_log SELECT created_at, pid, psid, mid, 1, is_read FROM msg_log FINAL WHERE pid = 'AB' AND psid = 'CD' AND mid = 'EF'; INSERT INTO msg_log SELECT created_at, pid, psid, mid, is_delivered, 1 FROM msg_log FINAL WHERE pid = 'AB' AND psid = 'CD' AND mid = 'EF'; SELECT created_at, pid, psid, mid, is_delivered, 1 FROM msg_log FINAL :-] WHERE pid = 'AB' AND psid = 'CD' AND mid = 'EF'; ┌──────────created_at─┬─pid─┬─psid─┬─mid─┬─is_delivered─┬─1─┐ │ 2018-09-27 12:26:19 │ AB │ CD │ EF │ 1 │ 1 │ └─────────────────────┴─────┴──────┴─────┴──────────────┴───┘ на миллиардах все это не заработает. вам надо summingmergetree использовать, и только insert ... без всяких селект из самой таблицы

Да я буквально с полчаса назад переписать на SummingMergeTree. Вы правы с постоянными SELECT при вставке получаются неоднозначные результаты

к тому же на движке SummingMergeTree если в таблице одна запись с полем для суммирования 0, то при SELECT FINAL мы ничего не получаем

к SummingMergeTree не надо делать final, т.к. "select sum, sum .... group by" возвращает финальный результат.

In file included from /root/rpmbuild/BUILD/ClickHouse-f483e4cb051e0ccb8f3866c609754fce9fa9034f/contrib/zlib-ng/zutil.h:28:0, from /root/rpmbuild/BUILD/ClickHouse-f483e4cb051e0ccb8f3866c609754fce9fa9034f/contrib/zlib-ng/adler32.c:9: /root/rpmbuild/BUILD/ClickHouse-f483e4cb051e0ccb8f3866c609754fce9fa9034f/contrib/zlib-ng/zlib.h:1819:66: error: unknown type name 'va_list' ZEXTERN int ZEXPORTVA gzvprintf(gzFile file, const char *format, va_list va);

никто не сталкивался?

судя по zlib.h/zconf.h stdarg должен включаться всегда

а учитывает кх свободное место при мутациях ?

Привет! Подскажите, есть ли в кликхаусе какой-нибудь механизм ротирования system.query_log?

а учитывает кх свободное место при мутациях ?

да, кажется так же как и при мержах, этот вопрос был тут https://events.yandex.ru/lib/talks/6167/

спс , почитаю и посмотрю

Для тех, кто использует Kotlin в связке с КЦ, советую очень интересную либу для облегчения рутины: https://github.com/TanVD/AORM.

Привет! Подскажите, есть ли в кликхаусе какой-нибудь механизм ротирования system.query_log?

t.me/clickhouse_ru/14957

t.me/clickhouse_ru/14957

thx!

Попробовал с aggregatingMergeTree - все работает как надо Есть вопрос по ReplacingMergeTree - почему игнорируется условие WHERE ? https://gist.github.com/lanwen/206c9aa6740a4f2728c1f88610c55dd6

BTW если кому интересно как вышло с AggregatingMergeTree https://gist.github.com/lanwen/211f5a6dc7a463bdf364099850b8efcc

Попробовал с aggregatingMergeTree - все работает как надо Есть вопрос по ReplacingMergeTree - почему игнорируется условие WHERE ? https://gist.github.com/lanwen/206c9aa6740a4f2728c1f88610c55dd6

А зачем при создании lanwen.anonymous_replacing подзапрос? Возможно из-за него не отфильтровало

а как это без подзапроса написать?