У нас есть "странный" кейс с партишенами. У нас есть сырые данные и постпроцессинг который агрегирует данные в "отчеты" для пользователей, т.к. вливать данные напрямую долго и пользователи будут видеть разные данные, мы делаем create table tmp_*** as source_table заливаем в нее (или несколько таблиц) данные, делаем DETACH перемещаем файлы и делаем ATTACH в нужной таблице, это не очень удобно т.к. требует чтоб у воркера был доступ к файловой системе, да и вообще тот ещё костыль )

Имеется ввижу возможность сделать MOVE PARTITION между таблицами?

могу предложить воспользоваться нативным python-драйвером, если не нужно ORM: https://github.com/mymarilyn/clickhouse-driver там есть Nullable

спасибо, смотрю.

У нас вообще очень остро сейчас стоит вопрос с обновлением данных и удалением. Удаление не так приоритетно пока есть запас места. А обновление да. Есть у нас например пользователь у которого имеется куча фактов. Эти факты аггрегируются из сырых данных каждый раз когда прилетает новая пачка данных по пользователю. Пересчитываются все факты, т.к. они между собой взаимосвязаны, например в MySQL у нас сейчас есть строка пользователя к которой джойнятся нужные факты и пользователи по ним фильтруются, группируются и пр., но MySQL такая тугая штука, что капец просто...рассматриваем сейчас вариант переезда на постгрес, но хотелось бы аггрегированные данные складывать в КХ и там проводить последующую аггрегацию для построения отчетов

С партициями ограничение - их не должно быть слишком много. Хотя они легче, чем отдельные таблицы, но если партиций много, то будет просаживаться производительность SELECT-ов, затрагивающих большое количество партиций.

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

Например запрос возвращает три колонки (одна из них лишняя) работает за 5мс, а тот же самый запрос только с двумя колонками работает уже 2 секунды...MySQL мать его.

И таких кейсов пруд пруди блин

Доброе утро! Народ, вот хоть убейте! Мы не можим настроить реплицирование с шардированием 2х2. Схему реплик прописали, зукипер прописали, с макросами не понятно. На каждой ноде прописали в config.xml <macros><shard>01</shard><replica>01</replica></macros> с разными цифрами на каждой ноде. Пытаюсь создать таблицу .............. ) ENGINE = ReplicatedSummingMergeTree('/clickhouse/tables/{shard}/normal_summing_sharded', '{replica}', event_date, (event_date, event_time, body_id), 8192); Получаю Received exception from server: Code: 62. DB::Exception: Received from 10.254.122.232:9000. DB::Exception: No macro shard in config. Что не так-то???

В конфиге у нас макрос инклюдится из соседнего файла: <macros incl="macros" /> в итоге в сгенерированном config-preprocessed.xml вижу такое: <macros> <shard>01</shard> <replica>02</replica> </macros> вроде как всё на месте, а ошибка всё равно осталась

10.254.122.232:9000. DB::Exception: No macro shard in config.

С партициями ограничение - их не должно быть слишком много. Хотя они легче, чем отдельные таблицы, но если партиций много, то будет просаживаться производительность SELECT-ов, затрагивающих большое количество партиций.

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

И еще есть вопрос по поводу Nested колонок. Они как то сжимаются? Например нужно собирать статистику по тестированию (вопрос-ответ), у вопроса может быть несколько вариантов ответа и соответсвенно пользователь выбирает 2-3 варианта ответа и я кладу их в nested колоноку, сжатие будет эффективным в таком случае или лучше класть не текстовое представление ответа, а именно идентификатор варианта ответа?

Они сжимаются так же, как обычные поля. То есть, текстовые значения будут сжаты. Но идентификаторы или Enum будут сжаты ещё несколько лучше, а также будут существенно более выгодными по CPU.

Ну я так и думал, что все таки идентификаторы будут лучше. Enum не получится вкрутить, т.к. идентификаторы не UUID :( Идентификаторы по tincan не предусматриваются для вариантов ответа и приходят в чистом текстовом виде, а мы уже перед записью строки в КХ можем присваивать им идентификаторы

Точнее не потому что они не UUID, а список идентификаторов заранее неизвестен )

