Проверю на счёт места через хардлинки

Добрый день! Скажите, есть ли какие-нибудь рекомендации по выполнению бекапа КХ, кроме тех что указаны в документации. В частности, интересуют методы создания, и последующей передачи данных на удаленный сервер. Очень уж не хочется переносить терабайт по rsync. Спасибо.

Его и так и так переносить...

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

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

Удивительно. Я пересоздал таблицу, указав явно PARTITION BY, какие поля суммировать и как сортировать: ENGINE = SummingMergeTree( (col1, col2...) ) PARTITION BY toYYYYMM(EventDate) Order BY (EventDate, EventTime, Account) И внезапно, у меня всё заработало. SummingMergeTree начал суммировать. Неужели КХ как-то иначе партицирует данные по-умолчанию? Но нет же, в доках сказано: по месяцам. Я потом смотрел в system.partitions и видел, что у меня ровно один партишен - по месяцу. Может быть какой-то баг в 18.12?

Удивительно. Я пересоздал таблицу, указав явно PARTITION BY, какие поля суммировать и как сортировать: ENGINE = SummingMergeTree( (col1, col2...) ) PARTITION BY toYYYYMM(EventDate) Order BY (EventDate, EventTime, Account) И внезапно, у меня всё заработало. SummingMergeTree начал суммировать. Неужели КХ как-то иначе партицирует данные по-умолчанию? Но нет же, в доках сказано: по месяцам. Я потом смотрел в system.partitions и видел, что у меня ровно один партишен - по месяцу. Может быть какой-то баг в 18.12?

покажите show create table от старой и от новой таблиц, а то вы рассказываете чудеса, что core функциональность не работает.

сейчас

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

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

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

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

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

даст ли это гарантию обращения к ней локально?

а ну кстати можно наверное join с табличной функцией remote сделать

даст ли это гарантию обращения к ней локально?

конечно

а ну кстати можно наверное join с табличной функцией remote сделать

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

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

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

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

250 миллионов, нужно довольно часто

ну тогда я бы сделал реплику на всех нодах

ну тогда я бы сделал реплику на всех нодах

и если я правильно понимаю, то на доагегацию будет прилетать совсем небольшая часть. Верно?

и если я правильно понимаю, то на доагегацию будет прилетать совсем небольшая часть. Верно?

откуда я-то знаю? select sum from X group by day -- вернется по миллиону от каждой из 100 нод, инициатор будет делать доагрегации 100млн select sum from X group by year -- вернется по тысяче от каждой из 100 нод, инициатор будет делать доагрегации 100тысяч

откуда я-то знаю? select sum from X group by day -- вернется по миллиону от каждой из 100 нод, инициатор будет делать доагрегации 100млн select sum from X group by year -- вернется по тысяче от каждой из 100 нод, инициатор будет делать доагрегации 100тысяч

спасибо

Привет. Возможно ли в КХ создавать материализованные представления с удалённым (remote) источником данных?

Привет. Возможно ли в КХ создавать материализованные представления с удалённым (remote) источником данных?

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

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

Спасибо

Появилась текстовая расшифровка доклада "Разработчики остались неизвестны": https://habr.com/company/yandex/blog/423905/

Спасибо

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

Приветы. Ребят, помогите понять как будет отпартиционирован вью если это ENGINE = ReplacingMergeTree PARTITION BY tuple()?

он не будет отпартиционирован вовсе?

Приветы. Ребят, помогите понять как будет отпартиционирован вью если это ENGINE = ReplacingMergeTree PARTITION BY tuple()?

будет одна партиция

скажите, а CH может продолбать данные частично из батча, если пушить в него по 200 строк за раз в виде tsv?

скажите, а CH может продолбать данные частично из батча, если пушить в него по 200 строк за раз в виде tsv?

нет

т.е. либо он весь батч запишет, либо ничего?

т.е. либо он весь батч запишет, либо ничего?

Да, данные пишутся блоком

не построчно

Denny А вру. В пересозданной таблице тоже не работает. Оно заработало т.к. я в Order BY указал не все поля, увы. Указывая PARTIION BY, CH требует перечислить в энжине только поля для суммирования и в дополнение указать еще и ORDER BY, где я и ошибся. Но всё же попытался задокументировать все свои шаги: https://gist.github.com/azzz/c2618fe6b62a782896cdb13edb45e7a3

Вот тут с юаем даже: https://monosnap.com/file/PkqMvtxrPldpRl2h4MREwUihjN8keQ Вот три первых строки. Ну они же должны быть сгруппированы

