Как сделать запрос с группировкой по blog_id. Получить сумму последних balance по created_at у всех user_id Желательно без подзапроса

С подзапросом сначала выбираются последние по createdAt (читайте про агрегатную функцию argMax), дальше суммируется

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

по-моему никак не выйдет но с подзапросом же быстро всё работает, если объемы не космические

Здраствуйте, как повторить AUTO INCREMENT из mysql в clickhouse? Можно ли сделать подобное? INSERT INTO users (id, nickname,) VALUES ({клво данных в таблеце},'aquaminer1')

@PolyakovAV просто уже есть orm но подзапрос не ложится на текущую реализацию. Из-за одного запроса придется все переделать

@PolyakovAV просто уже есть orm но подзапрос не ложится на текущую реализацию. Из-за одного запроса придется все переделать

есть вариант сделать materialized view типа AggregatingMergeTree и к этой вьюхе уже запросы будет без подзапроса

да, это вариант, думаю может так решим

Здраствуйте, как повторить AUTO INCREMENT из mysql в clickhouse? Можно ли сделать подобное? INSERT INTO users (id, nickname,) VALUES ({клво данных в таблеце},'aquaminer1')

как делают подобные таблицы для пользывателей?

Здраствуйте, как повторить AUTO INCREMENT из mysql в clickhouse? Можно ли сделать подобное? INSERT INTO users (id, nickname,) VALUES ({клво данных в таблеце},'aquaminer1')

Как вариант UID

Как вариант UID

можете немного по конкретней? не могу найти в доке

можете немного по конкретней? не могу найти в доке

Думаю что имелось в виду использование UUID для поля id.

как делают подобные таблицы для пользывателей?

Не надо хранить пользователей в КХ

а как получить номер недели для даты?

необходимо посчитать данные по неделям, обнаружил в документации toRelativeWeekNum которая выдает не понятное число

необходимо посчитать данные по неделям, обнаружил в документации toRelativeWeekNum которая выдает не понятное число

и как выгялдит эито число?

