да, конечно

https://clickhouse.yandex/docs/ru/single/#table-engines-replication >Блоки данных дедуплицируются. При многократной записи ...

спасибо. помогло

TTL нет. Можно зайти в директорию Distributed таблицы и найти там ровно те (первые) файлы, которые с неправильной структурой, и удалить их. Посмотреть структуру можно по началу файла - там будет приведён INSERT запрос.

Прочекали все .bin файлики в директории distributed таблицы на всех нодах: на трёх нодах вообще папки пустые, но на одной скопилось достаточно много .bin файлов (за целую неделю). Я так понимаю, в идеале, они не должны копиться? Олсо, в наименовании вложенных директорий записан юзер и ip адрес, это адрес источника данных? Ну и самое главное — ни в одном из файлов не нашли "неподходящих" insert-ов, все указанные в запросе поля есть сейчас в текущих схемах (что в distributed, что в локальных).

И ещё: если делать SELECT на такой distributed таблице, туда попадают данные из этого буфера?

https://twitter.com/paaleksey/status/898205950271737856

Прочекали все .bin файлики в директории distributed таблицы на всех нодах: на трёх нодах вообще папки пустые, но на одной скопилось достаточно много .bin файлов (за целую неделю). Я так понимаю, в идеале, они не должны копиться? Олсо, в наименовании вложенных директорий записан юзер и ip адрес, это адрес источника данных? Ну и самое главное — ни в одном из файлов не нашли "неподходящих" insert-ов, все указанные в запросе поля есть сейчас в текущих схемах (что в distributed, что в локальных).

Да, не должны накапливаться. Данные остаются на файловой системе только если их не удалось отправить. Да, в имени директории записывается адрес, куда отправлять. Старые данные также могут остаться, если адрес перестал быть валидным. > Ну и самое главное — ни в одном из файлов не нашли "неподходящих" insert-ов, все указанные в запросе поля есть сейчас в текущих схемах (что в distributed, что в локальных). Возможно, что по логу сервера будет понятно, какой файл не удаётся отправить? Если нет, то попробуйте перенести в сторону некоторое количество файлов с начала по порядку их номеров. > И ещё: если делать SELECT на такой distributed таблице, туда попадают данные из этого буфера? Нет, не попадают.

Спасибо за ответы.

По этому поводу есть новость: в последней stable версии, которая вышла вчера, появилась опция insert_distributed_sync. Если её выставить в 1, то данные в Distributed таблицу будут вставляться синхронно. Возможно, даже лучше было бы сделать этот вариант по-умолчанию.

> Возможно, что по логу сервера будет понятно, какой файл не удаётся отправить? Вот в том то и дело, что в логах сам файл не указывается, указывается только query.

https://twitter.com/paaleksey/status/898205950271737856

Интересно! Давно просят такую штуку.

Так мы и были одни из тех, что просили ?

По этому поводу есть новость: в последней stable версии, которая вышла вчера, появилась опция insert_distributed_sync. Если её выставить в 1, то данные в Distributed таблицу будут вставляться синхронно. Возможно, даже лучше было бы сделать этот вариант по-умолчанию.

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

Теперь очень надеемся на английскую документацию на GraphiteMergeTree

По этому поводу есть новость: в последней stable версии, которая вышла вчера, появилась опция insert_distributed_sync. Если её выставить в 1, то данные в Distributed таблицу будут вставляться синхронно. Возможно, даже лучше было бы сделать этот вариант по-умолчанию.

Это коррелирует с настройкой internal_replication? Или имеется в виду, "синхронно дожидаться отправки на одну из реплик шарда, куда должна случиться запись" ?

Это коррелирует с настройкой internal_replication? Или имеется в виду, "синхронно дожидаться отправки на одну из реплик шарда, куда должна случиться запись" ?

В зависимости от internal_replication, вставляет либо на все реплики (если internal_replication = false), либо на любую (если internal_replication = true). Это работает так же, как и при асинхронной записи.

Теперь очень надеемся на английскую документацию на GraphiteMergeTree

У нас делается так: одни лиюди пишут документацию на русском, затем другие переводят. Правда процесс перевода пока ещё не налажен - как раз завтра буду разговаривать с теми, кто за это отвечает.

