коллеги, а есть простой способ в кх сделать типа апсерта что-то? Чтобы записалось, если такой строки нет, и не записалось дубля, если есть. Не хочу сотни тысяч селектов лишних делать ?

ReplacingMergeTree

только версию нужно будет менять

Добрый день, а как бд перенести на другой сервер?

только версию нужно будет менять

Версия по доке optional? The last optional parameter for the table engine is the version column. When merging, it reduces all rows with the same primary key value to just one row. If the version column is specified, it leaves the row with the highest version; otherwise, it leaves the last row. А в жизни — нет?

ReplacingMergeTree

В любом случае — спасибо! На вид — оно

Добрый день, а как бд перенести на другой сервер?

через реплику, просто скопировав папку с данными кх , дамп ресторе.

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

всё так и было. вынесенный урок - ReadonlyReplica из system.metrics и is_readonly из system.replicas это не одно и то же =) по факту почти все CH были в ro, т.к. поднялись раньше зукиперов. я был прав - количество LeaderReplica по всем серверам CH в реплицируемой системе должно быть равно количеству шард. то есть среди реплик каждого шарда должна быть одна LeaderReplica

ну это очевидно

ну это очевидно

откуда это очевидно? по метрикам документация вообще голая. скиньте почитать, если где-то расписано

Ну это очевидно из того как работают реплики

Шарды как таковые физически то отсутствуют

откуда это очевидно? по метрикам документация вообще голая. скиньте почитать, если где-то расписано

Лидер назначает мержи внутри шарда. Ставит задачу: мержим такие-то куски и все они их мержат, соответственно он не может знать о кусках в других шардах, поэтому да - он один на шард

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

Реплицируемые таблицы работают через зукипер а там нет никаких записей про шарды как в конфиге кх

а как указать формат выдачи при общении через http api? конкретно в CSV вывод интересует

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

У меня в голове шард и реплика - это одно и тоже

Короче, они там завязаны на путь в ZK, но путь зависит от шарда, если не сделано что-то специально.

У меня в голове шард и реплика - это одно и тоже

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

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

Я вам там выше написал как они к шардам отношение имеют ;)

Attaching to services_backend-clickhouse_1 backend-clickhouse_1 | Updating config file: /etc/clickhouse-server/config.d/docker_related_config.xml... backend-clickhouse_1 | Updating config file: /etc/clickhouse-server/config.d/dictionaries.xml... backend-clickhouse_1 | Updating config file: /etc/clickhouse-server/users.d/users.xml... backend-clickhouse_1 | Updating config file: /etc/clickhouse-server/dictionaries.d/mysql_upload_dictionary.xml... backend-clickhouse_1 | Updating config file: /etc/clickhouse-server/dictionaries.d/mysql_affiliate-creative_dictionary.xml... backend-clickhouse_1 | Updating config file: /etc/clickhouse-server/dictionaries.d/mysql_creative_dictionary.xml... backend-clickhouse_1 | Updating config file: /etc/clickhouse-server/dictionaries.d/mysql_lead_dictionary.xml... backend-clickhouse_1 | Updating config file: /etc/clickhouse-server/dictionaries.d/mysql_campaign-brand_dictionary.xml... backend-clickhouse_1 | Updating config file: /etc/clickhouse-server/dictionaries.d/mysql_affiliate_dictionary.xml... backend-clickhouse_1 | Updating config file: /etc/clickhouse-server/dictionaries.d/mysql_brand_dictionary.xml... backend-clickhouse_1 | Starting ClickHouse server, version: 1.0.1-7050adf on node f17c80a8dd72 backend-clickhouse_1 | Include not found: clickhouse_remote_servers backend-clickhouse_1 | Include not found: clickhouse_compression backend-clickhouse_1 | Logging trace to /var/log/clickhouse-server/clickhouse-server.log backend-clickhouse_1 | Logging errors to /var/log/clickhouse-server/clickhouse-server.err.log services_backend-clickhouse_1 exited with code 70docker-compose win10

timezone - прописал

Короче, они там завязаны на путь в ZK, но путь зависит от шарда, если не сделано что-то специально.

никак не зависит ) я могу как угодно эти пути генерить по сути то

timezone - прописал

возможно нужна сборка без sse

возможно нужна сборка без sse

Просто это все нормально запускается на ubuntu. Но на win10 не хочет.

было бы странно если бы запустилось

Хорошо, а как запустить? Я не очень разбираюсь в тонкостях.

по документации, из ubuntu или любой другой нормальной операционной системы