SELECT toRelativeWeekNum(toDate('2018-01-01')) ┌─toRelativeWeekNum(toDate(\'2018-01-01\'))─┐ │ 2505 │ └───────────────────────────────────────────┘

А ничего не менялось в механизме использования сессий в последних релизах? Что-то обновил все реплики, и указание session_id перестало работать...

и как выгялдит эито число?

toRelativeWeekNum Переводит дату-с-временем или дату в номер недели, начиная с некоторого фиксированного момента в прошлом. Это что-то типа как timestamp для секунд.

Для подсчёта данных по неделям можно дату привести к началу недели ( toMonday(date) ) и аггрегировать по получившейся дате

а как получить номер недели для даты?

toRelativeWeekNum(Date) - 2504 as isoweek

у меня так работает

оно конечно некошерно

но другого способа не нашлось

необходимо посчитать данные по неделям, обнаружил в документации toRelativeWeekNum которая выдает не понятное число

toMonday тут нагляднее чем номер будет SELECT toMonday(today()) ┌─toMonday(today())─┐ │ 2018-08-27 │ └───────────────────┘

парни, привет

поделитесь рецептами, как вы переобогащаетесь, если плохие данные прилетели

Сегодня на clickhouse-server-е (версия 18.10.3) обнаружилось странное разграничение доступов по ip адресам. Если для юзера в файле users.xml прописать: <networks incl="networks" replace="replace"> <ip>::1</ip> <ip>127.0.0.1</ip> <ip>10.4.4.10/32</ip> </networks> то clickhous-server почему то игнорирует маску /32 и доступ раздает подсети 0.0.0.0/0 (странное поведение). Если для юзера в файле users.xml прописать: <networks incl="networks" replace="replace"> <ip>::1</ip> <ip>127.0.0.1</ip> <ip>10.4.4.10</ip> </networks> то clickhous-server воспринмает адрес 10.4.4.10 как 10.4.4.10/32 (больше похоже на правду). Кто-нибудь с талкивался с таким поведением clickhouse-server-а (возможно что-то делаю не так)? Версия clickhous-server 18.10.3.

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

Сегодня на clickhouse-server-е (версия 18.10.3) обнаружилось странное разграничение доступов по ip адресам. Если для юзера в файле users.xml прописать: <networks incl="networks" replace="replace"> <ip>::1</ip> <ip>127.0.0.1</ip> <ip>10.4.4.10/32</ip> </networks> то clickhous-server почему то игнорирует маску /32 и доступ раздает подсети 0.0.0.0/0 (странное поведение). Если для юзера в файле users.xml прописать: <networks incl="networks" replace="replace"> <ip>::1</ip> <ip>127.0.0.1</ip> <ip>10.4.4.10</ip> </networks> то clickhous-server воспринмает адрес 10.4.4.10 как 10.4.4.10/32 (больше похоже на правду). Кто-нибудь с талкивался с таким поведением clickhouse-server-а (возможно что-то делаю не так)? Версия clickhous-server 18.10.3.

>то clickhous-server воспринмает адрес 10.4.4.10 как 10.4.4.10/32 (больше похоже на правду). Что значит "воспринимает"? Вы пробовали с разных ip из этой подсети к нему подключаться или что?

>то clickhous-server воспринмает адрес 10.4.4.10 как 10.4.4.10/32 (больше похоже на правду). Что значит "воспринимает"? Вы пробовали с разных ip из этой подсети к нему подключаться или что?

Пробовал с разных адресов подсети 10.4.4.0/24 и с других подсетей. Эффект одинаков сервер успешно авторизует. Поэтому и сделан вывод что открыт доступ для подсети 0.0.0.0/0

а если попробовать 1.1.1.1/32?

Проверьте логи сервера и файлы -processed. Возможно что-то прояснится.

подскажите, как правильно настроить окружение для сборки clickhouse? может у кого-то есть Dockerfile правильный? а то у меня ./release не работает, компиляция тоже валится на zconf.h

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

а в чем проблема? два параллельных insert в разные таблицы работают без проблем

не понимаю, в чем проблема. пишу в 5 таблиц пакетно раз в 5 секунд или по 65К записей, в двух из них время от времени растет количество кусков до >300 и появляется это “Merges are processing significantly slower than inserts”

пытаюсь понять, что не так

ну… попробуйте писать реже но больше ?

а чем такой совет обоснован? то есть какие метрики посмотреть, чтобы понять, что именно плохо?

по-моему, КХ и так говорит, в чем проблема - мержить не успевает

может эти таблицы очень тяжелые? что с CPU? диск?

la 0.3-0.5, iostat показывает что-то вроде Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util xvda 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 xvdh 0.00 1242.40 0.20 40.40 0.80 5139.20 253.20 0.17 4.30 0.00 4.32 0.22 0.88

подскажите, как правильно настроить окружение для сборки clickhouse? может у кого-то есть Dockerfile правильный? а то у меня ./release не работает, компиляция тоже валится на zconf.h

какая версия ch и какая ос?

stable/master, docker ubuntu:18.04

debian 8, 9 тоже пробовал

какая версия ch и какая ос?

код из бранча fix3 тоже не помог

Проверьте логи сервера и файлы -processed. Возможно что-то прояснится.

В логах clickhouse-server успешно регистрируется коннект (ошибки не регистрируются за период времени связанный с данными коннектами), при этом подсеть 10.5.4.0/24 (и тем более адрес 10.5.4.23) отсуствует в списках доступов users.xml 2018.08.28 19:45:46.886172 [ 21 ] <Trace> TCPSHandlerFactory: TCP Request. Address: 10.5.4.23:44124 2018.08.28 19:45:46.993980 [ 21 ] <Debug> TCPHandler: Connected ClickHouse client version 18.10.0, revision: 54405, user: writer. . В processed, информация таже что и в users.xml.

а если попробовать 1.1.1.1/32?

Попробую тестануть, чуть позже сообщу.

код из бранча fix3 тоже не помог

а лог полный можно? а то не воспроизводится

а лог полный можно? а то не воспроизводится

https://paste.ofcode.org/75WQ7ckuW69FV3aQ5f3VbT

кажется, что это может быть связано с -- The following features have been disabled: * ZLIB_COMPAT, Provide a zlib-compatible API

вообще, советую в докере попробовать собрать для чистоты окружения

ага, с чистотой проблемы, нужно просто склонировать вчистую или git clean -fdx ...

сейчас попробую. к текущему состоянию я пришел запуском ./release несколько раз, который тоже не работает, но валится на pbuilder

возможно в списке инклюд проблемы

неа, с fix3 после git clean -fdxX все равно валится на fatal error: zconf.h: No such file or directory

поймал

мешала системная zlib1g-dev

вы планируете все либы с собой носить?

Народ, подскажите: Нужно снимать бизнес-аналитику с сайта с небольшой нагрузкой (10-20 RPS) и далее смотреть ее в ClickHouse. Есть ли уже готовое решение для буферизации данных перед вставкой в ClickHouse. Или же может есть best Practices, как это лучше делать. Задача в принципе стандартная и яб ее решал просто через промежуточную таблицу в MySQL к примеру, но может быть есть что-то лучше.

уже все носим кроме icu но это отключаемо

gcc -nostdinc не поможет?

stdlib , sys/* и всякие icu все еще нужны

ну тогда в докере собирать

а сейчас ? https://github.com/yandex/ClickHouse/commit/c4f6bb1de07751d3254de3d0dda4d7de05a3ce1c

git clone + release (pbuilder) не хуже докера по чистоте

Народ, подскажите: Нужно снимать бизнес-аналитику с сайта с небольшой нагрузкой (10-20 RPS) и далее смотреть ее в ClickHouse. Есть ли уже готовое решение для буферизации данных перед вставкой в ClickHouse. Или же может есть best Practices, как это лучше делать. Задача в принципе стандартная и яб ее решал просто через промежуточную таблицу в MySQL к примеру, но может быть есть что-то лучше.

таблица типа Buffer ?

таблица типа Buffer ?

Да, как варинт. Минус: труднее готовить данные, Плюс: дальнейшее масштабирование

чем труднее?

чем труднее?

+1 интересно

а сейчас ? https://github.com/yandex/ClickHouse/commit/c4f6bb1de07751d3254de3d0dda4d7de05a3ce1c

спасибо, собирается

чем труднее?

Это не характеристика сложности работы с CH. Это особенности нашей реализации.

так буфер-таблица будет структурно идентична обычной. только имя другое

Вопрос про оптимизацию. Есть в таблице поле с миллисекундами msec. Подавляющее число запросов выполняет округление до секунд intDiv(msec, 1000) * 1000 (привет графане). Будет ли оптимальней сделать первичный ключ с приведением поля к секундам (date, sipHash64(host), …, intDiv(msec, 1000))? Или какие есть варианты?

Вопрос про оптимизацию. Есть в таблице поле с миллисекундами msec. Подавляющее число запросов выполняет округление до секунд intDiv(msec, 1000) * 1000 (привет графане). Будет ли оптимальней сделать первичный ключ с приведением поля к секундам (date, sipHash64(host), …, intDiv(msec, 1000))? Или какие есть варианты?

intDiv(msec, 1000) * 1000 в select или where? какого результата вы хотите добиться?

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

А как вы размер индекса определяете? И что даёт меньший размер?

Можно как-нибудь посмотреть, какая колонка больше всего занимает места?

По system.columns

Подскажите PARTITON BY по умолчанию бьет по дням? Если нет то как по дням?

Подскажите PARTITON BY по умолчанию бьет по дням? Если нет то как по дням?

по месяцам

Как - в доке подробно описано

Как - в доке подробно описано

Доку по месяцам видел. А по дням?

и в тесте в коде

сейчас посмотрю

и в тесте в коде

ок.

сейчас посмотрю

нашел. Спасибо! PARTITION BY FlightDate

без преобразований

Это только колонка