Понятно.

Имеется ввижу возможность сделать MOVE PARTITION между таблицами?

да, это было бы удобно

Не понимаю, вот я вызвал геофункцию ради теста из примера в доке SELECT DISTINCT regionToName(regionToArea(toUInt32(number), 'ua')) FROM system.numbers LIMIT 15 А мне намекают, Dictionaries was not loaded. You need to check configuration file.. Я так понял, что словари д.б. из Яндекс.Метрики. Они-таки embedded ? следовательно опенсурс? ) Или это нечто экономически сакральное, только для служебного парсинга?

Не понимаю, вот я вызвал геофункцию ради теста из примера в доке SELECT DISTINCT regionToName(regionToArea(toUInt32(number), 'ua')) FROM system.numbers LIMIT 15 А мне намекают, Dictionaries was not loaded. You need to check configuration file.. Я так понял, что словари д.б. из Яндекс.Метрики. Они-таки embedded ? следовательно опенсурс? ) Или это нечто экономически сакральное, только для служебного парсинга?

Это значит, что словарь надо скачать и положить в папочку с конфигом :)

Хотя могу ошибаться )

а не обязательно сперва проходить собеседование? ) —- Геобаза загружается из текстовых файлов. Если вы работаете в Яндексе, то для их создания вы можете воспользоваться инструкцией: https://github.yandex-team.ru/raw/Metrika/ClickHouse_private/master/doc/create_embedded_geobase_dictionaries.txt

а не обязательно сперва проходить собеседование? ) —- Геобаза загружается из текстовых файлов. Если вы работаете в Яндексе, то для их создания вы можете воспользоваться инструкцией: https://github.yandex-team.ru/raw/Metrika/ClickHouse_private/master/doc/create_embedded_geobase_dictionaries.txt

Кажется, обязательно

Кажется, обязательно

печалити

печалити

Так и зарплату дадут :)

И бонусный пакет. Может и место на парковке :)

Узко мыслите :)

Узко мыслите :)

false

false

не хотел задеть (((

ничо. Но оффтопик)

'''Доступ к БД не связан с настройкой readonly. Невозможно дать полный доступ к одной БД и readonly к другой.''' Из документации. Есть ли изменения в сисетме прав доступа, или пока всё так же?

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

А почему не пойдёт просто первичный ключ вида (VideoID, UserID)? Или старые видео хочется удалять потом?

заметил такую штуку: если в поля Date или DateTime вставлять unix timestamp, то вставка существенно замедляется. Примерно так: 100к строк вставляется за 0.5 сек, если указаны нормальные даты ('2017-08-18'), и 5 секунд. если timestamp (1503063892). Разница в 10 раз. Это нормально? У нас во всех сислогах timestamp'ы, а сишники не чешутся, мне грустно...

заметил такую штуку: если в поля Date или DateTime вставлять unix timestamp, то вставка существенно замедляется. Примерно так: 100к строк вставляется за 0.5 сек, если указаны нормальные даты ('2017-08-18'), и 5 секунд. если timestamp (1503063892). Разница в 10 раз. Это нормально? У нас во всех сислогах timestamp'ы, а сишники не чешутся, мне грустно...

проще в скриптах и коде конвертировать

или перейти на native формат

да, я и говорю, сишники не хотят чесаться и конвертировать :)

в native это вроде unixts (или что-то близкое) и дни с 1970 года соответственно

да, я и говорю, сишники не хотят чесаться и конвертировать :)

кто пишет в базу тот и конвертирует :P

можно в крайнем случаи за них сделать код конвертации и им просто его отдать )

вот это выход)))

Да, в native дата int16(дни от 1970), дататайм int32, на Go это выглядит так https://github.com/kshvakov/clickhouse/blob/refactoring/lib/column/datetime.go#L30

