Добрый вечер прошу подсказать есть один большой запрос (слишком большое вложение IN) через http clickhouse отвечает 400, мол слишком много, как быть и что делать?)

WHERE IN "local.csv.file"

"Внешние данные для обработки запроса" тут https://clickhouse.yandex/docs/ru/single/ ( не получается дать ссылку на раздел )

Добрый вечер прошу подсказать есть один большой запрос (слишком большое вложение IN) через http clickhouse отвечает 400, мол слишком много, как быть и что делать?)

Попробуйте отправить запрос в теле HTTP POST

Есть ещё ограничения в самом парсере запросов, но их можно поднять. В HTTP-парсере гвоздями прибито ограничение URL не больше 16кб.

Подскажите по ON CLUSTER и его работоспособновтси Вчера опробовал ON CLUSTER через отправку запроса DROP TABLE IF EXISTS db.last_state_model ON CLUSTER model Такой таблицы не существовало, весь кластер пропал - пришлось вручную поднимать каждую ноду Сегодня пытаюсь еще раз попробовать : отправляю несколько комманд `DROP TABLE IF EXISTS db.last_state_model ON CLUSTER model ... CREATE TABLE db.last_state_model ON CLUSTER model ...` Через какоето время отправляю еще пару запросов DROP TABLE IF EXISTS db.last_state_model ON CLUSTER model Происходит падение всего кластера из 6 нод ;( Из лога нахожу : `BaseDaemon: (from thread 24948) Received signal Segmentation fault (11). BaseDaemon: Address: NULL pointer. BaseDaemon: 0. clickhouse-server(DB::ProcessList::addTemporaryTable(DB::ProcessListElement&, std::string const&, std::shared_ptr<DB::IStorage>)+0x8c) [0x29602cc] BaseDaemon: 1. clickhouse-server(DB::Context::addExternalTable(std::string const&, std::shared_ptr<DB::IStorage>)+0x207) [0x2986dc7] ` Куда смотреть ? Подскажите кто-то использует ON CLUSTER у вас нормально работает в проде ?

В проде у нас включен, но еще активно не используется. Можете полный кусок лога показать а также show create table? И вас 54276 версия?

добрай день, расскажите, пожалуйста, где почитать про clickhouse benchmark?

как его юзать и как анализировать результтаы?

как его юзать и как анализировать результтаы?

Готовите файлик queries.txt с набором запросов (каждый запрос на своей строке) - например, запросы из query_log с продакшена, или один запрос, который хочется ускорить какими-то настройками. Запускаете командой cat queries.txt | clickhouse --benchmark -c4 (параметр -c определяет, во сколько потоков будут задаваться запросы). Дальше ждёте, пока он задаст все запросы по нескольку раз и нажимаете ctrl-C. В результате получаются квантили времён выполнения запросов.

Движок CollapsedMergeTree. Возникает ситуация, когда появляются строки с sign=0. После этого схлопывание останавливается. Не подскажите, варианты их возникновения ?

Готовим багфикс-релиз (относительно 1.1.54276) с фиксами следующих багов: * Assertion violation: !_path.empty() при вставке в Distributed таблицу * Фиксы рантайм-компиляции агрегатных функций * Проблемы с парсингом формата RowBinary

Фиксы уже в мастере, пакеты скорее всего завтра.

Спасибо за оперативность!

Супер, спасибо

?Прям быстро, спасибо!

В проде у нас включен, но еще активно не используется. Можете полный кусок лога показать а также show create table? И вас 54276 версия?

Я попробую сегодня вечером / завтра собрать тестовый кластер - и там погонять Т/к в логах очень много всего - у нас Debug режим, и найти что-то тяжело )

ClickHouse 1.1.54276

@ztlpn а подскажите пожалуйста еще, как указать хост и порт при использовании бенчмарка?

нашел, сорри

(для истории) так же, как в клиенте - --host, --port

Смотрю на результаты, и, кажется, квантили не кумулятивные, а за последнюю пачку запросов.. так?

Всем привет. Конвертим таблички из MergeTree в ReplicatedMergeTree. Сделали все по инструкции, но у нас задублировались данные за август. Пока что рабочая теория - что мы копировали парты в момент склейки, и скопировали как и несклеенный, так и склеенные

Возможно ли такое, и как от этого защищаться?

