это https://clickhouse.yandex/docs/ru/table_engines/custom_partitioning_key.html ?

Благодарю, оно самое!

поймали! При вставке в Replicated через Distributed, настройка кворума игнорируется. @orantius , коль скоро вы только что показались в чате :) Это by design?

Это, скорее, некоторая недоделка. Настройки не сохраняются, так как это не очень удобно: при асинхронной вставке надо дописывать их к данным куска или еще куда-то. При синхронной вставке тоже не сделано по аналогии, но должно быть проще добавить.

Приветствую, при попытке подключить внешний словарь через MySQL получаю ошибку: <Error> ExternalDictionaries: Cannot create external dictionary 'ad_networks' from config path /etc/clickhouse-server/ad_networks_dictionary.xml: Code: 62, e.displayText() = DB::Exception: Empty query, e.what() = DB::Exception, Stack trace: 0. clickhouse-server(StackTrace::StackTrace()+0x16) [0x3876e86] 1. clickhouse-server(DB::Exception::Exception(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, int)+0x1f) [0x1354c8f] 2. clickhouse-server(DB::parseQuery(DB::IParser&, char const*, char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)+0x8b) [0x34869db] 3. clickhouse-server(DB::DataTypeFactory::get(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) const+0x58) [0x286e9c8] 4. clickhouse-server(DB::DictionaryStructure::getAttributes(Poco::Util::AbstractConfiguration const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, bool, bool)+0x7e0) [0x2db3310] ..... подключение к серверу я проверил, доступ тоже проверил часть конфига словаря <dictionaries> <dictionary> <name>ad_networks</name> <source> <mysql> <host>mysql.lan</host> <port>3306</port> <user>clickhouse</user> <password>***********</password> <db>api-stat/db> <table>ad_networks</table> </mysql> </source>

а можно еще 2-ю часть? :)

вторую это аттрибуты и прочее?

да

https://pastebin.com/8r9nYv6k

нашел: <attribute> <name>media_source</name> String <type /> <null_value></null_value>

мда, форматтер у меня не крякнул на это, сорян не доглядел ?

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

коллеги, помогите мне в понимании: есть таблица collapsingmergetree и у этой таблицы есть признак sign. Этот признак у старых записей должен становится в -1. Собсвтенно вопрос в том, как это можно сделать не имея update?

Со старой записью ничего не должно становиться. Смысл CollapsingMergeTree, насколько я понимаю, в том, что, если вы хотите "как бы удалить" старую запись, вы вставляете 2 новые: 1. Одну точно такую же, как старая, но с sign=-1 2. Вторую - с новыми значениями и уже с sign = 1. Важно понимать, что "удаление" не гарантируется. Вы должны строить запросы на выборку рассчитывая на то, что в таблице будут присутствовать все 3 записи

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

Вопрос есть интересный партицирование работает только на mergetree?

Вот такая конструкция не работает не пойму почему

CREATE TABLE graphite ( \ Path String, \ Value Float64, \ Time UInt32, \ Date Date, \ Timestamp UInt32 \ ) ENGINE = GraphiteMergeTree(Date, (Path, Time), 8192, 'graphite_rollup') PARTITION BY toMonday(Date);

вы пишите или по старому стилю, или по новому. https://clickhouse.yandex/docs/ru/table_engines/custom_partitioning_key.html

эммм

а чем стили отличаются ?

Я вот поглядел сюда https://github.com/yandex/ClickHouse/blob/master/dbms/tests/queries/0_stateless/00502_custom_partitioning_local.sql#L29

взял пример с партицированием недели

и добавил кусок partition by к нужной мне таблице

при этом без partition by добавление таблицы работает

для таблицы в этом примере движок объявлен как ENGINE = MergeTree PARTITION BY toMonday(d) ORDER BY x;

все обычные merge tree параметры пропали из MergeTree() и переехали в partition by order by