в native наши сишники будут полгода переделывать формат заливки, так что тут только переделка timestamp на обычные даты спасет, и заливка в 10 раз ускорится

Здравствуйте. Есть запрос, который выполняется на distributed таблице. SELECT hash1, hash2, sum(month = '2017-05-15') AS cnt_1, sum(month = '2017-06-15') AS cnt_2, minIf(p, month = '2017-05-15') AS p_1, minIf(p, month = '2017-06-15') AS p_2, p_2 - p_1 AS p_diff FROM table_distributed WHERE (month IN ('2017-05-15', '2017-06-15')) AND (hash1 = cityHash64('value')) GROUP BY hash1, hash2 HAVING (cnt_1 > 0) AND (cnt_2 > 0) AND (p_diff < 0) ORDER BY p_diff desc LIMIT 100 Данных в distributed таблице 25kkk, обрабатываемых данных на этот запрос 250kk, из которых получается 10кк. Если выполнять этот запрос на каждом шарде, он выполняется довольно быстро (данные хорошо размазаны), если выполнять на distributed(ключ hash1), запрос выполняется за время (время выполнения на одном шарде * количество шардов * 1.5). Мы посмотрели, что, похоже, кх отправляет все данные, полученные до выполнения HAVING, для последующей агрегации на сервер, с которого выполняется запрос. Отсюда вопрос: можно ли как-то заставить кх полностью выполнить запросы на шардах (включая having), а на сервере, с которого делается запрос, просто смержить результаты и сделать limit?

Здравствуйте. Есть запрос, который выполняется на distributed таблице. SELECT hash1, hash2, sum(month = '2017-05-15') AS cnt_1, sum(month = '2017-06-15') AS cnt_2, minIf(p, month = '2017-05-15') AS p_1, minIf(p, month = '2017-06-15') AS p_2, p_2 - p_1 AS p_diff FROM table_distributed WHERE (month IN ('2017-05-15', '2017-06-15')) AND (hash1 = cityHash64('value')) GROUP BY hash1, hash2 HAVING (cnt_1 > 0) AND (cnt_2 > 0) AND (p_diff < 0) ORDER BY p_diff desc LIMIT 100 Данных в distributed таблице 25kkk, обрабатываемых данных на этот запрос 250kk, из которых получается 10кк. Если выполнять этот запрос на каждом шарде, он выполняется довольно быстро (данные хорошо размазаны), если выполнять на distributed(ключ hash1), запрос выполняется за время (время выполнения на одном шарде * количество шардов * 1.5). Мы посмотрели, что, похоже, кх отправляет все данные, полученные до выполнения HAVING, для последующей агрегации на сервер, с которого выполняется запрос. Отсюда вопрос: можно ли как-то заставить кх полностью выполнить запросы на шардах (включая having), а на сервере, с которого делается запрос, просто смержить результаты и сделать limit?

distributed_group_by_no_merge https://github.com/yandex/ClickHouse/issues/332

Мы батчуем поток эвентов в файлы, потом эти файлы гоним в таблицы. В одну таблицу может быть несколько вставок из одного файла. Чтобы сделать exact-once семантику, хотим делать delete по filename из таблиц при вставке

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

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

5000 в день

distributed_group_by_no_merge https://github.com/yandex/ClickHouse/issues/332

Спасибо большое, но с LIMIT эта штука работает очень странно. Если оборачивать в селект и его лимитировать, то прироста не наблюдается.

5000 в день

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

Всем привет. Вопрос по ключу семлирования. У нас есть огромная табличка, в которой хранятся показы, клики и действия. Сейчас пытаемся решить, как будет правильнее, поставить ключем семплирования хеш от id юзера, хеш от id показа или рандом? В случае id юзера, будет семпл юзеров с полным набором событий. Соответственно, запросы по типу avgPerUser домножать не нужно будет, а uniqUserId - нужно будет. В случае id показа - полные цепочки, от показа до лида. В случае рандома честный семпл, при котором нужно будет домножать все результаты выборок.