В логе скрипта: Copy parts: - 20170404_20170404_2_4_1 - 20170601_20170630_6_482_75 - 20170630_20170630_484_484_0 - 20170701_20170731_486_1170_106 - 20170731_20170731_1172_1172_0 - 20170801_20170823_1174_2368_241 - 20170801_20170823_1174_2373_242 - 20170823_20170823_2369_2369_0 - 20170823_20170823_2370_2370_0 - 20170823_20170823_2371_2371_0 - 20170823_20170823_2372_2372_0 - 20170823_20170823_2373_2373_0

Судя по всему, вот причина дубля: - 20170801_20170823_1174_2368_241 - 20170801_20170823_1174_2373_242

когда начали разбираться партов стало уже меньше 20170404_20170404_2_4_1 20170601_20170630_6_482_75 20170630_20170630_484_484_0 20170701_20170731_486_1170_106 20170731_20170731_1172_1172_0 20170801_20170823_1174_2373_242

Да, похоже, это и произошло. Такие манипуляции лучше проводить при выключенном сервере, или использовать FREEZE PARTITION

а можно как-то запретить склейку на некоторое время?

Такое есть в планах, но сейчас нет (кстати, правильнее не "склейка", а "слияние" ? ). Попробуйте через ALTER TABLE FREEZE PARTITION - команда создаст снапшот данных, который уже можно спокойно копировать.

есть таблица src и Summing MV на неё src_country CREATE TABLE default.src ( date Date, datetime DateTime, userId UInt64, countryId UInt8, typeId UInt8 ) ENGINE = MergeTree(date, (userId, datetime), 8192) CREATE MATERIALIZED VIEW default.src_country ( date Date, datetime DateTime, userId UInt64, recordsByCountryMap Nested( countryId UInt8, records UInt64 ) ) ENGINE = SummingMergeTree(date, (date, datetime, userId), 8192) AS SELECT date, toStartOfMinute(datetime) AS datetime, userId, [countryId] as recordsByCountryMap.countryId, [count()] AS recordsByCountryMap.records FROM default.src GROUP BY date, datetime, userId, countryId В документации движка SummingMergeTree указано, что производится суммирование для столбцов заканчивающихся на 'Map'. Но если данные вставлены в разных пачках, то их суммирует только optimize либо они сами "когда-то" просуммируются. Вопрос - есть ли агрегирующая функция, которая сложит соотвествующие значения по ключам? Или до-агрегацию в таком случае производить на стороне клиента в коде? Пример: SELECT * FROM src_country ┌───────date─┬────────────datetime─┬─userId─┬─recordsByCountryMap.countryId─┬─recordsByCountryMap.records─┐ │ 2017-01-01 │ 2017-01-01 00:00:00 │ 1 │ [10] │ [4] │ └────────────┴─────────────────────┴────────┴───────────────────────────────┴─────────────────────────────┘ ┌───────date─┬────────────datetime─┬─userId─┬─recordsByCountryMap.countryId─┬─recordsByCountryMap.records─┐ │ 2017-01-01 │ 2017-01-01 00:00:00 │ 1 │ [10] │ [4] │ └────────────┴─────────────────────┴────────┴───────────────────────────────┴─────────────────────────────┘ ┌───────date─┬────────────datetime─┬─userId─┬─recordsByCountryMap.countryId─┬─recordsByCountryMap.records─┐ │ 2017-01-01 │ 2017-01-01 00:00:00 │ 1 │ [10,11] │ [4,3] │ └────────────┴─────────────────────┴────────┴───────────────────────────────┴─────────────────────────────┘ SELECT datetime, groupArray(recordsByCountryMap.countryId), groupArray(recordsByCountryMap.records) FROM src_country WHERE userId = 1 GROUP BY datetime ┌────────────datetime─┬─groupArray(recordsByCountryMap.countryId)─┬─groupArray(recordsByCountryMap.records)─┐ │ 2017-01-01 00:00:00 │ [[10],[10],[10,11]] │ [[4],[4],[4,3]] │ └─────────────────────┴───────────────────────────────────────────┴─────────────────────────────────────────┘

https://github.com/yandex/ClickHouse/releases/v1.1.54282-stable was tagged

Фиксы уже в мастере, пакеты скорее всего завтра.

Пакеты версии 1.1.54282 в репозитории, changelog: https://github.com/yandex/ClickHouse/blob/master/CHANGELOG_RU.md#%D0%A0%D0%B5%D0%BB%D0%B8%D0%B7-clickhouse-1154282

