тоже самое

Так. Получается, что если я ставлю в первый раз "1". Затем "-1". Он заменит перевую строку. Что мне теперь вставить, чтобы заменить последнюю вставленную?

1

хотя нет )

Менять 1/-1?

> Здесь Sign - столбец, содержащий -1 для "старых" значений и 1 для "новых" значений. - терминологию не могу понять (

Изначально я подумал, что он сам меняет Sign на -1 при устаревании данных пок какому-то признаку. Но я ошибался.

Я туплю сегодня что-то

одинаковый ключ + строки с Sign = 1 и Sign = -1 просто удалят строку, а новую пишете отдельно

Например мы пишем все события с sign = 1, если нам нужно их "затереть" делаем INSERT INTO (..., sign) events SELECT ..., -1 FROM events

после чего пишем новые с sign=1

Вроде понял, спасибо

Встречался ли кто-то с проблемой потери строк при вставке? Есть самописный сишный демон, который читает сислог, собирает его в батчи (100к), и отправляет в кликхаус по HTTP (INSERT ... FORMAT Values). Грубо говоря, лог показов, сырой. Есть еще сгруппированный лог показов, который льется в мускуль. Так вот, иногда бывает, что они не совпадают по количеству за сутки, дельта порядка сотен тысяч строк (иногда 50к, иногда 400к) при 200 млн за сутки. В логах ни у демона, ни у кликхауса ничего по этому поводу нет. Но! Когда берешь сислог за этот день (он отдельно еще складируется), и заливаешь его руками в соседнюю таблицу - совпадает. То есть, единственное куда грешить - это заливка данных. Таблица ReplicatedMergeTree. Много селектов и записи данных, процы и диски загружены по самое не балуй, но в репликации ошибок нет, работает без сбоев, селекты селектятся быстро. В новогодние праздники не было "ни единого разрыва", а перед новым годом почти каждый день. То есть грешу на высокую нагрузку, но критических значений железо вроде не превышает, в логах пусто. Обещают новые мощные серваки, но пока их нет, а проблема есть. Может ли такое быть, что демон отправил INSERT, КХ ему ответил "200 OK", но в результате каких-то затупов zookeeper отвалился по таймауту (такое иногда проскакивает), и поэтому данные не вставились?

Встречался ли кто-то с проблемой потери строк при вставке? Есть самописный сишный демон, который читает сислог, собирает его в батчи (100к), и отправляет в кликхаус по HTTP (INSERT ... FORMAT Values). Грубо говоря, лог показов, сырой. Есть еще сгруппированный лог показов, который льется в мускуль. Так вот, иногда бывает, что они не совпадают по количеству за сутки, дельта порядка сотен тысяч строк (иногда 50к, иногда 400к) при 200 млн за сутки. В логах ни у демона, ни у кликхауса ничего по этому поводу нет. Но! Когда берешь сислог за этот день (он отдельно еще складируется), и заливаешь его руками в соседнюю таблицу - совпадает. То есть, единственное куда грешить - это заливка данных. Таблица ReplicatedMergeTree. Много селектов и записи данных, процы и диски загружены по самое не балуй, но в репликации ошибок нет, работает без сбоев, селекты селектятся быстро. В новогодние праздники не было "ни единого разрыва", а перед новым годом почти каждый день. То есть грешу на высокую нагрузку, но критических значений железо вроде не превышает, в логах пусто. Обещают новые мощные серваки, но пока их нет, а проблема есть. Может ли такое быть, что демон отправил INSERT, КХ ему ответил "200 OK", но в результате каких-то затупов zookeeper отвалился по таймауту (такое иногда проскакивает), и поэтому данные не вставились?

200 ОК при вставке в ReplicatedMergeTree возвращается только после записи пачки данных в файловую систему и регистрации этого куска данных в ZooKeeper. От нагрузки не может зависить. Можно подумать над граничными случаями - если при вставке разорвалось соединение и статус неизвестен - клиент должен повторить вставку, но не повторяет?

наоборот, дельта всегда в плюсе, демон заливаешь лишнего

то есть дублей заливает

будет ли надежнее вставка данных, если HTTP заменить на какую-то сишную либу? Видел вроде, есть такие

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

Если сделать что-то вроде постгресового bgworker то можно будет много хорошего понаписать для работы в фоне

Я вот такой штукой удаляю https://github.com/kshvakov/clickhouse-partition-cleaner

наоборот, дельта всегда в плюсе, демон заливаешь лишнего

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

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

Этого пока нет в roadmap-е. Решаем скриптами в cron-е.

ну да, по другому пока никак :)

Как правильно заметили, Вы можете сделать view специально для графиков. Так же, если Вы будете использовать https://github.com/Vertamedia/chproxy, то сможете настроить лимиты по выполнению запросов из графаны. Например, не больше 2 запросо одновременно, не больше 20 сек на выполнение. Так же можно настроить кеширование результатов запроса и округление запрашиваемого периода времени до 10мин, например. Более подробно здесь - https://github.com/Vertamedia/clickhouse-grafana#chproxy-optional От себя скажу, что мы постоянно смотрим сырые данные непосредственно ч-з графану