а как у вас один и тот же id показа поадает в лог несколько раз, и может ли это быть событиями разных пользователей?

Есть еще вопрос. Подскажите, пожалуйста, если max_concurrent_queries = 5, но приходит одновременно 10 запросов, они становяться в очередь?

а как у вас один и тот же id показа поадает в лог несколько раз, и может ли это быть событиями разных пользователей?

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

Есть еще вопрос. Подскажите, пожалуйста, если max_concurrent_queries = 5, но приходит одновременно 10 запросов, они становяться в очередь?

Да. Это определяется настройкой queue_max_wait_ms (уровня пользователя), по-умолчанию - 5 секунд.

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

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

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

смотря какие запросы вам нужны. если у вас половина людей делает десять событий а вторая половина одно событие то после семплирования 0.1 по рандому вы получите ровным слоем размазанных "однособытийных" людей и потеряете свойства исходного распределения.

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

у нас только 5% юзеров делают кроме показа клик. И менее 1% действия. Запросы в основном такие select slice(может быть date, geo, browser и еще штук 30), sum(IsShow),sum(isClick),sum(isAction) form table group by slice

10.254.122.232:9000. DB::Exception: No macro shard in config.

А ClickHouse перезагружали после изменения макросов?

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

Всем добрый день! Кто-нибудь сталкивался с проблемой, что в системе появляются зомби процессы с именем [sh]. Может быть КХ выполняет какой-то скрипт и что-то не отрабатывает? После рестарта сервиса КХ все такие процессы пропадают. Ошибок в логе КХ нет.

Такой процесс не один появляется, десяток за сутки

Всем добрый день! Кто-нибудь сталкивался с проблемой, что в системе появляются зомби процессы с именем [sh]. Может быть КХ выполняет какой-то скрипт и что-то не отрабатывает? После рестарта сервиса КХ все такие процессы пропадают. Ошибок в логе КХ нет.

У вас словаря из executable источников нет?

Всем добрый день! Кто-нибудь сталкивался с проблемой, что в системе появляются зомби процессы с именем [sh]. Может быть КХ выполняет какой-то скрипт и что-то не отрабатывает? После рестарта сервиса КХ все такие процессы пропадают. Ошибок в логе КХ нет.

была аналогичная проблема

у вас какая версия клика?

мы перешли на HTTP сурс

но по комитам, эта проблема должна была уйти с одним из stable релизов

это из за словарей

это из за словарей

Версия 1.1.54245 да, словари есть /usr/bin/mysql и далее TSV данные через запрос

значит ошибка не ушла с релизом... как вариант, перейдите на источник file, и по крону записывайте данные с мускуля в файлик... С зомби у нас не получилось решить проблему при executable источнике. Там любой запрос создает зомби

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

значит ошибка не ушла с релизом... как вариант, перейдите на источник file, и по крону записывайте данные с мускуля в файлик... С зомби у нас не получилось решить проблему при executable источнике. Там любой запрос создает зомби

Да, похоже что словари спасибо большое

Добавили changelog для недавнего и прошлого релиза https://github.com/yandex/ClickHouse/blob/master/CHANGELOG_RU.md

> Добавлена поддержка неконстантных аргументов и отрицательных смещений в функции substring(str, pos, len) О, я об этом писал, ура

ничего себе! появился WITH!

в справке, правда, не описано, и ждем подвоха, но CTE это пять ?

Нет никаких CTE.

Нет никаких CTE.

Алексей, а нет никакой информации по исправлению ошибок в оптимизаторе? https://github.com/yandex/ClickHouse/issues/859

Привет всем. Вопрос про внешние словари. Возможен ли словарь в виде tab separated файла, где значения (атрибуты) имеют тип Array(Array(UInt32))? В моем случае это массив с массивами типа [[0, 1], [2, 1], [5, 2]]. Из документации следует, что возможно, но на деле получаю экспешпн Cannot parse input.

Добавили changelog для недавнего и прошлого релиза https://github.com/yandex/ClickHouse/blob/master/CHANGELOG_RU.md