У нас делается так: одни лиюди пишут документацию на русском, затем другие переводят. Правда процесс перевода пока ещё не налажен - как раз завтра буду разговаривать с теми, кто за это отвечает.

Алексей, а есть changelog к версии вышедшей вчера?

@milovidov_an а насчёт ченджлога может быть тоже где то зафиксировать? Что бы не перечитывать всю документацию раз в месяц

Привет всем. Настолько оправдано использование toStartOf... функций для группировки при создании временных рядов? Является ли создание экстра колонок лучшей альтернативой?

Привет всем. Настолько оправдано использование toStartOf... функций для группировки при создании временных рядов? Является ли создание экстра колонок лучшей альтернативой?

мы постоянно юзаем, колонки две: дата и ДатаИВремя. Дата наверное нужна для партицирования. Очень удобно и быстро работает)

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

Ну так делаете одну колонку, не дублируя информации, и будет отлично работать toStart и другие функции с датой-временем

@milovidov_an а насчёт ченджлога может быть тоже где то зафиксировать? Что бы не перечитывать всю документацию раз в месяц

Ещё нет changelog. И документация тоже обновляется с задержкой.

Привет всем. Настолько оправдано использование toStartOf... функций для группировки при создании временных рядов? Является ли создание экстра колонок лучшей альтернативой?

Эти функции весьма дешёвые по вычислению. Отдельные столбцы оправданы только в случае, если они позволяют считывать существенно меньше данных с диска. Например, если есть столбец DateTime, то имеет смысл держать отдельный столбец Date - он намного легче. И в случае MergeTree это и так форсировано. В остальном отдельные столбцы с результатами этих функций держать неоправдано. (Единственное, когда может быть существенный выигрыш - если запрос очень лёгкий и почти ничего больше не делает.)

Спасибо, именно это и хотелось услышать.

Я тоже за changelog . Выходит много релизов , а что в них - одному Алексею Миловидову известно )) Да и судя по планам которые видел на семинарах по КликХаусу уже давно должен быть update и delete .

+1 к changelog

+1 к changelog

+1, было бы шикарно!

Help Code: 229, e.displayText() = DB::Exception: Query is too large (263512). max_query_size = 262144, e.what() =

Поменял в config.xml

не исправилось

сервер ребутил

Help Code: 229, e.displayText() = DB::Exception: Query is too large (263512). max_query_size = 262144, e.what() =

Это настройка уровня пользователя, настраивается в users.xml. Пропишите в profiles/default.

Changelog в пути :)

Ой! Приятно ) Просили передать от коллег большое спасибо ) пол года прода без единой проблемы))

Подскажите, произвольное партицирование в ближ время подоспеет ?:)

Подскажите, произвольное партицирование в ближ время подоспеет ?:)

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

Ой! Приятно ) Просили передать от коллег большое спасибо ) пол года прода без единой проблемы))

Передал всем, кто сидит рядом, спасибо!

Подскажите, произвольное партицирование в ближ время подоспеет ?:)

Не очень в ближайшее. Скорее в середине осени.

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

Партиции - отдельные части таблицы, которые можно удалять, перемещать вручную, и это сейчас только по месяцам.

Ну в середине осени уже неплохо!

Тут недолго осталось :)

Прямо сейчас активно занимаюсь этой задачей.

Скорейшего решения, для нас прям очень актуально

Скорейшего решения, для нас прям очень актуально

Кстати, какой у вас кейс - по какому выражению хотите партиционировать?

Кстати, какой у вас кейс - по какому выражению хотите партиционировать?

(сорри что врываюсь в вашу беседу) я помоему кстати про свой кейс рассказывал - хочу чистить данные меньше чем по месяцу - а конкретно у меня есть статистика из графита и стек трейсы, они где-то сжирают 20ГБ места в день на сервере после сжатия кликхаусом (при условии 4х серверов и distributed таблицы). Вот я хочу хранить 45 дней максимум, больше мне надо

потому что 2 месяца помещаются, но впритык

пока приходится дропать по партициям раз в два месяца )

Ага, про вас помню :) Как раз интересно услышать побольше кейсов.

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

