Эффективнее сразу в базу стримить или накапливать в каком нибудь csv?

Кликхаус любит инсерты пачками. Идеально - один инсерт в секунду или реже. Размеры пачек - до нескольких сотен тысяч строк.

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

Ругается на arrayDifference

нужна версия 18.12.13+

нужна версия 18.12.13+

понял( Попробую попросить обновить.

Кликхаус любит инсерты пачками. Идеально - один инсерт в секунду или реже. Размеры пачек - до нескольких сотен тысяч строк.

То есть в той же Метрике сначала идёт накопление а потом вставка в кликхаус?

Эффективнее сразу в базу стримить или накапливать в каком нибудь csv?

стримить большие куски

То есть в той же Метрике сначала идёт накопление а потом вставка в кликхаус?

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

Где то 50мб в день внутри кх

Где то 50мб в день внутри кх

Смешные объемы данных для КХ. Вам точно нужен кликхаус? Или вы данные за 10 тысяч лет будете анализировать? :)

запускаю ch-server и tabix в докере в разных контейнера создаю базу и таблицу (Log) в ней через tabix volumes прокинут файлы на хосте появляются перезапускаю контейнер, файлы в контейнере появляются но tabix не видит базу так же и в обычном запросе по http (?query=...) в чем может быть проблема?

приходится при перезапуске делать attach базы и всех таблиц другого решения нет что ли?

Где то 50мб в день внутри кх

а зачем вам кх тогда ? у вас тупо будет из текстового файла быстро работать )

Ну не в мускул же пихать) а так сжато и не мешает

Ну не в мускул же пихать) а так сжато и не мешает

Если данных 50 мб в день - то можете и по одной строке инсертить :D

Если данных 50 мб в день - то можете и по одной строке инсертить :D

А вот и ответ))

А вот и ответ))

Только если вдруг будут пики - типа весь день тишина, а потом в течение минуты миллион единичных инсертов - то и так всё встанет.

Всем привет! Добавили в таблицу новые значения поля enum на всем кластере, сделали альтер на всех нодах, но все равно в логах кликхауса видим ошибки вида Type mismatch for column - и он говорит что Enum8 еще видит старый, хотя везде новый в таблицах в describe table. Такое кто-нибудь встречал? Нужно рестартить что ли зуукипер или сам кликхаус-сервер или просто почистить папку broken ? Есть подозрения, что эти ошибки мешают текущей вставке записей.

@miptgirl подскажешь?

Есть чат про Яндекс.Метрику, в общем - https://t.me/yandexmetrika Там можно спрашивать и про Logs API

Всем привет! Добавили в таблицу новые значения поля enum на всем кластере, сделали альтер на всех нодах, но все равно в логах кликхауса видим ошибки вида Type mismatch for column - и он говорит что Enum8 еще видит старый, хотя везде новый в таблицах в describe table. Такое кто-нибудь встречал? Нужно рестартить что ли зуукипер или сам кликхаус-сервер или просто почистить папку broken ? Есть подозрения, что эти ошибки мешают текущей вставке записей.

Проверьте DEFAULT/MATERIALIZED выражения. Кликхаус там явные приведения типов добавляет, которые при альтерах тоже нужно изменять.

Только если вдруг будут пики - типа весь день тишина, а потом в течение минуты миллион единичных инсертов - то и так всё встанет.

В плане встанет что данные будут вставлены?

В плане встанет что данные будут вставлены?

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

Проверьте DEFAULT/MATERIALIZED выражения. Кликхаус там явные приведения типов добавляет, которые при альтерах тоже нужно изменять.

не, там все пусто было и раньше, если смотреть describe table

не, там все пусто было и раньше, если смотреть describe table

Посмотрите что там в логах рядом с сообщением Type mismatch for column.

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

Ок, поставлю на мониторинг

Посмотрите что там в логах рядом с сообщением Type mismatch for column.

ничего особенного, просто Column has type Enum8 не совпадает, и список полей отображается. Хотя в БД норм все

ничего особенного, просто Column has type Enum8 не совпадает, и список полей отображается. Хотя в БД норм все

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

Возможно в самом селекте/инсерте что-то не так?

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

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

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

ага, теперь кажется понял в чем проблема. Да, интересный кейс. :)

Инсерты идут через Distibuted?

Да

Distributed уже пересоздана?

А зачем ее пересоздавать? Мы там альтеры везде тоже сделали

А зачем ее пересоздавать? Мы там альтеры везде тоже сделали

Ну не суть, в смысле структура у Distributed тоже уже изменилась.

Вкратце - скорее всего проблема связана с тем что alter на Distributed и на подчиненных таблицах были выполнены не одновременно, и между этими событиями приехали какие-то инсерты (по возможности лучше останавливать записть на время альтеров) которые теперь "зависли" в Distibuted.

