а почему мне казалось что можно только по месяцам....

а почему мне казалось что можно только по месяцам....

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

воу воу, насколько недавно? ) это же очень хорошая новость

Ребят, а можно только словать отобразить в таблицу, без создания отдельной БД?

можно. нужно создать таблицу с движком Dictionary у Dictionary параметр - имя словаря. Нужно только правильно угадать сигнатуру столбцов. Если не угадали, то подскажет сообщение об ошибке.

например, create table x () engine = Dictionary(my_dict) а в скобочки вставить то, что выведет сообщение об ошибке

например, create table x () engine = Dictionary(my_dict) а в скобочки вставить то, что выведет сообщение об ошибке

Ага, спасибо большое!

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

Точно. Я еще не читал :) Релиз ClickHouse 1.1.54310, 2017-11-01 Новые возможности: Произвольный ключ партиционирования для таблиц семейства MergeTree.

Привет. Подскажите, пожалуйста, по вьюшкам: хочу изменить запрос для MAT VIEW, без изменения типов или количества полей (просто чуть поменяется запрос). Можно ли сделать это вручную, отредактировав sql в /metadata/ ? А если вьюшка - реплицируемая - нужно отключать и редактировать одновременно на всех репликах шарда?

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

например, create table x () engine = Dictionary(my_dict) а в скобочки вставить то, что выведет сообщение об ошибке

А как то айдишник вытащить в таблицу можно? внутрь скобок я так понимаю можно указывать только из attributes

а где почитать про настройку произвольного партицирования?

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

А с репликацией тоже все будет ок?

А как то айдишник вытащить в таблицу можно? внутрь скобок я так понимаю можно указывать только из attributes

id тоже должно быть можно

А с репликацией тоже все будет ок?

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

Логично. Значит, с репликацией - только с одновременным отключением.

id тоже должно быть можно

прямо пишете пустые скобки () вместо сигнатуры, и в ошибке будет правильный вариант

@kochetovnicolai , есть ли в планах подфиксить багу, когда вместо count() с результатом 0 возвращается пустое множество строк?

Или в этом есть какая-то логика?

Алексей обещал на прошлом митапе

А это в ближайших планах или при случае ?

нет. это сложно и не очень скоро

Всем привет, подскажите, пожалуйста, по такому вопросу: есть сервер 12 потоков и 256 озу , я делаю два запроса --max_threads=12 1 rows in set. Elapsed: 1.539 sec. Processed 155.42 million rows, 10.26 GB (100.97 million rows/s., 6.66 GB/s.) --max_threads=6 1 rows in set. Elapsed: 1.792 sec. Processed 155.42 million rows, 10.26 GB (86.74 million rows/s., 5.73 GB/s.) почему такое несущественное различие?

А что при этом с дисками происходит?

Это среднее время?

Всем привет, подскажите, пожалуйста, по такому вопросу: есть сервер 12 потоков и 256 озу , я делаю два запроса --max_threads=12 1 rows in set. Elapsed: 1.539 sec. Processed 155.42 million rows, 10.26 GB (100.97 million rows/s., 6.66 GB/s.) --max_threads=6 1 rows in set. Elapsed: 1.792 sec. Processed 155.42 million rows, 10.26 GB (86.74 million rows/s., 5.73 GB/s.) почему такое несущественное различие?

а HT включен?

нет, это не среднее время

диски посмотрю

а HT включен?

а что такое HT?

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

Там же не запрос реплицируется, а данные таблицы .inner.name_of_the_view, там самая проблема в том, что после изменения запроса в файле нужно ребут сервера КХ делать чтоб файлик перечитать

а что такое HT?

Hyper-threading. Когда физических ядер у вас 6, а не 12.

Hyper-threading. Когда физических ядер у вас 6, а не 12.

должен быть включен, я его не трогал

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

@milovidov_an @kochetovnicolai вопрос "идеологического" характера. Нужно дать доступ на работу с временными таблицами для readonly, очень не хочется для этого делать readonly=3 и т.д., а хочется использовать для этого SecurityManager и добавить галочку на уровне profiles.readonly что-то вроде <readonly> <readonly>1</readonly> <hasAccessToTemporaryTable/> </readonly> это было бы ОК?

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