Denny А вру. В пересозданной таблице тоже не работает. Оно заработало т.к. я в Order BY указал не все поля, увы. Указывая PARTIION BY, CH требует перечислить в энжине только поля для суммирования и в дополнение указать еще и ORDER BY, где я и ошибся. Но всё же попытался задокументировать все свои шаги: https://gist.github.com/azzz/c2618fe6b62a782896cdb13edb45e7a3

в ORDER BY надо указать поля, по которым надо суммировать

Всем привет! Добавили в таблицу новые значения поля enum на всем кластере, сделали альтер на всех нодах, но все равно в логах кликхауса видим ошибки вида Type mismatch for column - и он говорит что Enum8 еще видит старый, хотя везде новый в таблицах в describe table. Такое кто-нибудь встречал? Нужно рестартить что ли зуукипер или сам кликхаус-сервер?

Tatiana Так у меня же вот: ) ENGINE = SummingMergeTree( EventDate, (EventTime, Node, Account, PullZone, Domain), 8192 )

т.е. нет там полей, да

но документация пишет, что будут смержены все числовые поля, не попадающие в ПК

и оно реально мержит. Но не все. Вот запущу OPTIMIZE FINAL и первые две сроки смержатся, будет новая с значением 21. А почему третья туда не сплюсуется - нипанятна

Да, данные пишутся блоком

вот как на днях объяснил Алексей, атомарность только на партицию, поэтому если 100 строк из 200 будут в одну партицию то они могут быть записаны, а следующие 100 уже нет.

Всем привет еще раз, продублирую свое сообщение может кто ответит, столкнулся с неожиданной проблемой, cоздаю View ReplicatedMergeTree, и данные в ней и в таблице не совпадают. Может кто сталкивался? На что обратить внимание? В логах ничего подозрительного не заметил. Сам запрос: CREATE MATERIALIZED VIEW test.test_view ENGINE = ReplicatedMergeTree( '/clickhouse/tables/{shard}/test_view', '{replica}', event_date, (user_id, event_date), 8192 ) POPULATE AS

всем привет, а не подскажете, в какую часть конфига добавлять native_insert_adapt_block_structure? не нашёл документации по этой настройке https://github.com/yandex/ClickHouse/issues/2838

вот как на днях объяснил Алексей, атомарность только на партицию, поэтому если 100 строк из 200 будут в одну партицию то они могут быть записаны, а следующие 100 уже нет.

Да, конечно в рамках партиции, но данное поведение, по хорошему, нужно бы пофиксить

Подскажите пожалуйста, Есть табличка: клиент, номер заказа и дата заказа На выходе нужно получить: Клиент, массив с датами заказов

Подскажите пожалуйста, Есть табличка: клиент, номер заказа и дата заказа На выходе нужно получить: Клиент, массив с датами заказов

groupArray

Подскажите пожалуйста, Есть табличка: клиент, номер заказа и дата заказа На выходе нужно получить: Клиент, массив с датами заказов

SELECT Клиент, groupArray([toString(номер заказа),toString(дата заказа)]) FROM ... GROUP BY Клиент Ну или как вам нужно упаковать массив с датами заказов

SELECT Клиент, groupArray([toString(номер заказа),toString(дата заказа)]) FROM ... GROUP BY Клиент Ну или как вам нужно упаковать массив с датами заказов

Спасибо!!

Тому, кто посоветовал Redash, большое спасибо, - идеальная штука для того, чтобы делать Dashboards для менеджеров.

Всем привет, столкнулся со странным поведением вьюх. Дано: Clickhouse Version: 18.12.17 users table (ReplacingMergeTree): ┌─name────────────────┬─type───────────────┬─default_type─┬─default_expression──────────┐ │ user_id │ UInt64 │ │ │ │ affiliation_id │ String │ │ │ │ email │ String │ │ │ │ full_name │ String │ │ │ │ role_id │ UInt64 │ │ │ │ role_name │ String │ │ │ │ responsible_user_id │ UInt64 │ │ │ │ organization_id │ UInt64 │ │ │ │ organization_name │ String │ │ │ │ country_id │ String │ │ │ │ status │ String │ │ │ │ group_ids │ String │ │ │ │ created_at │ DateTime │ │ │ │ updated_at │ DateTime │ │ │ │ deleted_at │ Nullable(DateTime) │ │ │ │ record_date │ Date │ │ │ │ email_id │ UInt64 │ MATERIALIZED │ sipHash64(lowerUTF8(email)) │ └─────────────────────┴────────────────────┴──────────────┴─────────────────────────────┘ Минимальная рафинированая вьюха tmp_users_1 view: CREATE VIEW IF NOT EXISTS tmp_users_1 AS SELECT user_id AS user_id, affiliation_id AS affiliation_id FROM users; SELECT count() from tmp_users_1; # Реазультат есть, 100500 SELECT count() from tmp_users_1 where affiliation_id = 'nbcu' # работает, 100000 SELECT count() from tmp_users_1 where affiliation_id = 'some-random-string'; # возвращает 0, так и должно быть SELECT count() from tmp_users_1 where affiliation_id = 'nbcu' # ВСЕ ПРОПАЛО, этот и все последующие запросы возвращают 0, похоже предыдущий запрос все портит

