Size: a a a

ClickHouse не тормозит

2019 December 09

S

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

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

DC

Denny Crane (I don't... in ClickHouse не тормозит
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, то сохранено будет ничего.
источник

S

Slach in ClickHouse не тормозит
спасибо большое
источник

S

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

A

Armenak in ClickHouse не тормозит
Заметил, что при 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 │
└────────────┘

Ес
ть ли способ этого избежать?
источник

S

Slach in ClickHouse не тормозит
Armenak
Заметил, что при 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 │
└────────────┘

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

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

смотрите в нативном клиенте что происходит
SELECT query, query_id, elapsed, rows FROM system.processes WHERE query LIKE '%your_big_table%';
источник

S

Slach in ClickHouse не тормозит
сам clickhouse во время дропа нормально доступен
источник

A

Armenak in ClickHouse не тормозит
Спасибо! Проверю в следующий раз.
источник

GA

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

OT

Oleg Tarasov in ClickHouse не тормозит
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
источник

OT

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

OT

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

N

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

GA

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

N

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

AL

Alexey Labosenko in ClickHouse не тормозит
Привет!

Никто не сталкивался с такой проблемой - обновились с 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 оказались десятки тысяч заданий и подобная процедура уже идет третьи сутки.
источник

AL

Alexey Labosenko in ClickHouse не тормозит
Alexey Labosenko
Привет!

Никто не сталкивался с такой проблемой - обновились с 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 обновляться? Или ролбечится? Или может просто дропать всю реплику и фетчить всё заново?
источник

VU

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

VU

Vladislav U. in ClickHouse не тормозит
источник

N

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