А есть какая-то документация на это? Как данные будут биться на партиции?

Есть

В гите

/doc/

Вот пример из тестов https://github.com/yandex/ClickHouse/blob/master/dbms/tests/queries/0_stateless/00502_custom_partitioning_local.sql

А что при этом с дисками происходит?

во время выполнения запросов чтения с диска не происходит

Там же не запрос реплицируется, а данные таблицы .inner.name_of_the_view, там самая проблема в том, что после изменения запроса в файле нужно ребут сервера КХ делать чтоб файлик перечитать

да, звучит логично. перезагрузить точно надо. но я бы всё-таки проверил на тестовых данных

Ребят, напомните плз, что означает injective у словарей. Формулировку из доки не понял =\

Ребят, напомните плз, что означает injective у словарей. Формулировку из доки не понял =\

в английской документации написано подробнее: https://clickhouse.yandex/docs/en/dicts/external_dicts.html#notes

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

Ни у кого не было такой ошибки? Похоже, у нас из-за неё сервер кликхауса падает. 2017.12.17 13:58:11.859618 [ 17 ] <Error> void DB::BackgroundProcessingPool::threadFunction(): Code: 84, e.displayText() = DB::Exception: Directory /var/clickhouse//data/default/nds_docs/19700101_19700101_6700774_6820814_1 already exists, e.what() = DB::Exception, Stack trace: 0. /lib/libclickhouse.so.1(StackTrace::StackTrace()+0x16) [0x7fe471b850f6] 1. clickhouse-server(DB::Exception::Exception(std::string const&, int)+0x26) [0x4b8386] 2. /lib/libclickhouse.so.1(DB::MergeTreeDataMerger::mergePartsToTemporaryPart(std::vector<std::shared_ptr<DB::MergeTreeDataPart const>, std::allocator<std::shared_ptr<DB::MergeTreeDataPart const> > >&, std::string const&, DB::MergeListEntry&, unsigned long, long, DB::DiskSpaceMonitor::Reservation*)+0x4c96) [0x7fe471cd5aa6] 3. /lib/libclickhouse.so.1(DB::StorageMergeTree::merge(unsigned long, bool, std::string const&, bool)+0x7f6) [0x7fe471c42036] 4. /lib/libclickhouse.so.1(DB::StorageMergeTree::mergeTask()+0xff) [0x7fe471c4275f] 5. /lib/libclickhouse.so.1(DB::BackgroundProcessingPool::threadFunction()+0x3f3) [0x7fe471ca46b3] 6. clickhouse-server() [0x5df02f] 7. /lib64/libpthread.so.0(+0x7dc5) [0x7fe46c12ddc5] 8. /lib64/libc.so.6(clone+0x6d) [0x7fe46b74c76d]

у вас почему то в пути два слэша после clickhouse /var/clickhouse//data/default/nds_docs/19700101_19700101_6700774_6820814_1 может что то с каким-то конфигом - лишний слеш?

Вообще, разве что комментарий в конфиге не корректный и закрывающий слеш не нужен <!— Path to data directory, with trailing slash. —> <path>/var/clickhouse/</path>

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

Ребят, напомните плз, что означает injective у словарей. Формулировку из доки не понял =\

Из англ. документации: An attribute is called injective if different attribute values correspond to different keys. So when GROUP BY uses a function that fetches an attribute value by the key, this function is automatically taken out of GROUP BY.

Инъективность - означает что разным значениям ключа ОБЯЗАТЕЛЬНО соответствуют РАЗНЫЕ значения аттрибута. Т.е. например словарь номер пользователя - фамилия пользователя НЕ инъективный, т.к. 2 разных пользователя могут иметь ту же фамилию. А словарь где каждому браузеру назначен уникальный номер - должен быть инъективным, и 2 разных номера обязательно означают 2 разных браузера. Если <injective> включено - кликхаус будет сначала группировать по ключу словаря, и только потом воспользуется словарем. Если выключено - то сначала словарь, а потом группировка.

Формальное описание: https://ru.wikipedia.org/wiki/%D0%98%D0%BD%D1%8A%D0%B5%D0%BA%D1%86%D0%B8%D1%8F_(%D0%BC%D0%B0%D1%82%D0%B5%D0%BC%D0%B0%D1%82%D0%B8%D0%BA%D0%B0)

