основной упор мы делаем на редактор) да eng нужно, вон и доку для dev и комменты в коде CH пишут на не понятном мне языке))) Да нужно перевести на Eng ради "развития/продвиженя" - CH

открыл issue https://github.com/smi2/clickhouse-frontend/issues/21

translate file?

типа json - "выполнить запрос"="execute query" но честно говоря нашим js dev виднее как это "true way" на angular делается

what about comments?

Недавно обновили до Версия 1.1

где бы посмотреть changelist с новыми фичами ?

https://github.com/facebook/zstd/releases

если кто то возьмется переводить, пока запросов не было и нужно ли ?) в роад мап я себе пометил мульти-язык - т.е вынести в отдельный js , все русские слова. но приоритетные для меня : - Ошибки редактора, не корректно отправляет запрсы "под курсором" - Подсветка полей , указанных таблиц в select - возможно Pivot перевод на 20ом месте)

можно поделиться примером pivot как оно сейчас работает. ооочень нужно для понимания как мигрировать отчеты

Задам вопрос еще и здесь, кажется что людей тут больше https://groups.google.com/forum/#!topic/clickhouse/nHwMoA5QOhI

можно поделиться примером pivot как оно сейчас работает. ооочень нужно для понимания как мигрировать отчеты

Как работает pivot в gui? в gui никак - мы не сделали. Если про запросы, под возможностью "pivot" я предполагал что используя конструкции sumIf , countIf - можно строки - "повернуть" в столбцы)

Задам вопрос еще и здесь, кажется что людей тут больше https://groups.google.com/forum/#!topic/clickhouse/nHwMoA5QOhI

Написал свои мысли в группу.

Там ситуация такая, что всё происходит в рамках одной страницы и переходы выполняются на внешние ссылки, т.е. мы не покидаем страницу.

Задам вопрос еще и здесь, кажется что людей тут больше https://groups.google.com/forum/#!topic/clickhouse/nHwMoA5QOhI

Состояние хранится снаружи ClickHouse

Ну, мы в Метрике так делаем

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

Тогда же

Чтобы было синхронно

супер. большое спасибо

да, для этого и хотелось писать их вместе

Виктор, а как вы гарантируете консистентность данных между этим "снаружи" и clickhouse? вот если это "снаружи" данные потеряет или они разойдутся (может быть ситуация что более старые данные запишутся в clickhouse позже) суммы то сойдутся, но из-за того что после схлопывания оставшаяся "последняя строка" может отличаться от сохраненного состояния они по идее могут разойтись

Мы пока научились только обновлять информацию о хитах: максимальная прокрутка, время на странице, наборы внешних кликов и другие меняющиеся параметры. До обновления визитов (в терминах https://yandex.ru/support/metrika/general/glossary.xml) мы пока сами не дошли.. Да, в хитах состояние хранит счетчик. Для хранения состояний визитов, наверно, можно хранить активные визиты в RAM приложения (рядом с CH) и сбрасывать информацию либо об изменениях визитов, либо по их завершении (после N минут idle-состояния, где N - настройка конкретного счетчика). Мысли? Витя, как в Яндекс.Метрике это внешнее состояние технически реализовано?!

Мы пока научились только обновлять информацию о хитах: максимальная прокрутка, время на странице, наборы внешних кликов и другие меняющиеся параметры. До обновления визитов (в терминах https://yandex.ru/support/metrika/general/glossary.xml) мы пока сами не дошли.. Да, в хитах состояние хранит счетчик. Для хранения состояний визитов, наверно, можно хранить активные визиты в RAM приложения (рядом с CH) и сбрасывать информацию либо об изменениях визитов, либо по их завершении (после N минут idle-состояния, где N - настройка конкретного счетчика). Мысли? Витя, как в Яндекс.Метрике это внешнее состояние технически реализовано?!

Вы свою собственную XYZ.Метрику изобретаете? :)

Вы свою собственную XYZ.Метрику изобретаете? :)

Это нам нужно для рекомендательной нашей системы

но по сути да своя Метрика

То что снаружи данные не теряет :)

Мы пока научились только обновлять информацию о хитах: максимальная прокрутка, время на странице, наборы внешних кликов и другие меняющиеся параметры. До обновления визитов (в терминах https://yandex.ru/support/metrika/general/glossary.xml) мы пока сами не дошли.. Да, в хитах состояние хранит счетчик. Для хранения состояний визитов, наверно, можно хранить активные визиты в RAM приложения (рядом с CH) и сбрасывать информацию либо об изменениях визитов, либо по их завершении (после N минут idle-состояния, где N - настройка конкретного счетчика). Мысли? Витя, как в Яндекс.Метрике это внешнее состояние технически реализовано?!

Мысли такие что между записью в RAM и записью в clickhouse может пройти время, которое при параллельном вызове может привести к расхождению данных до схлопывания это не страшно (суммы вроде будут сходиться). а вот после может быть такое что вы пишете отрицание на то чего уже нет в утверждении

То что снаружи данные не теряет :)

да, это меньшая вероятность чем расхождение )

Если внешняя система работает надёжно, расходиться ничего не будет