в вашем случае нужно что-то вроде GraphiteMergeTree('graphite_rollup') PARTITION BY toMonday(Date) order by (Path, Time);

аааа

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

привет, олег.

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

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

Привет всем! Кто подскажет. Пришлось вывести сервер из кластера КХ . При заведении создаю реплицируемые таблицы и говрит, что реплика уже есть: Code: 253. DB::Exception: Received from localhost:9000, 127.0.0.1. DB::Exception: Replica /clickhouse/tables/01/graphite_tree/replicas/r1 already exists..

добавлю как 4я реплика, как удалить старую r1 ?

нужно удалить данные о реплике в зукипере. Это делается автоматом если на старой реплике запустить drop database или drop table, там где есть реплицируемые таблицы

Иначе нужно добавлять новую реплику с другим номером

Спасибо за скорый отклик! я добавил, старой реплики нет уже, как почистить зукипер, кроме [zk: localhost:2181(CONNECTED) 9] delete /clickhouse/tables/01/graphite/replicas/r1/ ?

Тут не подскажу... Зукипер обходил стороной. На вид вот так, как вы написали

ок, все равно спасибо

Именно так и чистить. На тестовом кластере извращался. Правда, чистил через гуй zooinspector

Можно не создавать таблицы, а подложить их в metadata с рестарт ом. Возможно, прокатит attach table. Тогда насчёт создаваться не будет, CH посчитает, что просто данные пропали и парой манипуляций все сольется.

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

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

Если вдруг поможет, находил тулзу питонячью, которая работает на порядок быстрее штатной zkCli.sh Кажется, что вот этот https://github.com/rgs1/zk_shell

ок, спасибо, я уже из баша все почистил, но сохраню

коллеги, подскажите, отчего такое может быть: 1. размер партиции вырос с 350 гиг до 480 гиг минут за двадцать 2. потом минут 15 находилось в этом состоянии 3. потом где-то за минуту размер обратно вернулся до 350 гиг с чем это может быть связано?

мердж?

т.е. минут 20 писались "сырые" данные, а потом дело дошло до мёржа?

А что вас удивляет?

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

Кол-во партов была одинаково?

в контексте MergeTree — что за сырые данные, куда они пишутся, и с чем потом мёржатся?

Кол-во партов была одинаково?

да, это всё коснулось партиции текущего месяца, которая постоянно пополняется

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

смотреть в system.merges

и system.parts

ясно. спасибо!

а отчего КХ может настолько долго (20 минут) не мёржить? данных вроде прилично, по графикам за прошлое время подобных "лагов" не наблюдается и, самое главное, как подобные "лаги" уменьшить?

а отчего КХ может настолько долго (20 минут) не мёржить? данных вроде прилично, по графикам за прошлое время подобных "лагов" не наблюдается и, самое главное, как подобные "лаги" уменьшить?

В настройках merge tree можно задать таймаут, вроде бы

Время выбирается произвольно. На сколько знаю - ускорить для MergeTree нельзя. Можно повлиять только установкой кол-во одновременных слияний. Тогда, вероятно, будет чаще запускаться склеивание

И чем плохи эти лаги? Если не критично место

вот сейчас как раз место критично :О) ну и как-то это неожиданно довольно случилось

ну тут ... тогда если есть возможность часть партов deattach -> attach на другой ноде Включить другой вид сжатия (но тогда места может не хватить, пока идет пересохранение)

ага. попробуем. спасибо!

Если данные однородные, и хорошо сжимаются - то можно увеличить размер кусков

тоже попробуем

