Я не могу написать where path like '%stage%' ?

Я не могу написать where path like '%stage%' ?

Нет, так как для выполнения такого запроса в общем случае потребуется обойти всё дерево нод зукипера. Если у вас нужные ноды в одной директории находятся, то можно написать WHERE path = '<dirname>' AND name LIKE '%stage%'

thx

https://pastebin.com/9iaG79Ac все 9.6. isql с этим dsn работает

Починилось путем переименования DSN (с символами "-" - игнорирует вообще DSN)

Доброго дня коллеги, прошу помочь разобраться в warning. <Warning> *** (Merger): Unexpected number of parts removed when adding *: 2 instead of 6 в чем может быть причина подобных ошибок?

Подскажите, как select email from ... вывести со сворим форматированием, т.е. результат выборки должно быть не какой-то емейл, а например some_test + email

ну и всё это мне нужно для подготвки csv дампа в PG и некий email надо к jsonb формату для встаки подготовить

Подскажите, как select email from ... вывести со сворим форматированием, т.е. результат выборки должно быть не какой-то емейл, а например some_test + email

concat(toString('some_test'), email) as email_formatted,

спаисбо

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

разместите, будет интересно, что просят нынче

верно

Я ищу (senior) аналитика на интереснейший проект - компания пилит платформу цифровой дистрибуции видеоигр с экономикой, построенной на использовании криптовалют и технологии блокчейн. Находимся на м.Дмитровкая, вопросы можно писать мне. Чем предстоит заниматься: * Построение системы аналитики в компании: * Разработка регулярных отчетов и их автоматизация; * Создание dashboard с ключевыми метриками; * Автоматизация сбора данных из различных источников (внутренние базы компании, системы веб аналитики; * Решение задач бизнеса в части клиентской, маркетинговой, товарной аналитики; * Написание требований к аналитике для реализуемого нового функционала. Полное описание вакансии https://hh.ru/vacancy/27361356

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

Вот пример обычной (по месяцам партиции) и посуточной. В дневных хранится последние дней 10, в обычной примерно 2 месяца, по структуре они один в один, только партиционирование разное SELECT * FROM cas.table_size WHERE (table LIKE '%v2%') AND (table LIKE 'publishers_subid%') ┌─database─┬─table──────────────────────────┬─parts─┬─size──────┬─marks_size─┬─pk_memory──┬─pk_memory_allocated─┬───────rows─┐ │ reports │ publishers_subid_live_v2_local │ 88 │ 23.34 GiB │ 564.74 MiB │ 87.63 MiB │ 129.17 MiB │ 378963071 │ │ reports │ publishers_subid_v2_local │ 17 │ 50.51 GiB │ 3.46 GiB │ 577.79 MiB │ 787.72 MiB │ 2376137870 │ └──────────┴────────────────────────────────┴───────┴───────────┴────────────┴────────────┴─────────────────────┴────────────┘

А как это связано с моим вопросом?

всем привет обновил кх до 18.10.3 и теперь получаю в лог <Error> BaseDaemon: (from thread 37) Received signal Segmentation fault (11). при выполнении запроса над таблицей Engine = Dictionary()

А как это связано с моим вопросом?

Тем, что в партиции за месяц могут достаточно сильно сжиматься и не всегда нужно придумывать схему с мелкими партициями.

Можно ли указывать несколько партиций в OPTIMIZE, и если да, то как?

Тем, что в партиции за месяц могут достаточно сильно сжиматься и не всегда нужно придумывать схему с мелкими партициями.

Понял, к сожалению, у меня не так - если что-то крупное, то оно и жмётся плохо, маленькие зато хорошо жмутся.

Привет! Нужна помощь, так как я затупил ( не как кликхаус ). Нужно написать cumSumArray который аккумулирует 0 вместо ухода в минус. Сломал голову как это сделать? Обычный аккумулятор работает так: SELECT arrayCumSum(values) FROM ( SELECT [3, -1, -1, -1, -1, -1, 3, -10, 1] AS values ) ┌─arrayCumSum(values)─────┐ │ [3,2,1,0,-1,-2,1,-9,-8] │ └─────────────────────────┘ А нужно так: ┌─arrayCumSum(values)─────┐ │ [3,2,1,0,0,0,3,0,1] │ └─────────────────────────┘

столькнулся со странностью

переливал данные из одно стаблицы в другую и данным запросом сверял

в результате получил в июле расхождение на 4 записи

SELECT id FROM stat WHERE (toYear(date) = 2018) AND (toMonth(date) = 7) AND (id NOT IN ( SELECT id FROM stat_v2 WHERE (toYear(date) = 2018) AND (toMonth(date) = 7) ))

а такой запрос выдал пустой результат: 0 rows in set. Elapsed: 145.999 sec. Processed 66.44 million rows, 3.99 GB (455.05 thousand rows/s., 27.30 MB/s.)

где в запросах я мог ошибиться?

в том запросе, где сверка, сделайте countUniqExact везде

или как-то так функция называется

мб просто дубли

привет, Саш :)