1) считываем состояние из внешней системы 2) обновляем данные во внешней системе 3) пишем изменения в ch вот если между 2 и 3 может влезть кто-то в параллельном вызове того-же визита (если нет лока), то данные разойдутся. смена 2 и 3 местами не решает эту проблему или я что-то не так понимаю :)

Как работает pivot в gui? в gui никак - мы не сделали. Если про запросы, под возможностью "pivot" я предполагал что используя конструкции sumIf , countIf - можно строки - "повернуть" в столбцы)

ах.. я нашел что искал ,)) вот это правильно ! ) https://clickhouse.yandex/reference_ru.html#Секция ARRAY JOIN

1) считываем состояние из внешней системы 2) обновляем данные во внешней системе 3) пишем изменения в ch вот если между 2 и 3 может влезть кто-то в параллельном вызове того-же визита (если нет лока), то данные разойдутся. смена 2 и 3 местами не решает эту проблему или я что-то не так понимаю :)

Состояния хитов пишем в очередь (они упорядочены по времени: старые будут обрабатываться первыми, порядок дальнейшей записи будет соблюдаться). Активные(!) состояния визитов в памяти внешнего приложения упрощённо могут выглядеть примерно так: hash_map< VISIT_ID, pair< OLD_STATE, NEW_STATE >. Если визита в памяти нет, значит создаётся новый визит. Если есть, за ~ константное время получаем последнее состояние для заданного идентификатора визита (при этом не выполняем никаких SELECT-ов в CH для поиска состояний). Изменения по хитам идут и в память по состояниям визитов, и в CH (хиты и визиты). При старте внешнего приложения сначала поднимаем в память все активные визиты из CH и только потом разбираем очередь состояний хитов. В любом случае, ни о какой транзакционности с CH мы не говорим. Как вариант для размышлений..

Состояния хитов пишем в очередь (они упорядочены по времени: старые будут обрабатываться первыми, порядок дальнейшей записи будет соблюдаться). Активные(!) состояния визитов в памяти внешнего приложения упрощённо могут выглядеть примерно так: hash_map< VISIT_ID, pair< OLD_STATE, NEW_STATE >. Если визита в памяти нет, значит создаётся новый визит. Если есть, за ~ константное время получаем последнее состояние для заданного идентификатора визита (при этом не выполняем никаких SELECT-ов в CH для поиска состояний). Изменения по хитам идут и в память по состояниям визитов, и в CH (хиты и визиты). При старте внешнего приложения сначала поднимаем в память все активные визиты из CH и только потом разбираем очередь состояний хитов. В любом случае, ни о какой транзакционности с CH мы не говорим. Как вариант для размышлений..

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

Добрый день. ODBC драйвер под Windows планируется?

2 и 3 у нас происходит атомарно

Точнее, разделено через отдельную очередь

а, понятно. спасибо

под винду по идее можно ODBC->JDBC бридж какой то сделать https://uda.openlinksw.com/odbc-jdbc-st/

А как в кликхауз на счет интерфейсов для простых смертных пользователей? Я имею ввиду odbc windows

В планах на ближайшее время есть?

odbc в планах есть

Под windows он тоже будет работать

Виетор я наверное не первый кто спрашивает) но спрошу : есть увас для нас какойнибудь роадмап или список приоритетов реализации функциональностей? Это нужно чтобы понимать чего ожидать или на что расчитывать.

Там выше фотография была с митапа

Пока что в таком виде

понял. Там нет оконных sql функций. Это означает что они в далекой перспективе?

Скорость порадовала. Теперь хотим комфорта;)

Да, это значит что они в далекой перспективе =)

Но всё зависит и от вас тоже, можете найти задачу на гитхабе и написать что вам тоже хочется

Добрый день. ODBC драйвер под Windows планируется?

он есть в репозитории в стадии "альфа". если у вас есть разработчики, то они могут начать пользоваться. И натыкаться на проблемы, как сообщал Алексей на встрече.

Я так понял, что допиливаться он будет, т.к. нужен в том числе и внутри Яндекса

Я честно признаюсь, что не до конца понял, о чем обсуждение чуть выше про хиты, но, судя по всему, вы пытаетесь найти CRDT, и, возможно, вам просто нужно взять один из готовых паттернов и реализовать вручную. Если речь идет о том, что в CH есть запись, которая может обновиться заблудившимися старыми данными, то тут никакого спасения быть не может, пока у CH нет транзакций или версионирования записей (i.e. оптимистичная блокировка, с чем, насколько понимаю, вообще будет сложно из-за column-oriented архитектуры), я бы на вашем месте просто делал повторы с предварительным чтением через условные пять минут после первой отправки.

Как указать case insensitive regexp в match для строки? match(value, '(?i)smthng') не срабатывает.

Я честно признаюсь, что не до конца понял, о чем обсуждение чуть выше про хиты, но, судя по всему, вы пытаетесь найти CRDT, и, возможно, вам просто нужно взять один из готовых паттернов и реализовать вручную. Если речь идет о том, что в CH есть запись, которая может обновиться заблудившимися старыми данными, то тут никакого спасения быть не может, пока у CH нет транзакций или версионирования записей (i.e. оптимистичная блокировка, с чем, насколько понимаю, вообще будет сложно из-за column-oriented архитектуры), я бы на вашем месте просто делал повторы с предварительным чтением через условные пять минут после первой отправки.

