Я тут вроде не причём :)

DB::Settings::... вызывает такое поведение

DB::Settings::Set это что-то в кликхаусе, по названию оно не дложно бы вызываться слишком часто)

вот да

DB::Settings::Set это что-то в кликхаусе, по названию оно не дложно бы вызываться слишком часто)

Ещё раз напишу что я вставляю по одной строке. Но тем не менее.

слушайте, у меня есть машина с такой нагрузкой

секнду

Так что там нагружать: curl_easy_perform с одной строкой rowbinary в цикле.

В #define Apply_for_settings видно random на loadbalancing. , Если оно вообще к этому.

http://paste.org.ru/?qjf5hy

у меня вот так

но у меня не хттп протокол

я открываю базу 1 раз и пишу строки туда через С++ либу

я открываю базу 1 раз и пишу строки туда через С++ либу

По одной за insert?

Попробую завтра с другим load_bal

Поодной да

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

Сомнительно. У меня одно соединение.

sudo perf top —call-graph dwarf покажет более правильные стек-трейсы.

Ok, завтра сделаю. Просто, если я правильно понимаю, то всё же при вставке в буфер ничего сложного происходить не должно, кроме обработки http.

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

а может цурл каждый раз открывает новое соединение?

и это вызывает валидацию пароля повторно?

В http протоколе пароль проверяется на каждый запрос. Нет сущности "пароль на соединение"

ну, видимо в этом и ответ, почему столько ша1 в выдаче

ну, видимо в этом и ответ, почему столько ша1 в выдаче

Пока ещё это не ответ. Не совпадает количество.

Всем привет! Это внутрияндексовский чат или тут действует NDA

?

это внешний чат

ладно я тогда пойду в другое место :)

Но мы не против послушать))

после обновления до последней версии появилась ошибка во внешнем словаре: last_exception: Code: 36, e.displayText() = DB::Exception: Unknown key \'name[1]\' inside attribute section, e.what() = DB::Exception ругается вот на это: <name>created</name> <type>DateTime</type> <null_value>NULL</null_value> хотя в мускуле поле (timestamp) селектится нормально, и до обновления работало нормально. Никто не знает в чем причина?

<name> случайно не дублируется?

точно, мой косяк, почему-то раньше не алертило об ошибке =)

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

Мы планируем устроить хакатон по ClickHouse для frontend разработчиков. Основная тема - всевозможные визуализации данных, инструменты для работы с ClickHouse. Нужны ваши идеи :)

Здравствуйте. Можно ли найти пересечение двух массивов? Не смог найти подходящие функции. Массивы содержат строки, и мне нужно найти элементы массива A, которые не содержатся в массиве B.

Мы планируем устроить хакатон по ClickHouse для frontend разработчиков. Основная тема - всевозможные визуализации данных, инструменты для работы с ClickHouse. Нужны ваши идеи :)

идеи чего? проектов для хакатона?

Да.

Здравствуйте. Можно ли найти пересечение двух массивов? Не смог найти подходящие функции. Массивы содержат строки, и мне нужно найти элементы массива A, которые не содержатся в массиве B.

Коллеги подсказали SELECT arrayFilter(x -> NOT arrayExists(y -> (y = x), ['a', 'b', 'c'] AS B), ['b', 'c', 'd', 'e', 'f'] AS A)

Мы планируем устроить хакатон по ClickHouse для frontend разработчиков. Основная тема - всевозможные визуализации данных, инструменты для работы с ClickHouse. Нужны ваши идеи :)

посмотреть на все возможные инструменты визуализации, сделать выводы, еще раз посмотреть, потом еще раз посмотреть, пересмотреть выводы, а потом запилить универсальную ??

и в open-source ?

За один день трудновато.

QueryEditor extends React.Component, вот это все.

Мне сказали что для просмотра статистики запросов к базе можно смотреть в system.query_log

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

В http протоколе пароль проверяется на каждый запрос. Нет сущности "пароль на соединение"

т.е. надо на нативный попробовать переехать? Ок

ее переименовали или теперь такой функциональности больше нет?

ее переименовали или теперь такой функциональности больше нет?

а log_queries в настройках выставлена?

https://github.com/yandex/ClickHouse/issues/230

похоже нет

