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

Друзья, помогите решить проблемку: Есть материалайзед вьюха CREATE MATERIALIZED VIEW defult.users ENGINE = ReplacingMergeTree PARTITION BY tuple() ORDER BY (subjectId) POPULATE AS SELECT subjectId, min(if( eventType = 'user/added', timestamp, null )) as createdAt, anyLast(if( eventType = 'user/updated', timestamp, null )) AS updatedAt FROM ( SELECT subjectId, eventType, timestamp, event FROM default.events WHERE eventType in ('user/added', 'user/updated') ORDER BY timestamp ) GROUP BY subjectId если сделать запрос из вьюхи - то возвращается один элемент, если селект по вьюхе, то user_282a1503-918a-4854-b064-169a5b2fb2b9 null 2018-09-26 13:27:49 user_282a1503-918a-4854-b064-169a5b2fb2b9 2018-09-17 17:05:05 2018-09-17 17:18:42 т.е. дедубликация не сработала. Конечно в доке написано что реплейсинг сделан для экономии места, но неужели нет возможности хоть сколько нибудь гарантировать отсутствие повторов? Связанная с этим проблема - что нельзя дать доступ к обычной вьюхе не давая доступа к оригинальной табличке - это можно как то обойти?

Напрямую никак. Можно сделать вьюху поверх матвьюхи, и в этой вьюхе сделать что-то типа SELECT * FROM defult.users FINAL Тогда будет гаранития, что не будет дублей. И отдельная таблица-вьюха

Напрямую никак. Можно сделать вьюху поверх матвьюхи, и в этой вьюхе сделать что-то типа SELECT * FROM defult.users FINAL Тогда будет гаранития, что не будет дублей. И отдельная таблица-вьюха

О, это интересно. Но есть еще одна проблема с этим - почему то матвьюха добавила элемент который потерял createdAt (будто селект отработал на части только). отсюда последний элемент на самом деле неправильный мерж - откуда такое поведение?

Потому что матвьюха работает так: 1. идет инсерт данных в исходную таблицу 2. КХ выполняет запрос матвьюхи над ВСТАВЛЯЕМЫМИ данными 3. результат вставляет в матвьюху Насчёт createdAt не понял, нужно больше деталей

- в оригинале было 2 эвента user/created, user/updated при популейте взяли сгруппировали оба и получили строку с createdAt, updatedAt. -Приехал еще один user/updated в источник. - В матвьюхе получился еще один элемент, но в котором не createdAt + updatedAt последнего элемента, а null вместо createdAt. Будто весь запрос сделали только над этим одним 3м эвентом

А timestamp что содержит в строке где потеряно значение createdAt

<null>

т.е. как бы не противоречит п.2 твоего ответа

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

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

Например для чего?

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

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

Храните стейты и мержите их в запросе

вот как хранить стейты? Как нам эвент лог превратить в таблицу с стейтами?

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

вот как хранить стейты? Как нам эвент лог превратить в таблицу с стейтами?

https://clickhouse.yandex/docs/ru/single/#aggregatingmergetree

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

стейты наверное считать надо не в КХ

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

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

пасиб в общем, буду пробовать aggregate

У меня снова ворос по бэкапу. Вот я создал табличку create table testdb.test2 (id UInt64, User String) ENGINE MergeTree ORDER BY id Сделал в неё 3 инсерта. Смотрю, что у неё за партиции select partition, partition_id, name from system.parts WHERE database='testdb' AND table='test2' ┌─partition─┬─partition_id─┬─name──────┐ │ tuple() │ all │ all_1_1_0 │ │ tuple() │ all │ all_2_2_0 │ │ tuple() │ all │ all_3_3_0 │ └───────────┴──────────────┴───────────┘ Какая-то лажа. Делаю ALTER TABLE testdb.test2 FREEZE PARTITION 'all' Получаю: Wrong number of fields in the partition expression: 1, must be: 0 Что я делаю не так?

Что это за tuple() и all?

tuple() - это тупл арности 0. используется в качестве типа, имеющего одно значение. подходит для случая, когда надо не партиционировать таблицу, а значит сделать для нее одну партицию.

а вот почему id партиции не подходит в запрос - это интересно.

а freeze partition tuple() работает?

нет, тоже не работает

о! кажется сработло!

я её как строку передавал)

спасибо!

пасиб в общем, буду пробовать aggregate

пример https://gist.github.com/den-crane/6eff375752a236a456e1b3dc2ca7db62 пример как сделать "популейт" через null таблицу https://gist.github.com/den-crane/a72614fbe6d23eb9c2f1bce40c66893f

