а нельзя сделать что-то вроде постгресячего a in '{1,2,3}'::int[] ?

В документации ничего такого нет...

Скажите, поле типа MATERIALIZED - заполняется значением при вставке или расчитывается на лету при селекте?

Судя по названию - заполняется при вставке.

подскажите, в CollapsingMergeTree я пишу сначала первую запись с 1 знаком, при каждом апдейте я сначала пишу запись с -1 знаком, а потом обновленную версию?

Если я правильно пониманию, то если нужно оставить старую версию то да, нужно записать -1, потом 1, а если старая версия не нужна, то можно просто новую вставить с 1

подскажите, в CollapsingMergeTree я пишу сначала первую запись с 1 знаком, при каждом апдейте я сначала пишу запись с -1 знаком, а потом обновленную версию?

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

я пока использую обычный MergeTree и пишу по окончании сессии

Если я правильно пониманию, то если нужно оставить старую версию то да, нужно записать -1, потом 1, а если старая версия не нужна, то можно просто новую вставить с 1

т.е. я постоянно пишу новую версию с 1?

апдейты сессий можно писать в Collapsing, тогда старую версию при апдейте надо вычитать, и переписать все запросы, которые считают статистику, с учетом Sign.

ну вот и вопрос. в описании старая строка с -1, но как я ее получу, если всегда пишу с 1

Если я правильно пониманию, то если нужно оставить старую версию то да, нужно записать -1, потом 1, а если старая версия не нужна, то можно просто новую вставить с 1

если вы пишете только строки с sign=1, у вас при мерже для ключа остается одна строка, и если вы только пишете или только читаете, то это ок. но если вы и пишете и читаете, то вы читаете из не до конца померженной таблицы, и тогда надо либо делать final, что медленно, либо компенсировать в статистике старые версии объектов, т.е. записывать их с sign=-1.

А в чем тогда разница между CollapsingMergeTree и ReplacingMergeTree ? Что лучше использовать, для того чтобы изменять данные?

Кто такое ReplacingMergeTree? В документации нет такого вроде

Я вот тоже не понял еще как правильнее дополнять данные

Кто такое ReplacingMergeTree? В документации нет такого вроде

нету, да, ток в исходниках

Или изменять их

нету, да, ток в исходниках

я сегодня создал PR на эту тему)

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

Можно коротенечко, в чем суть этого движка или где можно прочитать? Замена по ключу? Просто update всей строки?

я про ReplacingMergeTree

можно тут почитать https://github.com/yandex/ClickHouse/blob/master/dbms/src/Storages/StorageFactory.cpp#L608

Спасибо

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

Спасибо

в этом месте тоже https://github.com/yandex/ClickHouse/blob/012c5f1079e7a2605e872eb223b9c5dcd065880e/dbms/tests/queries/0_stateless/00325_replacing_merge_tree.sql.disabled

Добрый день. В таблице MySQL храним координаты широту и долготу в Decimal, какой тип данных лучше использовать при подключении таблицы в качестве словаря в CH? Float32?

Decimal в MySql 4 байта значит float32 хватит

23 бита мантиссы дает точность в сантиметрах, должно быть достаточно.

Спасибо

ну, не в сантиметрах, а около 5 метров... :)

экватор (~40 000 км) / 2^23 ~= 4.8 метров

а знак

?

в каждую сторону 20k

imho там и int32 хватит

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

но знак тебе даст 2.4 метра, и не сантиметры

ну да

а кто-то собрался с точностью до сантиметра мерять? :)

в старых гарминах так экономили, родовая болячка у них была - раскуроченные домики

2.4 метра -- попадет в любое здание, и даже в ларек

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

а потом у тебя, например, восстановленная скорость в два раза пляшет :)

garmin etrex, который у меня был, вообще +- 10 метров за погрешность не считал

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

нужна скорость - пиши мгновенную скорость отдельно

как ведет себя первая производная кусочно-линейной функции? :)

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

а кликхаус сжимать то что хранит умеет же?

и float32 в лоб - не сантиметры :)

а кликхаус сжимать то что хранит умеет же?

да, он сжимает

Всем привет! Подскажите плз == Для одного счетчика Яндекс.Метрики суммарный размер данных, передаваемых в запросах (включая не удаленные из хранилища логи), составляет 10 ГБ == ограничение 1 день? спасибо!

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

обычно именно так и происходит в тех проектах, где округляют координаты до float. при этом скорость обычно режут до int ;)

экватор (~40 000 км) / 2^23 ~= 4.8 метров

и действительно, я один градус мерял вместо 360.

Всем привет! Подскажите плз == Для одного счетчика Яндекс.Метрики суммарный размер данных, передаваемых в запросах (включая не удаленные из хранилища логи), составляет 10 ГБ == ограничение 1 день? спасибо!

вы имеете в виду данные посещаемости?

вы имеете в виду данные посещаемости?

Да, это цитата отсюда https://tech.yandex.ru/metrika/doc/api2/logs/intro-docpage/.. Предполагаю, что день, но хотелось бы подтверждения от компетентных людей ) Только-только начинаем работать с ClickHouse.. Спасибо! )