опс, форматирование таблицы слетело, простите

Всем привет, столкнулся со странным поведением вьюх. Дано: Clickhouse Version: 18.12.17 users table (ReplacingMergeTree): ┌─name────────────────┬─type───────────────┬─default_type─┬─default_expression──────────┐ │ user_id │ UInt64 │ │ │ │ affiliation_id │ String │ │ │ │ email │ String │ │ │ │ full_name │ String │ │ │ │ role_id │ UInt64 │ │ │ │ role_name │ String │ │ │ │ responsible_user_id │ UInt64 │ │ │ │ organization_id │ UInt64 │ │ │ │ organization_name │ String │ │ │ │ country_id │ String │ │ │ │ status │ String │ │ │ │ group_ids │ String │ │ │ │ created_at │ DateTime │ │ │ │ updated_at │ DateTime │ │ │ │ deleted_at │ Nullable(DateTime) │ │ │ │ record_date │ Date │ │ │ │ email_id │ UInt64 │ MATERIALIZED │ sipHash64(lowerUTF8(email)) │ └─────────────────────┴────────────────────┴──────────────┴─────────────────────────────┘ Минимальная рафинированая вьюха tmp_users_1 view: CREATE VIEW IF NOT EXISTS tmp_users_1 AS SELECT user_id AS user_id, affiliation_id AS affiliation_id FROM users; SELECT count() from tmp_users_1; # Реазультат есть, 100500 SELECT count() from tmp_users_1 where affiliation_id = 'nbcu' # работает, 100000 SELECT count() from tmp_users_1 where affiliation_id = 'some-random-string'; # возвращает 0, так и должно быть SELECT count() from tmp_users_1 where affiliation_id = 'nbcu' # ВСЕ ПРОПАЛО, этот и все последующие запросы возвращают 0, похоже предыдущий запрос все портит

set enable_optimize_predicate_expression=0 оно пока не работает, но в 18.12.17 включено по умолчанию

Tatiana спасибо, попробую

Denny А вру. В пересозданной таблице тоже не работает. Оно заработало т.к. я в Order BY указал не все поля, увы. Указывая PARTIION BY, CH требует перечислить в энжине только поля для суммирования и в дополнение указать еще и ORDER BY, где я и ошибся. Но всё же попытался задокументировать все свои шаги: https://gist.github.com/azzz/c2618fe6b62a782896cdb13edb45e7a3

я не знаю что такое CLEAR COLUMN, его возможно нельзя делать для полей с sortkey похоже что в засечках ничего не чистится

@den_crane хммм. А может быть, кстати, да, блин. Не даром Update не умеет обновлять значения в полях под ПК. Может и CLEAR COLUMN значение-то и изменяет, но где-то в каком-то индексе не обновляет. Вот блин

хотя у этого чувачка вот работает как-то же https://github.com/kshvakov/ClickHouse-CPP-Meetup

О, так это же статья @kshvakov

@kshvakov а почему у тебя SummingMergeTree суммирует записи после CLEAR COLUMN, а у меня - нет? ?

нет, не воспроизводится, что-то другое drop table cctest CREATE TABLE cctest(a UInt64 default c, b UInt64, c UInt64) ENGINE=SummingMergeTree partition by tuple() order by a; insert into cctest values (99,1,0), (98,1,0); select * from cctest final; ALTER TABLE cctest CLEAR COLUMN a IN PARTITION tuple() optimize table cctest partition tuple() final select * from cctest

хм. ?

Есть пара вопросов по конфигурированию КХ вместе с docker swarm и zookeeper: 1) Это осмысленно делать? 2) Это возможно?

