Планируем чуть позже.

Спасибо.

Будем ждать?

Планируем чуть позже.

Киев?

Поможете с анонсированием? :)

в Киеве

Мы поможем)

Здорово. Собираем чемоданы :)

Отлично, Харьков уже спит на чемоданах)

Давайте в Харькове

Подскажите, а MATERIALIZED VIEW на движке AggregatingMergeTree содержит аггрегированные данные сразу после insert в таблицу на которую смотрит, или должно пройти какое то время?

По идее -- сразу. Операция атомарная с insert.

Я чет если много данных заливаю сразу, результаты не сходятся.

Друзья! Открылась регистрация на ClickHouse митап в Новосибирске 3 апреля. Регистрируйтесь и делитесь новостью с коллегами в сибирском регионе. https://twitter.com/ya_events/status/843771103441010689 https://vk.com/yandex.events?w=wall-17796776_5203 https://www.facebook.com/Yandex.Events/photos/a.207908329229296.53451.122612334425563/1475215179165265/?type=3&theater

жаль что 3, а не 31. многие как раз приезжают к кодфесту в пятницу вечером. кодфест 1,2 апреля

Давайте в Харькове

+3 так точно) да и Харьков ближе ?

А в СПб?)

Подскажите, а MATERIALIZED VIEW на движке AggregatingMergeTree содержит аггрегированные данные сразу после insert в таблицу на которую смотрит, или должно пройти какое то время?

Нет, агрегации приходит в фоне. Поэтому надо всегда считать, что данные недоагрегированные и доагрегировать запросом.

Нет, агрегации приходит в фоне. Поэтому надо всегда считать, что данные недоагрегированные и доагрегировать запросом.

А вот если результат доагрегации не сходится с реальными агрегатами?)

Ну т.е. я делаю запрос с count и group by в таблицу сырых данных, а потом доагрегирующий запрос в view агрегатов. И данные не сходятся.

Причем это как то зависит от обьема. Когда мало данных заливаю, все ок.

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

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

выхлоп в TSV и импорт через клиент. А вообще зависит от данных.

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

есть c++ клиент/либа в разработке, https://github.com/artpaul/clickhouse-cpp но это не си, конечно

выхлоп в TSV и импорт через клиент. А вообще зависит от данных.

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

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

да просто вопрос странный. У Clickhouse есть все мыслимые и немыслимые интерфейсы вплоть до http. Как удобнее так и лейте.

от языка то не особо зависит. Если только вы не планируете в КХ класть прямо готовые партиции в его формате

от языка то не особо зависит. Если только вы не планируете в КХ класть прямо готовые партиции в его формате

Ну просто я не очень сведущ в особенностях нативного си, насколько там просто выдать в потом данные массивом, тем более на виндовой платформе. Посему если бы был плагин/либа/модуль который сам знает как портировать данные на сервер, а я бы ему просто скормил массив - это и было бы искомым для меня решением и ответом на вопрос.

@ewgeniyk такое есть и для С++ и для го

в чем проблема?

и что такое сишные скрипты?

и что такое сишные скрипты?

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

https://github.com/artpaul/clickhouse-cpp ?

в чем проблема?

Проблема в том, что я не знаю этого решения и поэтому спросил у того кто а) его знает и б) может на него навести

https://github.com/artpaul/clickhouse-cpp ?

спасибо, ознакомлюсь

но это С++

CH написан на нем и я не уверен, что стоит ожидать версии на чистом С от авторов (исправьте, если я не прав)

привет. а данные между репликами сразу переливаются? переезжаем из одного сервера кликхауса в кластер, сделали 3 шарда по 2 реплики (связь 1-2, 3-4, 5-6). создал везде таблицы test, на 1-м сервере distributed-таблицу. вставил по одной строке в 1, 2, 3 ноды. теперь при селекте вижу то 1 запись, то 2. получается, что между 3-й и 4-й нодами данные не перелились?

не сразу

Вот ещё - репликация асинхронная мульти-мастер, то есть на реплике может не быть свежих данных.

спасибо. а как в таком случае добиться селекта свежих данных из distributed-таблицы?

никак, полагаю делать селект не из distributed таблицы, а из mergetree (или какой там) таблицы на сервере, на который инсертятся данные

ясно, спасибо.

Сейчас можно мониторить отставание реплик, например получая информацию из http://localhost:8123/replicas_status?verbose=1