еще была мысль под time-series данные тоже в общем по той же причине - чтобы удалять ненужные данные прям четко. Конкретно - сделать storage слой под посекундные данные, которые хранить например 2-4 дня

а потом грохать

ну нам бы не помешало партиционирование по типу события (тип UInt* или Enum*) и месяцу, чтобы у разных событий могло быть разное время жизни. Например, какие-нибудь хиты хранить не больше месяца, действия пользователей - два месяца, а клики - полгода

я создавал похожий фиче реквест для alter table * drop key range - https://github.com/yandex/ClickHouse/issues/654 . Партиционирование позволило бы решить эту задачу немного по-другому

удаление тоже нужно )

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

я создавал похожий фиче реквест для alter table * drop key range - https://github.com/yandex/ClickHouse/issues/654 . Партиционирование позволило бы решить эту задачу немного по-другому

Мы продумывали эту задачу в виде ALTER UPDATE/DELETE. Смысл в том, что соответствующий UPDATE/DELETE реализуется путём перезаписи part-ов, подходящих под условие. Проблема в реализации сейчас в том, что это плохо проходит через механизм репликации. В целом решаемо, но пока откладываем.

и это медленнее, чем просто удалить папку с партишном )

Ага, про вас помню :) Как раз интересно услышать побольше кейсов.

У нас данные растянуты по времени, но привязаны к пользователю. Очень часто получается так, что сотрудника увольняют и его данные не нужны больше в системе и их было бы не плохо удалять. Сейчас это планируем делать в лоб :) Хранить файл с идентификаторами удаленных/уволенных пользователей и отправлять на сервер с исключающим условием, либо подключать словарь и через dictionary движок исключать их из выборки. Конечно, можно удаленных и в сам КХ писать, но это не позволяет бизнес-логика ( Есть некоторые сложности (

Так же у нас есть некоторые типы эвентов, которые в дальнейшем не планируется хранить впринципе. Они нужны какой то определенный период времени. В качестве идентификатора типа эвента - строка.

У нас есть "странный" кейс с партишенами. У нас есть сырые данные и постпроцессинг который агрегирует данные в "отчеты" для пользователей, т.к. вливать данные напрямую долго и пользователи будут видеть разные данные, мы делаем create table tmp_*** as source_table заливаем в нее (или несколько таблиц) данные, делаем DETACH перемещаем файлы и делаем ATTACH в нужной таблице, это не очень удобно т.к. требует чтоб у воркера был доступ к файловой системе, да и вообще тот ещё костыль )

Костыль тот еще, но мы подобными костылями страдаем )я имею ввиду пока не удалось избавиться от аггрегации

Господа, а не планируется что то типа ораклового pivot?

Тк есть кейс когда нельзя использовать широкую таблицу - только узкую, а работать с широкой удобнее...

Доброе утро! Народ, вот хоть убейте! Мы не можим настроить реплицирование с шардированием 2х2. Схему реплик прописали, зукипер прописали, с макросами не понятно. На каждой ноде прописали в config.xml <macros><shard>01</shard><replica>01</replica></macros> с разными цифрами на каждой ноде. Пытаюсь создать таблицу .............. ) ENGINE = ReplicatedSummingMergeTree('/clickhouse/tables/{shard}/normal_summing_sharded', '{replica}', event_date, (event_date, event_time, body_id), 8192); Получаю Received exception from server: Code: 62. DB::Exception: Received from 10.254.122.232:9000. DB::Exception: No macro shard in config. Что не так-то???

1) значение в replica должно быть уникальным для каждой машины (это идентификатор по которому можно понять что и куда нужно засинкать) 2) скорее всего у вас в конфиге выше есть <macros incl="macros" optional="true" />

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

Мы батчуем поток эвентов в файлы, потом эти файлы гоним в таблицы. В одну таблицу может быть несколько вставок из одного файла. Чтобы сделать exact-once семантику, хотим делать delete по filename из таблиц при вставке

1) значение в replica должно быть уникальным для каждой машины (это идентификатор по которому можно понять что и куда нужно засинкать) 2) скорее всего у вас в конфиге выше есть <macros incl="macros" optional="true" />

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

