вот это кстати вынесло мозг при первых попытках вставлять данные в КХ из Го хотя это конечно скорее минус database/sql, который не предоставляет интерфейса для батчинга - приходится вот такую магию применять

Мдемс... Откровение, однако! Огромное спасибо!

begin/commit вполне себе батчер ) а так, во второй версии будет более дружественныи интерфейс чтоб можно было работать вобход database/sql от которого очень сильный оверхед если нужно вставлять много данных

Т.е. в моем случае, если я шлю не правильное количество аргументов, то он тупо считает количество знаков вопроса, видит 20 и щлет меня сразу - чувак, мне надо 20 аргументов А если я шлю 20 аргументов, то локальную проверку я прохожу, затем он шлет запрос на сервер, сервер ему отвечает, что надо 5 полей, и он такой - чувак, мне надо 5. так получается?

как-то так

хотя он вроде уже после Prepare и до Exec должен знать, что нужно 5.....

он знает, после Prepare он знает какие колонки нужны и в дебаге даже об этом пишет

в Exec гошный database/sql спрашивает какое количество аргуметов нужно и если оно не совпадает, то он выкидывает ошибку

Всем привет! У нас есть запрос: SELECT ... FROM ( SELECT ... - тут запрос который выдает > RAM этот запрос никак не получается ограничить, потому что он по сути является большим словарем с количеством > 10 млрд записей ) AS a ANY INNER JOIN ( SELECT ... - тут запрос который выдает не очень много данных ) AS b USING ключ; Разумеется, в результате выполнения такого запроса в различных вариациях мы получаем ошибку с превышением memory limit И причина тоже нам понятна, CH загружает каждый подзапрос участвующий в JOIN в RAM и сам JOIN выполняет уже в RAM, и вообще это не та сторона CH, в которой он хорош. Тем не менее, какими методами можно завести этот запрос, если убрать очевидное решение с созданием большой денормализованной таблицы?

я про это же. Откуда ж, если я шлю 4 аргумента, берется: sql: expected 20 arguments, got 4? Это так же происходит уже после Prepare

он считает ? как плейсхолдеры, надо будет поправить поведение

можно сюда написать https://github.com/kshvakov/clickhouse/issues чтоб я не забыл

Всем привет, подскажите как правильно убить мертвую реплику? Вроде в зукипере прибил, но при этом ? optimize table stats OPTIMIZE TABLE stats Received exception from server: Code: 999. DB::Exception: Received from localhost:9000, 127.0.0.1. zkutil::KeeperException. zkutil::KeeperException: Can't get data for node /clickhouse/tables/0/stats/replicas/2/host: node doesn't exist (no node).

а при записи выдает 2017.08.11 15:25:33.291647 [ 113 ] <Error> executeQuery: Code: 252, e.displayText() = DB::Exception: Too much parts. Merges are processing significantly slower than inserts., e.what() = DB::Exception

кто-нибудь сталкивался?

можно сюда написать https://github.com/kshvakov/clickhouse/issues чтоб я не забыл

Я не мастер issues писать. Но кое как написал

ok

Оперативно ))

при прочих равных - SummingMergeTree vs AggregatingMergeTree у какого движка будет выше производительность, лучше потребление памяти, другие ньюансы/недостатки использования? может есть бенчмарки?

Всем привет! У нас есть запрос: SELECT ... FROM ( SELECT ... - тут запрос который выдает > RAM этот запрос никак не получается ограничить, потому что он по сути является большим словарем с количеством > 10 млрд записей ) AS a ANY INNER JOIN ( SELECT ... - тут запрос который выдает не очень много данных ) AS b USING ключ; Разумеется, в результате выполнения такого запроса в различных вариациях мы получаем ошибку с превышением memory limit И причина тоже нам понятна, CH загружает каждый подзапрос участвующий в JOIN в RAM и сам JOIN выполняет уже в RAM, и вообще это не та сторона CH, в которой он хорош. Тем не менее, какими методами можно завести этот запрос, если убрать очевидное решение с созданием большой денормализованной таблицы?

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

Привет! Я правильно понимаю, что возможности указывать query_id при использовании jdbc вообще нет?

Хочется отслеживать ход выполнения запроса из приложения. Никто не сталкивался с таким?