Если у вас одна строчка долго реплицируется, возможно что-то не в порядке с конфигурацией

В будущем планируем сделать отстреливание сильно отстающих реплик

Всем добрый день. Спрошу повторно, может кто подскажет. Создаю таблицу, и MATERIALIZED VIEW с движком AggregatingMergeTree следящее за ней. Заливаю данные. Делаю селект из вьюхи с доагрегацией и селект из таблицы сырых данных. Результаты агрегатов не сходятся. Причем если залить данных не много, то все ок.

В какую сторону смотреть?

около 5 минут ждал пока не долилось. конфиг похож на тот, который в документации, только добавлен еще 1 шард.

Если у вас одна строчка долго реплицируется, возможно что-то не в порядке с конфигурацией

А в логах есть какие-нибудь ошибки?

Всем добрый день. Спрошу повторно, может кто подскажет. Создаю таблицу, и MATERIALIZED VIEW с движком AggregatingMergeTree следящее за ней. Заливаю данные. Делаю селект из вьюхи с доагрегацией и селект из таблицы сырых данных. Результаты агрегатов не сходятся. Причем если залить данных не много, то все ок.

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

Не знаю как телеграм отнесется к форматированию. Но попробуем)

/* Создаем таблицу */ CREATE TABLE events ( user_id Int64, event_id Int64, event_date Date ) ENGINE = MergeTree(event_date, (user_id), 8192); /* Создаем MATERIALIZED VIEW следящее за таблицей events */ CREATE MATERIALIZED VIEW events_agg ENGINE = AggregatingMergeTree(event_date, (event_id, user_id), 8192) AS SELECT event_date, event_id, user_id, countState(event_id) AS count_of_events FROM events GROUP BY event_id, user_id, event_date;

Заливаю данные

Затем 2 запроса для сверки

/* Делаем выборку из таблцы сырых данных. я получаю результат: ┌─event_date─┬─event_id─┬─user_id─┬─count(event_id)─┐ │ 2016-02-09 │ 3402641 │ 2136 │ 7 │ └────────────┴──────────┴─────────┴─────────────────┘ */ SELECT event_date, event_id, user_id, count(event_id) FROM events where event_id = 3402641 and event_date = '2016-02-09' and user_id = 2136 GROUP BY event_id, user_id, event_date;

/* Делаем выборку из VIEW с аггрегатами 0 rows in set. Elapsed: 0.004 sec. Processed 24.58 thousand rows, 1.02 MB (5.66 million rows/s., 234.94 MB/s.) */ SELECT event_date, event_id, user_id, countMerge(count_of_events) FROM events_agg where event_id = 3402641 and event_date = '2016-02-09' and user_id = 2136 GROUP BY event_id, user_id, event_date;

ENGINE = MergeTree(event_date, (user_id), 8192);

event_id не потерялся?

Но вообще-то странно выглядит. Такой именно сценарий мы не пробовали, но SummingMergeTree работает без нареканий

Всем привет. Пытаемся вставить достаточно большую пачку в кликхаус, через http. Ругается ошибкой: Code: 36, e.displayText() = DB::Exception: Element of set in IN or VALUES is not a constant expression: toDate, e.what() = DB::Exception В каком случае это может быть?

Но вообще-то странно выглядит. Такой именно сценарий мы не пробовали, но SummingMergeTree работает без нареканий

Я может что-то не верно делаю. У меня задача получить таблицу с сырыми данными и таблицу с автообновляемыми агрегатами рядом.

это не та же проблема?

Так и есть. Обычно INSERT предназначен для вставки готовых данных в заданном формате и не умеет выполнять выражения (такие как toDate(now()) или то же самое - today()). В качестве исключения, возможность выполнять выражения, была добавлена в формат Values. Но эта возможность добавлена в очень ограниченном виде. Во-первых, производительность вставки будет очень низкой. Во-вторых, она работает в пределах размера данных, помещающихся в буфер (~1 МБ), и в случае большего размера, выдаётся недостаточно хорошая диагностика - именно это вы наблюдаете. Поэтому я предлагаю всё-таки указывать конкретное значение даты в виде '2017-03-19'.

Понятно, спасибо.

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

Вообще, мы пытаемся вставить toDate от таймстемпа, а можно ли вообще не делать этого преобразования, а сразу таймстемп вставлять в Date поле?

