https://en.wikipedia.org/wiki/IEEE_754

вот там подробнее

если очень вкратце - то в памяти у тебя записывается экспонента и мантиса и по ним число восстанавливается, но есть некоторые особенности такого.

уши проблемы растут от того что double это мантиса * 2^порядок

вопрос не в том, как Float хранится в памяти, а в том, что функция преобразования строки парсит неправильно

Что конкретно неправильно? То, что строковое представление не возвращается обратно в 1516.13?

Что конкретно неправильно? То, что строковое представление не возвращается обратно в 1516.13?

Уже неактуально, перевел всё в Int64 * 100, дольше разбираться

если работаете с деньгами (и если я не пропустил введение decimal в кликхаус), то это, наверное, самый правильный путь

вопрос не в том, как Float хранится в памяти, а в том, что функция преобразования строки парсит неправильно

почему парсит неправильно то?

все верно

видимо потому что в данном случае toFloat64(x) != toFloat64(toString(x))

Я, наверное, перефразирую, скорее вопрос не в том, как КХ парсит числа с плавающей точкой, а на сколько вообще точны арифметические операции, а дальше и аналитеческие функции. И, если заходить глубже, возможно ли использовать КХ для аналитики с большой чувствительности к отклонениям

хотя казалось бы разбор float64 строки "из запроса" и "из строки" должен вести себя одинаково.

Я, наверное, перефразирую, скорее вопрос не в том, как КХ парсит числа с плавающей точкой, а на сколько вообще точны арифметические операции, а дальше и аналитеческие функции. И, если заходить глубже, возможно ли использовать КХ для аналитики с большой чувствительности к отклонениям

настолько, насколько точны ieee754 и стандартные реализации математических функций.

ну, то есть, округлять?

ну, то есть, округлять?

то есть тебе решать. Такие артефакты будут вылезать, потому что так построен ieee754

на котором впрочем базируется большая часть вещественной арифметики, включая научной

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

а в чем проблема использовать их для денег при условии 7 знаков после запятой?

а в чем проблема использовать их для денег при условии 7 знаков после запятой?

ошибка будет накапливаться

то есть тебе решать. Такие артефакты будут вылезать, потому что так построен ieee754

поэтому, как написал выше Int64/100

поэтому, как написал выше Int64/100

уже сказали что для денег это прям оптимальное решение для любого случая

https://stackoverflow.com/a/3730040

что, впрочем, не отменяет вопрос про x!=toFloat64(toString(x))

а в чем проблема использовать их для денег при условии 7 знаков после запятой?

Было не мало случаев когда в банковских структурах теряли миллионы из-за вот таких погрешностей :)

а в чем проблема использовать их для денег при условии 7 знаков после запятой?

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

Добрый день. Привет из Минска всем. Пропустил митап, увидел только 30 блин. Надеюсь наверстать тут и в мэйлнг листе. Может кто по доброте душевной ответит, прольет свет тут на некоторые вопросы, буду примного благодарен. https://groups.google.com/forum/#!topic/clickhouse/xzlFiMBIhi4

Хотел спросить для понимания: а в чём причина гедетерминированности anyLast - в том что выбирается одно значение из нескольких потоков? Пишется в mergetree оно тоже произвольно?

так более оптимально.jpg

пишется в mergetree?

Если бы я все до одного потока сократил - anylast стал бы нормальным last? :)

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

Просто argMax довольно тяжёлой операцией выглядит. Надо как минимум дополнительное поле читать. При уверенности если пишется в mergetree складывается в нужной последовательности, то можно было бы этого избежать.

Не пойму как другие anyLast или просто any используют. Например получить последнюю цену.

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

Ещё вопрос: поставил uncompressed cache: 20gb. Но virt/res клик-хаус занимает 400/113mb. А где кеш? Хотя вроде все загружено. Или я чего-то не дополнял где он должен быть виден.

Подскажите, а можно как-то схлопнуть rows в массив? ( плоховато у меня с array ) Пример таблица : | datetime | some_id | value | Если сгруппировать по some_id получить массив из [ value от первого datetime, value от второго datetime, и т/д ]

groupArray?

groupArray?

Спасибо, то что нужно )

Вопрос: возможна потенциально какая-то блокировка сессии юзера? Например запрос в одной сессии, но нитки занимаются аггрегацией запроса другого юзера.

И очередной вопрос: а что есть для аналитиков кроме tabix?

если речь про дашборды то superset хорош и дружит с кликхаузом

