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

кафка

вроде бы в том года на HL Миловидов говорил про буферизованный ввод или какой-то другой механизм позволяющий писать в кх напрямую безопасно. насколько помню, могу ошибаться

Редис просто и удобно

если в лоб то возвращает вот так: ┌─polygon─────────────────────────────── │ ▒▒,+▒▒B@+-▒1y▒K@9▒˃▒B@▒e▒▒▒▒K@▒8b@▒B@G

Ну а чего вы ожидали? В Clickhouse нет нативных spatial типов. Можно попробовать конверьить в текст всякими ST_AsText по стороне MySQL, только и так не очень понимаю что с этим будете делать дальше в КХ.

Ну а чего вы ожидали? В Clickhouse нет нативных spatial типов. Можно попробовать конверьить в текст всякими ST_AsText по стороне MySQL, только и так не очень понимаю что с этим будете делать дальше в КХ.

Хранить же) st_astext вернет полигон в wkt - мне было бы за глаза, жаль что нельзя этого добиться просто запросом

Хранить же) st_astext вернет полигон в wkt - мне было бы за глаза, жаль что нельзя этого добиться просто запросом

Можно по стороне MySQL создать view с вычисляемым столбцом и в КХ селектить из него вместо исходной таблицы.

Кстати если обработка spatial данных предполагается опять же в MySQL то скорее всего те бинарные данные которыми он в вас плюнул он же сумеет прочитать если ему подсунуть их в нужном месте. КХ не портит бинарные данные.

вроде бы в том года на HL Миловидов говорил про буферизованный ввод или какой-то другой механизм позволяющий писать в кх напрямую безопасно. насколько помню, могу ошибаться

Есть движок Buffer - поищите в документации.

Если у вас логи и хотите реалтайма - вроде кто-то выкладывал КХ как output для logstash.

Есть движок Buffer - поищите в документации.

только вряд ли его можно назвать "надежным"

Если у вас логи и хотите реалтайма - вроде кто-то выкладывал КХ как output для logstash.

Вот тут описано https://www.altinity.com/blog/2017/12/18/logstash-with-clickhouse

только вряд ли его можно назвать "надежным"

Ну минусы у него есть, вроде бы в документации про это было. Если есть возможность - лучше обойтись без Buffer, но если нужно - вроде бы можно жить и с Buffer. А какие именно проблемы с надежностью вы имеете в виду?

Ну очевидные для таблицы в RAM ?

"If the server is restarted abnormally, the data in the buffer is lost."

"Due to these disadvantages, we can only recommend using a Buffer table in rare cases."

Ну очевидные для таблицы в RAM ?

ну т.е. в документации описано :) Дальше каждый сам решает. Иногда потерять пару строк при рестарте некритично, а иногда (как в случае логфайлов) несложно немного "перемотать назад" до последней успешной вставки если неожиданный рестарт всё же случился.

Привет! Я подозреваю, что у меня не используется индекс, а сканируется вся таблица. В трейсе есть: clickhouse_1 | 2018.10.24 00:14:44.822559 [ 25 ] <Debug> default.task_events (SelectExecutor): Key condition: (column 0 in [1, 1]), (column 2 in [8, 8]), and, (column 5 in [1540328400, +inf)), and, (column 5 in $ -inf, 1540340084]), and, (column 3 in 13-element set), and, unknown, and Но дальше: clickhouse_1 | 2018.10.24 00:14:44.827190 [ 1774 ] <Trace> Aggregator: Aggregation method: without_key Я правильно понимаю, что он типа сначала собирается использовать индекс, а потом решает идти без ключа? В конце пишет: clickhouse_1 | 2018.10.24 00:14:44.844308 [ 25 ] <Information> executeQuery: Read 1000000 rows, 54.58 MiB in 0.025 sec., 39323331 rows/sec., 2.10 GiB/sec. В тестовых данных ровно миллион записей в таблице, и вот он её всю просканил, хотя по параметрам там немного записей подходит.

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