Готовите файлик queries.txt с набором запросов (каждый запрос на своей строке) - например, запросы из query_log с продакшена, или один запрос, который хочется ускорить какими-то настройками. Запускаете командой cat queries.txt | clickhouse --benchmark -c4 (параметр -c определяет, во сколько потоков будут задаваться запросы). Дальше ждёте, пока он задаст все запросы по нескольку раз и нажимаете ctrl-C. В результате получаются квантили времён выполнения запросов.

А когда один и тот же запрос задается несколько раз при бэнчмарке, кэширование как-то отключается?

ак вроде нет такой штуки как кеширование в кх

Ну если задать один и тот же запрос в клиенте, например, и сравнить время исполнения, получается, что есть -- второй запрос отработает намного быстрее первого

там кэш ОС, можно сбросить sync; echo 3 > /proc/sys/vm/drop_caches

pagecache можно сбросить, да. это главное. https://clickhouse.yandex/docs/ru/single/#mark-cache-size есть ещё кэш засечек https://clickhouse.yandex/docs/ru/single/#uncompressed-cache-size и есть кэш неразжатых данных для небольших запросов (только для действительно небольших). Больше кэшей особо влияющих на скорость запросов нет, кажется

Спасибо!

Такое есть в планах, но сейчас нет (кстати, правильнее не "склейка", а "слияние" ? ). Попробуйте через ALTER TABLE FREEZE PARTITION - команда создаст снапшот данных, который уже можно спокойно копировать.

ок. Спасибо. будем пробовать

Кстати, а добавьте плиз, про FREEZE PARTITION в доку по миграции с MergeTree в ReplicatedMergeTree. нам очень повезло, что мы этот баг поймали на маленькой тестовой табличке.

Добрый вечер, подскажите оптимальный вариант для подсчета визитов, имея таблицу логов хитов. Тип таблицы использую MergeTree. По доке рекомендуют использовать CollapsingMergeTree. (прочитав чат, понял, что метрика это делает вне ch, правильно? )

зависит от вашего определения визита.

метрика делает вне ch, правильно.

визит группа хитов, интервал между которыми равен n (n - время, минимум 30 минут максимум 1 час, задается уже непосредственно перед выборкой из ch)

чтобы считать сессии по событиям вам нужен либо group by user_id который не масштабируется с какой-то работой с получающимися массивами историй которые в общем случае не ограничены ничем по размеру, либо события лежащие по юзерам и по времени, с какой-то подходящей функциональностью оконных функций, ни того ни того в готовом для данной задачи виде сейчас еще нет. второй момент состоит в том, что плюс который вы имеете - это изменение таймаута, польза от этого не очевидна. зато на каждое чтение у вас оверхед на построение сессий.

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

Доброе утро! Помогите пожалуйста, у меня есть 8 злачный номер, как мне выбирать UInit8 или 16?

И еще хочу загрузить csv а рам разделитель ";" а CH принимает только запятую

UInt32 нужен, 32 - это разрядность двоичного числа

Доброе утро! Помогите пожалуйста, у меня есть 8 злачный номер, как мне выбирать UInit8 или 16?

http://edoras.sdsu.edu/doc/matlab/techdoc/ref/int8.html http://edoras.sdsu.edu/doc/matlab/techdoc/ref/uint8.html

И еще хочу загрузить csv а рам разделитель ";" а CH принимает только запятую

http://colin.maudry.com/csvtool-manual-page/

Спасибо

Всем привет, апнули версию гошного драйвера (https://github.com/kshvakov/clickhouse). По большей части это рефакторинг, т.к. изначально всё было сделано совсем на коленке и поддерживать было уже сложно. Но кое-что всё же добавилось: * добавили типы Nullable(T) и UUID * добавили параметр connection_open_strategy, по умолчанию работает как раньше (random), т.е. при попытке открытия нового соединения пытается выбрать какое-то; и in_order когда пытается достучаться до первого рабочего сервера из списка * реализовали интерфейс NamedValueChecker для Go 1.9, начиная с Go 1.9 database/sql будет отдавать проверку типов в драйвер (если реализован NamedValueChecker) что в случае библиотеки для ClickHouse ускорит запись в 2-2.5 раза и уменьшит потребление CPU/памяти * улучшен интерфейс Сolumnar () (https://github.com/kshvakov/clickhouse/blob/master/examples/columnar.go) за что огромное спасибо Marek Vavruša (https://github.com/vavrusa) из Cloudflare. Интерфейс позволяет заливать очень много данных гораздо быстрее с меньшим расходом CPU и памяти чем стандартный

@orantius спасибо ;)