Спасибо! Сейчас попробую

Логгирование запросов включается настройкой log_queries. Настройка может быть изменена динамически, так же как все остальные настройки. По-умолчанию включено везде в нашем пакете и отключено в пакете для сторонних пользователей. Логгирование запросов полностью асинхронное. Запись сначала вставляется в очередь. Очередь блокирующая, но её максимальный размер достаточно большой, чтобы это не вызывало проблем. Затем запись из этой очереди достаёт отдельный поток и кладёт себе в массив. Периодически, этот поток сбрасывает массив, записывая данные в таблицу. Периодичность сброса по-умолчанию - 7.5 секунд. Записи, не сброшенные в таблицу, недоступны для чтения. По-умолчанию, запись осуществляется в таблицу system.query_log. Если таблица для записи уже существует, то проверяется соответствие её структуры текущей структуре лога. Если она не соответствует, то существующая таблица сначала переименовывается в query_log_0 или query_log_1 и т. п, а затем создаётся новая таблица, как если бы её не было. Если таблица не существует, то создаётся новая таблица с движком MergeTree. Проверка и создание таблицы осуществляется только один раз - при первой записи в лог. Эти действия (инициализация логгера) делаются синхронно (при первом запросе). Периодичность сброса и имя таблицы могут быть настроены в конфиге: <!— Лог запросов. Используется, только для запросов с настройкой log_queries = 1. —> <query_log> <!— В какую таблицу писать. Если таблицы нет, она создаётся. При изменении структуры лога, старая таблица переименовывается и создаётся новая. —> <database>system</database> <table>query_log</table> <!— Интервал сброса данных в таблицу. —> <flush_interval_milliseconds>7500</flush_interval_milliseconds> </query_log> При штатном завершении работы сервера, данные тоже сбрасываются в таблицу. Если при записи данных возникает ошибка, то данные теряются и ошибка пишется в обычный лог. Логгирование производится в четырёх случаях: В начале выполнения запроса. При успешном завершении запроса. В случае исключения до начала выполнения запроса. В случае исключения в середине выполнения запроса. Лог запросов не очищается автоматически. Для ручной очистки можно использовать запрос ALTER ... DROP PARTITION.

Логгирование запросов включается настройкой log_queries. Настройка может быть изменена динамически, так же как все остальные настройки. По-умолчанию включено везде в нашем пакете и отключено в пакете для сторонних пользователей. Логгирование запросов полностью асинхронное. Запись сначала вставляется в очередь. Очередь блокирующая, но её максимальный размер достаточно большой, чтобы это не вызывало проблем. Затем запись из этой очереди достаёт отдельный поток и кладёт себе в массив. Периодически, этот поток сбрасывает массив, записывая данные в таблицу. Периодичность сброса по-умолчанию - 7.5 секунд. Записи, не сброшенные в таблицу, недоступны для чтения. По-умолчанию, запись осуществляется в таблицу system.query_log. Если таблица для записи уже существует, то проверяется соответствие её структуры текущей структуре лога. Если она не соответствует, то существующая таблица сначала переименовывается в query_log_0 или query_log_1 и т. п, а затем создаётся новая таблица, как если бы её не было. Если таблица не существует, то создаётся новая таблица с движком MergeTree. Проверка и создание таблицы осуществляется только один раз - при первой записи в лог. Эти действия (инициализация логгера) делаются синхронно (при первом запросе). Периодичность сброса и имя таблицы могут быть настроены в конфиге: <!— Лог запросов. Используется, только для запросов с настройкой log_queries = 1. —> <query_log> <!— В какую таблицу писать. Если таблицы нет, она создаётся. При изменении структуры лога, старая таблица переименовывается и создаётся новая. —> <database>system</database> <table>query_log</table> <!— Интервал сброса данных в таблицу. —> <flush_interval_milliseconds>7500</flush_interval_milliseconds> </query_log> При штатном завершении работы сервера, данные тоже сбрасываются в таблицу. Если при записи данных возникает ошибка, то данные теряются и ошибка пишется в обычный лог. Логгирование производится в четырёх случаях: В начале выполнения запроса. При успешном завершении запроса. В случае исключения до начала выполнения запроса. В случае исключения в середине выполнения запроса. Лог запросов не очищается автоматически. Для ручной очистки можно использовать запрос ALTER ... DROP PARTITION.