А альтер реплицируемой таблицы как себя ведет вообще?

У меня нода начала жрать 100% памяти при этом логе валит постоянно https://img.facedsid.ru/4mygt.jpg

Зукипер жив

Инъективность - означает что разным значениям ключа ОБЯЗАТЕЛЬНО соответствуют РАЗНЫЕ значения аттрибута. Т.е. например словарь номер пользователя - фамилия пользователя НЕ инъективный, т.к. 2 разных пользователя могут иметь ту же фамилию. А словарь где каждому браузеру назначен уникальный номер - должен быть инъективным, и 2 разных номера обязательно означают 2 разных браузера. Если <injective> включено - кликхаус будет сначала группировать по ключу словаря, и только потом воспользуется словарем. Если выключено - то сначала словарь, а потом группировка.

Спасибо за подробный ответ. Теперь полностью понятно. А нет ли жизненных примеров применения? Просто не приходит на ум. Ведь получается, если каждая строка имеет свою собственную строку в словаре, то смысл словаря только в изменяемости(за счёт источника)

ClickHouse client version 1.1.54318. Connecting to localhost:9000. Code: 210. DB::NetException: Connection refused: (localhost:9000, ::1)

Но при этом в error.log постоянно валятся варнинги. Processlist пустой абсолютно.

При этом нагрузка на проц ~0%, а вот память он жрет без остановки. Как и что можно дампнуть что бы разобраться?

Спасибо за подробный ответ. Теперь полностью понятно. А нет ли жизненных примеров применения? Просто не приходит на ум. Ведь получается, если каждая строка имеет свою собственную строку в словаре, то смысл словаря только в изменяемости(за счёт источника)

Главный смысл словаря очень часто просто в том, чтоб вместо относительно длинной строки хранить в базе небольшое число, которое однозначно соответствует той строке. Оно и места меньше занимает, и жмется (обычно) лучше и фильтрование / группирование по числовым колонкам можно значительно эффективнее делать. Ну и вообще с числовыми значениями комьютеры лучше "дружат" чем со строковыми, да и куча эффективных алгоритмов для числовых значений придумана.

Главный смысл словаря очень часто просто в том, чтоб вместо относительно длинной строки хранить в базе небольшое число, которое однозначно соответствует той строке. Оно и места меньше занимает, и жмется (обычно) лучше и фильтрование / группирование по числовым колонкам можно значительно эффективнее делать. Ну и вообще с числовыми значениями комьютеры лучше "дружат" чем со строковыми, да и куча эффективных алгоритмов для числовых значений придумана.

Я просто думаю. Ведь это просто вынос куска данных наружу. Чтобы оно хранилось "гдетотам" + занимало память. И вот не могу профита понять. Вроде как на митапах даже говорили что если данные сильно разные, то смысла нет их выносить, а лучше хранить как есть. Вроде про User-Agent речь шла тогда.

Ну и разумеется изменяемость. Скажем у вас есть клиент ООО "Рога и копыта", если его закодировать как UInt16 (выходя из предположения что у вам не больше 65 тыс клиентов), то вместо ~ 30 байт (столько занимает эта строка в UTF) будет всего 2 байта. Ну и если в один прекрасный день фирма скажем именит название, или форму собственности, то достаточно будет обновить словарь, а в данных остаётся старый номер.

AST is too big ктото говорил что clickhouse может большие запросы прожевывать

Нашел откуда ноги растут. Фоновый мерж жрет просто сотни гигов памяти. Прогресс висит на месте и ничего не происходит.

AST is too big ктото говорил что clickhouse может большие запросы прожевывать

Ну всё зависит от того как постараться :) Попробуйте подкрутить max_ast_elements

Есть возможность как то остановить фоновый мерж?

Нашел откуда ноги растут. Фоновый мерж жрет просто сотни гигов памяти. Прогресс висит на месте и ничего не происходит.

Ну видимо огромные куски мерджит. Иногда это много времени занимает. Давно висит?

Ну видимо огромные куски мерджит. Иногда это много времени занимает. Давно висит?

Оно может два часа висеть и прогресс с места не двигается

В таблице много нестед колонок

И у некоторых нестед колонок жирно значений написано...