Вкратце - скорее всего проблема связана с тем что alter на Distributed и на подчиненных таблицах были выполнены не одновременно, и между этими событиями приехали какие-то инсерты (по возможности лучше останавливать записть на время альтеров) которые теперь "зависли" в Distibuted.

ага, спасибо, так и думали. А как теперь испрвить это? Удалить все файлы в папке broken?

ага, спасибо, так и думали. А как теперь испрвить это? Удалить все файлы в папке broken?

Если эти данные не нужны - то можно просто удалить. Как вариант - можно создать таблицу со старой структурой, перенести broken_ части в detached для этой временной таблицы, там сделать attach, и потом заинсертить их ещё раз в Distributed.

Вообще наверное Enum с расширенным набором значений должен "принимать" на уровне типов Enum'ы с более узким (при этом совпадающим) набором значений.

Вообще наверное Enum с расширенным набором значений должен "принимать" на уровне типов Enum'ы с более узким (при этом совпадающим) набором значений.

Не, не принимает так.

Не, не принимает так.

Угу, знаю. Просто мысли вслух :)

Если эти данные не нужны - то можно просто удалить. Как вариант - можно создать таблицу со старой структурой, перенести broken_ части в detached для этой временной таблицы, там сделать attach, и потом заинсертить их ещё раз в Distributed.

а могут ли они аффектить текущую вставку? Ну то есть если все нормально уже с новыми запросами?

Кто знает, после скольки попыток мерджа и несовпадении чексумы КХ таки скачает его с одной из реплик. Перезагрузка серверов с изменеием конфига с разницей в 5-10 секунд привела к тому, что на одном хосте этот парт уже есть, 2 дугих попеременно мерджат его и откидывают уже минут 40, сам мердж занимает 2 минуты

новое мерджится нормально, проблема в единственном парте

Если эти данные не нужны - то можно просто удалить. Как вариант - можно создать таблицу со старой структурой, перенести broken_ части в detached для этой временной таблицы, там сделать attach, и потом заинсертить их ещё раз в Distributed.

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

Всем привет, столкнулся с необычным на мой взгляд поведением у меня есть VIEW таблица ReplicatedSummingMergeTree, так вот в ней данных, например SUM(events), больше чем в оригинальной табличке, не значительно, такое ощущение что при инсерте, данные сначала попадают во вьюху, а потом уже в таблицу. Это нормально? Так задумано?

а могут ли они аффектить текущую вставку? Ну то есть если все нормально уже с новыми запросами?

broken части вроде бы не должны. Но если там "висят" части с названием реплики, то наверное могут. В смысле он будет пробовать повторно заинсертить данные, а в случае неудачи - будет думать что с этой репликой "что-то не так".

Но я не уверен. Может быть девелоперы подскажут быстрее. :)

broken не аффектят вставку, и оттуда не отправляются повторно записи, согласно доке. А вот вся очередь копится в /var/lib/clickhouse/data/database/table/ - а как можно оттуда вычесть неверные записи, кто-нибудь знает?