Всем привет, апнули версию гошного драйвера (https://github.com/kshvakov/clickhouse). По большей части это рефакторинг, т.к. изначально всё было сделано совсем на коленке и поддерживать было уже сложно. Но кое-что всё же добавилось: * добавили типы Nullable(T) и UUID * добавили параметр connection_open_strategy, по умолчанию работает как раньше (random), т.е. при попытке открытия нового соединения пытается выбрать какое-то; и in_order когда пытается достучаться до первого рабочего сервера из списка * реализовали интерфейс NamedValueChecker для Go 1.9, начиная с Go 1.9 database/sql будет отдавать проверку типов в драйвер (если реализован NamedValueChecker) что в случае библиотеки для ClickHouse ускорит запись в 2-2.5 раза и уменьшит потребление CPU/памяти * улучшен интерфейс Сolumnar () (https://github.com/kshvakov/clickhouse/blob/master/examples/columnar.go) за что огромное спасибо Marek Vavruša (https://github.com/vavrusa) из Cloudflare. Интерфейс позволяет заливать очень много данных гораздо быстрее с меньшим расходом CPU и памяти чем стандартный

Очень круто, особенно про колумнар

Давно ждал

Всем привет Надо подсчитать кол-во переходов IP и продолжительность периода Схема базы CREATE TABLE user_ips ( userID String, ip String, dateAt DateTime DEFAULT now() ) ENGINE = Log; Положим данные такие (дату опустил) 10, 1.1.1.1 10, 2.2.2.2 10, 2.2.2.2 10, 1.1.1.1 10, 1.1.1.1 10, 2.2.2.2 Всего переходов получается 3, уникальных IP - 2 для юзера 10 Есть мысли как это сделать SQLом?

Движок CollapsedMergeTree. Возникает ситуация, когда появляются строки с sign=0. Не подскажите, варианты их возникновения?

самый очевидный - записали туда 0

Есть вопрос про бенчмарк.

Смотрю на результаты, и, кажется, квантили не кумулятивные, а за последнюю пачку запросов.. так?

:

^ @ztlpn в личку может?

Точно не помню - вроде бы пока работает, пишет про последнюю пачку, а после ctrl-C за всё время выполнения. Могу сегодня уточнить.

а вот как! спасибо, похоже на правду да.

Подскажите как лучше время визита писать, через промежуточное хранилище или можно просто CollapsingMergeTree?

@ztlpn @milovidov_an Привет, поймали баг: Была таблица в которой хранились UUID как FixedString(16) (неправильные или пустые UUID записываем как "00000000-0000-0000-0000-000000000000") Перешли на встроенный тип UUID, удобно, но при репликации получаем: Row 2: ────── database: stats table: events_local replica_name: ch1 position: 1 node_name: queue-0000000006 type: MERGE_PARTS create_time: 2017-08-24 10:31:06 required_quorum: 0 source_replica: ch1 new_part_name: 20170821_20170824_0_5_1 parts_to_merge: ['20170824_20170824_0_0_0','20170824_20170824_1_1_0','20170821_20170824_2_2_0','20170824_20170824_3_3_0','20170824_20170824_4_4_0','20170824_20170824_5_5_0'] is_detach: 0 is_currently_executing: 0 num_tries: 55 last_exception: Code: 169, e.displayText() = DB::Exception: Bad type of Field, e.what() = DB::Exception last_attempt_time: 2017-08-24 10:32:46 num_postponed: 0 postpone_reason: last_postpone_time: 0000-00-00 00:00:00 И как следствие при записи code: 252, message: Too much parts. Merges are processing significantly slower than inserts.

Интересно, а можете поискать в логах стектрейс ошибки DB::Exception: Bad type of Field?

2017.08.24 10:33:18.209109 [ 9 ] <Error> DB::StorageReplicatedMergeTree::queueTask()::<lambda(DB::StorageReplicatedMergeTree::LogEntryPtr&)>: Code: 169, e.displayText() = DB::Exception: Bad type of Field, e.what() = DB::Exception, Stack trace: 0. clickhouse-server(StackTrace::StackTrace()+0x16) [0x2bed4a6] 1. clickhouse-server(std::decay<DB::FieldVisitorToString>::type::ResultType DB::applyVisitor<DB::FieldVisitorToString, DB::Field>(DB::FieldVisitorToString&&, DB::Field&&)+0x14d) [0x2ed33bd] 2. clickhouse-server(DB::CollapsingSortedBlockInputStream::reportIncorrectData()+0x323) [0x2ed09c3] 3. clickhouse-server(DB::CollapsingSortedBlockInputStream::insertRows(std::vector<DB::IColumn*, std::allocator<DB::IColumn*> >&, unsigned long&, bool)+0x3d8) [0x2ed1928] 4. clickhouse-server(void DB::CollapsingSortedBlockInputStream::merge<DB::SortCursor>(std::vector<DB::IColumn*, std::allocator<DB::IColumn*> >&, std::priority_queue<DB::SortCursor, std::vector<DB::SortCursor, std::allocator<DB::SortCursor> >, std::less<std::vector<DB::SortCursor, std::allocator<DB::SortCursor> >::value_type> >&)+0x660) [0x2ed71f0] 5. clickhouse-server(DB::CollapsingSortedBlockInputStream::readImpl()+0x3f6) [0x2ed22e6] 6. clickhouse-server(DB::IProfilingBlockInputStream::read()+0x221) [0x255db11] 7. clickhouse-server(DB::MergeTreeDataMerger::mergePartsToTemporaryPart(std::vector<std::shared_ptr<DB::MergeTreeDataPart const>, std::allocator<std::shared_ptr<DB::MergeTreeDataPart const> > >&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, DB::MergeListEntry&, unsigned long, long, DB::DiskSpaceMonitor::Reservation*, bool)+0x2aa7) [0x2e078f7] 8. clickhouse-server(DB::StorageReplicatedMergeTree::executeLogEntry(DB::ReplicatedMergeTreeLogEntry const&)+0xfd2) [0x2ce9c72] 9. clickhouse-server() [0x2cec68d] 10. clickhouse-server(DB::ReplicatedMergeTreeQueue::processEntry(std::function<std::shared_ptr<zkutil::ZooKeeper> ()>, std::shared_ptr<DB::ReplicatedMergeTreeLogEntry>&, std::function<bool (std::shared_ptr<DB::ReplicatedMergeTreeLogEntry>&)>)+0x4a) [0x2d7bc6a] 11. clickhouse-server(DB::StorageReplicatedMergeTree::queueTask()+0x150) [0x2cd7540] 12. clickhouse-server(DB::BackgroundProcessingPool::threadFunction()+0x3de) [0x2de074e] 13. clickhouse-server() [0x399ca5f] 14. /lib/x86_64-linux-gnu/libpthread.so.0(+0x76ba) [0x7f6568e866ba] 15. /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7f65684a73dd]

