Подскажите, пожалуйста, это баг или фича? SELECT toUnixTimestamp(toDateTime(toDate('0000-00-00'))); Возвращает 4294956496 Интуитивно ожидается 0 в этом случае.

0 это 1970 год :)

Для сравнения select toUnixTimestamp(toDateTime('0000-00-00 00:00:00')); возвращает 0

таймстемп это коилчество секунд от 1970 года

@milovidov_an привет! Выше спам ^^

Сидел на нескольких больших каналах и такого не видел, а тут прям задалбливают...

Уже не первый раз именно этот спам вижу...

давайте только не будем Алексея на такие вещи отвлекать. тут другие админы есть

Зовите @Cyberdyne_Systems_bot в чат )

Точечные UPDATE/DELETE вряд ли будут скоро. Пока есть только batch DELETE и планируется batch UPDATE.

я так понимаю тут речь про alter table … drop partition … или про что то другое?

я так понимаю тут речь про alter table … drop partition … или про что то другое?

Речь про "мутации": https://clickhouse.yandex/docs/ru/query_language/alter/#_4

Переформулирую свой вопрос: Запрос: select toUnixTimestamp(toDateTime(toDate('1970-01-01'))); возвращает 4294956496 Запрос: select toUnixTimestamp(toDateTime(toDate('1970-01-02'))); возвращает: 75600 Запрос: select toUnixTimestamp(toDateTime(toDate('1970-01-03'))); возвращает значение: 162000 Как изменить запрос (я беру данные из поля типа Date) , чтобы запросы возвращали корректные значения?

Речь про "мутации": https://clickhouse.yandex/docs/ru/query_language/alter/#_4

thx

75600 - это правильное значение для Москвы.

Понял, UTC+3

4294956496 - видимо, потому что минус 3 часа никак не преобразовать в таймстемп.

Да, понял. Тогда вопрос такой: можно ли, чтобы toDateTime не учитывал смещение часового пояса?

All functions for working with the date and time for which this makes sense, can take a second, optional argument - the time zone name.

О! Спасибо большое!

Подскажите, а как из таблицы следующего вида: user_id (Int64) | vendors (Array(String)) 1 | [apple] 2 | [xiaomi] 3 | [samsung, apple] 4 | [lg, asus, xiaomi] ... получить частотные значения из vendors? Например: vendor (String) | freq (Int32) apple | 101 samsung | 62 xiaomi | 31 ... Есть функция topK(N)(column), но она не возвращает сами частоты, только сортирует значения по ним.

count(1) group by vendors?

Подскажите, а как из таблицы следующего вида: user_id (Int64) | vendors (Array(String)) 1 | [apple] 2 | [xiaomi] 3 | [samsung, apple] 4 | [lg, asus, xiaomi] ... получить частотные значения из vendors? Например: vendor (String) | freq (Int32) apple | 101 samsung | 62 xiaomi | 31 ... Есть функция topK(N)(column), но она не возвращает сами частоты, только сортирует значения по ним.

WITH arrayJoin([['a', 'b', 'c'], ['c', 'd']]) AS data, arrayJoin(data) AS result SELECT result, count() GROUP BY result ┌─result─┬─count()─┐ │ b │ 1 │ │ c │ 2 │ │ d │ 1 │ │ a │ 1 │ └────────┴─────────┘ 4 rows in set. Elapsed: 0.002 sec.

О, спасибо большое, про такую магию я и не знал)

А вот такой запрос у меня роняет КХ версии 1.1.54383: SELECT countArray(), arrayJoin([['a', 'b', 'c'], ['c', 'd']]) Кто-нибудь может проверить на последней версии?

а какой массив должна подсчитывать первая колонка?

может быть скобку в конец вынести?

Запрос синтаксически вроде правильный (у функции count() нет аргументов + модификатор Array). Не знаю, что он должен выдать, выполнил просто для теста.

1.1.54390 падает. Достаточно SELECT countArray();

потому что в конце смайлик грустный );

добрый день кто-нибудь сталкивался со следующей ошибкой при подключении через RClickhouse? `Error in connect(config[["host"]], strtoi(config[["port"]]), config[["db"]], : closed: No error` подключение с теми же параметрами (host, port, db, user, password) через tabix работает отлично

добрый день кто-нибудь сталкивался со следующей ошибкой при подключении через RClickhouse? `Error in connect(config[["host"]], strtoi(config[["port"]]), config[["db"]], : closed: No error` подключение с теми же параметрами (host, port, db, user, password) через tabix работает отлично

подключаетесь к порту 9000?

8123

8123

так надо к 9000 же

гм, а почему?

либа разве не через http интерфейс работает?

гм, а почему?

RClickhouse не использует HTTP-интерфейс кликхауса, подключается по нативному протоколу.

на 8123 http proxy висит, а 9000 для нативного

о как

спасибо!