#faq #query_log #log_queries

Добрый день, что нибудь появилось для миграций в clickhouse ?

Всем привет! Это внутрияндексовский чат или тут действует NDA

Точно говорю: действует

Добрый день, что нибудь появилось для миграций в clickhouse ?

Ну это, select, insert :(

Ну это, select, insert :(

а как же алтер столбцов

создание новых таблиц и т.д.

Мы планируем устроить хакатон по ClickHouse для frontend разработчиков. Основная тема - всевозможные визуализации данных, инструменты для работы с ClickHouse. Нужны ваши идеи :)

Вот рад бы к вам как-то присоединиться. Мы как и многие делаем сейчас морду вокруг кликхауса

а как же алтер столбцов

Делаешь новую таблицу и переливаешь туда

Делаешь новую таблицу и переливаешь туда

что к чему...

Яндекс дайте миграции(

Вот рад бы к вам как-то присоединиться. Мы как и многие делаем сейчас морду вокруг кликхауса

Отлично! Пока ещё не анонсировали. Наверное это где-то в конце июня будет. Сейчас только собираем идеи.

Яндекс дайте миграции(

А сами написать?)

за миграции -- минус минус.

это не первостепенная фича, первостепенная - кастомные шардирования)

и батчер)

о нет

)) блин

и батчер)

Trivial Buffer вмержили

оооо, дай доки)

Trivial Buffer вмержили

На всякий случай предупрежу, что он ещё не разработан. Он вмержен для удобства последующей разработки.

а в чем ключевое отличие от обычноно буфера ожидается?

На всякий случай предупрежу, что он ещё не разработан. Он вмержен для удобства последующей разработки.

не знал, видел просто что вы его смержили )

В общем случае он ничем не лучше Buffer, и использовать его не надо. Подходит для специфических кейсов - когда данные вставляются пачками, но всё-таки достаточно часто. И нужно сохранять порядок вставленных блоков, а также осуществлять дедупликацию блоков.

тогда это не батчер

Привет, у нас в ZK у некоторых ReplicatedMergeTree таблиц по 19 миллионов znode-ов (при том что в system.parts у соотв. таблиц не более 500-600 записей). Похоже, это ненормально и ZK от этого нехорошо. Есть идеи, что может быть не так и как починить?

Были ли случаи добавления/удаления реплик?

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

Да, похоже, дело именно в этом. А как теперь это починить, если старой реплики уже нет и не будет?

Можно вручную удалить каталог в ZK: rmr /<path-to-table>/replicas/<replica>

Главное не перепутать с живой репликой :)

Ясно, так и подумал. Спасибо большое за быстрый ответ! :)

Месяц назад поменялся формат записей в Zookeeper-е. С версии 3 на версию 4. Теперь новую версию КХ нельзя откатить на более старую, ругается на DB::Exception: Unknown ReplicatedMergeTreeLogEntry format version: 4 Есть простой способ все-таки откатиться?

Простого нет, лучше всё-таки не откатываться. Есть только сложный.

Простого нет, лучше всё-таки не откатываться. Есть только сложный.

Наступил на баг https://github.com/yandex/ClickHouse/pull/810 . Надо либо откатываться, либо собирать из исходников версию с патчем :(

Баг присутствовал во всех старых версиях.

В логах ошибка "Sizes of columns doesn't match" появилась только в новых версиях (в 1.1.54135 не было). Но возможно я наступил еще в какой-то баг? Симптомы - растет количество несмердженных чанков, от этого растет потребление CPU, через пару дней cpu заканчивается совсем

Возможно, раньше не проявлялось по другой причине. Или я ошибаюсь. Поставить версию из master будет нормально. Мы как раз сейчас из неё собираем релиз. Но ещё не факт, что она пойдёт в stable.

Добрый день, что нибудь появилось для миграций в clickhouse ?

Мы пользуемся моими костыликами... вполне устраивает на 12 нод

Мы планируем устроить хакатон по ClickHouse для frontend разработчиков. Основная тема - всевозможные визуализации данных, инструменты для работы с ClickHouse. Нужны ваши идеи :)

;) поучаствую