привет

ты имеешь ввиду uniqExact?

ага

Добрый день! Скажите, как посмотреть запрос, и есть ли такая возможность, который был при выполнении CREATE VIEW ... AS (-запрос-)?

мб просто дубли

действительно, спасибо

Добрый день! Скажите, как посмотреть запрос, и есть ли такая возможность, который был при выполнении CREATE VIEW ... AS (-запрос-)?

SHOW CREATE TABLE

SHOW CREATE TABLE

Спасибо!

SHOW CREATE TABLE

иногда показывает фигню кстати, у меня так однажды пара стринговых полей почему-то дополнились DEFAULT \'\'

иногда показывает фигню кстати, у меня так однажды пара стринговых полей почему-то дополнились DEFAULT \'\'

Это ескейпинг, в ноых версиях правили

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

table="distributed.tbl"; create=clickhouse-client --query="SHOW CREATE TABLE $table" | tr -d '\\'; clickhouse-client --query="DROP TABLE $table"; clickhouse-client --query="$create" Я такой скрипт использую для пересоздания таблицы из консоли линукса

иногда показывает фигню кстати, у меня так однажды пара стринговых полей почему-то дополнились DEFAULT \'\'

В нём эта хрень удаляется

В нём эта хрень удаляется

???️

иногда показывает фигню кстати, у меня так однажды пара стринговых полей почему-то дополнились DEFAULT \'\'

Попробуйте SHOW CREATE TABLE name FORMAT TSVRaw

напомните плиз что нужно сделать, чтобы обратиться к словарю как к таблице? select * from dict.name

SELECT * FROM dictionaries.name

SELECT * FROM dictionaries.name

DB::Exception: Database dictionaries doesn't exist. =(

напомните плиз что нужно сделать, чтобы обратиться к словарю как к таблице? select * from dict.name

CREATE DATABASE dict Engine=Dictionary

CREATE DATABASE dict Engine=Dictionary

во, точно! спасибо)

а можно ли обратиться к словарю по pointInPolygon?

почему INTO OUTFILE может не писать? файл создается, а не пишет

подскажите, пожалуйста, статью или видео о том, как правильно выбирать и как работает индекс в КХ

подскажите, пожалуйста, статью или видео о том, как правильно выбирать и как работает индекс в КХ

https://medium.com/@f1yegor/clickhouse-primary-keys-2cf2a45d7324 ?

спасибо

пара экспериментов про индексы (смотрите на Processed .... rows) https://gist.github.com/den-crane/cbc6f0777d03a00417d70018378d360d

ага, интересно

