Алексей, а еще BI-системы рассматриваете для взаимодействия? Если да, то какие в ближайших планах?

Да, похоже на то, было бы круто конечно, чтобы при создании view появлялась соответствующая ошибка. А не падала загрузка в исходную таблицу.

Привет всем! Подскажите как можно результат вывода FORMAT JSON вернуть в select. примерно так select s from (select .... FORMAT JSON) as s;

Будем надеяться, что отсутствие поддержки subqueries во view временное.

Привет! Подскажите, пожалуйста, где можно посмотреть статистику, которая используется для load_balancing? Под нагрузкой запросы в distributed отправляются на реплики, не можем понять почему. Используем перекрестную репликацию и для нас это не очень выгодно. load_balancing стоит в in_order

Алексей, а поддержку SELECT db.table.column из роадмапа в этом году ждать можно? Теоретически, тогда еще и Pentaho заработает полноценно. Вчера с последний jdbc драйвером ее мучал, валится именно на этом

Ребят, туплю, не могу найти: как зафикисровтаь количество знаков после запятой для Float64 ?

Оно уже есть, но в ограниченном виде. При наличии JOIN, работает только для левой таблицы.

Недавно набросали вот такую штуку, чтобы лить данные в clickhouse через akka-stream: https://github.com/findify/clickhouse-akka-stream

