Что делать?

Ребутнуть )

сервер?

как-то не хочется )) может удалить что-нибудь ))

?

сервер?

Зачем же сразу сервер, КХ ребутните.

я ж написал что не помогло

вижу дир с именем таблицы на диске

удалю ее сча и поглядим

Расскажите пожалуйста какие практики применяются для быстрого добавления столбцов в структуру таблицы? Изначально добавляется n столбцов прозапас или экспорт-импорт? Может быть что-то оригинальное?

Расскажите пожалуйста какие практики применяются для быстрого добавления столбцов в структуру таблицы? Изначально добавляется n столбцов прозапас или экспорт-импорт? Может быть что-то оригинальное?

ALTER TABLE ADD COLUMN, не надо прозапас их создавать.

удаление директории помогло

какой-то глюк был что КХ ее сам недоудалил

ALTER TABLE ADD COLUMN, не надо прозапас их создавать.

оу, это альтеры не так давно появились? Или они всегда были?

оу, это альтеры не так давно появились? Или они всегда были?

Сразу были.

Извиняюсь, видимо я перепутал с изменением primary key. Спасибо.

Добрый вечер, есть таблица CREATE TABLE Test ( appId UInt32, metricId UInt32, timestamp UInt32 ) Engine = MergeTree() PARTITION BY (floor(timestamp/604800), appId) ORDER BY (appId, metricId, timestamp); Есть запросы вида select * from Test where appId in (...) and metricId in (...) and timestamp>X and timestamp<Y Нужно ли добавлять условие and floor(timestamp/604800)>X' and timestamp<floor(timestamp/604800)>Y' Или это ничего не ускорит?

ничего не ускорит, нужно только так where .... timestamp>X and timestamp<Y ( t.me/clickhouse_ru/54651 ) но в текущей версии сканируются все партиции, исправлено в мастере https://github.com/yandex/ClickHouse/issues/2342

Ага, тоесть КХ умный и применит только по timestamp Но только начиная со сл версии Верно?

у вас appId , timestamp есть в PK (ORDER BY (appId, metricId, timestamp)) поэтому будет работать быстро и так, но со след. версии будет возможно еще быстрее

Круто На это и надеялся тк отсекаем партициями (но основная их цель конечно же удаление данных) Спсб Денис

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

Здравствуйте. Подскажите пожалуйста, это баг или фича: пробую работать с функцией: cutToFirstSignificantSubdomain и вижу такой результат: ghg.i.ua -> i.ua - тут правильно g.f.d.com -> d.com - тут правильно rrr.tp.ntu-kpi.com.ru - ntu-kpi.com.ru - тут то же правильно rrr.tp.ntu-kpi.kiev.ua - kiev.ua - а вот тут не правильно, так как kiev.ua это доменная зона , а функция думает что это домен

Clickhouse версия 1.1.54385

вчера с утра обновился только

Здравствуйте. Подскажите пожалуйста, это баг или фича: пробую работать с функцией: cutToFirstSignificantSubdomain и вижу такой результат: ghg.i.ua -> i.ua - тут правильно g.f.d.com -> d.com - тут правильно rrr.tp.ntu-kpi.com.ru - ntu-kpi.com.ru - тут то же правильно rrr.tp.ntu-kpi.kiev.ua - kiev.ua - а вот тут не правильно, так как kiev.ua это доменная зона , а функция думает что это домен

Это исключение и оно не обрабатывается.

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

таблицы реплицируются не друг с другом

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

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

ну из второй реплики данные удалятся , а в новой отреплицируются?

ну из второй реплики данные удалятся , а в новой отреплицируются?

Да. Новый кусок отреплицируется. В мастере есть вот такая штука https://github.com/yandex/ClickHouse/pull/2217

а он делает какой то реплейс или перемещает таблицу

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

а он делает какой то реплейс или перемещает таблицу

Там есть разные варианты использования https://github.com/yandex/ClickHouse/blob/5a78d1b0905513ad20eb74671275771dc804c29c/dbms/tests/queries/0_stateless/00626_replace_partition_from_table.sql.

а когда мастер этот зарелизится ?

а когда мастер этот зарелизится ?

Я не знаю, самому нужна эта фича, сейчас просто партиции отцепляем, переносим в соседнюю папку и атач делаем.

А нет проблемы из за совпадения имён партий?

А нет проблемы из за совпадения имён партий?

Нет.

хорошо протестирую на днях

Главное чтоб в detached не лежало куска с таким же именем