ну вот например запрос и соотв. таблица select min(command_result) from task_events where user_id = 1 and task_id = 81 and event_timestamp = toDateTime(1540341869) and event_date > toDate(now()-86400-43200) create table if not exists task_events ( task_id Int64, event_timestamp DateTime, event_date MATERIALIZED toDate(event_timestamp), task_type String, command_type String, task_status Int32, command_result UInt8, account_id Int64, user_id Int64 ) Engine = MergeTree PARTITION BY (event_date, command_result) ORDER BY (user_id, account_id, task_id, event_timestamp);

по этому user_id в таблице всего 1000 записей

а сканируется таблица полностью

могу конечно попробовать в ORDER BY переставить местами account_id и task_id, но кмк и только по user_id должен индекс тут использоваться

Даже optimize table final сделал на всякий пожарный, не помогает :(

если count(*) вместо min(command_result) в запросе сделать, то вернёт 1. Если оставить только условие на user_id=1 то останется 1000 записей. Это первое поле в индексе. Ума не приложу, почему кликхаус предпочитает просканить миллион записей, чем максимум 1000 по индексу.

есть идеи, что ещё можно посмотреть/попробовать?

Редис просто и удобно

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

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

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

а если писать в лист и ltrim сразу большой кидать. при переполнении часть страых скинет

rpush q record ltrim q -1000000 -1

День добрый! Возникла странная проблема в кластере

между двумя нодами

<Error> executeQuery: Code: 209, e.displayText() = DB::NetException: Timeout exceeded while reading from socket ([::ffff:192.168.0.11]:40175), e.what() = DB::NetException (from [::ffff:192.168.0.11]:40175)

и данные между ними не распространяются

соединение между ними нормальное

можно с одной ноды на другую попасть - без проблем

есть ли возможность как-то повысить таймаут?

а если писать в лист и ltrim сразу большой кидать. при переполнении часть страых скинет

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

есть ли возможность как-то повысить таймаут?

дело не в таймауте все таки наверно

у вас все ок по ипв6 ходит и на ипв6 спокойно заходите с одной ноды на другую ?

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

если данные "холодные" и на крутящемся диске, то да

в моём случае ssd и данные уже в оперативке. по индексу будет быстрей

индекс то тут это не какая то внешняя структура типа btree

хотя тогда наверное и на крутящемся по "индексу" быстрей будет

в моём случае ssd и данные уже в оперативке. по индексу будет быстрей

Есть функция IndexHint, которая может заставить читать по индексу, вроде бы.

О, спасиб надо попробовать

Есть функция IndexHint, которая может заставить читать по индексу, вроде бы.

Она совсем "заставляет" читать по индексу

Ну т.е. если вы сделаете indexHint и просто where, то индекс все равно будет использоваться

Просто в первом случае where применится ТОЛЬКО на сам индекс, а не на результирующие строки, а во втором случае как раз таки и на индекс и на строки

ну мне это тоже пойдёт. бенчмарки погонять по крайней мере. посмотреть, лучше станет или нет

Она совсем "заставляет" читать по индексу

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

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

Смотрите, пример. Таблица с колонками clicks, month У вас первичный ключ month, clicks Вы делаете запрос: select sum(clicks) from table where month in ('01', '02') КХ пойдет по индексу, выдерет, например 10 000 строк, но они не все попадают под условие where, но эти 10 000 строк попадают под условие индекса и в конечном счете вам вернется результат в 8 542 строки. Если перенести where в indexHint, то КХ вернет все 10 000 строк.

Индекс будет использоваться и в том и в другом случае. indexHint не заставляет КХ принудительно использовать индекс.

Смотрите, пример. Таблица с колонками clicks, month У вас первичный ключ month, clicks Вы делаете запрос: select sum(clicks) from table where month in ('01', '02') КХ пойдет по индексу, выдерет, например 10 000 строк, но они не все попадают под условие where, но эти 10 000 строк попадают под условие индекса и в конечном счете вам вернется результат в 8 542 строки. Если перенести where в indexHint, то КХ вернет все 10 000 строк.

Понятно. Тогда непонятно, почему может не использоваться индекс в обсуждаемом запросе.

ну вот например запрос и соотв. таблица select min(command_result) from task_events where user_id = 1 and task_id = 81 and event_timestamp = toDateTime(1540341869) and event_date > toDate(now()-86400-43200) create table if not exists task_events ( task_id Int64, event_timestamp DateTime, event_date MATERIALIZED toDate(event_timestamp), task_type String, command_type String, task_status Int32, command_result UInt8, account_id Int64, user_id Int64 ) Engine = MergeTree PARTITION BY (event_date, command_result) ORDER BY (user_id, account_id, task_id, event_timestamp);

не знаю, что именно стало причиной. но сейчас в этом запросе индекс используется. (в частности я пересоздал таблицу, поменяв местами в индексе account_id и task_id)

'Aggregator: Aggregation method: without_key' - это же не значит, что индекс не используется?

я по этому сужу, что используется: executeQuery: Read 16384 rows, 915.20 KiB in 0.022 sec., 737809 rows/sec., 40.25 MiB/sec.

в таблицы миллионы записей, раз не всё сканит - значит использует, верно?

не знаю, что именно стало причиной. но сейчас в этом запросе индекс используется. (в частности я пересоздал таблицу, поменяв местами в индексе account_id и task_id)

Должен же использоваться и в старом варианте. Надо будет потестить

Мб условие на user_id надо в prewhere? Или я неправильно понимаю, как это работает?

Скажите пожалуйста, а сталкивался кто с такой ошибкой при работе с кликхаузом из табло? Cannot interpret 'ᴺᵁᴸᴸ' as double: stod: no conversion tableau

Скажите пожалуйста, а сталкивался кто с такой ошибкой при работе с кликхаузом из табло? Cannot interpret 'ᴺᵁᴸᴸ' as double: stod: no conversion tableau

Какая версия кликхауса, odbc драйвера и какой запрос

Может быть драйвер слишком старый и не умеет null

Может быть драйвер слишком старый и не умеет null

Сходу не скажу, но за наводку спасибо. Обновлю.

Сходу не скажу, но за наводку спасибо. Обновлю.

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

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

Сервер как раз недавно обновили, а вот драйвер - забыл

Добрый день,

Здравствуйте. Каждую минуту приходит пачка данных типа Uint. Для отчетов, сбора метрик и так далее, мне нужны не значения счетчиков за время T, а разница между счетчиками за врема T и T-1. Подскажите, может быть есть способ сделать это хорошо? 1-й вариант, что я вижу: сохранять всё как есть, а в момент выборки написать какой-нибудь сложный SELECT, который будет применят некоторые аггрегаторы или под-запросы для рассчета delta(T, T-1) для каждого T и для каждого поля Unint (а полей два десятка, а записей в выборке будет тоже не одна тысяча) 2-й вариант: я смотрю, что CH умеет что-то под названием AggregatingMergeTree. Может быть в эту сторону покопать? 3-й вариант: сохранять как в варианте 1, но сделать материализованную вьюху для предрасчетов данных, и выборки осуществлять с нее. Но это, по сути, лишь оптиимизация варианта N1

Умеет ли ClickHouse обращаться к нужному чанку merge tree если в запросе фильтрация по времени, которое сильно коррелирует с временем записи ?

Здравствуйте. Каждую минуту приходит пачка данных типа Uint. Для отчетов, сбора метрик и так далее, мне нужны не значения счетчиков за время T, а разница между счетчиками за врема T и T-1. Подскажите, может быть есть способ сделать это хорошо? 1-й вариант, что я вижу: сохранять всё как есть, а в момент выборки написать какой-нибудь сложный SELECT, который будет применят некоторые аггрегаторы или под-запросы для рассчета delta(T, T-1) для каждого T и для каждого поля Unint (а полей два десятка, а записей в выборке будет тоже не одна тысяча) 2-й вариант: я смотрю, что CH умеет что-то под названием AggregatingMergeTree. Может быть в эту сторону покопать? 3-й вариант: сохранять как в варианте 1, но сделать материализованную вьюху для предрасчетов данных, и выборки осуществлять с нее. Но это, по сути, лишь оптиимизация варианта N1

https://clickhouse.yandex/docs/ru/query_language/functions/other_functions/#runningdifferencex не подходит?

Roman, воу, это же супер круто! Спасибо, не попалась мне эта функция. Практически.то, что мне надо. Единственное, у меня логика немного сложнее для подсчета дельт: v1 = Value(T) v2 = Value(T-1) v1 > v2 ? v1 - v2 : v1 + v2 Но может я и с этим что-то придумаю

Добрый день. Есть вопрос по использованию опции insert_quorum для реплик. Имеет ли смысл эта опция, если запись в Replicated таблицы используется через Distributed таблицу? Ведь Distibuted подразумевает возможное накопление вставленных данных у себя. То есть код успеха или неуспеха при записи в Distibuted, которая в свою очередь пишет в Replicated, будет возвращаться клиенту какой таблицей - первой или наследоваться от второй Replicated?

Умеет ли ClickHouse обращаться к нужному чанку merge tree если в запросе фильтрация по времени, которое сильно коррелирует с временем записи ?

Есть фильтрация кусков по условиям на столбцы, входящие в ключ партиционирования. То есть, например, если у вас в ключе партиционирования дата, то условия на дату будут отфильтровывать куски.

Добрый день. Есть вопрос по использованию опции insert_quorum для реплик. Имеет ли смысл эта опция, если запись в Replicated таблицы используется через Distributed таблицу? Ведь Distibuted подразумевает возможное накопление вставленных данных у себя. То есть код успеха или неуспеха при записи в Distibuted, которая в свою очередь пишет в Replicated, будет возвращаться клиенту какой таблицей - первой или наследоваться от второй Replicated?

Для distributed insert_distributed_sync

Для distributed insert_distributed_sync

То есть оно гарантирует, что при получении успеха данные уже доехали до всех реплик?

И можно ли как-то мониторить очередь копящуюся в Distibuted таблице, кроме как du линуксом по папке?

То есть оно гарантирует, что при получении успеха данные уже доехали до всех реплик?

Нет, не гарантирует. Но если у вас дефолтная асинхронная вставка, то ОК клиенту вернётся, когда записи сохранились в локальной директории на ФС. А вставка в реплики будет потом, при чём скорее всего с дефолтными настройками, а не с теми, с которыми вы вставляли в Distributed. Если включить и insert_distributed_sync и insert_quorum, то будет то, что вы хотите. Правда этот режим работает так себе (мы всё собирались включить его по умолчанию, да так пока и не собрались) - если вставка в один шард не прошла, то непонятно в какой, и приходится повторять весь батч, что приводит к куче дубликатов.

И можно ли как-то мониторить очередь копящуюся в Distibuted таблице, кроме как du линуксом по папке?

Из ClickHouse нельзя.

Кто-нибудь сталкивался на 18.14.9( "самосборка" ) CentOS с : <Error> ExternalDictionaries: Cannot create external dictionary 'PG_DICT_ADDRESSES' from config path /etc/clickhouse-server/postgre_dict_addresses_dictionary.xml: Code: 86, e.displayText() = DB::Exception: Received error from remote server /identifier_quote?connection_string=DSN%3Dpostgres. HTTP status code: 500 Internal Server Error, body: No 'query' in request body ? При этом, на Debian та же версия работает без проблем. Может не так собираю?

Нет, не гарантирует. Но если у вас дефолтная асинхронная вставка, то ОК клиенту вернётся, когда записи сохранились в локальной директории на ФС. А вставка в реплики будет потом, при чём скорее всего с дефолтными настройками, а не с теми, с которыми вы вставляли в Distributed. Если включить и insert_distributed_sync и insert_quorum, то будет то, что вы хотите. Правда этот режим работает так себе (мы всё собирались включить его по умолчанию, да так пока и не собрались) - если вставка в один шард не прошла, то непонятно в какой, и приходится повторять весь батч, что приводит к куче дубликатов.

Всё понятно, спасибо. А есть где-то тикеты может именно по этой проблеме с совместным использованием insert_distributed_sync и insert_quorum?

Так, я немного неточно выразился - проблема в insert_distributed_sync, с insert_quorum она скорее всего усугубится, так как вставка с кворумом тяжелее. На гитхабе тикетов кажется не было.

Коллеги, подскажите плиз, в error логе неприрывные ошибки "Connection reset by peer" без деталей https://pastebin.com/z5WP5bnJ - сплошным потоком на всех надоах (3 шарда по 2 реплики). с чего начать дебаг, если эта ситуация не штатная?

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

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

Коллеги, все доброго дня! скажите, пожалуйста, есть ли возможность в Clickhouse удалять представления? drop view не работает..

Коллеги, все доброго дня! скажите, пожалуйста, есть ли возможность в Clickhouse удалять представления? drop view не работает..

DROP TABLE <название view>

Gregory Табикс же вроде как client-side only, как же он может что-то шарить между юзерами. Для этого надо другую тулзу, которая на бекенде знает про юзеров и про репорты.

Gregory Табикс же вроде как client-side only, как же он может что-то шарить между юзерами. Для этого надо другую тулзу, которая на бекенде знает про юзеров и про репорты.

Что за тулза? Хочется что б прям как в Кибане, ну или почти

можно попробовать наш SeekTable, у него есть нативный коннектор к CH. Но там немного другая идеология: сначала настраивается датасорс, а потом уже без доступа к SQL юзера могут свои репорты делать - pivot tables, charts, просто таблицы с фильтрами. Можно развернуть self-hosted, если что обращайтесь в личку

Подскажите а нужно ли в order by для движка mergetree включать ключ партицирования? Или там автоматически партицирование по ключу будет. Имеется таблица CREATE TABLE default.book ( datetime DateTime, timestamp UInt64, pr String, bp Float32, bv Float32, ap Float32, av Float32, position UInt16) ENGINE = MergeTree() PARTITION BY toYYYYMM(datetime) ORDER BY timestamp SETTINGS index_granularity = 8192 timestamp - timestamp. Может его и не включать в order by? Или включить только datetime

Подскажите а нужно ли в order by для движка mergetree включать ключ партицирования? Или там автоматически партицирование по ключу будет. Имеется таблица CREATE TABLE default.book ( datetime DateTime, timestamp UInt64, pr String, bp Float32, bv Float32, ap Float32, av Float32, position UInt16) ENGINE = MergeTree() PARTITION BY toYYYYMM(datetime) ORDER BY timestamp SETTINGS index_granularity = 8192 timestamp - timestamp. Может его и не включать в order by? Или включить только datetime

Нет, не нужно. Подразумевается, что оптимальный запрос сначала отфильтрует по ключу партиционирования, а замет в нужных партициях поищет по ключу (поля в ORDER BY)

Подскажите пожалуйста, возможно кто-то уже сталкивался. Пытаюсь подключится к консоли клик хауза через докер, и всплывает такая ошибка: docker: Error response from daemon: OCI runtime create failed: container_linux.go:348: starting container process caused "exec: \"--host\": executable file not found in $PATH": unknown Для запуска использую след.команды: 1) docker run -d --name some-clickhouse-server --ulimit nofile=262144:262144 yandex/clickhouse-server - чтобы поднять сервер 2) docker run -it --rm --link some-clickhouse-server:clickhouse-server yandex/clickhouse-client --host clickhouse-server - чтобы подключится к консоли. После второй команды возникает ошибка. Буду благодарен любым советам)