там десятки тысяч значений

и таблица replacing merge tree :)

Реплицируется + ко всему я запустил там optimize table ... partition ... и у меня лег весь кластер

Т.к. мерж пошел по всему кластеру

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

Ну и если есть какие-то естественные периоды простоя сервера (ночь, например) то можно добавить OPTIMIZE в крон чтоб в это время сервер занимался полезным делом, а не во время "часов пик".

Я просто думаю. Ведь это просто вынос куска данных наружу. Чтобы оно хранилось "гдетотам" + занимало память. И вот не могу профита понять. Вроде как на митапах даже говорили что если данные сильно разные, то смысла нет их выносить, а лучше хранить как есть. Вроде про User-Agent речь шла тогда.

А вы представьте себе что у вас есть 100 миллионов строк. И есть строковая колонка в которой хранится одна из 1000 варантов строк, каждая длиной в 12 знаков. Если хранить это как строку. То потребуется 100 миллионов * 12 байт = 1.2 Гб. А если добавить словарь с 2 байтовым ключом, то 1000 строк в словаре = 1000 * ( 12 (длина строки) + 2 (длина ключа) ) = 14000 байт. Ну и вместо строки будем хранить теперь 2 байтовый ключ. Получаем 100 миллионов строк * 2 байта = 200 Мб + 14 Кб которые хранятся "где-то там" и занимают там память :)

А вы представьте себе что у вас есть 100 миллионов строк. И есть строковая колонка в которой хранится одна из 1000 варантов строк, каждая длиной в 12 знаков. Если хранить это как строку. То потребуется 100 миллионов * 12 байт = 1.2 Гб. А если добавить словарь с 2 байтовым ключом, то 1000 строк в словаре = 1000 * ( 12 (длина строки) + 2 (длина ключа) ) = 14000 байт. Ну и вместо строки будем хранить теперь 2 байтовый ключ. Получаем 100 миллионов строк * 2 байта = 200 Мб + 14 Кб которые хранятся "где-то там" и занимают там память :)

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

Неинъективный словарь это когда 2 разным значения ключа соответствует тот же аттрибут.

Например:

1 => Москва

и

3 => Москва

если будем группировать по ключу получится две строки "Москва".

Если будем группировать по значению то получится одна "Москва"

Вы имеете в виду такой пример? Словарь: 1 => Москва 3 => Москва Таблица CH: city_id = 1, некоторые другие колонки city_id = 3, некоторые другие колонки

Mikhail

Ну чтоб был более наглядный пример - тогда уж что-то вроде: Post_code,city_name 119002,Moscow 119019,Moscow 121069,Moscow

Если поставите такому словарю injective = true то при группировке по словарю получите 3 разных москвы (потому что индесы у них разные). А если поставите injective = false - то будет одна москва.

Если поставите такому словарю injective = true то при группировке по словарю получите 3 разных москвы (потому что индесы у них разные). А если поставите injective = false - то будет одна москва.

Огонь, большое спасибо. Понял.

Ну всё зависит от того как постараться :) Попробуйте подкрутить max_ast_elements

это помогло, плюс max_query_size но вот это не могу побороть Unmatched parentheses: ( как будто бы реально часть запроса не доехала, а она есть

Посмотрите в query_log или в логах сервера что доезжает

Посмотрите в query_log или в логах сервера что доезжает

радикльное увеличение max_query_size помогло... а так то конечно опасная штука...

зпрос может оказатсья валидным но неправильным просто из за того что не поместился в буфер ... по хорошему всегда фейлится нужно если это select а не insert

радикльное увеличение max_query_size помогло... а так то конечно опасная штука...

Блин, что ж вы там за селекты такие пишете? :D Длинный список значений в селект передаете или что?

зпрос может оказатсья валидным но неправильным просто из за того что не поместился в буфер ... по хорошему всегда фейлится нужно если это select а не insert

Ну в принципе замечание верное. Добавите issue на гитхабе?

Блин, что ж вы там за селекты такие пишете? :D Длинный список значений в селект передаете или что?

да select in (long id list) ... лень было поиложение переделывыть под работу с множеством... в качестве клиента http а в http с temporaty table беда

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

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

поясни плиз... как в http с сессиямиможно работать?