Те на win не пойдет?

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

Спасибо. Жаль.

Версия по доке optional? The last optional parameter for the table engine is the version column. When merging, it reduces all rows with the same primary key value to just one row. If the version column is specified, it leaves the row with the highest version; otherwise, it leaves the last row. А в жизни — нет?

replacing прекрасно работает без версии. дока не врет.

Как начнете ловить "Too many parts" они и появятся

А в какой таблице? events или metrics?. Я про ошибки RejectedInserts

Всем привет! Есть кластер с N шардами. На нем гоняются запросы к некоторой distributed таблице. Есть ли способ посмотреть все выполняющиеся процессы (system.processes) на кластере одним запросом? Или нужно обходить все шарды по очереди и на каждом смотреть system.processes? (Ну и более общий вопрос, можно ли к системным таблицам обращаться поверх всего кластера, аля distributed)

Всем привет! Есть кластер с N шардами. На нем гоняются запросы к некоторой distributed таблице. Есть ли способ посмотреть все выполняющиеся процессы (system.processes) на кластере одним запросом? Или нужно обходить все шарды по очереди и на каждом смотреть system.processes? (Ну и более общий вопрос, можно ли к системным таблицам обращаться поверх всего кластера, аля distributed)

Да, делайте distributed поверх системных

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

А в какой таблице? events или metrics?. Я про ошибки RejectedInserts

В events

Хотя вряд ли получится с одной машины убить процесс на другой..

никак не зависит ) я могу как угодно эти пути генерить по сути то

Можете, но, обычно, оно к шарду прибито

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

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

понятно, хотелось сделать более автоматическое решение) но спасибо за помощь

В секции <enabled_partitions> для clickhouse-copier есть предупреждение NOTE: In spite of this section is optional (if it is not specified, all partitions will be copied), it is strictly recommended to specify them explicitly. If you already have some ready paritions on destination cluster they will be removed at the start of the copying since they will be interpeted as unfinished data from the previous copying!!! это получается, если я добавляю шард в существующий кластер и делаю задачу копирования партиций с решардингом из кластера в него же самого, на уже существующих серверах удалятся партиции? но как тогда они будут скопированы и перешардированы? звучит абсурдно)

Коллеги, добрый вечер. Такой вопрос: раскатали ClickHouse в своем Kubernetes (через HELM+StatefulSet) в конфигурации "6 шардов по одной реплике". На всех шардах один и тот-же конфиг, т.е. каждый шард знает все про весь кластер. Запросы соответственно идут через headless Service произвольно на любой шард. Все работает замечательно и быстро. Но есть проблема когда один из контейнеров падает и перезапускается — у него меняется внутренний IP и из кластера он выпадает совсем, потому что все остальные шарды однажды отрезолвили его IP и он для них теряется. Из документации: В случае указания домена, при старте сервера делается DNS запрос, и результат запоминается на всё время работы сервера. Если DNS запрос неуспешен, то сервер не запускается. Если вы изменяете DNS-запись, перезапустите сервер. однако есть и такое: Как видно, движок Distributed требует прописывания кластера в конфигурационный файл; кластера из конфигурационного файла обновляются налету, без перезапуска сервера. Источник: https://clickhouse.yandex/docs/ru/table_engines/distributed/ Вижу пока только дав решения: 1) поднять центральный сервер, хранить на нем одном конфиг с указанием шардов и ходить в кластер строго через него; 2) каким-то хуком после перезапуска контейнера прописывать новый IP на всех шардах в конфиги, которые якобы подхатятся налету. Подскажите, возможно я что-то упускаю или действительно авторезолв DNS имен шардов и реплик из настроек такая проблема?