Добрый день. Для вставки в таблицу используется clickhouse-driver под python. В случае если сервер clickhouse выбрасывает ошибку, то драйвер вызывает исключение. Если сервер не выбросил ошибки, то с точки зрения драйвера вставка произошла успешно. Так же попробовал http интерфес через curl, при успешной вставке возвращается 200 код ответа без дополнительной информации. Т.е. вставку можно считать успешной. 1. Выбираем из постоянного хранилища все записи, которые не были синхронизированы в CH. 2. Производим операцию вставки в CH в Buffered таблицу, которая пишет в ReplictedMergeTree пачками по 50К строк. Размер строки около 250-300 байт. Если произошло исключение, то пробуем еще несколько раз. 3. Если исключения не произошло, то в основном хранилище помечаем записи как синхронизированные. Проблема: в постоянном хранилище элементы были отмечены как синхронизированные, т.е. явных ошибок между драйвером и CH не произошло, при этом эти записи отсутствуют в CH. Текущая версия CH v1.1.54327-stable Первый раз заметили проблему в ноябре, затем обновили сервер до 1.1.54327 от 2017-12-21 в котором была исправлена такая проблема. Есть ли какой-то способ или опция, которая отдает дополнительный признак успешности операции? Или после вставки делать select в CH и проверять успешность?

в логах отсутствует from own log doesn't

Привет. Накопилось у одной таблички 300 сегментов, которые мёржатся медленнее чем появляются новые. Но INSERT-ы не более частые, чем раньше, просто непонятно что случилось. Есть мнение что если бы они смёржились то дальше было бы всё хорошо. Можно ли как-то форсировать мёрджинг?

Привет. Накопилось у одной таблички 300 сегментов, которые мёржатся медленнее чем появляются новые. Но INSERT-ы не более частые, чем раньше, просто непонятно что случилось. Есть мнение что если бы они смёржились то дальше было бы всё хорошо. Можно ли как-то форсировать мёрджинг?

Можно. optimize table partition '201701' например ну или смотря какой ключ партиционирования. Можно еще final конечно прописать, но мне не приходилось с final запускать optimize table.

Но, optimize table не выполнит все мержи на 100% :) Т.е. такой optimize возможно потребуется запускать 10-100 раз и т.д.

Привет. Накопилось у одной таблички 300 сегментов, которые мёржатся медленнее чем появляются новые. Но INSERT-ы не более частые, чем раньше, просто непонятно что случилось. Есть мнение что если бы они смёржились то дальше было бы всё хорошо. Можно ли как-то форсировать мёрджинг?

Версия клика последняя?

У нас такое было часто, после какого из релизов, все прошло само собой

а в КХ есть способ посмотреть сколько физического места занимают данные и индексы?

du -sh /var/lib/clickhouse ?

system.parts

SELECT database, table, formatReadableSize(sum(bytes)) AS size FROM system.parts WHERE active GROUP BY database, table ORDER BY database ASC, table ASC

У нас такое было часто, после какого из релизов, все прошло само собой

Нет, не последний.

Нет, не последний.

Случайно после рестарта сервиса - мержды не запускаются с нормальной скоростью?

Случайно после рестарта сервиса - мержды не запускаются с нормальной скоростью?

Не пробовали. Поудаляли какие-то лишние materialized view, сделали optimize table - всё прошло. От чего прошло точно супердостоверно непонятно.

SELECT database, table, formatReadableSize(sum(bytes)) AS size FROM system.parts WHERE active GROUP BY database, table ORDER BY database ASC, table ASC

спасибо

@milovidov_an, а есть у вас презенташка про устройство экзекутора? ато я читаю http://db.cs.cmu.edu/papers/2017/p1-menon.pdf и интересно как у вас сделано