Всем привет! Подскажите плз == Для одного счетчика Яндекс.Метрики суммарный размер данных, передаваемых в запросах (включая не удаленные из хранилища логи), составляет 10 ГБ == ограничение 1 день? спасибо!

Такого не помню (кстати, чат не про Метрику). Общего ограничения нет. Но есть ограничение на суммарный размер параметров визитов (это которые передаются произвольным JSON-ом).

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

С этим движком всё Ок. Тест убрали, так как сам тест немного некорректный. В нём вызовы OPTIMIZE не обязательно мержат всё до конца. Возникает race condition, если до этого уже запустилось другое слияние автоматически. Тогда OPTIMIZE не будет мержить те куски, которые уже мержатся. Этот race condition является нормальным и не означает некорректную работу.

я сегодня создал PR на эту тему)

Там чуть-чуть некорректно написано. Поправлю сам.

Такого не помню (кстати, чат не про Метрику). Общего ограничения нет. Но есть ограничение на суммарный размер параметров визитов (это которые передаются произвольным JSON-ом).

Алексей, спасибо!

Да, это цитата отсюда https://tech.yandex.ru/metrika/doc/api2/logs/intro-docpage/.. Предполагаю, что день, но хотелось бы подтверждения от компетентных людей ) Только-только начинаем работать с ClickHouse.. Спасибо! )

это ограничения на объемы выгрузки через logs api, сама метрика принимает данные в количествах ограниченных другими факторами.

это ограничения на объемы выгрузки через logs api, сама метрика принимает данные в количествах ограниченных другими факторами.

Да, я понимаю. Вот вопрос и состоит в том - это ограничение на обьем в день? Час? "Суммарный обьем данных передаваемый в запросах"

@milovidov_an https://twitter.com/marklit82/status/824892282910306304?cn=cmVwbHk%3D&refsrc=email

@milovidov_an https://twitter.com/marklit82/status/824892282910306304?cn=cmVwbHk%3D&refsrc=email

Отлично, спасибо!

Да, я понимаю. Вот вопрос и состоит в том - это ограничение на обьем в день? Час? "Суммарный обьем данных передаваемый в запросах"

вы делаете запрос в logs api, за день/час/месяц, для ответа во внутреннем облаке создается файл или файлы с данными. суммарный объем этих временных файлов на один счетчик ограничен 10Гб.

вы делаете запрос в logs api, за день/час/месяц, для ответа во внутреннем облаке создается файл или файлы с данными. суммарный объем этих временных файлов на один счетчик ограничен 10Гб.

Супер! Спасибо огромное! Всем отличных выходных!

поставил свежий кликхаус, заменил старый страшный регексп на UUIDtostring и запрос резко стал быстрее

видимо fixedstring16 сначала превращается в текстовый uuid, а потом идет группировка?

скорее сначала идет группировка, а потом превращается в текст.

видимо fixedstring16 сначала превращается в текстовый uuid, а потом идет группировка?

Вроде бы нет - этой функции нет в списке "инъективных". Это недоработка. Если бы была - было бы ещё быстрее. Запрос стал быстрее, потому что функция точно быстрее страшного выражения с регекспом :)

а что такое инъективная?

Значит можно GROUP BY f(x) исполнять так же как GROUP BY x. Это используется в оптимизаторе запросов.

x!=y=>f(x)!=f(y)

ух

соответственно простой регексп гарантированно не является гарантированно инъективным?

я может не очень внимательно прочитал документацию (вообще её почти не читал, если честно), но мне кажется, что недостаточно четко отражен тот факт, что надо достаточно агрессивно просовывать все обращения к CH через пулы и синглтоны

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

слишком много одновременных запросов

соответственно простой регексп гарантированно не является гарантированно инъективным?

Да, extract по регекспу - не инъективная функция.

слишком много одновременных запросов

Это настраивается в конфиге. Там есть ограничение на количество соединений (соединения расходуются если клиент просто ничего не делает), 1024 по-умолчанию, и на количество одновременных запросов, 100 по-умолчанию, если я правильно помню.

да, 100

ну у вас наверное какое-то современное умолчание, не под компьютеры с 256 мб памяти?

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

ну у вас наверное какое-то современное умолчание, не под компьютеры с 256 мб памяти?

Да, это не my_tiny.cnf.

ну я об этом и говорю: надо думать головой и агрегироваьт запросы на стороне софта

ладно хоть рельсы тут проблем не создадут =)

Да, если есть возможность на стороне софта это контролировать - это хорошо.

а куда деваться то =)

@milovidov_an а вы откуда качали nyc-taxi-data? как в статье написано несжатые csv? или где-то есть пожатая версия?

Как в Github, да - несжатые.

Приветствую. Есть ли готовые сборки ch под debian jessie? Или подскажите как правильнее собрать пакет под jessie?

подскажите, в clickhouse-cli же история не пишется ни в какой файлик?

пишется

~/.clickhouse-cli_history

а clickhouse-client'ом - в ~/.clickhouse-client-history

я просто в докерконтейнере не вижу таких файлов. проверю еще раз