и еще один вопрос, я правильно понимаю, что даже в случае с 500+ серверами в Яндек Метрике кластере, каждый Distributed запрос посетит все 500 серверов независимо от схемы шардирования - рандомно или по ключу user_id? Или все таки есть способ разграничить SELECTы?

и еще один вопрос, я правильно понимаю, что даже в случае с 500+ серверами в Яндек Метрике кластере, каждый Distributed запрос посетит все 500 серверов независимо от схемы шардирования - рандомно или по ключу user_id? Или все таки есть способ разграничить SELECTы?

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

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

то что как раз интересует, где-то подробнее о такой схеме почитать/послушать можно? Я видел в репо презентаций Two-Level Sharding, но деталей там мало.

Привет, в версии 1.1.54342 делаю выборку по колонке. В результате ключ по котрому делается запрос растягивается на все записи. Как сделать чтобы он полностью был в каждой записи

Можете показать запрос?

Я использую infi.clickhouse_orm так что в прямом виде запроса нет

До этого в версии 1.1.54292 все было как нужно

Если в replacingmergetree сделать optimize во время вставки большой порции данных, то, кажется, всё ломается. Кто-нибудь сталкивался с таким?

Нет, не сталкивались. Напишите подробнее - какая версия сервера и как проявляется проблема.

Привет, в версии 1.1.54342 делаю выборку по колонке. В результате ключ по котрому делается запрос растягивается на все записи. Как сделать чтобы он полностью был в каждой записи

Это выглядит как проблема infi.clickhouse_orm драйвера. Для подтверждения, выполните запрос из клиента командной строки.

то что как раз интересует, где-то подробнее о такой схеме почитать/послушать можно? Я видел в репо презентаций Two-Level Sharding, но деталей там мало.

Тут немного есть в тексте: https://github.com/yandex/clickhouse-presentations/blob/master/drafts/various.txt

подскажите, возможно ли отменить тяжелый мерж, спровоцированный OPTIMIZE TABLE? Судя по всему, можно удалить запись в очереди в Zookeeper, типа такого /clickhouse/{CLUSTER}/tables/6/{TABLE}/replicas/{NODE}/queue/queue-0002370007

Вы можете отменить назначенный мерж вручную таким образом, но это небезопасно: - если одна из реплик уже выполнила этот мерж, то вы получите рассинхронизацию; - для обновления очереди придётся перезапускать реплики.

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

При таймауте в процессе соединения или обмене ping пакетами, работает failover. Если соединение установлено, но запрос выполняется медленно, то failover-а нет.

Привет, а никто не скажет, нет ли в КХ каких нибудь механизмов плагинов? Конкретно, что нужно мне - по различным признакам классифицировать эвенты, логика достаточно сложная. Чтобы было что-то вроде INSERT INTO блаблабла url, referrer, classify_external(url,referrer)

Для этой цели можно попробовать executable словарь с типом cache. Он годится, если вычисляемая функция достаточно сложная.

Нет, не сталкивались. Напишите подробнее - какая версия сервера и как проявляется проблема.

Tima правильно сказал. Это происходит в случае если запускать optimize несколько раз в ходе одного инсёрта. Происходит гарантированно. Таблица в 50 столбцов, из них 3 uint64, остальные string. Данные гружу пачками по 100к. Баг был замечен на виртуалке, где всего 2 гига озу. Возможно, это важно. На реальной системе не тестировал. Версия 1.1.54327

Ключ составной, из 7 значений. Все значения в ключе string.

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

Для этой цели можно попробовать executable словарь с типом cache. Он годится, если вычисляемая функция достаточно сложная.

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

Друзья, тут после апдейта в определённый момент стала падать ошибка Exception: Could not find a column of minimum size in MergeTree, part /var/lib/clickhouse//data/public/events/20180124_20180124_14437_14442_1/. Подскажите что делать (

ClickHouse server version 1.1.54337.

Друзья, тут после апдейта в определённый момент стала падать ошибка Exception: Could not find a column of minimum size in MergeTree, part /var/lib/clickhouse//data/public/events/20180124_20180124_14437_14442_1/. Подскажите что делать (

https://github.com/yandex/ClickHouse/issues/1818 Такого в логах нет? Ещё видел у себя Part ... from own log doesn’t exist

@roman_yashin Увы нет.

