Добрый день, Скажите как ClickHouse использует директорию /opt/cores. Хотим разместить данные ClickHouse в другой директории, не в /opt. Можно ли изменить расположение cores из конфига, или это лучше сделать ссылкой?

Добрый день, Скажите как ClickHouse использует директорию /opt/cores. Хотим разместить данные ClickHouse в другой директории, не в /opt. Можно ли изменить расположение cores из конфига, или это лучше сделать ссылкой?

в конфиге core_path

А используется когда clickhouse упал чтоб отложить core dump

Всем привет, а в КХ есть функция row_number()

?

ну или аналог какой-нибудь

Всем привет, а в КХ есть функция row_number()

А какую задачу хочется решить?

вообще есть таблица, у строках которой есть id и date_time (дата_добавления) ну и другие параметры для каждого ID надо вывести последнюю версию строки

argMax

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

воистину работает, спасибо

а, ок.

да я открыл Доку, посмотрел эту функцию и запилил запрос, все сошлось

спасибо большое)

классно на самом деле, а я сидел голову ломал

КликХаус - сила

есть rowNumberInAllBlocks

"Happy New Year" сказал clickhousr на проде

В корке?

в консоли

сегодня запросы на проде начали проседать по таймауту(60 сек). посмотрел query_log - все отрабатывает быстро, есть подозрение что клиент не успевает забирать результаты, надо бы действительно стримить их. насколько я понимаю Accept-Encoding: gzip же не будет работать?

будет, только там вроде надо передать флажок один

enable_http_compression=1

вот тест

https://github.com/yandex/ClickHouse/blob/1c849f14af0abeeb450115f800cc3c507ef73523/dbms/tests/queries/0_stateless/00302_http_compression.sh

с этим флажком отдастся какой-то кастомный lz, которые не прочитать, если я ничего не путаю

ненене, это компрессор метрики какой-то свой, наверное

если enable_http_compression, то там честный gzip или deflate (по умолчанию вроде deflate, не уверен, честно)

а кастомный lz это ты, наверное, про > вам придётся использовать для работы с ним специальную программу compressor (%%sudo apt-get install compressor-metrika-yandex%%). Если вы указали в URL compress=1, то сервер будет сжимать отправляемые вам данные.

просто enable_http_compression в документации никак не упоминается, только в тестах

поставлю галочку - добавлю в документацию)

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

да, я бы предполагал что должно без всяких флажков работать, просто через headers. странно сделали

но кстати, если данных мало, то запрос дольше выполняется, ЕМНИП

ну, т.е., SELECT count() делать с хттп-сжатием глупо, например %)

а вы, Игорь, не в яндексе же работаете?

я? неееет

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

gzip всё-таки медленно жмёт (~30 МБ/сек/ядро при уровне сжатия 3, для типичного Intel ~2 GHz, если я правильно помню). Когда добавляли его поддержку, то у нас было много программ, которые уже ходили на сервер с заголовком Accept-Encoding: gzip. И если бы сделали, чтобы он сжимал по-умолчанию, то это привело бы к увеличению потребления CPU при релизе. Поэтому сделали флаг, чтобы в момент релиза ничего резко не поменялось. На самом деле зависит от сети. Для 1 GBit как раз под вопросом, стоит ли использовать gzip или нет (зависит от коэффициента сжатия). На 10 GBit точно не gzip. Если Accept-Encoding: gzip, deflate, то сервер использует gzip. На будущее, можно добавить Accept-Encoding: br (для Brotli). Также коллега сейчас делает, чтобы использовалась библиотека zlib-ng вместо zlib - станет лучше, но только чуть-чуть.

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

Более-менее быстро. Почти как zstd. Для хороших уровней сжатия (как gzip 3..6) получается в районе 200..600 МБ/сек.

brotli жмет быстрее всего, что мы пробовали. Включая zstd

(впрочем, zstd мы пробовали год назад, а brotli -- совсем недавно)

а снаппи там всякие не?

которыми монги по дефолту жмутся

https://quixdb.github.io/squash-benchmark/ - только сразу при загрузке переключите на Xeon, а dataset на enwik8 или urls.10K.

снаппи жмет быстро, но плохо

Правда там страница наполовину устарела :( Нет уровней для zstd. Зато есть уровни для lz4, которые сбивают с толку. Значит лучше туда не смотреть.

По поводу видео митапа 14 декабря. Видео готово, я его посмотрел - там всё Ок. Но мне тут коллеги советуют, что исходя из формата этой встречи (встреча была ограниченной, не для всех желающих), видео выкладывать не нужно - чтобы сохранить смысл такого формата встреч. (При этом видео с первой встречи 21 ноября уже выложили.) Что думаете? Есть какие-нибудь аргументы по этому поводу?

Я его как раз начал смотреть вчера, поэтому думаю, что его стоит оставить )

А, сорри, это от 21-го ноября смотрю.

Его точно оставим :) Речь только про второй митап.

А что, если желающие посмотреть не из ДС? :)

В ДС2, надеюсь, приедем и ещё вживую что-нибудь интересное расскажем. И в ДС3 (правда не знаю, в какой).

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

