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

и при каждом запросе открывалось новое подключение

по ssh на сервак еще заходило, но кх не отвечал

Можно ли как-то выставить distributed_group_by_no_merge в единичку для read-only юзеров? Есть запрос с группировкой и шардинг гарантирующий размещение этих групп только на конкретных нодах. Кажется логичным применять эту настройку, но для read-only оно ругается "Cannot execute SET query in readonly mode"

readonly в 2 выставить надо

Тогда можно делать SET и создавать временные таблицы

Или просто в профиле пользователя указать

Всем привет. Подскажите, плиз, нам нужно выполнять по запросу порядка 2к запросов типа insert into table select col1,col2,sum(col4) from table where ... group by col1,col2 Если начинаем подряд слать 2к штук, то взлетает количество кусков, и начинает идти дым. Как это можно оптимизировать? Понимаю, что в КХ слать батчем, но тут практически нереально объединить эти 2к запросов в один большой. Если мы их отправим через ; эти чем-то поможет? т.е. будет одна отправка в КХ, а не несколько.

Всем привет. Подскажите, плиз, нам нужно выполнять по запросу порядка 2к запросов типа insert into table select col1,col2,sum(col4) from table where ... group by col1,col2 Если начинаем подряд слать 2к штук, то взлетает количество кусков, и начинает идти дым. Как это можно оптимизировать? Понимаю, что в КХ слать батчем, но тут практически нереально объединить эти 2к запросов в один большой. Если мы их отправим через ; эти чем-то поможет? т.е. будет одна отправка в КХ, а не несколько.

Сгруппировать по таргетам и аплоадом через файл (дескриптор / сокет)

Сгруппировать по таргетам и аплоадом через файл (дескриптор / сокет)

А что значит сгруппировать по таргетам?

В чем может быть плюс своего решения против Buffer таблицы?

Целевые таблицы с одинаковым форматом вставки

В чем может быть плюс своего решения против Buffer таблицы?

Если для замены масла в машине, то разница ощутима, цель то какая?

Если для замены масла в машине, то разница ощутима, цель то какая?

Цель — буферизировать запросы на вставку, идущие в реалтайме один за другим. Документация предлагает два решения — делать буфер в приложении которое делает insert, либо использовать Buffer таблицу

Buffer лежит в оперативке + расход на коннекты от разных инсертов. По этому в некоторых случаях буферизация на аппликухе куда лучше

Цель — буферизировать запросы на вставку, идущие в реалтайме один за другим. Документация предлагает два решения — делать буфер в приложении которое делает insert, либо использовать Buffer таблицу

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

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

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

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

Buffer не прокатит с репликой

Buffer не прокатит с collapsingmergetree

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

Пример то хороший) Только если буфер в своем приложении делать, он все равно будет лежать в оперативке)

оч много ограничений

Если будет более одного слоя буффера то никакой очередности в записи, полный фраш)

Если будет более одного слоя буффера то никакой очередности в записи, полный фраш)

Еще будет здорово при обрыве питания или падении KX)

Buffer не прокатит с репликой

Почему не прокатит с репликой?

Почему не прокатит с репликой?

Я так понял не с репликой а с Distributed?

https://clickhouse.yandex/docs/ru/table_engines/buffer.html

Если таблица назначения является реплицируемой, то при записи в таблицу Buffer будут потеряны некоторые ожидаемые свойства реплицируемых таблиц. Из-за произвольного изменения порядка строк и размеров блоков данных, перестаёт работать дедупликация данных, в результате чего исчезает возможность надёжной exactly once записи в реплицируемые таблицы.

сорян, немного ошибся

Это не называется «не будет работать» :)

может и прокатит))

удачи )

Я сделал себе файловый буффер. Данные копятся в файлах и когда запись в файл заканчивается (там может быть от 1 до n строк в одном файле), то ему в название дописывается -flushed. Затем я раз в 1 минуту собираю все эти файлы и склеиваю в один файл и отправляю в формате CSV на вставку

«В связи с этими недостатками, таблицы типа Buffer можно рекомендовать к применению лишь в очень редких случаях.»

Мы просто вставляем как раз в ReplicatedMergeTree через Buffer-таблицу, интересно было узнать, что с этой схемой не так, кроме exactly-once и сохранения порядка

Если не удалось скинуть в CH, то файл складывается в отдельную директорию из которой можно ручками залить

у нас тупо редис лист на пых приложениях

то что через реббит можно батч консюмеры использовать