Друзья, тут после апдейта в определённый момент стала падать ошибка Exception: Could not find a column of minimum size in MergeTree, part /var/lib/clickhouse//data/public/events/20180124_20180124_14437_14442_1/. Подскажите что делать (

У меня тоже такая ошибка была, такого куска нет на этой реплике. Я сделал detach partition 201801 и attach partition 201801, при аттаче потерянный кусочек скачался с другой реплики и стало хорошо

Подскажите пожалуйста, я пытаюсь вставлять через JDBC очень много данных (миллиарды в минуту), батчами по 10M записей в 40 потоков. INSERT часто падает с трейсом : Too many parts Merges are processing significantly slower than inserts. Я вижу в таблице system.merges от 5 до 10 записей. Сам сервак не загружен. CPU и MEM не загружаются полностью. LA не шкалит, и io диска свободные есть. Вопрос, как увеличить колличество тредов отвечающих за мёржи кусков и где настроить триггер, который срабатывает при моём эксепшене?

Подскажите пожалуйста, я пытаюсь вставлять через JDBC очень много данных (миллиарды в минуту), батчами по 10M записей в 40 потоков. INSERT часто падает с трейсом : Too many parts Merges are processing significantly slower than inserts. Я вижу в таблице system.merges от 5 до 10 записей. Сам сервак не загружен. CPU и MEM не загружаются полностью. LA не шкалит, и io диска свободные есть. Вопрос, как увеличить колличество тредов отвечающих за мёржи кусков и где настроить триггер, который срабатывает при моём эксепшене?

https://github.com/yandex/ClickHouse/blob/b8cb9267c743ba579b5f81304a769bf02b23ed81/dbms/src/Interpreters/Settings.h#L77 background_pool_size есть

Огромное спасибо! Я уже просто устал читать доку, ибо в ней этой настройки нет

Andrey , возьмите на вооружение этот файл, там кладезь настроек :)

А в какую секцию конфига эта настройка должна войти?

И ещё не понятно, где посмотреть значение по умолчанию для каждой настройки из этого файла

А в какую секцию конфига эта настройка должна войти?

В настройку квот https://github.com/yandex/ClickHouse/blob/2aaa847e10442d5ad34d7e4eb90ad1269c17181f/dbms/tests/integration/test_insert_into_distributed/configs/forbid_background_merges.xml

@Shegloff Спасибо за совет, попробовал сделал DETACH ATTACH для основной таблицы, но ошибка повотряется. Возникает у материализованных представлений на данную таблицу.

@Krashuevina Как я понимаю, рестартовать сервис для того чтобы он подхватил настройку не нужно?

не, надо именно у вьюшной таблицы inner_ так сделать

alter table db..inner.table attach partition 201801

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

Хмм а как к ней запрос выполнить? Он на 2ю точку ругается

в обратных апострофах

alter table db.`.inner.table` detach partition 201801 alter table db.`.inner.table` attach partition 201801

Понял)

Благодарю за совет.

можете на проблемной реплике вообще удалить все данные после detach из папки detached, после attach проблемная скачает всю партицию

@Krashuevina Как я понимаю, рестартовать сервис для того чтобы он подхватил настройку не нужно?

В старых версиях точно надо было.

Верно ли то, что невозможно DETACH PARTITION для MaterializedView или для ReplicatedMaterializedView ?

неверно, два сообщения выше посмотрите

неверно, два сообщения выше посмотрите