Надо объявить в таблице примерно так: date Date DEFAULT toDate(timestamp) и затем при INSERT в списке полей INSERT INTO t (c1, c2, ...) VALUES не указывать этот столбец. Тогда для него значение будет вычисляться при вставке само.

Спасибо!

Подскажите, пожалуйста, подобное поведение ch с Date и DateTime норма, или будет меняться? При вставке значений '1970-01-01' и '1970-01-01 00:00:00' соответственно, ch их в селектах выдаёт как '0000-00-00' и '0000-00-00 00:00:00', а самое противное, их же функция max() выдаёт.

Надо объявить в таблице примерно так: date Date DEFAULT toDate(timestamp) и затем при INSERT в списке полей INSERT INTO t (c1, c2, ...) VALUES не указывать этот столбец. Тогда для него значение будет вычисляться при вставке само.

#faq! отличная пара вопрос-ответ, многим пригодится, имхо :)

Подскажите, пожалуйста, подобное поведение ch с Date и DateTime норма, или будет меняться? При вставке значений '1970-01-01' и '1970-01-01 00:00:00' соответственно, ch их в селектах выдаёт как '0000-00-00' и '0000-00-00 00:00:00', а самое противное, их же функция max() выдаёт.

в доке описано в т.ч. то, что может поменяться > Date представлены как UInt16, содержащий количество дней, прошедших с 1970-01-01 в качестве значения. > Позволяет хранить значения от чуть больше, чем начала unix-эпохи до верхнего порога, определяющегося константой на этапе компиляции (сейчас - до 2038 года, но может быть расширено до 2106 года). > DateTime представлены как UInt32, содержащий unix timestamp в качестве значения.

спасибо, на слова "чуть больше" я внимания не обратил :) Посмотрел: 1970-01-02 нормально сохраняется, 1970-01-01 03:00:01 тоже. В общем, получается что при импорте в ch надо даты править принудительно, если в старой базе они нелевые были

+3 видимо питерский часовой пояс

Как заставить ReplacingMergeTree схлопывать данные?

они сами схлопываются, если хочется именно заставить - можно прогнать OPTIMIZE или сделать запрос с FINAL (будет очень медленно выполняться)

они сами схлопываются, если хочется именно заставить - можно прогнать OPTIMIZE или сделать запрос с FINAL (будет очень медленно выполняться)

А как настроить время до схлопывать? Прошло уже больше часа, а старые строки еще видны

> ReplacingMergeTree > Слияние происходят в фоне, в неизвестный момент времени, на который вы не можете ориентироваться. > Некоторая часть данных может так и остаться необработанной. Хотя вы можете вызвать внеочередное слияние с помощью запроса OPTIMIZE, на это не стоит рассчитывать, так как запрос OPTIMIZE приводит к чтению и записи большого объёма данных. > Таким образом, ReplacingMergeTree подходит для фоновой чистки дублирующихся данных в целях экономии места, но не даёт гарантий отсутствия дубликатов.

Всем добрый день. Спрошу повторно, может кто подскажет. Создаю таблицу, и MATERIALIZED VIEW с движком AggregatingMergeTree следящее за ней. Заливаю данные. Делаю селект из вьюхи с доагрегацией и селект из таблицы сырых данных. Результаты агрегатов не сходятся. Причем если залить данных не много, то все ок.

да, бага воспроизводится, будем..

да, бага воспроизводится, будем..

а я так надеялся что у меня просто руки кривые. Расскажете потом в чем дело было?

Пробовали ли этот алгоритм вместо siphash https://github.com/Cyan4973/xxHash ?

SipHash является криптографической хэш-функцией, а xxHash - нет. Таким образом, сравнение некорректно. xxHash относится к тому же классу, что и, например, CityHash, и его производительность примерно в 10 раз выше, чем SipHash.

> ReplacingMergeTree > Слияние происходят в фоне, в неизвестный момент времени, на который вы не можете ориентироваться. > Некоторая часть данных может так и остаться необработанной. Хотя вы можете вызвать внеочередное слияние с помощью запроса OPTIMIZE, на это не стоит рассчитывать, так как запрос OPTIMIZE приводит к чтению и записи большого объёма данных. > Таким образом, ReplacingMergeTree подходит для фоновой чистки дублирующихся данных в целях экономии места, но не даёт гарантий отсутствия дубликатов.