я таки сделал вьюшку, которая в онлайне делает то, что мне нужно, вот только перфоманс такого решения мне не очень нравится, IO в 2 раза на вставке данных взлетел

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

И если этот блок вставился в первый раз, то он второй раз отбросится как дубль, главное чтобы пачка была точно такая же, да? А что по поводу либы, например, https://github.com/artpaul/clickhouse-cpp, стоит попробовать вместо HTTP?

я таки сделал вьюшку, которая в онлайне делает то, что мне нужно, вот только перфоманс такого решения мне не очень нравится, IO в 2 раза на вставке данных взлетел

Там и пишется в 2 раза больше

нет, не в два

у меня из 20 полей во вьюшке всего 4

у меня из 20 полей во вьюшке всего 4

Понятно

для интереса попробую через скрипт подготавливать данные извне и складировать в другую таблицу :)

т.е. вытаскивать из КХ, и ложить в него же

И если этот блок вставился в первый раз, то он второй раз отбросится как дубль, главное чтобы пачка была точно такая же, да? А что по поводу либы, например, https://github.com/artpaul/clickhouse-cpp, стоит попробовать вместо HTTP?

Существенная разница может быть, если например, тормозит форматирование данных в TSV или CSV перед отправкой по HTTP. Это довольно типично, если надо форматировать дату-с-временем, float-ы, правильно эксейпить строки. Посмотрите perf-ом - если на стороне клиента тратится время на форматирование, то использование нативного протокола даст преимущество.

Существенная разница может быть, если например, тормозит форматирование данных в TSV или CSV перед отправкой по HTTP. Это довольно типично, если надо форматировать дату-с-временем, float-ы, правильно эксейпить строки. Посмотрите perf-ом - если на стороне клиента тратится время на форматирование, то использование нативного протокола даст преимущество.

Я понял, спс

Там и пишется в 2 раза больше

я похоже налажал с тестами, две вьюшки было

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

select uniq(*) from table_name

uniqExact - точно и медленно, uniq - неточно и быстро

там еще всякие есть, посмотрите в доке

"При обновлении кластера, на время, когда на одних репликах работает новая версия сервера, а на других - старая, репликация будет приостановлена и в логе появятся сообщения вида unknown parameter 'shard'. Репликация продолжится после обновления всех реплик кластера." Наткнулись на это при обновлении версии на 1.1.54342. Есть ли более детальное описание/коммит, объясняющий первопричину? Есть ли другой способ всё таки сделать rolling update?

"При обновлении кластера, на время, когда на одних репликах работает новая версия сервера, а на других - старая, репликация будет приостановлена и в логе появятся сообщения вида unknown parameter 'shard'. Репликация продолжится после обновления всех реплик кластера." Наткнулись на это при обновлении версии на 1.1.54342. Есть ли более детальное описание/коммит, объясняющий первопричину? Есть ли другой способ всё таки сделать rolling update?

Формат поменялся вот и "привет", такое бывает, но не во всех релизах, обычно разные версии работают нормально

"При обновлении кластера, на время, когда на одних репликах работает новая версия сервера, а на других - старая, репликация будет приостановлена и в логе появятся сообщения вида unknown parameter 'shard'. Репликация продолжится после обновления всех реплик кластера." Наткнулись на это при обновлении версии на 1.1.54342. Есть ли более детальное описание/коммит, объясняющий первопричину? Есть ли другой способ всё таки сделать rolling update?

Можно сделать rolling update, но не ждать слишком много времени между обновлением разных реплик.

"При обновлении кластера, на время, когда на одних репликах работает новая версия сервера, а на других - старая, репликация будет приостановлена и в логе появятся сообщения вида unknown parameter 'shard'. Репликация продолжится после обновления всех реплик кластера." Наткнулись на это при обновлении версии на 1.1.54342. Есть ли более детальное описание/коммит, объясняющий первопричину? Есть ли другой способ всё таки сделать rolling update?