А еще такой вопрос по будущему удалению Если есть таблица с appId и timestamp в ключе и надо будет удалять данные то как лучше поступить 1. Партицирование по дням и удалять потом данные как delete from table where appId in () and timestamp < XXX 2. Или все таки партицировать по дням и по appId и удалять целыми партициями? Первый варинт дает меньшую общую нагрузку тк количество партиции сильно меньше а мы обнаружили что при относительно большом кол-ве партиции (20К) и больше процессора надо и на диск в разы интенсивнее запись идет (если кому надо могу подробности выложить). Но этот вариант приемлем если удаление будет относительно легковесное и не положит кластер. Второй вариант жрет больше ресурсов тк кол-во партиции вырастает с 100 до 20К, но удаление относительно бесплатное. Господа кто знаком с тем как будет реализрванно удаление подскажите какой путь выбрать?

А еще такой вопрос по будущему удалению Если есть таблица с appId и timestamp в ключе и надо будет удалять данные то как лучше поступить 1. Партицирование по дням и удалять потом данные как delete from table where appId in () and timestamp < XXX 2. Или все таки партицировать по дням и по appId и удалять целыми партициями? Первый варинт дает меньшую общую нагрузку тк количество партиции сильно меньше а мы обнаружили что при относительно большом кол-ве партиции (20К) и больше процессора надо и на диск в разы интенсивнее запись идет (если кому надо могу подробности выложить). Но этот вариант приемлем если удаление будет относительно легковесное и не положит кластер. Второй вариант жрет больше ресурсов тк кол-во партиции вырастает с 100 до 20К, но удаление относительно бесплатное. Господа кто знаком с тем как будет реализрванно удаление подскажите какой путь выбрать?

Если у вас так много партиций возможно вы выбрали неправильный ключ.

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

грубо appID добавили к ключу партицирования потому как надо часто удалить данные для конкретной системы или мириться с тем что на диске будет много того что уже не надо (террабайты данных что не дешево)

грубо appID добавили к ключу партицирования потому как надо часто удалить данные для конкретной системы или мириться с тем что на диске будет много того что уже не надо (террабайты данных что не дешево)

Если бы партиций было бы меньше, то и данные жались бы лучше.

Кирилл ДА, но выход какой?

Есть еще 3 способ которыя я не описал ?

Есть еще 3 способ которыя я не описал ?

Есть, например удалять данные старым добрым CollapsingMergeTree и сделать партиции просто по месяцам.

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

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

Оно полностью переписывает партиции которые попадают под условие.

Сразу или отложенно при мерже?

Сразу или отложенно при мерже?

Все сразу переписывать и будет.

Ага

Спсб

Значит можно ожидать сильньной загрузки при запросе на удаление 10% данных например

Спсб Ценная информация

Друзья, подскажите новичку. Кручу, верчу КХ, применить хочу. Есть таблица, пусть MergeTree, туда вставляются данные. Допустим таблица вида PK( EventDate, ObjectID ), value1, value3, ..., valueN Описывает состояние объектов в n-ное время. 99% времени - value1, value2, value3, ..., valueN не изменяются. Изменяется только EventDate, что в PK, это время "съёма" значений. В целом, при хранении мне всё равно, пусть даже дублируются. В результатах запросов - не нужны. т.е. по факту, я хочу иметь историю изменения состояний и возможность выбрать только те, у кого состояния менялись за некоторый интервал времени, это будет 2-3 изменившихся значения. GROUP BY по всем филдам мне не кажется хорошей идеей. Использовать DISTINCT по value1, value2, value3, ..., valueN? Завести филд для хеша всех value и делать по нему GROUP by hash? Адаптироваться к CollapsingMergeTree?

а если сделать детач с mergtree и потом attach в replicatedmergetree все будет ок ?

а если сделать детач с mergtree и потом attach в replicatedmergetree все будет ок ?

Да

Подскажите пожалуйста, как правильно сделать? Хочу сгружать в clickhouse ошибки и по ним строить отчеты есть таблица большая с колонками (useragent, error, stacktrace, url, date etc) сделал для каждого большого строкового поля хэш, например useragent Nullable(String), useragentId MATERIALIZED sipHash64(useragent) ... ENGINE = MergeTree группирую по этим колонкам с хэшами(useragentId) так норм? такой кейс это вообще правильное использование clickhouse?

Привет всем. Кто подскажет? Внезапно на всех(3) серверах с кликхаусом пошло в логах: <Error> HTTPHandler: Code: 252, e.displayText() = DB::Exception: Too many parts (307). Merges are processing significantly slower than inserts., e.what() = DB::Exception, Stack trace: и ничего не вставялется

с зукипером все ок, carbon-clickhouse копит файлы с записями в логах ERROR [uploader] handle failed {"filename": "/mnt/data/carbon-clickhouse/default.1528828510519183840", "error": "clickhouse response status 500: Code: 252, e.displayText() = DB::Exception: Too many parts (307). Merges are processing significantly slower than inserts., e.what() = DB::Exception\n", "time": 1.291027654}