тут вопрос не про транзакционность, понятно что ее не может быть тут немного другое - в конкретном движке, CollapsingMergeTree, чтобы "изменить строчку" нужно знать "что там сейчас лежит" по идее - логичнее всего спросить об этом у самого Clickhouse. Но так делать не стоит. Поэтому - то что "лежит сейчас" стоит надо хранить отдельно (вне clickhouse), т.к. эта информация нужна очень ограниченное время (по сути до таймаута визита, потом она уже не важна, т.к. визит закрывается и не меняется) - ее можно хранить в каком-нибудь быстродоступном хранилище

Как указать case insensitive regexp в match для строки? match(value, '(?i)smthng') не срабатывает.

SELECT match('AbCd', '(?i)(abcd)') ┌─match(\'AbCd\', \'(?i)(abcd)\')─┐ │ 1 │ └─────────────────────────────────┘

SELECT match('AbCd', '(?i)(abcd)') ┌─match(\'AbCd\', \'(?i)(abcd)\')─┐ │ 1 │ └─────────────────────────────────┘

Nice! спасибо

тут вопрос не про транзакционность, понятно что ее не может быть тут немного другое - в конкретном движке, CollapsingMergeTree, чтобы "изменить строчку" нужно знать "что там сейчас лежит" по идее - логичнее всего спросить об этом у самого Clickhouse. Но так делать не стоит. Поэтому - то что "лежит сейчас" стоит надо хранить отдельно (вне clickhouse), т.к. эта информация нужна очень ограниченное время (по сути до таймаута визита, потом она уже не важна, т.к. визит закрывается и не меняется) - ее можно хранить в каком-нибудь быстродоступном хранилище

мм. может выстроить запись в очередь в собственном обработчике и в нем реализовать атомарность ? для точечных обновлений. для пакетных просто дропать протухшую партицию или таблицу

Там выше фотография была с митапа

Виктор, подскажи пожалуйста куда написать о проблеме в logsApi, есть фича когда дамп получается не валидным)

В саппорт очевидно :)

Там люди реагируют и до разработки это дойдёт если проблема действительно есть

Коллеги, добрый день! Подскажите, какие у кликхауса аппаратные требования? Планиуем на одной ноде использовать диски 1,5-2 ТБ, какой должен быть объем оперативной памяти?

чем больше тем лучше. агрегации в памяти идут

насколько я понял

чем больше, тем лучше - это понятно, но все-таки какой порядок величины? Есть ли best practice?

Все что есть про железо тут https://raw.githubusercontent.com/yandex/ClickHouse/master/doc/administration/tips.txt

да какая тут best practice. зависит от данных, которые хочется агрегировать. от их объема. типа.

да какая тут best practice. зависит от данных, которые хочется агрегировать. от их объема. типа.

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

если будете агрегировать по ним потом, то конечно

По опыту использование енумов (по сути те же числа) вместо строк дают значительный буст (вплоть до порядка). Но естественно их (как и внешние словари) надо поддерживать. Поэтому надо смотреть на задачу и решать, как лучше в корректной ситуации

туда же - хранение UUIDов в FixedString(16), ipv4 в UInt32, ipv6 в FixedString(16). будет жрать меньше оперативки (16 символов на один уид вместо 36, например), но если захочется читабельности, то, вероятно, начнет немного жрать процессор, чтобы сконвертировать на лету

Коллеги, всем привет. Мы с Романам Архаровым хотим использовать КХ на нашем проекте. У меня вопрос по внешним словарям. А могут ли быть ими таблицы с историчность. Поясню. Например у нас есть справочник вендоров-поставщиков, где по каждому id есть название, url и ссылка на картинку picture. В процессе жизни приложение, допустим, название или другие поля, например, могу меняться. Чтобы поддерживать историчность мы хотим сделать для каждого id пару столбцов actual_date_time и actual_end_date_time, определяющих, что такие-то поля были актуальны во временном промежутке от [actual_date_time, actual_end_date_time]. Понятно, если текущие поля актульны до сих пор, то можно поставить actual_end_date_time равным 2100 году, например. В КХ есть ли какая-то функция, которая возвращает поле не только по id, по и учитывая даты актульности, то есть date between actual_date_time and actual_end_date_time например

в доке видел только dictGetT('dict_name', 'attr_name', id) - получить из словаря dict_name значение атрибута attr_name по ключу id.

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

Леша, в этом чате можно говорить про range_hashed словари?

В-общем решение есть, называется range_hashed словарь

Но кажется документации пока что нет

Можно по коду посмотреть как пользоваться =)

да, в доке такого нет

ну если решение есть, то уже хорошо)

и можно пример кода, он нам понадобитсья?

пож-та)

В-общем ммм

вот код https://github.com/yandex/ClickHouse/blob/master/dbms/include/DB/Dictionaries/RangeHashedDictionary.h

только вместо 256 и 1024 черт знает, что правильно вводить)