:) select * from cluster_test1 SELECT * FROM cluster_test1 ┌─event─┬─exact_time─┐ │ e1 │ 1000 │ │ e2 │ 1001 │ │ e3 │ 1002 │ │ e4 │ 1004 │ │ e5 │ 1005 │ │ e6 │ 1006 │ └───────┴────────────┘ ┌─event─┬─exact_time─┐ │ e7 │ 1007 │ │ e8 │ 1008 │ │ e9 │ 1009 │ └───────┴────────────┘ 9 rows in set. Elapsed: 0.004 sec. почему две таблицы? это бага или фича? ?

от разных узлов прилетело асинхронно

фича, кмк :)

если будет order by, то будет одна "таблица"

запрос был не к Distributed-таблице же, а к Replicated

Значит не смерженое пришло

Смержится - будет один кусок

Это значит, что данные прилетели в нескольких "блоках". Блочная обработка - фича, да. Несколько блоков могут образовываться, если: данные прилетели с нескольких серверов; данные лежат на диске в нескольких кусках; данные обрабатываются в несколько потоков. Если не нравится - добавьте в конце запроса FORMAT PrettyCompactMonoBlock

спасибо

Господа, не подскажете, какие могут возникнуть проблемы, если увеличить дефолтный размер куска в одной партиции с 150 Гб до 2 Тб?

(считаем, что на диске >2 Тб свободно всегда)

Мержи мне кажется будут очень суровыми, а какой смысл увеличивать?

Партиции по 1,2 Тб за месяц разбиваются на ~20 файлов, а читать хочется за много месяцев, много маленьких метрик. За счет разбиения на много файлов сильно увеличивается количество дисковых обращений при чтении и все очень тормозит.

Кажется, что если сделать партиции по 1 файлу, то чтение будет лучше

Господа, не подскажете, какие могут возникнуть проблемы, если увеличить дефолтный размер куска в одной партиции с 150 Гб до 2 Тб?

Можно увеличить. Недостатки - изредка будут длинные мержи.

Можно увеличить. Недостатки - изредка будут длинные мержи.

Мы несколько суток мержили в фоне, вроде ничего страшного за это время не случалось :), поэтому это наверное норм

Спасибо за ответ, хотя бы попробуем :). А вы сами такое не используете?

Спасибо за ответ, хотя бы попробуем :). А вы сами такое не используете?

Нет, у нас размер по-умолчанию. Хотели постепенно его увеличивать, так как тоже есть серверы, где очень большой размер партиции. Пока увеличили всего лишь со 100 до 150 GB. У некоторых пользователей из-за этого возникли проблемы - началось много больших мержей. Но мы это исправили - сейчас много больших мержей сразу не инициируется.

Всем доброй ночи. Парни, есть кто может подсказать, у нас все работает, но часто идет следующая ошибка DB::Exception: Unknown packet 4 from server Уже не знаем куда толком копать. Может быть подпнете в правильном направлении?

Спасибо за ответ, хотя бы попробуем :). А вы сами такое не используете?

Отпишитесь потом что получилось, пожалуйста

Партиции по 1,2 Тб за месяц разбиваются на ~20 файлов, а читать хочется за много месяцев, много маленьких метрик. За счет разбиения на много файлов сильно увеличивается количество дисковых обращений при чтении и все очень тормозит.

Звучит как будто вам надо либо order by metric.... Либо уменьшать гранулярити, либо строить мат.вью которое станет как бы индексом метрика - таблица.

Звучит как будто вам надо либо order by metric.... Либо уменьшать гранулярити, либо строить мат.вью которое станет как бы индексом метрика - таблица.

order by metric уже есть. О мат вью думал, это будет следующий шаг, если не поможет :)

И сколько получается processed rows если выбирать метрику которая не существует? Чтобы 0 строк вернулось?

Чтобы 0 строк вернулось, особо ничего не процессится, засечки все в память влезают :). А вот если запрашивать метрику за пару месяцев, то там получается что-то около 300-500 тыс

Т.е метрик мало? Засечки вроде хранят диапазоны а не конкретные значения.

Метрик очень много :). Я могу завтра попробовать на каком-нибудь более-менее реалистичном ключе, но вроде несуществующие метрики довольно быстро искались

лол, кажется пора написать бота для бана этих мамкиных-сммщиков

Всем доброй ночи. Парни, есть кто может подсказать, у нас все работает, но часто идет следующая ошибка DB::Exception: Unknown packet 4 from server Уже не знаем куда толком копать. Может быть подпнете в правильном направлении?

Сеть (например нам нужно было вычитатть 16 байт, но вычиталось только 12, но на это забили и стали работать дальше и как итог все "поехало") или некоректно обрабатывается ошибка в этом соединении после чего снова пытаемся читать как ни в чем не бывало (это мало вероятно для конектора из коробки). Вообще стоит покопаться, такого быть не должно и это в любом случае баг.

Блин админы сделайте что то со спамом, только в этом чате спамит он

не только ))

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

/ban

Не тут)

Жаль...

Надо название вспомнить

5 как-то мало. можно мини-революцию устроить и испортить чат вообще

в принципе, бот банящий за больше 5 пробелов в имени имхо самое простое решение