Ещё вопрос: поставил uncompressed cache: 20gb. Но virt/res клик-хаус занимает 400/113mb. А где кеш? Хотя вроде все загружено. Или я чего-то не дополнял где он должен быть виден.

Ещё надо включить в запросах: use_uncompressed_cache = 1 (настрока запроса или профиля пользователя).

Не пойму как другие anyLast или просто any используют. Например получить последнюю цену.

anyLast редко имеет смысл использовать. Исключение - подзапрос с ORDER BY.

Вопрос: возможна потенциально какая-то блокировка сессии юзера? Например запрос в одной сессии, но нитки занимаются аггрегацией запроса другого юзера.

В ClickHouse на каждый запрос свои полноценные потоки ОС, то есть нет shared потоков для разных запросов. Это можно рассматривать, как недостаток - при обработке большого количества запросов создаётся много потоков, которые ОС вынуждена переключать по своему усмотрению.

И очередной вопрос: а что есть для аналитиков кроме tabix?

А подскажите, что хотелось бы в tabix, и чего не хватает? Интересно, т.к рисую роадмап себе на будущее

И очередной вопрос: а что есть для аналитиков кроме tabix?

Для графаны ставил плагин для clickhouse - работает в режиме прокси

А подскажите, что хотелось бы в tabix, и чего не хватает? Интересно, т.к рисую роадмап себе на будущее

Я бы смотрел в сторону Redash. Сохраняемые запросы/графики, типа того

Я бы смотрел в сторону Redash. Сохраняемые запросы/графики, типа того

Да это в ближайших планах - "дашбординг"

Коллеги, а с отрицательными Enum'ами ни у кого проблем не было? Почему то фейлится запрос и не пойму почему. SELECT * FROM orders WHERE Status = 'REFUND' Received exception from server: Code: 49. DB::Exception: Received from localhost:9000, ::1. DB::Exception: Unknown element 'REFUND' for type Enum8('REFUND' = -2, 'ERROR' = -1, 'INCOMPLETE' = 0, 'SUCCESS' = 1). UPD: решено вот так: select * from adguard.orders WHERE toInt8(Status)=-2

Да это в ближайших планах - "дашбординг"

Да может и не дэшбординг-дешбординг, запросы бы просто сохранить, для начала %)

Коллеги, а с отрицательными Enum'ами ни у кого проблем не было? Почему то фейлится запрос и не пойму почему. SELECT * FROM orders WHERE Status = 'REFUND' Received exception from server: Code: 49. DB::Exception: Received from localhost:9000, ::1. DB::Exception: Unknown element 'REFUND' for type Enum8('REFUND' = -2, 'ERROR' = -1, 'INCOMPLETE' = 0, 'SUCCESS' = 1). UPD: решено вот так: select * from adguard.orders WHERE toInt8(Status)=-2

Не получилось воспроизвести: :) CREATE TABLE test.enum (x Enum8('REFUND' = -2, 'ERROR' = -1, 'INCOMPLETE' = 0, 'SUCCESS' = 1)) ENGINE = Memory CREATE TABLE test.enum ( x Enum8('REFUND' = -2, 'ERROR' = -1, 'INCOMPLETE' = 0, 'SUCCESS' = 1) ) ENGINE = Memory Ok. 0 rows in set. Elapsed: 0.007 sec. :) INSERT INTO test.enum VALUES ('REFUND'), ('SUCCESS') INSERT INTO test.enum VALUES Ok. 2 rows in set. Elapsed: 0.012 sec. :) SELECT * FROM test.enum WHERE x = 'REFUND' SELECT * FROM test.enum WHERE x = 'REFUND' ┌──────x─┐ │ REFUND │ └────────┘ 1 rows in set. Elapsed: 0.009 sec.

у меня вот тоже на новой таблице не вышло. пока мучаю.

А подскажите, что хотелось бы в tabix, и чего не хватает? Интересно, т.к рисую роадмап себе на будущее

Я только пока название знаю. Но многие аналитики любят до сих пор Эксель.

Ещё надо включить в запросах: use_uncompressed_cache = 1 (настрока запроса или профиля пользователя).

Я этого слона пропустил. Думал размера Кеша достаточно. Пошел переделывать бенчмарки.

Значение поставил, в .settings почему-то changed. Но памяти по-прежнему ест только 400мб

Значение поставил, в .settings почему-то changed. Но памяти по-прежнему ест только 400мб

Память на кэш выделяется по мере его заполнения.

changed - значит было указано явно в конфиге или изменено. То есть, не умолчание.