вот так похоже воспроизводится CREATE TABLE cctest(a UInt64 default c, v String, b UInt64, c UInt64) ENGINE=SummingMergeTree partition by tuple() order by (a,v); insert into cctest values (99,'',1,0),(99,'v',1,0), (98,'',1,0), (98,'v',1,0) ; select * from cctest final; ALTER TABLE cctest CLEAR COLUMN a IN PARTITION tuple() optimize table cctest partition tuple() final select * from cctest https://github.com/yandex/ClickHouse/issues/3207

Есть пара вопросов по конфигурированию КХ вместе с docker swarm и zookeeper: 1) Это осмысленно делать? 2) Это возможно?

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

ок. хорошо(

а что вы хотели получить от сворма?

вот так похоже воспроизводится CREATE TABLE cctest(a UInt64 default c, v String, b UInt64, c UInt64) ENGINE=SummingMergeTree partition by tuple() order by (a,v); insert into cctest values (99,'',1,0),(99,'v',1,0), (98,'',1,0), (98,'v',1,0) ; select * from cctest final; ALTER TABLE cctest CLEAR COLUMN a IN PARTITION tuple() optimize table cctest partition tuple() final select * from cctest https://github.com/yandex/ClickHouse/issues/3207

А если ORDER BY (v, a) - все ОК, над посмотреть почему так

@kshvakov а почему у тебя SummingMergeTree суммирует записи после CLEAR COLUMN, а у меня - нет? ?

EventDate первым параметром в индекс добавьте

EventDate первым параметром в индекс добавьте

Попробую спасибо.

Есть пара вопросов по конфигурированию КХ вместе с docker swarm и zookeeper: 1) Это осмысленно делать? 2) Это возможно?

Если вы умеете и все у вас в сварме то на оба вопроса да

а что вы хотели получить от сворма?

Единый способ раскатки инфраструктуры всей.

И удобное скейлирование

ну если вы понимаете как сварм работает почему как говорится нет

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

Эм а почему не свормом ? Для реплики конфиге не надо менять там по сути за это отвечает запись в зк

запускаю ch-server и tabix в докере в разных контейнера создаю базу и таблицу (Log) в ней через tabix volumes прокинут файлы на хосте появляются перезапускаю контейнер, файлы в контейнере появляются но tabix не видит базу так же и в обычном запросе по http (?query=...) в чем может быть проблема?

clickhouse: image: yandex/clickhouse-server ports: - 8123:8123 volumes: - ${DATA_PATH_HOST}/clickhouse:${DATA_PATH_CH} tabix: image: spoonest/clickhouse-tabix-web-client ports: - 1234:80

create database qwe; ;; create TABLE qwe.rty ( asd Int16 ) engine = Log ;; insert into rty VALUES (1) ;; SELECT * from rty

Эм а почему не свормом ? Для реплики конфиге не надо менять там по сути за это отвечает запись в зк

А с конфигом zookeeper это как вязать?

там нет никакой связи с конфигом зукипера это просто записть в зк , причем тут его конфиг ?

Подскажите пожалуйста - есть массив с датами, нужно рассчитать среднее время в днях между датами в массиве.

Подскажите пожалуйста - есть массив с датами, нужно рассчитать среднее время в днях между датами в массиве.

соседними или всеми комбинациями?

соседними или всеми комбинациями?

С соседними, они по возрастающей идут

Доброго времени суток. У одного из наших клиентов, эксплуатирущего clickhouse возникала проблема с исчерпанием inode по причине большого колличества мелких файлов в базе. Как подобное можно предотвратить?

С соседними, они по возрастающей идут

WITH [toDate('2018-09-01'), toDate('2018-09-03'), today()] AS dates SELECT arrayDifference(arrayMap(x -> toUInt32(x), dates)) AS differences, arrayReduce('avg', differences) AS avg FORMAT TSV [0,2,22] 8

Доброго времени суток. У одного из наших клиентов, эксплуатирущего clickhouse возникала проблема с исчерпанием inode по причине большого колличества мелких файлов в базе. Как подобное можно предотвратить?

делать крупнее батчи при вставке + настроить мониторинг

WITH [toDate('2018-09-01'), toDate('2018-09-03'), today()] AS dates SELECT arrayDifference(arrayMap(x -> toUInt32(x), dates)) AS differences, arrayReduce('avg', differences) AS avg FORMAT TSV [0,2,22] 8

Спасибо! попробую сейчас применить!

Привет. А есть чат по logs api?

Привет. А есть чат по logs api?

@miptgirl подскажешь?

Эффективнее сразу в базу стримить или накапливать в каком нибудь csv?