хотел ещё раз сказать спасибо: 3 млрд записей и всё работает с невообразимой скоростью

привет. а где можно почитать об архитектуре кликхаус? эдакий хайлевел описание проекта.

привет, есть кто-то с carbon + graphite + clickhouse? имею примерно 90кк метрик в минуту, хочу поспрашивать про оптимизации clickhouse под E5-2620 v3/256G/raid6 ssd 960G

привет, есть кто-то с carbon + graphite + clickhouse? имею примерно 90кк метрик в минуту, хочу поспрашивать про оптимизации clickhouse под E5-2620 v3/256G/raid6 ssd 960G

эти обычно тут @metrics_ru

спасибо

привет. а где можно почитать об архитектуре кликхаус? эдакий хайлевел описание проекта.

https://clickhouse.yandex/docs/en/development/architecture.html

https://clickhouse.yandex/docs/en/development/architecture.html

о! большое спасибо. это ссылку я и проглядел

2017.08.24 10:33:18.209109 [ 9 ] <Error> DB::StorageReplicatedMergeTree::queueTask()::<lambda(DB::StorageReplicatedMergeTree::LogEntryPtr&)>: Code: 169, e.displayText() = DB::Exception: Bad type of Field, e.what() = DB::Exception, Stack trace: 0. clickhouse-server(StackTrace::StackTrace()+0x16) [0x2bed4a6] 1. clickhouse-server(std::decay<DB::FieldVisitorToString>::type::ResultType DB::applyVisitor<DB::FieldVisitorToString, DB::Field>(DB::FieldVisitorToString&&, DB::Field&&)+0x14d) [0x2ed33bd] 2. clickhouse-server(DB::CollapsingSortedBlockInputStream::reportIncorrectData()+0x323) [0x2ed09c3] 3. clickhouse-server(DB::CollapsingSortedBlockInputStream::insertRows(std::vector<DB::IColumn*, std::allocator<DB::IColumn*> >&, unsigned long&, bool)+0x3d8) [0x2ed1928] 4. clickhouse-server(void DB::CollapsingSortedBlockInputStream::merge<DB::SortCursor>(std::vector<DB::IColumn*, std::allocator<DB::IColumn*> >&, std::priority_queue<DB::SortCursor, std::vector<DB::SortCursor, std::allocator<DB::SortCursor> >, std::less<std::vector<DB::SortCursor, std::allocator<DB::SortCursor> >::value_type> >&)+0x660) [0x2ed71f0] 5. clickhouse-server(DB::CollapsingSortedBlockInputStream::readImpl()+0x3f6) [0x2ed22e6] 6. clickhouse-server(DB::IProfilingBlockInputStream::read()+0x221) [0x255db11] 7. clickhouse-server(DB::MergeTreeDataMerger::mergePartsToTemporaryPart(std::vector<std::shared_ptr<DB::MergeTreeDataPart const>, std::allocator<std::shared_ptr<DB::MergeTreeDataPart const> > >&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, DB::MergeListEntry&, unsigned long, long, DB::DiskSpaceMonitor::Reservation*, bool)+0x2aa7) [0x2e078f7] 8. clickhouse-server(DB::StorageReplicatedMergeTree::executeLogEntry(DB::ReplicatedMergeTreeLogEntry const&)+0xfd2) [0x2ce9c72] 9. clickhouse-server() [0x2cec68d] 10. clickhouse-server(DB::ReplicatedMergeTreeQueue::processEntry(std::function<std::shared_ptr<zkutil::ZooKeeper> ()>, std::shared_ptr<DB::ReplicatedMergeTreeLogEntry>&, std::function<bool (std::shared_ptr<DB::ReplicatedMergeTreeLogEntry>&)>)+0x4a) [0x2d7bc6a] 11. clickhouse-server(DB::StorageReplicatedMergeTree::queueTask()+0x150) [0x2cd7540] 12. clickhouse-server(DB::BackgroundProcessingPool::threadFunction()+0x3de) [0x2de074e] 13. clickhouse-server() [0x399ca5f] 14. /lib/x86_64-linux-gnu/libpthread.so.0(+0x76ba) [0x7f6568e866ba] 15. /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7f65684a73dd]