Для удаления дублей я создал новую таблицу, туда вставил данные через insert... select..., но дубликаты строк все равно остались( С чем это может быть связано?

сегодня наблюдал картину. очень слабый сервер 1ГБ рам и 1 Ядро при инсерте данных, данных исертятся через интернет. в пике видел 112Мбит. СH падает вот с таким сообщением. 2017.03.23 04:06:57.542078 [ 24 ] <Debug> default.events_jan_tv11 (Data): Removing part 20170201_20170201_8592_8592_0 2017.03.23 04:06:57.561428 [ 24 ] <Debug> default.events_jan_tv11 (Data): Removing part 20170201_20170201_8594_8594_0 2017.03.23 04:07:48.955882 [ 15 ] <Trace> TCPConnectionFactory: TCP Request. Address: :39883 2017.03.23 04:07:48.955958 [ 15 ] <Debug> TCPHandler: Connected ClickHouse client version 1.1.54164, user: default. 2017.03.23 04:07:49.808577 [ 15 ] <Debug> executeQuery: (from:39883) INSERT INTO default.events_jan_tv11 format Native 2017.03.23 04:07:54.361222 [ 15 ] <Trace> default.events_jan_tv11 (Data): Renaming tmp_20170202_20170202_8609_8609_0. 2017.03.23 04:07:57.157735 [ 15 ] <Trace> default.events_jan_tv11 (Data): Renaming tmp_20170202_20170202_8611_8611_0. 2017.03.23 04:07:59.579247 [ 15 ] <Trace> default.events_jan_tv11 (Data): Renaming tmp_20170202_20170202_8613_8613_0. Killed запускал прямо из консили. Притензий не имею, добавим РАМа и посмотрим что будет. Это наверное следует рассматривать как информацию о том как посупать не нужно

ООМ Killer пришел?

Видимо да

При желании можно выставить ограничения по памяти, в том числе и менее 1 gb

Тогда падать не должен

сегодня наблюдал картину. очень слабый сервер 1ГБ рам и 1 Ядро при инсерте данных, данных исертятся через интернет. в пике видел 112Мбит. СH падает вот с таким сообщением. 2017.03.23 04:06:57.542078 [ 24 ] <Debug> default.events_jan_tv11 (Data): Removing part 20170201_20170201_8592_8592_0 2017.03.23 04:06:57.561428 [ 24 ] <Debug> default.events_jan_tv11 (Data): Removing part 20170201_20170201_8594_8594_0 2017.03.23 04:07:48.955882 [ 15 ] <Trace> TCPConnectionFactory: TCP Request. Address: :39883 2017.03.23 04:07:48.955958 [ 15 ] <Debug> TCPHandler: Connected ClickHouse client version 1.1.54164, user: default. 2017.03.23 04:07:49.808577 [ 15 ] <Debug> executeQuery: (from:39883) INSERT INTO default.events_jan_tv11 format Native 2017.03.23 04:07:54.361222 [ 15 ] <Trace> default.events_jan_tv11 (Data): Renaming tmp_20170202_20170202_8609_8609_0. 2017.03.23 04:07:57.157735 [ 15 ] <Trace> default.events_jan_tv11 (Data): Renaming tmp_20170202_20170202_8611_8611_0. 2017.03.23 04:07:59.579247 [ 15 ] <Trace> default.events_jan_tv11 (Data): Renaming tmp_20170202_20170202_8613_8613_0. Killed запускал прямо из консили. Притензий не имею, добавим РАМа и посмотрим что будет. Это наверное следует рассматривать как информацию о том как посупать не нужно

См dmesg

root@qsg:/etc/clickhouse-server# dmesg -T [Tue Mar 21 15:36:02 2017] Out of memory in UB 10599: OOM killed process 521 (clickhouse-serv) score 0 vm:2111360kB, rss:1025832kB, swap:456676kB [Thu Mar 23 03:54:15 2017] Out of memory in UB 10599: OOM killed process 22388 (clickhouse-serv) score 0 vm:1519488kB, rss:512880kB, swap:514324kB [Thu Mar 23 04:16:43 2017] Out of memory in UB 10599: OOM killed process 22706 (clickhouse-serv) score 0 vm:1557376kB, rss:505656kB, swap:501556kB