Тут два пути, если по HTTP то можно принимать хедеры прогресса. Другой путь использовать system.queries

и запрашивать информацию по запросу

или не system.queries... хм

или не system.queries... хм

system.processes, наверное

да

верно

по параметрам total_rows_approx / read_rows. Поправьте если не прав

по параметрам total_rows_approx / read_rows. Поправьте если не прав

Да. Только проблема в задании query_id. Можно, конечно, отслеживать параметр "query".

если по HTTP то query_id можно указать

если по HTTP то query_id можно указать

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

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

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

jdbc драйвер

Подскажите в логах ошибка <Error> history_ctp_avg.Distributed.DirectoryMonitor: Code: 53, e.displayText() = DB::Exception: Received from 1111.211.211.11:9000. DB::Exception: Type mismatch for column shame_level. Column has type UInt32, got type UInt8. Stack trace: Как я понял из истории чата ( похожий пример ) - это когда-то я ошибочно вставил в нее данные, сейчас запись я в эту таблицу вообще остановил - ошибки продолжают сыпаться. Решение: пересоздать таблицу через временную таблицу ?

Можно удалить лишь некоторые файлы из data-директории таблицы. Посмотрите - там лежат файлы .bin, и по их содержимому, наверное, легко определить, находятся ли там данные с неправильной структурой.

Можно удалить лишь некоторые файлы из data-директории таблицы. Посмотрите - там лежат файлы .bin, и по их содержимому, наверное, легко определить, находятся ли там данные с неправильной структурой.

Спасибо,попробую

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

Агрегация устроена так: идём по строкам и кладём всё в хэш-таблицу. Ключи агрегации - ключ хэш-таблицы, а состояния агрегатных функций - значение хэш-таблицы. Параллельная агрегация устроена так: в каждом потоке независимо агрегируем разные части данных. Потом мержим вместе все хэш-таблицы с состояниями в одну. Есть много деталей.

В данный момент я просто from_mark сохраняю в блок - довольно просто. И потом, на основании него выбираю значение при мердже. Для простого случая вроде нормально. Теперь задача для group by протащить как-то этот from_mark в новый блок.

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

В конце из хэш-таблицы создаются блоки результата. В простом случае создаётся один большой блок (когда размер результата маленьких). В остальных случаях создаётся некоторое количество блоков, разбиение на которые определяется хэш-функцией от ключей. А что и как хотелось бы протащить? У тебя есть исходные номера строк, но после агрегации исходных строк уже нет. Можно считать уже агрегатные функции - min(row_number), max(row_number) и т. п.

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

Номеров строк нет. Есть from_mark , который я кладу в блок, который потом сохраняю в данные при addImpl и использую при merge чтобы понимать порядок блоков. Для простого селекта это работает.

А вот когда происходит агрегация, то блоки пересоздаются и я этот from_mark теряю. (это же я и выше написал). Соответственно думаю правильно ли вообще такое протаскивать, и если да, то как.

Т.е. в данный момент функция select lastEx(number) from test, где number - первичный ключ. Оно работает быстрее argMax и результат детерминирован в отличие от anyLast. Но пока без group by.

В конце из хэш-таблицы создаются блоки результата. В простом случае создаётся один большой блок (когда размер результата маленьких). В остальных случаях создаётся некоторое количество блоков, разбиение на которые определяется хэш-функцией от ключей. А что и как хотелось бы протащить? У тебя есть исходные номера строк, но после агрегации исходных строк уже нет. Можно считать уже агрегатные функции - min(row_number), max(row_number) и т. п.

Получается надо в агрегацию включать данные о строках - не очень просто и удобно. Да и вообще кажется что строки после агрегации не нужны же.

А вот когда происходит агрегация, то блоки пересоздаются и я этот from_mark теряю. (это же я и выше написал). Соответственно думаю правильно ли вообще такое протаскивать, и если да, то как.

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

доброе утро всем а вот если я создаю Distirubted DDL CREATE TABLE IF NOT EXISTS ... ON CLUSTER а через неделю подключаю в нее новую ноду в существующий шард, таблица на новой ноде будет создана автоматически?

Нет, на новой ноде нужно будет вручную добавлять таблицу

Можно так же запросом по кластеру

спасибо