UPDATE: случайно нагуглил настройку disable_internal_dns_cache (https://github.com/yandex/ClickHouse/blob/master/dbms/src/Server/config.xml#L367) и запрос SYSTEM DROP DNS CACHE. Буду их пробовать. Но вообще, в документации про них ни слова ?

UPDATE: случайно нагуглил настройку disable_internal_dns_cache (https://github.com/yandex/ClickHouse/blob/master/dbms/src/Server/config.xml#L367) и запрос SYSTEM DROP DNS CACHE. Буду их пробовать. Но вообще, в документации про них ни слова ?

Поиском по чату словом dns на 4 позиции вверх находится эта команда сброса кэша)

Коллеги, добрый вечер. Такой вопрос: раскатали ClickHouse в своем Kubernetes (через HELM+StatefulSet) в конфигурации "6 шардов по одной реплике". На всех шардах один и тот-же конфиг, т.е. каждый шард знает все про весь кластер. Запросы соответственно идут через headless Service произвольно на любой шард. Все работает замечательно и быстро. Но есть проблема когда один из контейнеров падает и перезапускается — у него меняется внутренний IP и из кластера он выпадает совсем, потому что все остальные шарды однажды отрезолвили его IP и он для них теряется. Из документации: В случае указания домена, при старте сервера делается DNS запрос, и результат запоминается на всё время работы сервера. Если DNS запрос неуспешен, то сервер не запускается. Если вы изменяете DNS-запись, перезапустите сервер. однако есть и такое: Как видно, движок Distributed требует прописывания кластера в конфигурационный файл; кластера из конфигурационного файла обновляются налету, без перезапуска сервера. Источник: https://clickhouse.yandex/docs/ru/table_engines/distributed/ Вижу пока только дав решения: 1) поднять центральный сервер, хранить на нем одном конфиг с указанием шардов и ходить в кластер строго через него; 2) каким-то хуком после перезапуска контейнера прописывать новый IP на всех шардах в конфиги, которые якобы подхатятся налету. Подскажите, возможно я что-то упускаю или действительно авторезолв DNS имен шардов и реплик из настроек такая проблема?

У меня вопрос, скажем так, собираю некую статистику по использованию КХ не на железе: почему Kubernetes, насколько это принципиально? Почему не поднять кластер в LXC/LXD? Если будет КХ с таким же уровнем автоматизации и управления как, скажем, CockroachDB готов ли был ваш проект использовать его при условии что он (бай дизайн) обратно несовместим с ванильным КХ?

Привет Скажите, а есть в планах развитие MATERIALIZED VIEW? Сейчас при инсерте в родительскую таблицу view пересчитывается только за новую пачку. Я бы хотел использовать view для аля-оконных функций, и хорошо бы чтобы view полностью бы пересчитывался (всю таблицу) при любом инсерте? Это вообще частый кейс, кому-то кроме меня это бывало нужно?

Привет Скажите, а есть в планах развитие MATERIALIZED VIEW? Сейчас при инсерте в родительскую таблицу view пересчитывается только за новую пачку. Я бы хотел использовать view для аля-оконных функций, и хорошо бы чтобы view полностью бы пересчитывался (всю таблицу) при любом инсерте? Это вообще частый кейс, кому-то кроме меня это бывало нужно?

Используйте AggregatingMergeTree, медленнее, но, возможно, вам подойдет

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

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

У нас был подобный кейс, но мы, слава богу изгнали эту нечистую силу

боюсь что *MergeTree мне не очень подойдут, потому что для одного класса нужны сырые данные (до агрегации), а для другого нужны агрегированные Если точнее, то аппенды ежедневные. Таблицы неогромные, помещаются на 1-2 крупные машины. Для каждого пользователя пишется id'шник очередной наливки. И иногда нужно взять все записи с максимальным айдишником заливки для пользователя: причем заранее неизвестно какой максимальный, и для разных пользователей он разный. А иногда нужны конкретные айдишники (непоследние) Планируем использовать массивы и лямбды, но хотели материализовывать результат

У нас был подобный кейс, но мы, слава богу изгнали эту нечистую силу

ой, а расскажите как изгоняли?

ой, а расскажите как изгоняли?

Агрегировали на прикладном уровне

Просто при поступлении новой пачки данных по конкретному юзеру переагрегировали данные и складывали в ReplacingMergeTree

PostgreSQL начал перенимать фичи ClickHouse и теперь в 11-й версии из psql можно выходить не только по \q https://www.postgresql.org/about/news/1855/

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

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

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

И такое проходили. Причем была проблема в том, что данные могут дописаться как вначало сессии, так и в конец и сессия должна как бы двигаться и влево, и вправо. Горя мы хапнули ппц. Теперь сложную логику агрегируем аля event sourcing и на выходе имеем кучу фактов по которым дальше уже проводим агрегацию. Например знаем все о сессиях и юзерах и еще много чего.

Сейчас есть некоторые неудобные моменты в виде жирных nested колонок в replacing merge tree таблицах, но есть план как это можно это обойти. Нужен POC для начала ) Есть подозрение, что 900 партиций для КХ прочитать это жирно, учитывая, что в каждой может быть дофига кусков.

ну тем не менее меня не покидает надежда, что это можно сделать внутри CH, а не умным препроцессингом снаружи)

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

мне бы тоже не помешало это....

