Это абсолютно не оно. Вообще не рядом. Откройте свою багу. Никто из разработчиков не вкурсе про вашу проблему

Добрый день товарищи!
Я раньше никогда не имел дел с добавлением больших объемов данных в базы поэтому у меня тупой вопрос.
Насколько сильно ограничен по длине SQL-запрос для Кликхауса?

моя проблема кстати решилась убиранием DEDUPLICATE из OPTIMIZE FINAL, но для replacing merge tree он и не нужен

то есть получается все работает

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

Словил глюк при копировании таблиц с одинаковой структурой с разницей в движке, исходная MergeTree, приемник ReplicatedMergeTree, INSERT INTO table1 SELECT * FROM table1_replicated; в результате значения одного из полей улетели в другой столбец. Кто-то сталкивался?

моя проблема кстати решилась убиранием DEDUPLICATE из OPTIMIZE FINAL, но для replacing merge tree он и не нужен

то есть получается все работает

да я уже понял, спасибо ) хотя порядок полей в create не менял вроде

Всем привет! Подскажите, есть какие-то рекомендации по оптимальному объёму партиций? Как понять что партицирование по месяцу уже слишком жирно и нужно, например, по неделе партицировать. Как не наломать дров и не сделать партиции слишком мелкими.

Вообще у кх настраивается длина запроса. Но в вашем случае это вообще не вадно. Правильный Insert обрабатывается другим парсером. Стрим парсером -- ему не важно длина запроса. Он обрабатывает поток и не ждет конца запроса. Вставляя кусками.

Тогда делайте месячные. Не шучу.

Ребят помогите разобраться в следующей ситуации.
У меня есть кластер из 2 шардов по 2 реплики. Когда отправляю запрос в каждую из локальных таблиц, запрос отрабатывает за 3сек, а когда этот же запрос отправляю в Distributed, он отрабатывает за 30 сек

Тогда - это в смысле чтоб не наломать дров?

Добрый день, подскажите плиз, по какой причине кх не использует всю доступную ему память? Выделено 400Gb (max_memory_usage_for_all_queries, max_memory_usage, max_memory_usage_for_user). В системе свободно более 500 (правда в buff/cache). Запрос съедает где-то 50gb и начинает слать (DB::Exception: Received from stat8:9000. DB::ErrnoException. DB::ErrnoException: Allocator: Cannot malloc 1.00 MiB., errno: 12, strerror: Cannot allocate memory: (avg_value_size_hint = 69.66058823529411, avg_chars_size = 73.99270588235294, limit = 8192): (while reading column uagent): (while reading from part /var/lib/clickhouse/data/ladnl/dnl_log_local/3287_0_2873_8_16121/ from mark 55681 with max_rows_to_read = 8192):
Происходит это только на одной ноде из 8, конфики везде одинаковые, железо практически тоже.  
Версия 19.13.6.51

Добрый день. Долго гуглил, но не нашел ответа по zookeeper. Может кто-нибудь сказать про конфигурацию серверов под него, а именно сколько место нужно на hdd с вот такими настройками:
tickTime=2000
dataDir=/data/zookeeper
clientPort=2181
maxClientCnxns=2000
initLimit=30000
syncLimit=10
maxSessionTimeout=60000000
autopurge.snapRetainCount=10
autopurge.purgeInterval=1
preAllocSize=131072
snapCount=3000000
?

может там какой нить PREWHERE не отрабатывает