Я ищу (senior) аналитика на интереснейший проект - компания пилит платформу цифровой дистрибуции видеоигр с экономикой, построенной на использовании криптовалют и технологии блокчейн. Находимся на м.Дмитровкая, вопросы можно писать мне. Чем предстоит заниматься: * Построение системы аналитики в компании: * Разработка регулярных отчетов и их автоматизация; * Создание dashboard с ключевыми метриками; * Автоматизация сбора данных из различных источников (внутренние базы компании, системы веб аналитики; * Решение задач бизнеса в части клиентской, маркетинговой, товарной аналитики; * Написание требований к аналитике для реализуемого нового функционала. Полное описание вакансии https://hh.ru/vacancy/27361356

Только мск?

Добрый вечер, пара вопросов по шардированию: 1. Можно ли начать с одной обычной таблицы и потом как-то без даунтайма ее конвертунть из Replicated в DistributedReplicated? 2. Для DistributedAggregatingMT лучше выбирать ключ шардирования чтоб все запросы шли на одну шарду или в конце случится конечная аггрегация на оркестраторе?

Добрый вечер, пара вопросов по шардированию: 1. Можно ли начать с одной обычной таблицы и потом как-то без даунтайма ее конвертунть из Replicated в DistributedReplicated? 2. Для DistributedAggregatingMT лучше выбирать ключ шардирования чтоб все запросы шли на одну шарду или в конце случится конечная аггрегация на оркестраторе?

Она не конвертится, создается поверх replicated одна distributed таблица

Даунтайм ровно столько, сколько вам возможно потребуется переименовать таблицы

Но можно и без этого обойтись

Коллеги, подскажите есть ли рекомендации по максимальному размеру значения в колонке. Скажем строка в 512 символов это норм?

Добрый вечер, пара вопросов по шардированию: 1. Можно ли начать с одной обычной таблицы и потом как-то без даунтайма ее конвертунть из Replicated в DistributedReplicated? 2. Для DistributedAggregatingMT лучше выбирать ключ шардирования чтоб все запросы шли на одну шарду или в конце случится конечная аггрегация на оркестраторе?

по умолчанию оркестратор доагрегрегирует, но есть опция distributed_group_by_no_merge чтобы это отключить, если шардирование настроено так, что это не требуется

Коллеги, подскажите есть ли рекомендации по максимальному размеру значения в колонке. Скажем строка в 512 символов это норм?

более-менее норм, мегабайты уже скорее нет

Коллеги, подскажите есть ли рекомендации по максимальному размеру значения в колонке. Скажем строка в 512 символов это норм?

"Засуньте длинные строки куда-нибудь ещё" :))

Сы на самом деле тоже храним примерно такие

Все норм

"Засуньте длинные строки куда-нибудь ещё" :))

В том и вопрос стоит, начиная с какой длинны строки пихать куда то еще, а не в кх

В том и вопрос стоит, начиная с какой длинны строки пихать куда то еще, а не в кх

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

+ В кх набор ID хранят массивом, 1 слово = 1 элемент

ОК. Благодарю

https://habr.com/post/304602/ Вот тут обратный индекс, не знаю почему не словари

https://habr.com/post/304602/ Вот тут обратный индекс, не знаю почему не словари

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

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

да я просто вспомнил как один из "безсловарных" подходов к хранению строк. Других примеров чот не помню

Существует. Относительно свежий фичер, но вполне работоспособный.

Сейчас только ALTER DELETE. UPDATE в разработке, ещё не помержили.

А может ли ALTER UPDATE затрагивать колонку, по которой происходит партицирование? Что если я сделаю какую-то хитрую колонку в основной таблице (вместо DAYLY, WEEKLY и пр) и буду записывать в неё значение date (получая партицирование по дням), а потом - раз в сутки - делать ALTER UPDATE, вручую "по умному" раскидывая по партициям?

Нет, update столбцов, входящих в ключ (primary, partition), невозможен.

У кого какой опыт по размеру словарей? Порядка сотен миллионов k-v-пар строка-строка, одна запись <= 128 байт - это нормально?

У кого какой опыт по размеру словарей? Порядка сотен миллионов k-v-пар строка-строка, одна запись <= 128 байт - это нормально?

плохие, один словарь у меня 25ГБ рамы ест. https://github.com/yandex/ClickHouse/issues/2738

Ох, жаль

Есть стандартная функция обратная hex?

unhex

Спасибо

В том и вопрос стоит, начиная с какой длинны строки пихать куда то еще, а не в кх

Прямо сейчас имею дело с таблицой в которой есть строковая колонка более 1000 символов, никаких проблем не замечено. Конечно, элементы этой строки по которой будет фильтр лучше вынести в отдельные колонки. http://take.ms/HPuBx

Прямо сейчас имею дело с таблицой в которой есть строковая колонка более 1000 символов, никаких проблем не замечено. Конечно, элементы этой строки по которой будет фильтр лучше вынести в отдельные колонки. http://take.ms/HPuBx

Их в любом случае нужно вынести в отдельные колонки и не хранить в КХ только дату и "какую-то строку"

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