Привет. Подскажите пожалуйста на что влияет второй параметр ("имя реплики") при создании таблицы с движком ReplicatedMergeTree?

Друзья, смежный вопрос, на clickhouse.yandex, в блоке When NOT to use ClickHouse, написано: Blob or document storage А чтоб такое применить для такой задачи? Документы однотипные XML, сжиматься должны прекраснейшим образом, если "поколоночно".

Привет. Подскажите пожалуйста на что влияет второй параметр ("имя реплики") при создании таблицы с движком ReplicatedMergeTree?

по идее ни на что

Привет. Подскажите пожалуйста на что влияет второй параметр ("имя реплики") при создании таблицы с движком ReplicatedMergeTree?

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

спасибо

мне бы тоже не помешало это....

Возможно вы что-то делаете не так, есть сырые данные, для остального можно использовать State, например: CREATE TABLE RawData( Date Date , UserID Int64 , Price Int64 , CreatedAt DateTime ) Engine MergeTree PARTITION BY Date ORDER BY Date; CREATE MATERIALIZED VIEW MV ENGINE = AggregatingMergeTree PARTITION BY Date ORDER BY (Date, UserID) AS SELECT Date , UserID , sumState(Price) AS SumPrice , maxState(CreatedAt) AS MaxCreatedAt FROM RawData GROUP BY Date, UserID; INSERT INTO RawData VALUES ('2018-01-01', 1, 42, '2018-01-01 21:00:00') , ('2018-01-01', 1, 42, '2018-01-01 22:00:00') , ('2018-02-01', 1, 42, '2018-02-01 21:00:00') , ('2018-02-01', 1, 42, '2018-02-01 22:00:00'); SELECT Date , UserID , sumMerge(SumPrice) AS Price , maxMerge(MaxCreatedAt) AS LastAction FROM MV GROUP BY Date, UserID; ┌───────Date─┬─UserID─┬─Price─┬──────────LastAction─┐ │ 2018-02-01 │ 1 │ 84 │ 2018-02-01 22:00:00 │ │ 2018-01-01 │ 1 │ 84 │ 2018-01-01 22:00:00 │ └────────────┴────────┴───────┴─────────────────────┘ 2 rows in set. Elapsed: 0.005 sec.

Возможно вы что-то делаете не так, есть сырые данные, для остального можно использовать State, например: CREATE TABLE RawData( Date Date , UserID Int64 , Price Int64 , CreatedAt DateTime ) Engine MergeTree PARTITION BY Date ORDER BY Date; CREATE MATERIALIZED VIEW MV ENGINE = AggregatingMergeTree PARTITION BY Date ORDER BY (Date, UserID) AS SELECT Date , UserID , sumState(Price) AS SumPrice , maxState(CreatedAt) AS MaxCreatedAt FROM RawData GROUP BY Date, UserID; INSERT INTO RawData VALUES ('2018-01-01', 1, 42, '2018-01-01 21:00:00') , ('2018-01-01', 1, 42, '2018-01-01 22:00:00') , ('2018-02-01', 1, 42, '2018-02-01 21:00:00') , ('2018-02-01', 1, 42, '2018-02-01 22:00:00'); SELECT Date , UserID , sumMerge(SumPrice) AS Price , maxMerge(MaxCreatedAt) AS LastAction FROM MV GROUP BY Date, UserID; ┌───────Date─┬─UserID─┬─Price─┬──────────LastAction─┐ │ 2018-02-01 │ 1 │ 84 │ 2018-02-01 22:00:00 │ │ 2018-01-01 │ 1 │ 84 │ 2018-01-01 22:00:00 │ └────────────┴────────┴───────┴─────────────────────┘ 2 rows in set. Elapsed: 0.005 sec.

Я транспонирую данные и за один insert мне приходят только кусок данных для транспонирования, я не могу запустить расчеты ранее чем наберутся все данные для транспонирования. Если есть идея как можно это победить то было бы круто :)

Конечно есть - не использовать MV, дождаться пока все данные придут и посчитать их

Конечно есть - не использовать MV, дождаться пока все данные придут и посчитать их

Вот мы так и делаем :) а очень бы хотелось использовать MV :)

Коллеги, добрый день! Ситуация следующая: в случае перезапуска Clickhouse и в случае если в кликхаусе находится большое кол-во таблиц, то перезапуск происходит очень долго. При запуске клик "перечитывает" все таблицы http://joxi.ru/LmGJ53DTe4dYGr и соответственно подключится к нему нет возможности ("Code: 210. DB::NetException: Connection refused: (localhost:9000, 127.0.0.1)"). Есть ли варианты более "быстрого запуска"? И второй вопрос, после выполнения нескольких сложных запросов, клик бывает начинает сильно "тормозить", при этом ресурсов сервера хватает, и далее те запросы которые выполнялись за доли секунда начинают выполнятся за 5-10 сек, в чем может быть проблема (в какую сторону копать)? Спасибо!