Спасибо за информацию. Жаль, пентаха сама все sql запросы строит и как-то направить ее на путь истинный нельзя :(

Алексей, в КХ нет никаких встроенных способов выполнять сложные запросы в несколько потоков? Возможно оно из коробки умеет дробить запрос на N подзапросов и выполнять их параллельно. а результат склевивать?

unknown JOIN strictness (must be ANY or ALL)

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

ANY FULL OUTER JOIN

Можете привести пример? Простые запросы уже должны обрабатываться нормально.

Всем привет. Столкнулись с проблемой подвисших на сервере запросов. Проявляется когда накидываем кучу запросов на одну машину в кластере - в какой-то момент достигаем лимита на количество одновременно выполняющихся запросов, часть из них начинает отваливаться И вот часть из отвалившихся запросов остаётся висеть в system.processes. gdb и код кликхауза помогли найти место, где происходит что-то плохое: #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x0000000003f6363b in Poco::SemaphoreImpl::waitImpl() () #2 0x00000000034896e2 in DB::UnionBlockInputStream<(DB::StreamUnionMode)0>::finalize() () #3 0x000000000348a68a in DB::UnionBlockInputStream<(DB::StreamUnionMode)0>::~UnionBlockInputStream() () ... Судя по тому, что в коде UnionBlockInputStream перед вечным локом есть намёк на print-debugging //std::cerr « "popping\n"; output_queue.pop(res); , проблема известная. Можете посоветовать как избавиться от подобного?

https://pastebin.com/TiYvChmv тут действительно не db.table.column , а в каких-то условаиях не видит table.column. Структура таблиц == копия из pgsql и там все отрабатыает (на случай вопросов - а есть ли там такие поля)

Увидели, что в одном из последних релизов пофиксили дедлок, обновили кликхаус, но проблема осталась. Никто больше не сталкивался с этой багой?

есть функции floor, ceil, round

Алексей, у нас "тяжелый запрос" это 970 значений которые передаются в IN

В последнем релизе 54292 - не сталкивались. А какой именно дедлок? Для разбирательства важны следующие подробности: 1. Как это выглядить с вашей стороны. 2. Стек трейс всех потоков: sudo gdb -batch -ex 't apply all bt' -p $(pidof clickhouse-server) во время блокировки. Пишите на gist или pastebin.

1. Есть кластер из 20 шардов. У каждого шарда есть реплика, лежит на следующей ноде. Когда засылаем одновременно кучу запросов (150 запросов в секунду достаточно) на distributed таблицу (шарды ReplicatedReplacingMergeTree) на какую-то одну ноду, получаем на этой ноде подвисшие подзапросы к конкретной таблице с данными. Т.е. эти запросы навсегда поселяются в system.processes При этом кликхаус продолжает нормально работать. Но если попытаться убить зависший запрос, то сервер встаёт намертво, любой новый запрос виснет. 2. bactrace до kill query: https://gist.github.com/sfod/4820270e8060fe7741366ec54f3cae3a backtrace после kill query: https://gist.github.com/sfod/e0eef68aa69b138dc0353a138c87727c

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

Подскажите пожалуйста, вложенный запрос типа SELECT a, b from ( SELECT a, b FROM t) всегда в памяти будет лежать или КХ умеет такие в складывать во временные файлы?

Подскажите, пожалуйста, по внутренним словарям. Хочу подключить гео базу, но информации о континентах и федеральных округах нет. Можно ли пропустить эти типы регионов при создании иерархий?

Такой запрос будет выполнен с потоковой отправкой данных на клиента - будет израсходовано O(1) памяти.

https://twitter.com/ClickHouseDB/status/918499427597332481

Добрый вечер вот сделал небольшой синтетический тест, т.к. нужно посчитать последовательности подряд идущих событий, но обнаружилась одна неприятная вещь. КХ хочет 34G на выполнение запроса, которому ну 10М должно хватать заглаза. SELECT z.2 AS strike, count(*) AS count FROM (SELECT arrayPopFront(arrayMap((a, b) -> (a.1, a.2 - t[(b - 1)].2), arrayPushFront(arrayFilter(t -> (t.2 != 0), arrayMap((a, b) -> if(a != x[(b + 1)], (a, b), (0, 0)), x, arrayEnumerate(x))), (0, toUInt32(0))) AS t, arrayEnumerate(t))) AS z from (select arrayMap(a -> intHash32(a) % 2, range(150000)) as x)) ARRAY JOIN z GROUP BY z.2 такое ощущение, что на вызов каждой лямбды создается копия массива

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

а такой запрос: select userid, UUIDStringToNum(userid) from stat.stream_log limit 1000 вообще чудеса делает: ":) PuTTYPuTTYPuTTYPuTTYSegmentation fault"

тоже тогда справедливо и для IPv6StringToNum?

Спасибо. А будет видео?

А вот этот запрос уже не будет выполняться потоково. Функции высшего порядка размножают значения по количеству элементов массива, и в результате в оперативке получаются блоки большого размера. Попробуйте две вещи: 1. Уменьшить max_block_size. По-умолчанию значение 65536, соответсвенно, постепенно пробуйте значения 8192, 1024 и т. п. 2. Если же оперативки не хватает при GROUP BY, то можете включить агрегацию во внешней памяти.

можно както повлиять на этот таймаут со стороны КХ или это проблема драйвера и power bi?

Я сомневаюсь, что запрос доходит до ClickHouse. Можно посмотреть в логе.

Обновил beta.tabix.io Кто может, и кто испытывает проблемы - погоняйте|по тестируйте - на тормоза и мемлики) Бонус : plotly добавил 3D https://twitter.com/tabix_io/status/918606140027654144?s=17

не открывается окно ввод sql это норм?)

день добрый! подскажите, пожалуйста, есть ли более подробное описание функций для работы с временем/датами? в текущей версии документации не совсем прозрачно например: https://clickhouse.yandex/docs/ru/functions/date_time_functions.html#totime toTime Переводит дату-с-временем на некоторую фиксированную дату, сохраняя при этом время. что такое "некоторая фиксированная дата"? где и как она устанавливается? toRelativeYearNum Переводит дату-с-временем или дату в номер года, начиная с некоторого фиксированного момента в прошлом. что такое "начиная с некоторого фиксированного момента в прошлом"? что это за момент? как он устанавливается? в чём отличие от просто toYear?

Ну например у вас есть просто дата, а вам нужен DateTime. Дата останется фиксированной, а время подставится текущее