AT
Спасибо, попробую
Size: a a a
2020 June 24
AT
Добрый день. А есть ли возможность узнать на какую таблицу приходится больше всего инсертов?
yl
they don't have to be reassigned
D
а почему background_pool_size конфигурится из users.xml o_O ?
D
"так надо" ?
DC
Спасибо. И объем буфера не параметризован?
два буфера по 1мб. Один это max_compress_block_size его можно уменьшить. Второй вроде нет , буфер чтения
DC
то есть kafka engine и MV находятся только в одной базе и если капут этой базе, то надо идти на другой сервер и создавать kafka engine и MV, верно?
На всех серверах создавайте одинаковые наборы кафка+mv
DC
Тут логика должна быть следующая: нормальный кластер должен состоять из шардов и реплик. На один шард один Kafka engine + mv.
Если у тебя кластер из 4-х машин где сетап 2+2 (2 шарда и у каждого есть реплика), то ke+mv надо 2 штуки, по одной на шард.
Главное в рамках одного шарда не делать больше 1 ke+mv, тк реплики друг в друга не должны реплицировать данные. В одну пишешь, и она реплицируется
Если у тебя кластер из 4-х машин где сетап 2+2 (2 шарда и у каждого есть реплика), то ke+mv надо 2 штуки, по одной на шард.
Главное в рамках одного шарда не делать больше 1 ke+mv, тк реплики друг в друга не должны реплицировать данные. В одну пишешь, и она реплицируется
Как раз наоборот -- кх мультимастер, надо/можно консьюмить и писать на всех репликах
DC
он ошибку выкидывает ищет distributed таблицу на одном из его шардов
Первым предложением в гисте: и не работает вообще при circle replication
D
Первым предложением в гисте: и не работает вообще при circle replication
для устаканивание терминологии.
circle replication - это когда
хост1: shard1repl1 shard3repl2
хост1: shard2repl1 shard1repl2
хост1: shard3repl1 shard2repl2
?
circle replication - это когда
хост1: shard1repl1 shard3repl2
хост1: shard2repl1 shard1repl2
хост1: shard3repl1 shard2repl2
?
C
Total messages: 168452
DC
для устаканивание терминологии.
circle replication - это когда
хост1: shard1repl1 shard3repl2
хост1: shard2repl1 shard1repl2
хост1: shard3repl1 shard2repl2
?
circle replication - это когда
хост1: shard1repl1 shard3repl2
хост1: shard2repl1 shard1repl2
хост1: shard3repl1 shard2repl2
?
Да
D
а почему background_pool_size конфигурится из users.xml o_O ?
а по этому можете подсказать
логично было бы иметь
system.user_settings
system.config_settings
логично было бы иметь
system.user_settings
system.config_settings
DC
Igor Kurmak
привет) народ, а может кто подсказать есть ли аналоги кластерных индексов? чтоб таблица была отсортирована всегда и можно было пользоваться ASOF JOIN без дополнительных сортировок?
Кх не использует индексы и сортированность таблиц при джойнах. Чистый МержДжойн не имплементирован
DC
а по этому можете подсказать
логично было бы иметь
system.user_settings
system.config_settings
логично было бы иметь
system.user_settings
system.config_settings
В replication_q есть поле про exception что там
DC
Коллеги, напомните, какая схема распределения узлов Zookeeper применяется для решений растянутых на 2 ЦОД.
С учетом кворума и возможного Disaster
С учетом кворума и возможного Disaster
Как далеко цоды? В км., в мс. пинга?
A
В км 20-30
DC
Artur
Добрый день. У кого нибудь есть опыт переноса данных из Influxdb в CH?
Какая структура данный на стороне CH наиболее подходящая? Главный вопрос как лучше хранить набор тегов (key:value набор тегов у метрик зарание неизвестен).
Сейчас мы выбираем из нескольких вариантов
1. Использовать одну таблицу и динамически добавлять новые колонки на каждый новый тег. Как CH себя ведет при частом обновлении таблиц? Бедет ли такой вариант работат? Есть риск что получиться таблица с очень большим набором колонок.
2. Использовать две таблицы одну для метрик и одно для тегов как предложено здесь (https://groups.google.com/forum/#!searchin/clickhouse//clickhouse/pyy0OW12JKM/hlfvz-CVAQAJ)
1 table have 3 columns
key Int32,
timestamp DateTime
value Float64) order by (key, timestamp)
2 table have 2 columns: key - tag
Не очень понятно как заполнять вторую таблицу: key - tag
Видимо придется создавать отдельный кеш поверх это палицы на запись
3. Просто поесть все теги в Array или Json
Какая структура данный на стороне CH наиболее подходящая? Главный вопрос как лучше хранить набор тегов (key:value набор тегов у метрик зарание неизвестен).
Сейчас мы выбираем из нескольких вариантов
1. Использовать одну таблицу и динамически добавлять новые колонки на каждый новый тег. Как CH себя ведет при частом обновлении таблиц? Бедет ли такой вариант работат? Есть риск что получиться таблица с очень большим набором колонок.
2. Использовать две таблицы одну для метрик и одно для тегов как предложено здесь (https://groups.google.com/forum/#!searchin/clickhouse//clickhouse/pyy0OW12JKM/hlfvz-CVAQAJ)
1 table have 3 columns
key Int32,
timestamp DateTime
value Float64) order by (key, timestamp)
2 table have 2 columns: key - tag
Не очень понятно как заполнять вторую таблицу: key - tag
Видимо придется создавать отдельный кеш поверх это палицы на запись
3. Просто поесть все теги в Array или Json
Ну по хорошему key/tag надо в бекенде хранить а не в кх
DC
В км 20-30
Да как угодно делайте, 20км это маленький пинг.
A
Это понятно, но вопрос в устойчивости к потере любого одного цода