Круто - через c2.`.inner... сработало.

Причём получилось ATTACH в ту партицию, в которой уже были данные. Я думал она должна быть совершенно чистой для аттача.

А можно 2 раза сделать аттач на одних и тех же detached данных? Они приаттачатся, исчезнут из detached, а мы в detached снова положим копию припасённую в рукаве. Данные продублируются в итоге в целевой таблице? Просто интересна физика процесса.

Всем привет. А никто не находил модуля для nginx, позволяющего складировать access\error логи в clickhouse?

написать простейшую хрень на lua? постить через http. там же и буферизацию можно приделать.

Google говорит что есть

например https://github.com/mintance/nginx-clickhouse

tail -f | perl | clickhouse-client

А можно 2 раза сделать аттач на одних и тех же detached данных? Они приаттачатся, исчезнут из detached, а мы в detached снова положим копию припасённую в рукаве. Данные продублируются в итоге в целевой таблице? Просто интересна физика процесса.

сдается мне, что продублируются, но попробуйте на тестовой табличеке, это недолго :)

есть плагин к графане https://github.com/Vertamedia/clickhouse-grafana там есть макрос $columns(key, value) - query values as array of [key, value], where key will be used as label пытаюсь его использовать: $columns(group, sum(s) r) FROM (SELECT any(time) as time, $timeSeries as tt, date, dictGetString('edge','group', tuple(srv)) as group, srv, avg(nic_speed) as s FROM net WHERE $timeFilter AND srv like 'edge%' GROUP BY tt, date, srv) это транслируется в SELECT t, groupArray((group, r)) as groupArr FROM ( SELECT (intDiv(toUInt32(time), 60) * 60) * 1000 as t, group, sum(s) r FROM (SELECT any(time) as time, (intDiv(toUInt32(time), 60) * 60) * 1000 as tt, date, dictGetString('edge','group', tuple(srv)) as group, srv, avg(nic_speed) as s FROM net WHERE date >= toDate(1516803127) AND time >= toDateTime(1516803127) AND date >= toDate(1516803127) AND time >= toDateTime(1516803127) AND srv like 'edge%' GROUP BY tt, date, srv) GROUP BY t, group ORDER BY t, group) GROUP BY t ORDER BY t и кликхаус ругается: Code: 184. DB::Exception: Received from localhost:9000, 127.0.0.1. DB::Exception: Aggregate function any(time) is found in WHERE or PREWHERE in query.

есть варианты обойти это?

а есть варианты не делать any(time) AS time ?

будет другая ругань

на тему что колонка есть, но не в агрегатеной функции и не в group by

может дополнительный слой подзапроса (select any_time as time from (select any(time) as any_time.. ) .. )

с графаной не скрещивал, поэтому не знаю какие там степени свободы.

а зачем вы выбираете any(time)? Вы ведь его не используете потом

использую. я же дал ссылку на макрос.

а сколько вложенных селектов позволяет кликхаус?

@vladislavadv также у nginx можно настроить кастомный формат логов так чтобы он максимально походил на csv. единственное что кликхаус требователен к качеству данных и скорее всего придётся чистить. но всё-таки чистить проще чем разбирать access log и писать csv

в nginx можно нативно писать в json

еще проще написать на lua обработчик лог-фазы и постить по http, имхо

и его уже очень просто разобрать и отправить куда угодно

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

в обработчике

использую. я же дал ссылку на макрос.

Извините, вот Ваш макрос: $columns( group, sum(s) r) FROM ( SELECT any(time) as time, $timeSeries as tt, date, dictGetString('edge', 'group', tuple(srv)) as group, srv, avg(nic_speed) as s FROM net WHERE $timeFilter AND srv like 'edge%' GROUP BY tt, date, srv ) я не вижу зачем здесь any(time)

поэтому я бы писал на диск json, а потом бы его отдельной мелкой тулзой слал в КХ

нет, описание макроса по ссылке — https://github.com/Vertamedia/clickhouse-grafana

и там показывается (правда довольно криво) как при разворачивании появляется time (по ссылке EventTime)

на новой (1.1.54342) последней версии слетел мониторинг внешних словарей, похоже там баг - колонки last_exception и source местами перепутаны

Row 1: ────── name: db_table last_exception: MySQL: db.table source:

действительно. поправлю.

например https://github.com/mintance/nginx-clickhouse

спасибо:)

День добрый! Вопрос - если включен insert_distributed_sync, и insert_quorum = Число реплик в шарде. Означает ли это, что по окончанию INSERT данные _обязательно_ должны быть видны в SELECT?

День добрый! Вопрос - если включен insert_distributed_sync, и insert_quorum = Число реплик в шарде. Означает ли это, что по окончанию INSERT данные _обязательно_ должны быть видны в SELECT?

да, но при падении одной из реплик Вы должны поиметь веселуху

@Felixoid , вы имеете в виду, что INSERT не пройдёт?

из-за не досягаемости кворума

всё так

всё так

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

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

Интересует именно https://github.com/yandex/ClickHouse/blob/fb9c7ab81d3d208b0585080e2288fccf0a768ec3/dbms/tests/queries/0_stateless/00502_custom_partitioning_local.sql

для графита

это https://clickhouse.yandex/docs/ru/table_engines/custom_partitioning_key.html ?