Подскажите - не могу понять причину. Вот такой вот запрос работает: select sc_ID, sc_CAMPAIGN_ID, sc_SUBSCRIPTION_ID, su.ACCOUNT_ID su_ACCOUNT_ID, sb_VALUE2, su.ID su_ID from (SELECT sc_ID, sc_CAMPAIGN_ID, sc_SUBSCRIPTION_ID, toDecimal64(toFloat64(sb.VALUE2),3) sb_VALUE2 FROM ( select ID sc_ID, CAMPAIGN_ID sc_CAMPAIGN_ID, SUBSCRIPTION_ID sc_SUBSCRIPTION_ID from external_data.rator_subscription_campaign WHERE FROM_DATE >= toDateTime('2018-08-01 00:00:00') AND FROM_DATE < toDateTime('2018-09-01 00:00:00')) ANY INNER JOIN external_data.rator_subscription_bundle sb ON sc_SUBSCRIPTION_ID = sb.SUBSCRIPTION_ID AND sc_ID = sb.SUBSCRIPTION_CAMPAIGN_ID) ANY INNER JOIN external_data.rator_subscription su ON su.ID = sc_SUBSCRIPTION_ID

Но если его дополнительно завернуть (немного упрощенно): select sc_ID from ( select sc_ID, sc_CAMPAIGN_ID, sc_SUBSCRIPTION_ID, su.ACCOUNT_ID su_ACCOUNT_ID, sb_VALUE2, su.ID su_ID from (SELECT sc_ID, sc_CAMPAIGN_ID, sc_SUBSCRIPTION_ID, toDecimal64(toFloat64(sb.VALUE2),3) sb_VALUE2 FROM ( select ID sc_ID, CAMPAIGN_ID sc_CAMPAIGN_ID, SUBSCRIPTION_ID sc_SUBSCRIPTION_ID from external_data.rator_subscription_campaign WHERE FROM_DATE >= toDateTime('2018-08-01 00:00:00') AND FROM_DATE < toDateTime('2018-09-01 00:00:00')) ANY INNER JOIN external_data.rator_subscription_bundle sb ON sc_SUBSCRIPTION_ID = sb.SUBSCRIPTION_ID AND sc_ID = sb.SUBSCRIPTION_CAMPAIGN_ID) ANY INNER JOIN external_data.rator_subscription su ON su.ID = sc_SUBSCRIPTION_ID) то получаю ошибку: Received exception from server (version 18.12.17): Code: 179. DB::Exception: Received from localhost:9000, 127.0.0.1. DB::Exception: Different expressions with the same alias su_ACCOUNT_ID: su.ACCOUNT_ID AS su_ACCOUNT_ID and ACCOUNT_ID AS su_ACCOUNT_ID

Коллеги, всем привет. Сталкиваемся с ошибкой при установке зафиксированной версии Get:24 http://repo.yandex.ru/clickhouse/deb/stable/ main/ clickhouse-server-common 1.1.54394 [7856 B] Fetched 282 MB in 2min 2s (2310 kB/s) E: Failed to fetch http://repo.yandex.ru/clickhouse/deb/stable/main/clickhouse-server-common_1.1.54318_amd64.deb Size mismatch E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?

Но если его дополнительно завернуть (немного упрощенно): select sc_ID from ( select sc_ID, sc_CAMPAIGN_ID, sc_SUBSCRIPTION_ID, su.ACCOUNT_ID su_ACCOUNT_ID, sb_VALUE2, su.ID su_ID from (SELECT sc_ID, sc_CAMPAIGN_ID, sc_SUBSCRIPTION_ID, toDecimal64(toFloat64(sb.VALUE2),3) sb_VALUE2 FROM ( select ID sc_ID, CAMPAIGN_ID sc_CAMPAIGN_ID, SUBSCRIPTION_ID sc_SUBSCRIPTION_ID from external_data.rator_subscription_campaign WHERE FROM_DATE >= toDateTime('2018-08-01 00:00:00') AND FROM_DATE < toDateTime('2018-09-01 00:00:00')) ANY INNER JOIN external_data.rator_subscription_bundle sb ON sc_SUBSCRIPTION_ID = sb.SUBSCRIPTION_ID AND sc_ID = sb.SUBSCRIPTION_CAMPAIGN_ID) ANY INNER JOIN external_data.rator_subscription su ON su.ID = sc_SUBSCRIPTION_ID) то получаю ошибку: Received exception from server (version 18.12.17): Code: 179. DB::Exception: Received from localhost:9000, 127.0.0.1. DB::Exception: Different expressions with the same alias su_ACCOUNT_ID: su.ACCOUNT_ID AS su_ACCOUNT_ID and ACCOUNT_ID AS su_ACCOUNT_ID

