Доброе утро всем. а кто нибудь знает что именно означает GRANULARITY ? как для Primary key, так и для skip indexes?

чем GRANULARITY 3 от GRANULARITY 4 отличается вот в этом примере?
https://clickhouse.yandex/docs/en/operations/table_engines/mergetree/#table_engine-mergetree-data_skipping-indexes

primary key хранит значения ключевых полей каждой n-й строки. Т.е. если index_granularity 8192 а в таблице 16384 строк, то в индексе будет значения только для 2 строй -- 1й и 8193й.

minmax GRANULARITY 3 -- означает что в skip индексе будет сохранено minmax значение для сразу 3х гранул первичного индекса (3*index_granularity строк).

set(1000) GRANULARITY 4 -- означает что в skip индексе будут сохранены 1000 значений 4х гранул первичного индекса (4*index_granularity строк), если уникальных значений больше 1000, то сохранено будет ничего.

спасибо большое

а как работает KILL QUERY SYNC ?
в смысле понятно что оно пытается лочить что-то или как то сигнал в running threads передать, вопрос что блокируется, когда проверяется?

Заметил, что при DROP большой таблицы CH похоже становится заблокированым - приложения не могут писать в другие таблицы. При этом CPU load и Disk I/O на нуле. В логах вижу такое:

level=error msg="commit error: driver: bad connection

Используемая go библиотека:
di

gest = "1:499e5c968a671233b5107680bc12a775d10a00662199100eb96dd02e0446fdb8"
name = "github.com/kshvakov/clickhouse"

┌─ve

rsion()──┐
│ 19.17.4.11 │
└────────────┘

Ес

ть ли способ этого избежать?

level=error msg="commit error: driver: bad connection

gest = "1:499e5c968a671233b5107680bc12a775d10a00662199100eb96dd02e0446fdb8"
name = "github.com/kshvakov/clickhouse"

rsion()──┐
│ 19.17.4.11 │
└────────────┘

Ес

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

bad connection у вас возникает судя по всему, потому что в go драйвере таймауты выставлены и он не получает ответ

смотрите в нативном клиенте что происходит

SELECT query, query_id, elapsed, rows FROM system.processes WHERE query LIKE '%your_big_table%';

сам clickhouse во время дропа нормально доступен

Спасибо! Проверю в следующий раз.

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

When merging, ReplacingMergeTree from all the rows with the same primary key leaves only one: - Last in the selection, if ver not set. - With the maximum version, if ver specified.

doc

Last in the selection больше похоже на последнюю вставленную, чем на рандомную :)

последняя запись надо полагать в последнем вставленном парте, а последний парт находится по времени вставки

Они же мержатся в конечном итоге. Записи будут в одном парте одинаковые

У меня такое же понимание. Пытался найти, как определить из списка записей - какая последняя, не смог. Для себя решил, что прозрачности может только ver добавить, но не уверен. Может кто-то сталкивался.

Можно попробовать посмотреть в исходниках. Например зайти со стороны инструкции optimize.

Привет!

Никто не сталкивался с такой проблемой - обновились с 19.11 до 19.16 и на репликах начали биться куски таблиц и начались попытки их перевыкачать с других реплик, ошибки типа
Code: 226, e.displayText() = DB::Exception: Marks file '/var/data/clickhouse/data/default/rawlog_shard/tmp_fetch_20191202_222396_222396_0/id.mrk' doesn't exist (version 19.16.2.2 (official build))

Причем если глянуть в system.replication_queue, то в колонке num_tries для некоторых таких попыток число много больше единицы.
Ну и в очереди system.replication_queue оказались десятки тысяч заданий и подобная процедура уже идет третьи сутки.

есть ли смысл вообще до 19.17 обновляться? Или ролбечится? Или может просто дропать всю реплику и фетчить всё заново?

Всем прривет.
А почему селекты могут блокировать новые insert?
Последнее время часто случается, что из-за 1 сложного селекта начинает копиться 30-50 инсертов.
После убийства селекта, инсерты еще потупят минут 5 и проходят. Причем судя по written bytes\memory usage - лочится прям перед записью на диск в одном месте

Там правее в вашем запросе есть ProfileEvents. Среди них есть RWLock. Помониторьте. Может они его ждут.