Первое решается репликами и дистрибьютед таблицей))

Спасибо!

Коллеги, добрый день! Ситуация следующая: в случае перезапуска Clickhouse и в случае если в кликхаусе находится большое кол-во таблиц, то перезапуск происходит очень долго. При запуске клик "перечитывает" все таблицы http://joxi.ru/LmGJ53DTe4dYGr и соответственно подключится к нему нет возможности ("Code: 210. DB::NetException: Connection refused: (localhost:9000, 127.0.0.1)"). Есть ли варианты более "быстрого запуска"? И второй вопрос, после выполнения нескольких сложных запросов, клик бывает начинает сильно "тормозить", при этом ресурсов сервера хватает, и далее те запросы которые выполнялись за доли секунда начинают выполнятся за 5-10 сек, в чем может быть проблема (в какую сторону копать)? Спасибо!

Скажите пожалуйста, а много — это сколько?

Скажите пожалуйста, а много — это сколько?

Много таблиц я так понимаю? Более 1к

Сурово

Простите, не удержался

Много таблиц я так понимаю? Более 1к

У нас 5к таблиц, такой беды не наблюдали

У нас 5к таблиц, такой беды не наблюдали

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

У нас кликхаус не особо радуется, когда на сервер приходится (в разные MergeTree таблицы) вставка чаще 10-20 раз в секунду

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

В наихудшем случае - раз в минуту. Это таблицы ReplicatedMergeTree с агрегационными данными

У нас кликхаус не особо радуется, когда на сервер приходится (в разные MergeTree таблицы) вставка чаще 10-20 раз в секунду

10-20 раз в каждую или в целом?

10-20 раз в каждую или в целом?

В целом. В каждую примерно раз в секунду.

Много таблиц я так понимаю? Более 1к

Второе тоже решается репликой по идее

В наихудшем случае - раз в минуту. Это таблицы ReplicatedMergeTree с агрегационными данными

Т.е. в наихудшем случае у вас вставка будет 5000/60 = 80 раз в секунду? Как себя чувствует сервер при этом? И где вы копите промежуточные данные? В LSD или в своем демоне?

Второе тоже решается репликой по идее

Спасибо! Смотрели в эту сторону, но решил все же уточнить.

Т.е. в наихудшем случае у вас вставка будет 5000/60 = 80 раз в секунду? Как себя чувствует сервер при этом? И где вы копите промежуточные данные? В LSD или в своем демоне?

Мы копим эвенты на хостах-агрегаторах, через LSD. Потом пушим события в шарды CH, таблица ReplicatedMergeTree, пачками по 900К. На весь кластер (6 машин) приходится порядка 1 инсерта в секунду. Остальные тысячи таблиц содержат агрегации из таблицы с сырыми эвентами. Т.е. есть отдельный шедулер, который их дропает/создает/заполняет/очищает.

"и эти люди обвиняют меня в фашизме" (c) Если у вас много таблиц, возможно вы что-то делаете не так. Добавлением распределенных таблиц/реплик эту ситуацию не решить

Давайте так: зачем вам столько, какая задача?

Есть такая необходимость

Есть такая необходимость

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

А дамп бд в кликхаузе есть?

А дамп бд в кликхаузе есть?

Неделю назад не было)) Я лично выбрал путь через select потабличный.

Неделю назад не было)) Я лично выбрал путь через select потабличный.

Опишите в двух словах. У меня есть 2 таблицы. Тестовый сервер и боевой. На боевом установлен кх, но больше никаких действий с ним не было.

Опишите в двух словах. У меня есть 2 таблицы. Тестовый сервер и боевой. На боевом установлен кх, но больше никаких действий с ним не было.

Dump of data: clickhouse-client --query="SELECT * FROM table FORMAT Native" > table.native Native is the most efficient format. CSV, TabSeparated, JSONEachRow are more portable: you may import/export data to another DBMS. Dump of metadata: clickhouse-client --query="SHOW CREATE TABLE table" --format=TabSeparatedRaw > table.sql Restore of metadata: clickhouse-client < table.sql Restore of data: clickhouse-client --query="INSERT INTO table FORMAT Native" < table.native