Сталкивался. У вас случайно в запросе нет вьюх? В любом случае попробуйте выключите оптимизацию условий во вьюхах enable_optimize_predicate_expression

все таблицы в запросе dictionary, может в этом дело, кстати. параметр попробуем включить, спасибо

пасиб в общем, буду пробовать aggregate

зависит от количества стейтов на объект, у меня похожая задача, но количество апдейтов на один объект небольшое (при большом кол-ве объектов), в результате запрос по таблице с евентами работает чуть быстрее чем подобный из AggMV. Ну и еще мне надо считать количество объектов в группе в каждом стейте в случайном интервале времени (счетчик по группе). Пока не понимаю как это сделать через AggMV

@milovidov_an подскажите, когда ожидается следующая stable версия, которая решает проблему memory tracking https://github.com/yandex/ClickHouse/issues/3143?

все таблицы в запросе dictionary, может в этом дело, кстати. параметр попробуем включить, спасибо

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

коллеги, так как лечить Block structure mismatch in UNION stream: different names of columns: ? откатывать сервер?

ok, понял, выключим :)

Коллеги, всем привет. Сталкиваемся с ошибкой при установке зафиксированной версии Get:24 http://repo.yandex.ru/clickhouse/deb/stable/ main/ clickhouse-server-common 1.1.54394 [7856 B] Fetched 282 MB in 2min 2s (2310 kB/s) E: Failed to fetch http://repo.yandex.ru/clickhouse/deb/stable/main/clickhouse-server-common_1.1.54318_amd64.deb Size mismatch E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?

Ну тут либо сделать апт апдейт либо руками посмотреть есть ли вообще эта версия в репозитории

коллеги, так как лечить Block structure mismatch in UNION stream: different names of columns: ? откатывать сервер?

Может запрос поправить?

Может запрос поправить?

он очень простой, select & where без каких либо вычислений

те есть версия эта

почему же http://repo.yandex.ru/clickhouse/deb/stable/main/clickhouse-server-common_1.1.54318_amd64.deb Size mismatch

Скажите, а можно ли при SELECT из AggregateMergeTree задавать в WHERE границы по времени, то есть, выполнить aggregate функцию только по событиям, которые попадают в диапазон? И если да, то я не понимаю, за счет чего должен получаться выигрыш по скорости по сравнению с подобной Aggregate операцией над обычным MergeTree? Если я правильно понимаю работу AggMT, то выигрыш должен получаться за счет хранения стейта и пересчете стейта при INSERT вместо SELECT. Но при выборке случайного диапазона по датам стейт не участвует (его надо считать опять, начиная с обработки первой записи в диапазоне). Помогите разобраться пожалуйста

возможно вопрос относится скорее к AggregateMV

появился новый синтаксис Engine=MergeTree partition by tuple() order by tuple() не могу найти в документации что это означает, ткните пожалуйста

Если событий много, а нужно их анализировать за широкий диапазон дат - то да, предварительная агрегация имеет смысл. В кликхаус это очень удобно делать с помощью Materialized View в таблицу с движком AggregatingMergeTree. Тогда всякие "неудобные" в агрегации метрики (типа количества уникальных пользователей) можно корректно суммировать.

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

@milovidov_an подскажите, когда ожидается следующая stable версия, которая решает проблему memory tracking https://github.com/yandex/ClickHouse/issues/3143?

Исправления MemoryTracker ещё нет. Как раз собирался либо его делать, либо выпускать ещё одну stable версию пока без исправления.

Tuple() = пустой кортеж. Использование его в качестве ключа партиционирования = отсутствие партиционирования (одна большая партиция)

В качестве первичного ключа - данные без сортировки.

Tuple() = пустой кортеж. Использование его в качестве ключа партиционирования = отсутствие партиционирования (одна большая партиция)

спасибо

Также можно не указывать секцию PARTITION BY.

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

Я с телефона. Кое какие примеры есть у @den_crane https://gist.github.com/den-crane И в тестах кликхауса.

В тестах КХ например тут https://github.com/yandex/ClickHouse/blob/0eed697623afd251c1908073c4a2850a9bfc9cdc/dbms/tests/queries/0_stateless/00384_column_aggregate_function_insert_from.sql

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