Добрый день. А возможно как-нибудь попросить автора библиотеки https://bitbucket.com/ppodolsky/clickhouse-python при наличии желания и возможности, апнуть библиотеку добавлением узнавания всяких Nullable(*) полей или нижеперечисленную парочку ? На данный момент стали нужны два типа, указанные в соотв. ошибках: No field class for Nullable(UInt32) No field class for Nullable(String) Я конечно ща сам попробую, но там так всё красиво, боюсь испортить)

Добрый день. А возможно как-нибудь попросить автора библиотеки https://bitbucket.com/ppodolsky/clickhouse-python при наличии желания и возможности, апнуть библиотеку добавлением узнавания всяких Nullable(*) полей или нижеперечисленную парочку ? На данный момент стали нужны два типа, указанные в соотв. ошибках: No field class for Nullable(UInt32) No field class for Nullable(String) Я конечно ща сам попробую, но там так всё красиво, боюсь испортить)

можете наверное там тикет завести или какой то комментарий также рекоммендую посмотреть на проект https://github.com/Infinidat/infi.clickhouse_orm

можете наверное там тикет завести или какой то комментарий также рекоммендую посмотреть на проект https://github.com/Infinidat/infi.clickhouse_orm

Спасибо. Этот не смог запустить на python3

посмотрите вот этот pr https://github.com/Infinidat/infi.clickhouse_orm/pull/44

Спасибо, посмотрю!

видимо какая то версия сломалась в python3. так то он работал без проблем в 2.7 и 3

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

К слову о партиционировании. Сейчас приплыла задача для анализа видео-контента. Есть видео, есть зритель и нужно понимать какие участки видео самые неинтересные, самые просматриваемые и все такое. Какой процент видео просматривается в среднем и пр. И я так полагаю, что тут партиционирование хорошо сработало бы по идентификатору видео, а не по дате, т.к. по сути с такими эвентами дата и время роли не играет.

Привет! Загружаю TSV файл 4GB. max_memory_usage установлен 1GB. cat /data/transactions | clickhouse-client --query="INSERT INTO stat.xxx FORMAT TabSeparated" Получаю: Connection reset by peer while writing to socket В логе: Memory limit (for query) exceeded: would use 1.04 GiB Что нужно настроить, чтобы это работало? Clickhouse вообще позволяет загружать файлы большие чем оператива, или их обязательно нужно делить на мелкие?

К слову о партиционировании. Сейчас приплыла задача для анализа видео-контента. Есть видео, есть зритель и нужно понимать какие участки видео самые неинтересные, самые просматриваемые и все такое. Какой процент видео просматривается в среднем и пр. И я так полагаю, что тут партиционирование хорошо сработало бы по идентификатору видео, а не по дате, т.к. по сути с такими эвентами дата и время роли не играет.

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

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

Вообще время будет присутствовать отдельной колонкой, но это не приоритет. К тому же, что по одному видео может быть примерно такой объем данных. 1 видео, длительность в 3 минуты (180 строк на одного пользователя), с учетом сиков по видео может быть 200-250 на просмотор, в среднем 5-10 просмотров, есть кейсы когда видео смотрят в течение трех часов и делают конспекты, в таких кейсах может быть по 1000-3000 строк на один просмотр. Кол-во пользователей просматривающих видео от 100 до 40 000, кол-во видео в курсе в среднем 100 штук длительностью от 3 минут до 10 минут, в системе пока 10 курсов, но в ближайшем будущем курсов будет около 200 ) И да, видео контент будет обновляться и старые данные нужно будет выкидывать, т.к. их будет овер дохрена...у нас как бы есть 77 ТБ места, но...даже оно когда то кончится.

Поэтому держать данные по видео в одной партиции будет куда рациональней чем размазать данные по времени )

может на каждый видеофайл по таблице?

может на каждый видеофайл по таблице?

200 курсов по 100 видео? )))

Идея хорошая, но не знаю как это сработает по факту

а

длительность одного видео же час-два

Нет, длительность видео от трех минут до десяти минут

делайте для каждого видеофайла смещение временное

один день - один видеофайл

что-то в таком духе наверное можно

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

делайте для каждого видеофайла смещение временное

Ну я так делал в другом проекте, работает :) Только КХ партиционирует по месяцам

Не по дням