MergeTreeData::MutableDataPartPtr Fetcher::fetchPart( ... uri.setQueryParameters( ... можете добавить сюда "shard", "0" чтобы временно вернуть совместимость.

"При обновлении кластера, на время, когда на одних репликах работает новая версия сервера, а на других - старая, репликация будет приостановлена и в логе появятся сообщения вида unknown parameter 'shard'. Репликация продолжится после обновления всех реплик кластера." Наткнулись на это при обновлении версии на 1.1.54342. Есть ли более детальное описание/коммит, объясняющий первопричину? Есть ли другой способ всё таки сделать rolling update?

https://github.com/yandex/ClickHouse/commit/729b114c

спасибо!

https://yandex.com/blog/clickhouse/clickhouse-community-meetup-in-beijing-on-january-27-2018

Почему так вышло, что консольный клиент по Ctrl + C закрывает клиент, а не по Ctrl + D?

Почему так вышло, что консольный клиент по Ctrl + C закрывает клиент, а не по Ctrl + D?

стандартно ctrl+c - убить процесс )

Почему не по Ctrl-D?

Вполне закрывает

Почему так вышло, что консольный клиент по Ctrl + C закрывает клиент, а не по Ctrl + D?

тоже с этим сталкивался, не очень удобно. Пытаешься прервать запрос, а он прерывает его и выходит из клиента. Было бы лучше сделать выход из клиента только по Ctrl+D

@AlexanderMillin Бинго! @kshvakov Но там же libreadline. Процесс = запрос, а EOF = выйти.

Есть в CH что-то вроде EXPLAIN?

Есть в CH что-то вроде EXPLAIN?

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

Как эти логи можно получить через консоль или http запрос? (tabix их получает)

нет

Как эти логи можно получить через консоль или http запрос? (tabix их получает)

Что-то типа такого tail -f /var/log/clickhouse-server/....log

Tabix их получает. Я не знаю через http или консольный клиент, вполне вероятно, что через http.

Имелось ввиду, как через клиент консоль (не на сервере)

> Время выполнениет и число просмотренных строк

Вопрос снят, данные возвращаются в каждом запросе в FORMAT JSON в параметре "statistics"

Привет всем, а на сколько старая дока по clickhouse на офф сайте?

Все базовые понятия там хорошо описаны

Возможно, но у нас есть те, кто ходил на разные доклады по Clickhouse, и у нас возник спор, а в документашке этого нет=)

Возможно, но у нас есть те, кто ходил на разные доклады по Clickhouse, и у нас возник спор, а в документашке этого нет=)

Спросите тут ;)

В changelog много полезной информации

Подробнее в GIT: https://github.com/yandex/ClickHouse/blob/master/CHANGELOG_RU.md

коллеги, привет. Есть ощущение, что при инсерте данных в формате JSONEachRow в таблице не заполняются поля, не заданные в запросе параметрами по умолчанию. Пример: есть поле ts DateTime, и есть event_date Date default toDate(ts). ts - корректное, event_date - нулевое. Аналогично с ip и ip_integer и еще с парой полей. Кто-то сталкивался с подобным?

Ага, https://github.com/yandex/ClickHouse/issues/75

Ага, https://github.com/yandex/ClickHouse/issues/75

Хотел написать "супер, спасибо" - но блин, не супер ? А есть какие-то workaround'ы?

Товарищи, есть ли возможность запускать запросы в фоне? Например мне нужно сделать длинный OPTIMIZE с дедупликацией. Как лучше всего это сделать?

/stat@combot

combot.org/chat/-1001080295593

Товарищи, есть ли возможность запускать запросы в фоне? Например мне нужно сделать длинный OPTIMIZE с дедупликацией. Как лучше всего это сделать?

OPTIMIZE и так в фоне отработает, он просто задачу ставит

/stat@combot

combot.org/chat/-1001080295593

после обновления кх в логах зукипера имею много ошибко такого плана: 2018-02-09 10:20:46,402 [myid:] - INFO [ProcessThread(sid:0 cport:2181)::PrepRequestProcessor@648] - Got user-level KeeperException when processing sessionid:0x161797f7f46008b type:setData cxid:0x5a7da9ac zxid:0x518ca txntype:-1 reqpath:n/a Error Path:/clickhouse/tables/1/Resources/block_numbers/201802/block-0000010151 Error:KeeperErrorCode = NoNode for /clickhouse/tables/1/Resources/block_numbers/201802/block-0000010151

что бы это могло значить?

всем привет. отстаёт одна из реплик шарда. в чём может быть причина и как восстановить?

в логах ничего криминального кроме zookeeper 2017-07-25 14:45:02,250 - INFO [ProcessThread(sid:3 cport:-1)::PrepRequestProcessor@651] - Got user-level KeeperException when processing sessionid:0x35d7af9cab10002 type:setData cxid:0x5977ae0e zxid:0xd0000f586 txntype:-1 reqpath:n/a Error Path:/clickhouse/tables/Traffic/block_numbers/201707/block-0000738003 Error:KeeperErrorCode = NoNode for /clickhouse/tables/Traffic/block_numbers/201707/block-0000738003

причем ругается на разные таблицы

Эти сообщения в логах ZK - нормальная работа и не говорит о какой-либо проблеме. Посмотрите SHOW PROCESSLIST на том сервере, который загружен.

после обновления кх в логах зукипера имею много ошибко такого плана: 2018-02-09 10:20:46,402 [myid:] - INFO [ProcessThread(sid:0 cport:2181)::PrepRequestProcessor@648] - Got user-level KeeperException when processing sessionid:0x161797f7f46008b type:setData cxid:0x5a7da9ac zxid:0x518ca txntype:-1 reqpath:n/a Error Path:/clickhouse/tables/1/Resources/block_numbers/201802/block-0000010151 Error:KeeperErrorCode = NoNode for /clickhouse/tables/1/Resources/block_numbers/201802/block-0000010151

это про NoNode)

сообщение уровня INFO