100500 раз уже это с вами и обсуждали, зачем вам вообще это надо? И я бы сделал по другому, просто по концу дня расчитывал конкретные цифры и складывал в отдельную табличку, по часам /дням, готовые цифры, а не стейты, потому что uniqstate это надо еще доагрегировать дофига.

100500 раз уже это с вами и обсуждали, зачем вам вообще это надо? И я бы сделал по другому, просто по концу дня расчитывал конкретные цифры и складывал в отдельную табличку, по часам /дням, готовые цифры, а не стейты, потому что uniqstate это надо еще доагрегировать дофига.

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

Т.е. если вчера на этом телеграмм канале было 1800 пользователей , а сегодня 1810, то всего было вовсе не 3610?

UniqState (не uniqExactState) относительно компактный, доагрегация вовсе не так страшна.

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

да обсуждали все это уже все миллиард раз t.me/clickhouse_ru/61723

и в прошлый раз вышло у товарища, что по таблице считать быстрее чем по MV

и в прошлый раз вышло у товарища, что по таблице считать быстрее чем по MV

Ну в твоём примере перевес явно на стороне MV, правда?

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

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

да, но есть у меня ощущение что последний раз закончилось это все вот так t.me/clickhouse_ru/64797

Ага

но может я уже запутался в обсуждениях. И в общем хотелось бы понять зачем это надо (в чем задача), а то спрашиватели делают супергранулярные MV, а потом удивляются, что медленней чем оригинальная таблица.

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

@den_crane не расстраивайтесь так ;) кликхауса быстрый, даже если его заставить какую-то лишнюю работу делать он обычно делает это быстро :)

@den_crane не расстраивайтесь так ;) кликхауса быстрый, даже если его заставить какую-то лишнюю работу делать он обычно делает это быстро :)

Ну не скажите, я вчера лишней работой его на пол часа загрузил =(

Ну не скажите, я вчера лишней работой его на пол часа загрузил =(

В целом наложились много факторов, но факт есть факт.

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

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

Ну не скажите, я вчера лишней работой его на пол часа загрузил =(

Бывает :) я тут обнаружил что у нас в одном скрипте из-за переименования столбца в запросе не использовался индекс, и для какой-то ерунды раз в полчаса был фулскан :D автор скрипта думал что все нормально, т.к. перед этим то же самое работало на mysql с индексами, и при этом было медленнее чем фулскан на КХ :D

Бывает :) я тут обнаружил что у нас в одном скрипте из-за переименования столбца в запросе не использовался индекс, и для какой-то ерунды раз в полчаса был фулскан :D автор скрипта думал что все нормально, т.к. перед этим то же самое работало на mysql с индексами, и при этом было медленнее чем фулскан на КХ :D

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

Я про вот эту историю

Я про вот эту историю

Да, я читал, и что-то там писал днём.

Неприятная штука.

а так понял что clear column используется чтобы схлопнуть старые записи ? а чем тогда готовые движки типа графит чего-то там не подходят?

В принципе альтер drop/detach относильно безопасны по идее можно было бы наверное не ставить локов, а просто сразу помечать партиции для удаления. Но есть риск что что-то может поломаться при этом.

а так понял что clear column используется чтобы схлопнуть старые записи ? а чем тогда готовые движки типа графит чего-то там не подходят?

Там вроде был просто alter drop partition запущенный одновременно с длинным селектом.

Альтер ждал пока кончится селект, остальные селекты ждали когда кончится альтер.

Там вроде был просто alter drop partition запущенный одновременно с длинным селектом.

Да

Альтер ждал пока кончится селект, остальные селекты ждали когда кончится альтер.

Именно

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

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

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

А если длинный селект во время которого запустится альтер

Можно убить SELECT с помощью KILL QUERY.

Можно убить SELECT с помощью KILL QUERY.

По законам жанра окажется что это был селект шефа, и у него уже "показывало 99%" :)

порой мне кажется что для селектов когда последняя стадия выполнения по времени непонятная (типа чтения group by с диска) лучше показывать ну скажем 95% вместо 99 :)

Можно убить SELECT с помощью KILL QUERY.

Не убивался

а ReplaceMergeTree матвьюху должна триггерить обычная вьюха которая финальная, поверх aggregatedMergeTree? (у меня не триггерится)

а ReplaceMergeTree матвьюху должна триггерить обычная вьюха которая финальная, поверх aggregatedMergeTree? (у меня не триггерится)

нет, MV на MV сделать нельзя. И смысла делать replace поверх Aggregating нет. Aggregating и так схлапывает

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

Исправления MemoryTracker ещё нет. Как раз собирался либо его делать, либо выпускать ещё одну stable версию пока без исправления.

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