там честно написали, что не успевают мержить инсерты

мелкими кусками по дофига раз в секунду, столь?

нет, carbon-clickhouse инзертит пачками

в файлах около 6330 строк

все работает как и раньше, но внезапно КХ перестал писать в БД

select * from system.merges; выдает 2 мерджа и они длятся часы

SELECT count(partition) FROM system.parts ┌─count(partition)─┐ │ 347 │ └──────────────────┘ 1 rows in set. Elapsed: 0.007 sec.

Background_pool_size(16) увеличил до 25, не помогает

Никто не сталкивался ?

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

Друзья, подскажите новичку. Кручу, верчу КХ, применить хочу. Есть таблица, пусть MergeTree, туда вставляются данные. Допустим таблица вида PK( EventDate, ObjectID ), value1, value3, ..., valueN Описывает состояние объектов в n-ное время. 99% времени - value1, value2, value3, ..., valueN не изменяются. Изменяется только EventDate, что в PK, это время "съёма" значений. В целом, при хранении мне всё равно, пусть даже дублируются. В результатах запросов - не нужны. т.е. по факту, я хочу иметь историю изменения состояний и возможность выбрать только те, у кого состояния менялись за некоторый интервал времени, это будет 2-3 изменившихся значения. GROUP BY по всем филдам мне не кажется хорошей идеей. Использовать DISTINCT по value1, value2, value3, ..., valueN? Завести филд для хеша всех value и делать по нему GROUP by hash? Адаптироваться к CollapsingMergeTree?

А если поменять структуру таблицы, сделать не value1, value2,... valueN, а name и value, в первую колонку пишем название показателя, во вторую - значение.

SELECT count(partition) FROM system.parts ┌─count(partition)─┐ │ 347 │ └──────────────────┘ 1 rows in set. Elapsed: 0.007 sec.

Нужно добавить в запрос where active

Или enabled, чет такое.

А если поменять структуру таблицы, сделать не value1, value2,... valueN, а name и value, в первую колонку пишем название показателя, во вторую - значение.

Что-то я не уверен, что EAV хорошая идея

Что-то я не уверен, что EAV хорошая идея

Я тоже, но бывают ситуации, когда по-другому никак :)

подскажите, как решить следующую проблему: 1. есть таблица MergeTree 2. над ней создается матвьюха AggregatingMergeTree 3. в этой матвьюхе есть вычисляемый через case (вложенные ifы) столбец 4. при создании матвьюхи на непустой существующей исходной таблице с ключом populate - все ок 5. но когда возобновляем запись в исходную таблицу, записывающий клиент получает исключения: ...Unknown identifier: error_type: while pushing to view default.exceptions1... at ru.yandex.clickhouse.except.ClickHouseExceptionSpecifier.specify(ClickHouseExceptionSpecifier.java:53) ~[clickhouse-jdbc-0.1.39.jar:?] error_type - имя вычисляемого столбца exceptions1 - имя матвьюхи как это лечить? полные sql и весь текст исключения здесь: https://pastebin.com/1AXNXQcg

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

заставить срабатывать mat view не на каждую прилетающую пачку данных в таблицу а раз в 5 минут например можно как-то?

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

Подзапросы в матвьюхах не работают правильно. В вашем случае легко переписать запрос без подзапроса.

Или enabled, чет такое.

C where active и без него одинаковый результат. Ещё догадкик есть ?

судя по метрике clickhouse.имя_хоста.ClickHouse.ProfileEvents.InsertedRows, данные вставляются, но так как число файлов в каталоге carbon-clickhouse растет, то вставка не успевает

причем вставляется в 10 раз больше , чем приходит, КХ врет?

Подзапросы в матвьюхах не работают правильно. В вашем случае легко переписать запрос без подзапроса.

круто, если дело все лишь в этом, то спасибо!!!

Привет. Можете подсказать?

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

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

И кстати - для дебага серверных ошибок лучше добавлять серверный стак-трейс (скорее всего есть в логах или в в query_log), а не стак-трейс с jdbc клиента.

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

Не инсертовать новую версию? :)

И кстати - для дебага серверных ошибок лучше добавлять серверный стак-трейс (скорее всего есть в логах или в в query_log), а не стак-трейс с jdbc клиента.

ок

Не инсертовать новую версию? :)

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

судя по метрике clickhouse.имя_хоста.ClickHouse.ProfileEvents.InsertedRows, данные вставляются, но так как число файлов в каталоге carbon-clickhouse растет, то вставка не успевает

а как часто вставка происходит?

Раньше была раз в секунду

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