а там нигде лишнего неэкранированного разделителя нету случайно?

а если --stacktrace

разделителю вроде неоткуда взяться =/

надо смотреть - что в файле в том месте, где была последняя вставленная запись. Для начала

stacktrace ничего не выдает

КХ всегда ругается на некорректные данные

по крайней мере, по http

работаем через клиент командной строки

хотя даже если без --stacktrace.. ❯ clickhouse-client -q "CREATE TABLE test (s String, i Int64) ENGINE = Memory;" ❯ echo -e '"hello",1\n"invalid csv' | clickhouse-client -q 'INSERT INTO test FORMAT CSV' Code: 27. DB::Exception: Cannot parse input: expected , at end of stream.: Could not print diagnostic info because two last rows aren't in buffer (rare case) : (at row 2)

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

и никаких ошибок

мм, а count() по этой таблице возвращает верное кол-во данных? если вообще без фильтров

вот как раз нет, он выдает ~50к записей, а в csv их 1кк

нет

есть по max query size

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

поднял юзеру - заработало

Так это не лимит POST-а, а лимит парсера SQL. Что как-бы разные вещи. POST-ом я гигабайты заливал

и мне таки интересно - что у клиента за запросы, если ему 64К на SQL не хватило

привет. когда я делаю RENAME таблицы, будет ли он заблокирован SELECT query из этой же таблицы?

после перезагрузки сервера новый RENAME все так же продолжает висеть.

Так это не лимит POST-а, а лимит парсера SQL. Что как-бы разные вещи. POST-ом я гигабайты заливал

ну в общем да, просто ошибка неинформативная

и по ней казалось словно есть лимит на вставку

и мне таки интересно - что у клиента за запросы, если ему 64К на SQL не хватило

очень большой селект, примерно на 1.6МБ

очень большой селект, примерно на 1.6МБ

http://filonov.livejournal.com/11140.html типа такого? ?

http://filonov.livejournal.com/11140.html типа такого? ?

не, нормальный, просто автоматически сгенерированный графаной

SELECT Path, Value, Time, Timestamp where PATH IN ( список из 80 тысяч path'ов)

потому что так * раскрылась

?

С лимитом POST-запросов чаще натыкаешься с клиентской стороны. Потому как не только лишь все могу отослать 10G POST, мало кто может это сделать.

Хм, интересная штука

мелкие запросы с PREWHERE выполняюстя в разы быстрее

в 2 раза где-то

а тяжелые наоборот, раз в 6 медленее

в чем причина?

На моих запросах разницы вообще не было

На моих запросах разницы вообще не было

у меня на легких запросах prewhere - 80ms, where - 200ms

на тяжелых prewhere - 15sec, where - 3sec

Мои "легкие" в минутах измеряются :)

ну у меня это графит

У меня - много миллиардов строк статистики

У меня - много миллиардов строк статистики

ну у меня пока графит на пол млн метрик и примерно 50 млрд точек

структура поэтому простая

в чем причина?

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

help "ReplicatedMergeTree('/clickhouse/tables/{layer}-{shard}/hits', '{replica}', EventDate, intHash32(UserID), (CounterID, EventDate, intHash32(UserID), EventTime), 8192) Путь к таблице в ZooKeeper должен быть разным для каждой реплицируемой таблицы. В том числе, для таблиц на разных шардах, должны быть разные пути. Что здесь значит "разным для каждой реплицируемой таблицы"?

ребят, а удаленно можно загузить csv-ник через курл в кликхаус ?

в документации же есть примеры

cat example.csv | curl 'http://localhost:8123/?query=INSERT+INTO+test+FORMAT+CSV' --data-binary @-

ага, спасибо!

просмотрел

:(

ну не прям такой

echo -ne '10\n11\n12\n' | POST 'http://localhost:8123/?query=INSERT INTO t FORMAT TabSeparated' но под curl несложно переделать

Ппр

кто то юзал блого движок Эгея?

Всем любителям фильмов советую отличный чатик @chatanonhownow

Вы зашли в канал чисто поспамить?

Не

А похоже.

Что такое клик хаус яндекс?

https://clickhouse.yandex/

Убрал этого человека из группы.

А есть бот которому скармливаешь чела и если много кто пожаловался то его банят вобще в телеграме ?

Не знаю.

А есть бот которому скармливаешь чела и если много кто пожаловался то его банят вобще в телеграме ?

Это не бот, скорее голосовалка. Но и какое-то подобие бота было.

есть, называется техподдержка.+42470 телефон

SELECT Path, Value, Time, Timestamp where PATH IN ( список из 80 тысяч path'ов)

а как кх к графане подключали?

а как кх к графане подключали?

https://github.com/lomik/graphite-clickhouse + carbonapi

grafana?

не графит

grafana?

Через слой совместимости с графитом

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

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

Да

а на прямую графану с кх никто не связывал?

Нужно плагин писать под графану

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

да и на работе под это времени нет

Ну у меня задачи мониторинговые сейчас.

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

Данные два раза не читаются.

help "ReplicatedMergeTree('/clickhouse/tables/{layer}-{shard}/hits', '{replica}', EventDate, intHash32(UserID), (CounterID, EventDate, intHash32(UserID), EventTime), 8192) Путь к таблице в ZooKeeper должен быть разным для каждой реплицируемой таблицы. В том числе, для таблиц на разных шардах, должны быть разные пути. Что здесь значит "разным для каждой реплицируемой таблицы"?

Первый параметр должен быть разным для каждого шарда. При этом он один для разных реплик одного шарда.

Спасибо

А как используется имя реплики? То есть для чего?

Для самоидентификации видимо. Чтоб с себя не качать

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

select * from system.zookeeper;

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

может, потому что данные до реплики могли еще не дойти, например?

ну тут можно понять дошли или не дошли

прогромировать надо просто

и кост модель делать

а какие тут кост модели щас

т.е. запись в два шарда идет синхронная?

нет, ты же можешь спросить запрос про старые уже данные

может, потому что данные до реплики могли еще не дойти, например?

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

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

Есть настройка max_parallel_replicas. Делает как раз то, что нужно. Но для консистентности (чтобы получить разные части одного и того же разбиения), эта опция работает только при заданном ключе сэмплирования.