Товарищи, подскажите, может есть схожий чат но по проблемам связанным с аппметрикой? Или к кому в ЛС обратиться... Прям с 11:20 (МСК) appmetrica logs api не отдает данные(

Товарищи, подскажите, может есть схожий чат но по проблемам связанным с аппметрикой? Или к кому в ЛС обратиться... Прям с 11:20 (МСК) appmetrica logs api не отдает данные(

С таким лучше в саппорт

Спасибо, просто думал может кто в чате в курсе и подтведил бы(может там обновление просто у них идет - тогда проще подожать) Но да, пойду в саппорт.

Подскажите, плиз, насколько длинный detach partition может быть? Уже больше часа висит запрос, критичной нагрузки ни по одному компоненту не вижу. SHOW PROCESSLIST Row 1: ────── is_initial_query: 1 user: default query_id: 0038d5f8-97ae-463e-9c21-05120bbc51c5 address: 127.0.0.1 port: 20323 initial_user: default initial_query_id: 0038d5f8-97ae-463e-9c21-05120bbc51c5 initial_address: 127.0.0.1 initial_port: 20323 interface: 1 os_user: root client_hostname: carbonch-d01 client_name: ClickHouse client client_version_major: 18 client_version_minor: 10 client_version_patch: 3 client_revision: 54405 http_method: 0 http_user_agent: quota_key: elapsed: 3637.367657261 is_cancelled: 0 read_rows: 0 read_bytes: 0 total_rows_approx: 0 written_rows: 0 written_bytes: 0 memory_usage: 0 peak_memory_usage: 0 query: ALTER TABLE graphite DETACH PARTITION '201809' Это вообще нормально? И насколько безопасно его прервать?

в каталоге detached не появилось ровным счетом ничего

зукипер тоже покуривает

чем-то он залочен видимо

селектами, инсертами, мержами?...

ну длинных запросов там точно нет

чем-то он залочен видимо

как корректно проверить чем залочен?

broken не аффектят вставку, и оттуда не отправляются повторно записи, согласно доке. А вот вся очередь копится в /var/lib/clickhouse/data/database/table/ - а как можно оттуда вычесть неверные записи, кто-нибудь знает?

Например по дате создания?

не знаю даже, show processlist пустой насчет этой таблицы?

только этот альтер

KILL QUERY WHERE query_id = '0038d5f8-97ae-463e-9c21-05120bbc51c5' ASYNC Row 1: ────── kill_status: pending query_id: 0038d5f8-97ae-463e-9c21-05120bbc51c5 user: default query: ALTER TABLE graphite DETACH PARTITION '201809' 1 rows in set. Elapsed: 0.002 sec.

и продолжает висеть

Подскажите, плиз, насколько длинный detach partition может быть? Уже больше часа висит запрос, критичной нагрузки ни по одному компоненту не вижу. SHOW PROCESSLIST Row 1: ────── is_initial_query: 1 user: default query_id: 0038d5f8-97ae-463e-9c21-05120bbc51c5 address: 127.0.0.1 port: 20323 initial_user: default initial_query_id: 0038d5f8-97ae-463e-9c21-05120bbc51c5 initial_address: 127.0.0.1 initial_port: 20323 interface: 1 os_user: root client_hostname: carbonch-d01 client_name: ClickHouse client client_version_major: 18 client_version_minor: 10 client_version_patch: 3 client_revision: 54405 http_method: 0 http_user_agent: quota_key: elapsed: 3637.367657261 is_cancelled: 0 read_rows: 0 read_bytes: 0 total_rows_approx: 0 written_rows: 0 written_bytes: 0 memory_usage: 0 peak_memory_usage: 0 query: ALTER TABLE graphite DETACH PARTITION '201809' Это вообще нормально? И насколько безопасно его прервать?

Возможно какие-то проблемы с репликацией этого запроса?

Что на других репликах?

И что в логах?

на другой реплике все чисто

и детач тоже не прошел, но я ON CLUSTER и не пускал его

select * from system.merges ?

carbonch-d01.ops.icq.com ? select table,elapsed,num_parts from system.merges; SELECT table, elapsed, num_parts FROM system.merges ┌─table────┬────────elapsed─┬─num_parts─┐ │ graphite │ 6421.559180916 │ 9 │ │ graphite │ 6421.348935277 │ 7 │ │ graphite │ 6421.34433493 │ 5 │ │ graphite │ 6421.34333058 │ 3 │ └──────────┴────────────────┴───────────┘ 4 rows in set. Elapsed: 0.001 sec.

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

а как понять что мешает мержам отработать?

Судя по всему они работают у вас, смотрите что за куски они мержат source_part_names и на размеры. Если ли ошибки?

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

откройте top и iotop и посмотрите что происходит

А как-то можно "ускорить" мутации на удаление данных? Просто htop показывает вот такую картину: https://img.facedsid.ru/ovt3e.jpg А в КХ 11540 партов для обработки при этом никакие запросы на сервер КХ не идут. Я мутации запустил еще в 12 часов и они ппц как медленно идут. Такое ощущение, что КХ их обрабатывает как-то вяленько

смотрите iotop

смотрите iotop

там тоже все "по нулям"

я делал мутации удалением они фактически сразу начались

https://img.facedsid.ru/se8z7.mp4

Они начинаются сразу, да, но они не задействуют все ресурсы что есть на сервере

Сервер стоит в холостую

https://img.facedsid.ru/xisd0.jpg

Мне кажется, что КХ может потреблять куда больше ресурсов :)

А такое ощущение, что ему лимиты воткнули на мутации и он за пределы этих лимитов не вылезает

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

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

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

В том-то и проблема ( На двух серверах такая история была ( Он прям мееееееееееееееееееедленно мутации на удаление исполняет. Версия 18.12.17

у меня тоже 18.12.17

а каким запросом удалили ? я просто удаляю по дате меньше 15 дней и там мутации прямо огонь как быстро идут

Кажется я увидел в чем проблема. Они встали на месте из-за того, что у меня в условии подзапрос. В логах валится, что таблица default.table не существует. Хотя я мутацию запускал явно в конкретной базе данных

Но почему-то эта штука использует default

И остановить мутацию никак...

Оно прям нонстопом валит ошибки