И ещё есть настройка merge_tree_max_rows_to_use_cache, которая отключает кэш для не слишком мелких запросов (защищает от вымывания кэша)

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

Миллион - из таблицы или пользователю?

Таблица 500млн

Получается надо туда хотя бы 150млн поставить. Ок

Миллион - из таблицы или пользователю?

Строк для чтения на один запрос, при превышении которого кэш перестаёт использоваться.

Извиняюсь - это для config или для юзера настройка?

Для юзера.

Спасибо, заработало. Прибавка не в разы конечно, но на некоторых запросах до 1.5 раз

Но опять же maxArg выжирает много.

Про проблемы с негативными енумами - пардон, ложная тревога, ошибка в коде создания таблицы (в значения енума при сериализации попадал какой-то непечатный символ, который не было видно describe/show create).

получается это 1/2 шага к закреплению самых актуальных данных в памяти. наверное 1) закрепить теоретически легко, но 2) тут замедляет копирование в user-space (судя по google-groups) 3) чтоб получить эти данные в памяти надо проходить полный цикл: запись/чтение/декомпрессия.

А подскажите, что хотелось бы в tabix, и чего не хватает? Интересно, т.к рисую роадмап себе на будущее

Привет. Отличный вроде UI и время от времени использую но постоянно замечаю что скатываюсь в CLI. Даже когда запросы большие, все равно пишу их в какой нибудь десктопной IDE (idea, sublime) и потом вставляю в CLI. 0. Сделать персистентные проекты не в JS сессии, а в самом кликхаусе. Есть же отличное место для хранения, чего бы не использовать :) При сохранении проекта указывать базу и префикс таблиц. Там хранить все настройки, табы, логи, сохраненные запросы и графики. Что бы из любого места можно было получить тот же проект в том же самом месте где его оставил на другом браузере. 1. Задержка которая там после того как уже кликнул мышкой на место в запросе и до того как уже можно начинать писать текст - очень некомфортная. Даже после отключения автокомплита. Если можно сделать быструю смену между простым режимом, без задержки, и красивым режимом с тормозами, но автокомплитом, подсветкой, строками и форматированием - было бы круто. После 500го запроса автокомплит уже не нужен, а задержка все еще мешает :) Задержка, мигание экрана и анимация между переходами по табам тоже раздражает, но я не знаю если это лечится. 2. В CLI можно несколько раз кликнуть вверх и получить запрос который был 3 запуска назад - используется постоянно. В табикс есть "query log", и есть request's log - но они оба странные и не решают задачу полностью. request log не по табу, а вообще по всей системе, а "query log" - я так и не понял как пользоваться. Ну и конечно доступ в 2 и более кликов мышкой - это совсем не так эффективно как из CLI 3. Логичное продолжение аналитической части - сохранять запросы с их выбранной визуализацией (таблица, график) отдельно с возможностью расшарить. 3.0 Добавить возможность обьединять их в дашбоарды. Query -> SavedSlice, Slices -> Dashboard 3.1. Сохранять последний набор данных для Slice, так что бы при открытии график сразу показывался. Таким образом ссылка на дашбоард будет открываться всегда с красивыми графиками. Перезапуск требуется далеко не во всех случаях и может быть совсем не часто. 3.2 Для запросов ввести параметризацию с дефолтами. Так что бы из редактора выполнянлись дефолтные значения, а из slice или dashboard эти значения переписывались текущими для дашбоарда. В итоге получатся интерактивные дашбоарды когда меняя параметр можно будет обновить сразу весь дашбоард. И для расшаренных slice пользователь без возможности (или способности) редактировать код сможет поиграть с параметрами. Независимо от того будут эти хотелки реализованы или нет, спасибо за работу! По ощущениям - получается отличный продукт.