Ну ДС3=Екат ящетаю, я б даже туда смотался по такому поводу.

> @milovidov_an видео выкладывать не нужно - чтобы сохранить смысл такого формата встреч. Есть смысл - не выкладывать чтобы простимулировать стать "избранным" ) С другой стороны там много "мебели" и "интеграторов" )))

В следующий раз мы надеемся сделать встречу более интересной и надеюсь участников (контрибьютеров) будет больше :)

Я за видео, т.к. нету возможности побывать вживую

Колеги, не все и всегда могут на митап явиться. Будет обидно пропускать обсуждаемую информацию. Может всё же будет общедоступным видео от таких встреч?

ага, показываешь паспорт, что не из ДС, и тебе дается уникальная секретная одноразовая ссылка на видео, которое уничтожается автоматом на твоем лептопе после первого просмотра... XD

ага, показываешь паспорт, что не из ДС, и тебе дается уникальная секретная одноразовая ссылка на видео, которое уничтожается автоматом на твоем лептопе после первого просмотра... XD

вот!

Что за дичь? Т.е. есть желание организации закрытого комьюнити по CH или всё же открытого? Для популиризации платформы наверное всё же чем больше публичной информации с рассказами, обсуждениями - тем лучше, ИМХО. Но это как уж авторы задумали. Или тут комьюнити только на Мск рассчитано, кто всегда сможет заглянуть на встречу? Тогда хоть вебинары организуйте

Да ладно вам. Все более менее крупные встречи будут с видео. Небольшие могут быть и без (это проще организовать). Видел с большого митапа тут было, с того что был в декабре - нет, мы как раз смотрим и думаем выкладывать ли.

Что за дичь? Т.е. есть желание организации закрытого комьюнити по CH или всё же открытого? Для популиризации платформы наверное всё же чем больше публичной информации с рассказами, обсуждениями - тем лучше, ИМХО. Но это как уж авторы задумали. Или тут комьюнити только на Мск рассчитано, кто всегда сможет заглянуть на встречу? Тогда хоть вебинары организуйте

Материалы митапов контрибьюторов имеет смысл закрывать от публичного доступа чтобы не вводить публику в заблуждение о фичах и роадмэпе продукта. На публичных митапах в презентациях и выступления стараются ничего лишнего не обещать и недостоверной информацией не делиться. А на встречах контрибьюторов "кишки" могут обсуждаться без купюр.

Ну то есть тут играют роль маркетинговые и PR сообраджения.

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

тогда надо действительно как-то делить встречи и доступ разделить. Через ту же Г+ группу для разработчиков иметь возможность видеть больше материалов с техническими обсуждениями, что будет недоступно просто в паблике. Это конечно решается в первую очередь через агенду при организации встреч - кто ЦА и кому будут доступны материялы. Для каких-то материялов строго "ватермарк", что это не публичная оферта, а лишь идеи внутри комьюнити разработки и деплоя

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

согласен

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

обычные правила - или "предупредить всех докладчиков, что запись будет публична", или "спросить каждого докладчика перед выкладыванием"

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

Как-то сразу захотелось посмотреть запись выступления товарища из Люксофта.... ?

Если серьезно, то как-то геморно всех опрашивать или отсматривать материал постфактум, что решить выкладывать или нет. Имхо.

там не для разглашения может быть только название клиента

Но мне кажется, что сам факт видео съемки подразумевает, что видео не для служебного пользования.

Но решать Яндексу

Подскажите а может существует другая документация по функциям в CH ? Не в таком формате ? Для чего: в gui хочу сделать подсказки по ф-циям пример https://monosnap.com/file/YCgjbBwBhxMBOhi3VbNbdSWUAdyRnR но в лоб регулярку не получилось написать чтобы распарсить текущую документацию. Идеал : "functionName"=>"desc" , но xml/yml/json тоже пойдет )

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

ну да, даже на том же примере с uniqHLL12 в исходниках документации вообще нету %)

на примере FunctionsArray.h есть /** Функции по работе с массивами: * * array(с1, с2, ...) - создать массив из констант. * arrayElement(arr, i) - получить элемент массива по индексу. * Индекс начинается с 1. Также индекс может быть отрицательным - тогда он считается с конца массива. * has(arr, x) - есть ли в массиве элемент x. * indexOf(arr, x) - возвращает индекс элемента x (начиная с 1), если он есть в массиве, или 0, если его нет. * arrayEnumerate(arr) - возаращает массив [1,2,3,..., length(arr)]

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

могу вам помочь с унификацией описаний функций и всего такого

угу, это я руками пример скопипастил из доки) остальные 1000 функции решил регуляркой ...

гг. а я некоторое время назад регуляркой проходился по всем исходникам, чтобы найти функции, которых нет в документации, и добавлял их туда %))

)))

регэкспы - это прекрасно!

select * from system.functions ?

я так подгружаю в gui список - чтобы всегда был актуальный список исходя из сборки

вот блин :(

чё-т я совсем невнимательно содержимое system изучал

а документация не доксигеном сгенерирована?

неа