Спасибо, проблема понятна. Не было дописано немного необходимого кода - в частности для распечатки в дебаг-сообщениях.

Слушайте) а тут вопрос возник насчёт нет клиента. Вот тот который в гитхабе лежит -он один? Он де мягко говоря неочень должен работать с этими ифами

Слушайте) а тут вопрос возник насчёт нет клиента. Вот тот который в гитхабе лежит -он один? Он де мягко говоря неочень должен работать с этими ифами

Если вы про веб-интерфейс - я использую Apache Zeppelin. Лучше конечно чем консоль, но не сильно (нет подсветки и подсказок)

про нативный клиент для c#)

Слушайте) а тут вопрос возник насчёт нет клиента. Вот тот который в гитхабе лежит -он один? Он де мягко говоря неочень должен работать с этими ифами

он на гитхабе лежит и с чем он не должен работать ?

исправила.спасибо. он работает, но наверное не супер быстро из--за того что много проверок ну вобщем-то это нестрашно и переписать можно. просто узнать хотела неужели он один и никто не выложил другого?

Привет! Никто ещё не сделал kernel или magic для jupyter для ClickHouse? Я немного потерялся, вроде очевидная вещь, но ничего не нашел)

Пытаюсь через pyspark и jdbc-драйвер вставить строку с колонкой queries и типом Array(String) Получаю ошиюбку: Exception: Cannot parse quoted string: expected opening quote Значение перед вставкой (вывод в консоль) http://joxi.ru/V2VEkayt0qnqKm Вывод в log http://joxi.ru/krDGe8Vi0xnxdA Всё тоже самое. но Array(UInt8) отрабатывает на ура. Никто не сталкивался?

както можно вообще потраблшутить кликхаус зукипер? такое ощущение, что кх просто игнрорует кусок в конфиге

не цепляется ?

ну запускаю кластер зу, все норм, запускаю кх - в логах ничего такого

а когда делаю таблицу - пишет что без зукпиера не может