Ура! Вот за это прям огромное спасибо!

Вот теперь совсем другое дело . Чувствуется Ваш профессионализм . И вот если бы вы это взяли за практику каждый раз добавлять - то я стал бы самым счастливым человеком . ))

А runningDifference с memory таблицами не работает?

Он всегда 0 возвращает (

Алексей, а нет никакой информации по исправлению ошибок в оптимизаторе? https://github.com/yandex/ClickHouse/issues/859

Пока нет информации. Последние несколько недель не разбирались с этой задачей.

Спасибо за ответ! Буду с нетерпением ждать :) Я думаю, что не один такой )

А runningDifference с memory таблицами не работает?

runningDifference работает в пределах блока. Memory таблица возвращает данные ровно такими блоками, какие были в неё вставлены. Если данные вставлялись по одной строке, то runningDifference всегда будет возвращать ноль.

Да, данные вставлялись по одной строке

Кстати, хороший хак для разделения данных :)

Да, данные вставлялись по одной строке

Можно слить в один блок с помощью INSERT SELECT в другую таблицу с ORDER BY.

Привет всем. Вопрос про внешние словари. Возможен ли словарь в виде tab separated файла, где значения (атрибуты) имеют тип Array(Array(UInt32))? В моем случае это массив с массивами типа [[0, 1], [2, 1], [5, 2]]. Из документации следует, что возможно, но на деле получаю экспешпн Cannot parse input.

Для атрибутов массивов поддерживаются только числовые типы и строки. То есть, даже обычные массивы - нет.

У меня помнится был кейс когда мне надо было в рамках одного запроса делать runningDifference, но если например у строки другой идентификатор объекта, то начинать сначала :) Теперь знаю как это можно обойти )

Привет всем. Вопрос про внешние словари. Возможен ли словарь в виде tab separated файла, где значения (атрибуты) имеют тип Array(Array(UInt32))? В моем случае это массив с массивами типа [[0, 1], [2, 1], [5, 2]]. Из документации следует, что возможно, но на деле получаю экспешпн Cannot parse input.

Тут проблема в том, какие геттеры должны быть для таких словарей. Их итак много. Надо придумать какой-нибуль generic вариант.

У меня помнится был кейс когда мне надо было в рамках одного запроса делать runningDifference, но если например у строки другой идентификатор объекта, то начинать сначала :) Теперь знаю как это можно обойти )

Жаль, что это всего лишь хак. Полноценную реализацию такой функции не так уж сложно сделать, хотя и существенно сложнее, чем runningDifference.

Ну да, я уже говорил о такой функции не раз :( Жаль ничем не могу помочь в этом деле

Тут проблема в том, какие геттеры должны быть для таких словарей. Их итак много. Надо придумать какой-нибуль generic вариант.

Generic вариант с хранением значений в Field - вполне приемлимо.

Еще вопросик по первичному ключу. Влияет ли первичный ключ на скорость выполнения sum? т.е. решаем добавлять ли в первый ключ колонки isShow\isClick для запросов по типу select eventDate,sum(isShow),sum(isClick) from table group by eventDate или это поможет только для запросов типа: select eventDate,Shows,Clicks from ( select eventDate,count() as Shows from table where isShow group by eventDate ) Join ( select eventDate,count() as Clicks from table where isClick group by eventDate ) Using eventDate

Еще вопросик по первичному ключу. Влияет ли первичный ключ на скорость выполнения sum? т.е. решаем добавлять ли в первый ключ колонки isShow\isClick для запросов по типу select eventDate,sum(isShow),sum(isClick) from table group by eventDate или это поможет только для запросов типа: select eventDate,Shows,Clicks from ( select eventDate,count() as Shows from table where isShow group by eventDate ) Join ( select eventDate,count() as Clicks from table where isClick group by eventDate ) Using eventDate

Нет, первичный ключ не влияет на скорость GROUP BY. (Возможно незначительное косвенное влияние.)

А ClickHouse перезагружали после изменения макросов?

да, конечно