добрый вечер. Подскажите пожалуйста, как POSTом сделать INSERT из csv файла?

добрый вечер. Подскажите пожалуйста, как POSTом сделать INSERT из csv файла?

В доке же прямо такой пример приведен.

в доке, надо заметить, без поллитры не разберешься. хотя про мои доки говорят то же самое :)

я вижу. Я так понял - в теле запроса нужно передавать содержимое файла. А нельзя ли не вычитывая его передать?

в доке, надо заметить, без поллитры не разберешься. хотя про мои доки говорят то же самое :)

это да. Дока CH по своему прекрасна

это да. Дока CH по своему прекрасна

Самый быстрый вариант это перенести зазипованный csv на другой сервер и там загрузичить через clickhouse-clien

это да. Дока CH по своему прекрасна

Если обязательно через POST, то можно через CURL передать на нужный сервер, написав INSERT запрос в query (1 строка), а данные потоком перенаправить в POST

>cat filename.csv | curl 'http://serverhost:8123/?query=INSERT INTO' -d @- Или >cat filename.csv | POST 'http://serverhost:8123/?query=INSERT INTO'

спасибо. Буду пробовать

привет

я возможно нашла баг

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

а optimize эти маленькие файлы в 1 перепишет?

допустим я пишу по 10 строк в секунду

и раз в сутки ночью optimize делаю

то он же приберется?

или это ложные надежды?

и раз в сутки ночью optimize делаю

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

можно же вручную вызвать optimize

чтобы наверняка

optimize final

я могу позволить себе на пару минут остановить работу ночью

а еще если у меня будет репликация, то optimize надо будет на каждой реплике запускать?

или запустив на одной он приберется на всех?

или запустив на одной он приберется на всех?

Мы же про кусочки партиций говорим? Optimize попробует что-то птимизировать, но clickhouse сам перестроит файлы, как сочтет нужным. Конкретно на моем проекте, вчерашние данные успешно компануются, хотя и не сразу. Вызов Optimize Final процесс не ускоряет (хотя может и ускоряет, но все равно это проихсдит не мгновенно).

судя по доке Optimize Final перезаписывает таблицу в другое место

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

тоесть все партиции будут забиты под завязку

всеравно через какоето время replicatedmergetree наделает дырок, или не так?

судя по доке Optimize Final перезаписывает таблицу в другое место

Можно ссылку?

Отключил прореживние на тестовом сервере, создал таблицу с грануляцией в 32768 строк, скопировал данные из таблицы с грануляцией в 8192 строк, БД усохла на диске с 91Г до 48Г, но часть данных потерялась: SELECT count(*) FROM graphite32 ┌─────count()─┐ │ 13901899118 │ └─────────────┘ 1 rows in set. Elapsed: 2.896 sec. Processed 13.90 billion rows, 27.80 GB (4.80 billion rows/s., 9.60 GB/s.) :) select count(*) from graphite; SELECT count(*) FROM graphite ┌─────count()─┐ │ 13903321793 │ └─────────────┘ 1 rows in set. Elapsed: 2.100 sec. Processed 13.90 billion rows, 27.81 GB (6.62 billion rows/s., 13.24 GB/s.) :)

как сравнить, что бы понять, что попадает?

всеравно через какоето время replicatedmergetree наделает дырок, или не так?

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

тоесть он каждый раз перестраивает партицию

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

значит я чтото попутал

тоесть он каждый раз перестраивает партицию

Не каждый раз, а по мере необходимости (конкретные признаки назвать не могу)

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

Если у вас сейчас 40 файлов (или 500), то через время их должно стать 20, а затем 10. И .тд.

На реплике такая же ситуация и работает независимо от 1 сервера.

у нас сейчас 50к записей, но в течении 1-2 месяцев будет 10 млн

и дальше будет расти в неизвестных объемах

копейки)

у нас сейчас 50к записей, но в течении 1-2 месяцев будет 10 млн

В данный момент переношу больше миллиарда записей. В секунду по миллиону. Наблюдаю рост от 10 до 160 файлов.

Все зависит еще от дат или иного ключа партиционирования

а ну тогда нормально

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

ну там минута или еще сколько-то

чтобы можно было заказчику цифру сказать

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

По этому вопросу пока не могу подсказать.

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

Да, я расчитываю на достаточно долгое слияние. Если дублей больше миллиона. Вчерашний тест показал, что при строках более 100 млн, 4 млн строк удалялись более 2 часов. На самом деле тестировать до конца не стал, так как этого достаточно, чтобы искать алгоритмическое решение.