всем привет, подскажите плиз, может ли AggregatingMergeTree содержать обычные колонки, не состоящие в PK, или их надо тоже заворачивать в аггрегат anyState()?

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

Из кода: For columns that are not part of the primary key and which do not have the AggregateFunction type, when merged, the first value is selected.

спасибо! буду глядеть в код в следующий раз

а Content-Encoding: gzip давно поддерживается?

Давно. Если правильно помню - больше года.

у меня у юзеров стоит, к примеру, 1.1.54190

пардон, забыл про git tag, вопрос снят

Добрый день. А как в CH вытаскивать кол-во строк селекта, несмотря на лимит? т.е. делать то, что в mysql позволяет постраничную навигацию делать. Пример на MySQL: SELECT SQL_CALC_FOUND_ROWS name FROM countries LIMIT 10,20; а затем для получения кол-ва ещё запрос SELECT FOUND_ROWS()

ща придумал count() использовать, но, может, что-то проще есть?

ERROR: S client not available

Есть такая возможность

На счет именно клиента не знаю, но через http интерфейс есть такая возможность

Я точно не помню какой параметр в ответе по http, но он там есть 100%

На счет jdbc драйвера не могу сказать

спасибо, Александр, поищу. выше я не прав был, если чо) LIMIT OFFSET, SIZE, так что всё ок) 20 строчек и должно было быть

Всем привет. Подскажите. плиз, а как работать с temp таблицами, используя http интерфейс?

что-то в документации ничего похожего не вижу

несколько заросов через ; как я понимаю нельзя(ошибка Multi-statements are not allowed)

А если подряд выполнять тогда ошибка "There is no session"

Всем привет. Подскажите. плиз, а как работать с temp таблицами, используя http интерфейс?

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

пример можно посмотреть в http клиенте от the-tinerbox или smi2

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

А что значит файл с описанием структуры? У меня примерно такая задача create temporary table tmp as select очень большой и сложный селект а потом сделать из нее несколько селектов

Через консольный клиент все работает. А через http - не понимаю. как выполнить все запросы в рамках одной сессии

В доке smi2 про это ни слова нет. В доке clickhouse нашел след фразу: Аналогично можно использовать ClickHouse-сессии в HTTP-протоколе, для этого необходимо указывать HTTP-праметр session_id. Не уверен, что это оно. Сейчас попробую в него какую-нибудь чушь передать )

Не прокатило Code: 115, e.displayText() = DB::Exception: Unknown setting session_id, e.what() = DB::Exception

Похоже причина в версии кх. Попробуем завтра обновить

После добавление в smi2 конфиг 'settings' => ['session_id' =>Helper::getUuid4()] Все заработало. Было бы круто, если бы кто-нибудь это добавил в доку(как кликхауса, так и smi2)

Вопрос, а нужно ли эти сессии как-то убивать? Или они сами через какой-то timeout умрут?

Вопрос, а нужно ли эти сессии как-то убивать? Или они сами через какой-то timeout умрут?

Сами, по-умолчанию таймаут 60 секунд. Таймаут можно изменить параметром session_timeout до некоторого максимального значения, определённого в конфиге.

И uuid4 в значении - ок?

Да. Можно использовать любую строку.

Отлично. Спасибо!

Еще вопрос, а функции которая возвращает номер недели как я понимаю нет? А то получается вот такая странная конструкция:)) case 2: // Month $whereForTop[] = "toMonth(`date`) = toMonth(now())"; break; case 3: // Week $whereForTop[] = "`date` >= toDate(now())-(toDayOfWeek(toDate(now()))-1) ";

Есть функция toMonday - округлить до понедельника. Она так называется, потому что есть страны, где неделя начинается в другой день.

Кстати, а как лучше будет: toMonth(`date`) = toMonth(now()) или date >=toStartOfMonth(now()) или оптимизатору все-равно?

Хотя, первый вариант все-равно косячный. Если года разные.

сорри

Да, пишите toStartOfMonth.

Спасибо. Передаем на toMonday\toStartOfMonth. :)

Оптимизатору должно быть всё равно, мы добавляли такую функциональность. Но на всякий случай проверьте, обрабатывают ли оба запроса одинаковое количество строк - это пишет clickhouse-client.