окей, попробуем, спасибо!

это ARM билд, кстати, собирали сами, но вроде все гладко по мануалу прошло - в остальных аспектах никаких проблем

Спасибо! Как так я её проглядел?.....

Добрый день!
Есть ли в КХ какой-то вариант посчитать аналог uniqExact экономнее, используя то, что считаем по части первичного ключа (= по отсортированному списку)

ааа это ARM, тогда вам никто не поможет кроме вас самих. Учитесь GDB/strace.
Пользователей CH с ARM в проде мало, все баги ваши.

понял принял 🙂 будем изучать, у нас еще и докер сверху - вообще хороший диапазон поиска выходит

Подскажите, а можно ли как-то "допопулейтить" материалку?

Создавали через CREATE MAT VIEW POPULATE AS ....
Запрос отпал с сообщением

DB::Exception: Too many partitions for single INSERT block (more than 100) .......

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

DB::Exception: Too many partitions for single INSERT block (more than 100) .......

удалить и создать заново, поставив 0 , а не 100

А где это можно поставть? Или где об этом почитать?

где угодно max_partitions_per_insert_block=0
в сессии в профиле

спасибо

Всем добрый день.
Такой вопрос: тестирую шардирование (пока на локальных виртуалках если это важно, по 4 ядра 8 Гб оперативки).
Есть тестовая таблица (из туториала кликхауса, та что hits_v1)
Она развернута как локально на 1 ноде вся, так и размазана по шардам через distributed таблицу по ключу rand()
Вопрос собственно в скорости, например обычный SELECT * дает одинаковый результат по скорости что из distributed что из локальной таблицы, хотя, насколько я понимаю, из distributed должен быть быстрее. Не в 3 раза конечно но как то и не в рамках погрешности. Или я неправильно понимаю? Может кто то сталкивался?
Версия 20.3.19.4
Заранее спасибо.

с чего бы просто select * быть быстрее? Это надо в диски упереться на 100%.

и как вы тестируете select * ? Я бы тестил select * from hits_v1 format Null -- чтобы клиент и сеть не были узким местом

и например попробуйте select * hits_v1 from where ClientIP = 666

и еще например select RegionID , count() hits_v1 from group by RegionID
CH и distributed созданы для запросов group by , а не для select *

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

КХ всасывает в хеш таблицу (K/V) данные из источника словаря.
если будет 10 Value для одного Key, то просто в хеш-таблице 10 раз перезапишется Value, и останется то которое вычиталось из источника последним

Спасибо! Получается, нет смысла оптимизировать потребление памяти в данном случае, это именно то, что я хотел узнать!

Привет, как посмотреть статус синхронизации реплики? Точнее узнать когда закончится копирование данных в реплику?

есть шард 2 реплики, в одной бэкапом восстановил данные, таблицы ReplicatedMergeTree, во второй просто создал таблицы.

шард автоматом начал репликацию данных. Вот как понять что он закончил и все актуализировано?

я смотрю по загрузке сети и занятому месту.
ну и select count() from system.replication_queue

отставание в system.replica absolute_delay

ну и тоже самое видно в http /replicas_status

Для мониторинга серверов в кластерной конфигурации необходимо установить параметр max_replica_delay_for_distributed_queries и использовать HTTP ресурс /replicas_status./replicas_status.