Добрый день. Для вставки в таблицу используется clickhouse-driver под python. В случае если сервер clickhouse выбрасывает ошибку, то драйвер вызывает исключение. Если сервер не выбросил ошибки, то с точки зрения драйвера вставка произошла успешно. Так же попробовал http интерфес через curl, при успешной вставке возвращается 200 код ответа без дополнительной информации. Т.е. вставку можно считать успешной. 1. Выбираем из постоянного хранилища все записи, которые не были синхронизированы в CH. 2. Производим операцию вставки в CH в Buffered таблицу, которая пишет в ReplictedMergeTree пачками по 50К строк. Размер строки около 250-300 байт. Если произошло исключение, то пробуем еще несколько раз. 3. Если исключения не произошло, то в основном хранилище помечаем записи как синхронизированные. Проблема: в постоянном хранилище элементы были отмечены как синхронизированные, т.е. явных ошибок между драйвером и CH не произошло, при этом эти записи отсутствуют в CH. Текущая версия CH v1.1.54327-stable Первый раз заметили проблему в ноябре, затем обновили сервер до 1.1.54327 от 2017-12-21 в котором была исправлена такая проблема. Есть ли какой-то способ или опция, которая отдает дополнительный признак успешности операции? Или после вставки делать select в CH и проверять успешность?

Если вставка производится в Distributed таблицу, то может случиться так, что insert успешен, но данные не доехали до всех нод. В этом случае они скапливаются в локальной директории Distributed таблицы (хотя, теряться не должны. куски переотправляются в отдельном потоке пока не отправятся). Можно включить опцию insert_distributed_sync=1, тогда вставка будет происходить синхронно (кидать исключение на первой ошибке). Правда, настройка еще не очень хорошо протестирована, стоит пользоваться с осторожностью.

Если вставка производится в Distributed таблицу, то может случиться так, что insert успешен, но данные не доехали до всех нод. В этом случае они скапливаются в локальной директории Distributed таблицы (хотя, теряться не должны. куски переотправляются в отдельном потоке пока не отправятся). Можно включить опцию insert_distributed_sync=1, тогда вставка будет происходить синхронно (кидать исключение на первой ошибке). Правда, настройка еще не очень хорошо протестирована, стоит пользоваться с осторожностью.

нет, вставка производится в Buffered

Коллеги, привет. Увидел в логе вот такое: 2018.01.26 14:20:01.490193 [ 20 ] <Debug> SrcData.TTStatBase (ReplicatedMergeTreeQueue): Not executing log entry for part 201801_18422_18445_2 because its size (2.26 GiB) is greater than current maximum (391.92 MiB). Такого - много. Есть ли тут что-то страшное? Начинать бояться и копать глубже?

Коллеги, привет. Увидел в логе вот такое: 2018.01.26 14:20:01.490193 [ 20 ] <Debug> SrcData.TTStatBase (ReplicatedMergeTreeQueue): Not executing log entry for part 201801_18422_18445_2 because its size (2.26 GiB) is greater than current maximum (391.92 MiB). Такого - много. Есть ли тут что-то страшное? Начинать бояться и копать глубже?

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

максимальный размер итогового куска после мержа ограничивается числом в диапазоне [max_bytes_to_merge_at_min_space_in_pool, max_bytes_to_merge_at_max_space_in_pool] в зависимости от загруженности пула потоков. Если кусков станет слишком много, можно увеличить max_bytes_to_merge_at_max_space_in_pool

Привет. Пытаюсь выбрать поля таблицы, дочерние по отношению к хотя бы одному элементу из переданного массива полей в словаре. Колонка в таблице - с индексом. arrayExists(x -> dictIsIn(...)=1) и всякое подобное (has(arrayConcat(...), искомое_поле), например) индексом, судя по всему, не пользуются. Подскажите, есть ли какой-то способ отфильтровать нужные поля без FullScan'а?

Подскажите, а можно версию ClickHouse запросом посмотреть?

Подскажите, а можно версию ClickHouse запросом посмотреть?

select version()

select version()

сеньк

Привет. Пытаюсь выбрать поля таблицы, дочерние по отношению к хотя бы одному элементу из переданного массива полей в словаре. Колонка в таблице - с индексом. arrayExists(x -> dictIsIn(...)=1) и всякое подобное (has(arrayConcat(...), искомое_поле), например) индексом, судя по всему, не пользуются. Подскажите, есть ли какой-то способ отфильтровать нужные поля без FullScan'а?

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