Привет. Отличный вроде UI и время от времени использую но постоянно замечаю что скатываюсь в CLI. Даже когда запросы большие, все равно пишу их в какой нибудь десктопной IDE (idea, sublime) и потом вставляю в CLI. 0. Сделать персистентные проекты не в JS сессии, а в самом кликхаусе. Есть же отличное место для хранения, чего бы не использовать :) При сохранении проекта указывать базу и префикс таблиц. Там хранить все настройки, табы, логи, сохраненные запросы и графики. Что бы из любого места можно было получить тот же проект в том же самом месте где его оставил на другом браузере. 1. Задержка которая там после того как уже кликнул мышкой на место в запросе и до того как уже можно начинать писать текст - очень некомфортная. Даже после отключения автокомплита. Если можно сделать быструю смену между простым режимом, без задержки, и красивым режимом с тормозами, но автокомплитом, подсветкой, строками и форматированием - было бы круто. После 500го запроса автокомплит уже не нужен, а задержка все еще мешает :) Задержка, мигание экрана и анимация между переходами по табам тоже раздражает, но я не знаю если это лечится. 2. В CLI можно несколько раз кликнуть вверх и получить запрос который был 3 запуска назад - используется постоянно. В табикс есть "query log", и есть request's log - но они оба странные и не решают задачу полностью. request log не по табу, а вообще по всей системе, а "query log" - я так и не понял как пользоваться. Ну и конечно доступ в 2 и более кликов мышкой - это совсем не так эффективно как из CLI 3. Логичное продолжение аналитической части - сохранять запросы с их выбранной визуализацией (таблица, график) отдельно с возможностью расшарить. 3.0 Добавить возможность обьединять их в дашбоарды. Query -> SavedSlice, Slices -> Dashboard 3.1. Сохранять последний набор данных для Slice, так что бы при открытии график сразу показывался. Таким образом ссылка на дашбоард будет открываться всегда с красивыми графиками. Перезапуск требуется далеко не во всех случаях и может быть совсем не часто. 3.2 Для запросов ввести параметризацию с дефолтами. Так что бы из редактора выполнянлись дефолтные значения, а из slice или dashboard эти значения переписывались текущими для дашбоарда. В итоге получатся интерактивные дашбоарды когда меняя параметр можно будет обновить сразу весь дашбоард. И для расшаренных slice пользователь без возможности (или способности) редактировать код сможет поиграть с параметрами. Независимо от того будут эти хотелки реализованы или нет, спасибо за работу! По ощущениям - получается отличный продукт.

Спасибо за фидбек ! Ценные идеи !

Чем то на metabase похоже становится, по хотелкам... Довольно не плохо, да ??

Привет. Начну с простых вопросов, ответы на которые плохо гуглятся в документации. Есть легальный способ посмотреть детальный план выполнения запроса в ClickHouse?

Привет. Начну с простых вопросов, ответы на которые плохо гуглятся в документации. Есть легальный способ посмотреть детальный план выполнения запроса в ClickHouse?

Плюсану. Ну, чо, пацаны? Есть?

Привет, а нет ни у кого проблемы после обновления докера, при раскатке стандартное имейджа CH он падает, с ошибкой (2017.07.03 18:30:26.705489 [ 1 ] <Error> Application: Net Exception: Cannot assign requested address: [::1]:8123)? Интересно, почему вайлдкард для ipv6

есть

Что нужно сделать, чтобы стартануть? Переписать имейдж под себя?

откатить докер до 17.04, в 17.06 явно какие-то проблемы с ipv6

Ну елы палы =)

Ладно - попробуем

Это не всё. Откат в лоб не помогает, ещё пришлось дописать вот такие строки в конфиги докер демона: "fixed-cidr-v6" : "2001:3984:3989::/64", "ipv6" : true

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

Привет. Начну с простых вопросов, ответы на которые плохо гуглятся в документации. Есть легальный способ посмотреть детальный план выполнения запроса в ClickHouse?

так вот, про план. Его от хорошей жизни не начинают искать. есть два простых запроса, которые процессят разное кол-во строк: select * from table where timestamp >= toDateTime('2017-07-03 18:21:55') -- Processed 2.49 million rows select * from (select * from table) where timestamp >= toDateTime('2017-07-03 18:21:55') -- Processed 4.97 million rows фильтр времени для экспериментов выбран примерно на avg(timestamp) если не срезать вложенные запросы каким-нибудь фильтром заранее, начинает процесситься вся таблица, и от этого становится больно использовать огромные сложные вьюхи, т.к. окончательные фильтры обычно попадают в конец запроса. Есть Issue на эту тему, или какой-нибудь способ сделать кликхаус быстрым снова?

Привет. Начну с простых вопросов, ответы на которые плохо гуглятся в документации. Есть легальный способ посмотреть детальный план выполнения запроса в ClickHouse?

легального нет, но если уровень для логов поставить в debug/trace то в нем можно будет увидеть план

штука с логами меня устроит, спасибо!

просто на уровне debug/trace логов будет очень много

пока нет Explain - это всё что есть )

Ни у кого никаких идей относительно https://groups.google.com/forum/#!topic/clickhouse/xzlFiMBIhi4 ? Хоть в правильную сторону думаю делать?