Если число соединений между серверами будет больше чем max_distributed_connections, выкинется исключение или запросы встанут в очередь?

Спасибо за полезную ссылку

Насколько я знаю, в КХ нет механизма очереди запросов, советуют использовать http://www.proxysql.com/blog/proxysql-143-clickhouse

да, где-то уже делали правку

Если число соединений между серверами будет больше чем max_distributed_connections, выкинется исключение или запросы встанут в очередь?

Привет! Создаю ReplicatedMergeTree (ENGINE = ReplicatedMergeTree('/clickhouse/tables/1/Turnovers','Turnovers1',RecordDate, (RecordDate,UserID), 8192)) на трех репликах, однако они не видят друг друга. Где бы посмотреть? Идеи кончились :( В логах на всех репликах такое (ошибок нет): 2018.02.12 07:06:08.240381 [ 4 ] <Debug> funprodwh.Turnovers (StorageReplicatedMergeTree): Creating table /clickhouse/tables/1/Turnovers ... 2018.02.12 07:06:08.246985 [ 4 ] <Information> funprodwh.Turnovers (StorageReplicatedMergeTree): This is the first replica ... 2018.02.12 07:06:08.254078 [ 24 ] <Information> funprodwh.Turnovers (StorageReplicatedMergeTree): Became leader В system.replicas везде total_replicas = 1.

max_distributed_connections отвечает за количество одновременных соединений к шардам при исполнении одного Distributed запроса. Если их будет больше, запросы просто выполнятся последовательно. Дефолтное значение - 1024, что более чем достаточно даже для самых больших кластеров :) Но возможно вы имели в виду настройку max_concurrent_queries_for_user, которая как раз отвечает за максимальное количество пользовательских запросов?

Доброго утра всем, вопрос такой, был ли у кого тут опыт с CH odbc + tableau? насколько хорошо работает и какие проблемы всплывали?

Нет, не будет. А вы хотите его уменьшить?

Так может быть, если реплики подключаются к разным кластерам ZooKeeper (например, ноды ZK сконфигурированы независимо и не собраны в кластер). Для работы Replicate таблиц конфигурировать кластера (тэг <remote_servers>) необязательно, достаточно сконфигурировать ZooKeeper.

max_distributed_connections по умолчанию установлено в 100 (если документация актуальна). Обработка исключение в любом случае должна быть.

На недавнем митапе был доклад: https://youtu.be/7Wcq6_9727A?t=24m59s Вкратце: в целом работает, но есть множество проблем с парсингом запросов, которые генерирует tableau. Проблемы постепенно исправляем, недавно был новый релиз odbc-драйвера: https://github.com/yandex/clickhouse-odbc/releases

Ага, значит в документации ошибка, спасибо. У себя значение можете проверить запросом select * from system.settings where name = 'max_distributed_connections'. Исключения, как я уже говорил, не будет.

Результат будет правильный, но запрос будет выполнен медленнее - в меньшее число потоков. Пример: у нас 4 шарда, max_distributed_connections=2. Значит запрос будет выполнен в 2 потока, сначала на двух шардах, потом на двух оставшихся.

День добрый, коллеги. Не могу понять как работает сжатие в CH. min_part_size и min_part_size_ratio проверяются с условием AND или OR? Перелили 700 ГБ сырых данных из Vertica с кастомным партицированием по неделям. сжалось только на 10%. В вертике сжимает В три(3) раза ? наши параметры: <clickhouse_compression> <case> <min_part_size>100000000</min_part_size> <min_part_size_ratio>0.01</min_part_size_ratio> <method>lz4</method> </case> </clickhouse_compression>

подскажите, где можно найти описание настроек (SETTINGS при создании таблицы/вьюшки) конкретного движка?

походу репликация умерла

Я верно понимаю, что JOIN сейчас полностью грузят "правую" таблицу при каждом запросе и ее имеет смысл помещать в движок JOIN, выделя под это необходимое количество оперативки (сейчас ее размер 2 ГБ в сжатом состоянии). В таблице хранятся строки (по типу имен пользователей), их около 100 млн, количество будет расти. JOIN идет по primary, но лог показывает, что читаются все строки, ключ не испоьзуется?

Подсобите пожалуйста, как понимать эту ошибку DB::Exception: Cannot parse input: expected \n before: .0\n2018-02-12\t �2 12:18:35\t6072736\t12208345\t22832753\t2140497316\t3207009083\t02a7 31a�: (at row 1)

Если без батча, просто инсертить, сохраняется без ошибки

@milovidov_an может быть ограничить максимальный размер запроса, который может быть обработан полноценным парсером, чтобы избежать ошибок, как указано выше?

Добрый день. При попытке экспорта даже с 1 строкой из CSVWithNames вида: "time","eventId","bannerId","idfa","platformId","hostId","ghostId","showId","userIp","param","gparam","answers","userAgent","referer","watchId","videoId","gparam2","date" 1486680824,3102,1881,"1486680749_5573035",2,248320,7617,14866808026836266,3116063728,"",30000138,"","","","","","","2017-02-09" 1486640392,3021,1881,"1486620643_2969813",2,248320,7617,148664039161868380,3116063696,"","","","","","","","","2017-02-09" Падает с ошибкой Code: 27. DB::Exception: Cannot parse input: expected , before: \n1486680824,3102 Больше ничего информативного в логах нет, в чем может быть еще проблема?

Смогли оживить?

Вы видимо импортируете CSV в Clickhouse. И у вас в CSV меньше полей, чем в таблице.

да, не экспорт конечно, а импорт. Обязательно все поля указывать? дефолтные значения не установит?

Тогда нужно явно указать в какие столбцы вы планируте вставлять имеющиеся данные insert into table (f1, f2, f3)

@Yuran нет, через JDBC и через терминальный клиент