да если бы

а если скобочки добавить

CREATE TABLE default.whitelisted ( domain String) ENGINE = Set

not tlds in whitelisted всегда срабатывает, даже если эта строка есть в сете

синтаксически оно работает, а семантически - фиг

a NOT IN ... - функция notIn(a, b)

notIn( tlds, whitelisted) не работает?

она работает, но возвращает всю выборку

Смотрите раздел "Операторы IN".

а где этот раздел вообще?

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

так это нашел, но оно все равно не работает

может баг просто?)

Приветствую! Подскажите, пожалуйста, самостоятельно найти ответа не получилось. Можно ли каким-то способом использовать 2 разных limit-by ? например SELECT day, client, domain, count(*) as count FROM table ARRAY JOIN domain GROUP BY toDate(date) AS day, client, domain ORDER BY day ASC, client ASC, count DESC LIMIT 2 BY day, client LIMIT 10 BY dayт.е. получить в итоге по 10 записей на day, а внутри по 2 записи на day, client. т.е. по 5 уникальным client на день

сейчас скорее нет чем да, хотя есть некоторые кейсы, когда бы это пригодилось.

where not tlds in (select domain from whitelisted) - не работает, говорит, что нет read для set не поддерживается

а tlds это что

сейчас скорее нет чем да, хотя есть некоторые кейсы, когда бы это пригодилось.

Я просто пытаюсь перевести запрос эластика, где вложенные агрегации terms с указанием кастомного size для каждой группировки. В данном случае пока вижу решение только через select * from (select *from(...) limit X by a) limit Y by b Хотя фактически это тоже самое, если бы была возможность просто подряд указать несколько ... GROUP BY ... LIMIT X BY a LIMIT Y BY b

Привет. Люди добрые, подскажите пожалуйста, на сервере 200ГБ оператики, но падает INSERT (Cannot allocate memory). Memory Peak при этом пишет 19GiB. Куда копать?

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

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

в общем, при вставке из stdin не указал клиенту —multiquery

поэтому в сете было аж одно боярское значение :)

а есть способы узнать кардинальность сета?

Есть таблица с полем "dt DateTime DEFAULT now()" и в нее вставляются данные с использованием формата TSKV. При этом, если в запросе явно указывать список полей ("INSERT INTO table (...) FORMAT TSKV") - то выражение DEFAULT now() выполняется, а если не указывать ("INSERT INTO table FORMAT TSKV") - то вместо выражения DEFAULT now() используется значения по-умолчанию для типа DateTime ("0000-00-00 00:00:00"). https://pastebin.com/raw/AcVXDDFL Подскажите, пожалуйста, это ожидаемое поведение? Версия: 1.1.54343

Всем привет. А кто-нибудь замечал катастрофическое падение производительности при работе с вьюхами (нематериализованными)? Есть таблица MergeTree, несколько миллиардов записей, простой запрос вида получить количество строк, min/max по одному полю работает за пару секунд, скорость обработки в районе полутора миллиардов строк в секунду. Вьюха вида create view as select field_list from table выдает 7-8 миллионов стров в секунду

А запрос во вьюху идет с условием?

Всем привет. А кто-нибудь замечал катастрофическое падение производительности при работе с вьюхами (нематериализованными)? Есть таблица MergeTree, несколько миллиардов записей, простой запрос вида получить количество строк, min/max по одному полю работает за пару секунд, скорость обработки в районе полутора миллиардов строк в секунду. Вьюха вида create view as select field_list from table выдает 7-8 миллионов стров в секунду

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

@alexeysetevoi Alexander в том и дело, что запрос вообще без условий. Я просто переименовал таблицы и сделал вьюхи со старыми именами, чтобы у пользователей ничего не сломалось. Тем не менее, теперь у всех connection timeout, так что непонятно, то ли откатывать все назад, то ли искать пути обхода

тогда даже не подскажу(

При чтении из представления, этот сохранённый запрос, используется в качестве подзапроса в секции FROM.

https://clickhouse.yandex/docs/ru/single/#create-view там пример расписан

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

то есть ваш запрос (select field_list from table) сначала захочет полностью выполнится и результат попробует залезть в оперативку

Кто-нибудь сталкивался с нехваткой памяти при запросах? max_memory_usage стоит 200Гб, запускаю INSERT - падает с ошибкой: 2018.02.20 [ 94 ] HTTPHandler: Code: 173, e.displayText() = DB::Exception: Allocator: Cannot mmap 64.00 MiB., errno: 12, strerror: Cannot allocate memory, e.what() = DB::Exception, Stack trace:

при этомЖ MemoryTracker: Peak memory usage (total): 19.40 GiB

ради всего святого, помогите

при этомЖ MemoryTracker: Peak memory usage (total): 19.40 GiB

А free -m что показывает?

total used free shared buff/cache available Mem: 251G 15G 62G 40G 173G 192G Swap: 4.0G 3.3M 4.0G

total used free shared buff/cache available Mem: 251G 15G 62G 40G 173G 192G Swap: 4.0G 3.3M 4.0G

Странное поведение. А такое ТОЛЬКО на инсертах?

У нас была подобная проблема с инсертом большого файла. Там порядка 2 гигов пихали с кучей nested колонок.

insert select?

Вылечить так и не удалось. Пихали маленькими файлами.

Insert из CSV

Insert из CSV

Файл большой?

да, у нас тоже - если разбить на несколько файлов меньшего размера - работает :<

да, у нас тоже - если разбить на несколько файлов меньшего размера - работает :<

Есть мнение, что кх не батчит данные в размер блока, либо блок в строках стандартный, но в объеме большой

Ну т.е. если блок например 8192 строк, а мы пихаем 1ярд строк, то он одни блоком это пытается проглотить

Но это лишь мои предположения

попробуйте вот так clickhouse-client —query="insert into table name format native" < file.native я обычно так файлы большие вставляю 100-140гб файлик

Так у него csv, а не натив, в натив такой проблемы нет.

а null значения есть? ( там экранировать нужно такие значения )

а null значения есть? ( там экранировать нужно такие значения )

Тогда была бы другая ошибка

Может быть не совсем по теме, но актуально для метирки. Параметр containsSampledData (Google Analytics Core Reporting API) не позволяет отключать сэмлирование, и чтобы получить реальный total приходится делать несолкьо запросов, ожидая, когда в ответе придет containsSampledData=false. Можно ли как то в метрике отключить сэмплирвоание, когда необходимо получить total?

Вот запрос: psql "sslmode=require host=localhost port=5432 dbname=db" —username=user —variable="FETCH_COUNT=100000" -c "COPY (SELECT * FROM db.table) TO STDOUT WITH (FORMAT csv, DELIMITER E'\t', ENCODING 'UTF8');" | docker exec -i clickhouse-client clickhouse-client —stacktrace —host clickhouse-server —query="INSERT INTO db.table FORMAT TSV"

если таблица занимает в КХ 1500М, сколько примерно её native дамп займёт?

уже 25гиг и растёт

а, вот на 25 и остановилось

ого сжатие, not bad

ну зайди в папку где БД сделай du --si -s и умножай примерно на 2-3

Может быть не совсем по теме, но актуально для метирки. Параметр containsSampledData (Google Analytics Core Reporting API) не позволяет отключать сэмлирование, и чтобы получить реальный total приходится делать несолкьо запросов, ожидая, когда в ответе придет containsSampledData=false. Можно ли как то в метрике отключить сэмплирвоание, когда необходимо получить total?

Есть же Logs API

Может быть не совсем по теме, но актуально для метирки. Параметр containsSampledData (Google Analytics Core Reporting API) не позволяет отключать сэмлирование, и чтобы получить реальный total приходится делать несолкьо запросов, ожидая, когда в ответе придет containsSampledData=false. Можно ли как то в метрике отключить сэмплирвоание, когда необходимо получить total?

А для обычного API есть accuracy=full

народ, подскажите, если в настройках сервера стоит utc timezone, а на сервере msk, при работе с фукциями времени из клиента kshvakov будет учитываться msk?

А для обычного API есть accuracy=full

Да, но хотелось использовать именно Google/Yandex решение. И непонятно, зачем containsSampledData, я думал он и выполняет роль того самого accuracy

если таблица занимает в КХ 1500М, сколько примерно её native дамп займёт?

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

В нативе он просто данные раскладывает не по строкам , а по колонкам, так что натив дамп занимает места столько же как и не натив. Хотя в первый раз я думал что он отдаст пожатые данные, как бинарный формат в postgres

Подскажите, пожалуйста, по движкам. У нас есть хиты и по части из них - клики. Сейчас мы уже положили все это в ReplicatedMergeTree в виде последовательного лога событий с EventType = Hit/Click, но получили ситуацию, когда по одному хиту может быть больше одного клика, что не подходит, т.к. портит статистику. Поможет ли тут CollapsingMergeTree? Я так понимаю, тогда в первичный ключ нужно добавить HitID? Предполагаю, что это сильно усложнит схлопывание данных?

Коллеги, добрый вечер, есть вопрос по clickhouse-cpp-lib, поскольку доки особо никакой нет, по коду не совсем ясно. Есть ли какой-то способ вызвать client.Select() без коллбека? Нужна блокировка, грубо говоря. Может быть какую-то другую функцию использовать?

Добрый день! Скажите, можно ли создать копию ReplicatedMergeTree таблицы, но с другим партиционированием и потом переключить на нее Distributed таблицу?

Приветствую! Подскажите, пожалуйста, самостоятельно найти ответа не получилось. Можно ли каким-то способом использовать 2 разных limit-by ? например SELECT day, client, domain, count(*) as count FROM table ARRAY JOIN domain GROUP BY toDate(date) AS day, client, domain ORDER BY day ASC, client ASC, count DESC LIMIT 2 BY day, client LIMIT 10 BY dayт.е. получить в итоге по 10 записей на day, а внутри по 2 записи на day, client. т.е. по 5 уникальным client на день

Если в подзапрос засунуть всё кроме последнего LIMIT BY, то должно эффективно работать: SELECT * FROM (... LIMIT 2 BY day, client) LIMIT 10 BY day

а просто not tlds in whitelisted вообще не о том

Предполагается, что именно так должно работать. Можете показать более подробный пример? Если большой, можно на почту clickhouse-feedback отправить.

а есть способы узнать кардинальность сета?

Простого способа нет, но можно так: При запуске или при аттаче таблицы, сервер пишет: "State has " « getSize() « " unique rows." Если сделать DETACH TABLE, ATTACH TABLE, то в логе будет это сообщение.

Есть таблица с полем "dt DateTime DEFAULT now()" и в нее вставляются данные с использованием формата TSKV. При этом, если в запросе явно указывать список полей ("INSERT INTO table (...) FORMAT TSKV") - то выражение DEFAULT now() выполняется, а если не указывать ("INSERT INTO table FORMAT TSKV") - то вместо выражения DEFAULT now() используется значения по-умолчанию для типа DateTime ("0000-00-00 00:00:00"). https://pastebin.com/raw/AcVXDDFL Подскажите, пожалуйста, это ожидаемое поведение? Версия: 1.1.54343

Это известная недоработка - при чтении форматов, сложные DEFAULT выражения не вычисляются. Исправление у нас в roadmap.

то есть ваш запрос (select field_list from table) сначала захочет полностью выполнится и результат попробует залезть в оперативку

Это не верно. Подзапросы выполняются потоково - то есть, поток данных результата подзапроса будет передаваться дальше по конвейеру выполнения запроса. Например, если вы напишете SELECT * FROM (SELECT * FROM system.numbers) - не смотря на то, что таблица system.numbers содержит бесконечное количество строк, запрос будет использовать ограниченное количество оперативки.

@alexeysetevoi Alexander в том и дело, что запрос вообще без условий. Я просто переименовал таблицы и сделал вьюхи со старыми именами, чтобы у пользователей ничего не сломалось. Тем не менее, теперь у всех connection timeout, так что непонятно, то ли откатывать все назад, то ли искать пути обхода

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

Кто-нибудь сталкивался с нехваткой памяти при запросах? max_memory_usage стоит 200Гб, запускаю INSERT - падает с ошибкой: 2018.02.20 [ 94 ] HTTPHandler: Code: 173, e.displayText() = DB::Exception: Allocator: Cannot mmap 64.00 MiB., errno: 12, strerror: Cannot allocate memory, e.what() = DB::Exception, Stack trace:

Тут не очевидно. Напишите, какая ОС и версия ClickHouse. Далее хотелось бы получить кусок strace: sudo strace -f -p $(pidof clickhouse-server) где виден этот неудачный mmap. Мне не очевидно, почему не удаётся выделить кусок памяти 64 МБ. Также попробуйте уменьшить max_insert_block_size. По-умолчанию он 1048576. Можете попробовать clickhouse-client --max_insert_block_size=100000 ...

Ну т.е. если блок например 8192 строк, а мы пихаем 1ярд строк, то он одни блоком это пытается проглотить

При INSERT поток вставляемых данных разбивается на блоки не более max_insert_block_size строк, по-умолчанию = 1048576.

Подскажите, пожалуйста, по движкам. У нас есть хиты и по части из них - клики. Сейчас мы уже положили все это в ReplicatedMergeTree в виде последовательного лога событий с EventType = Hit/Click, но получили ситуацию, когда по одному хиту может быть больше одного клика, что не подходит, т.к. портит статистику. Поможет ли тут CollapsingMergeTree? Я так понимаю, тогда в первичный ключ нужно добавить HitID? Предполагаю, что это сильно усложнит схлопывание данных?

CollapsingMergeTree - довольно сложная вещь; им весьма сложно пользоваться корректным образом. Поэтому не рекомендую. В качестве возможного решения - сделать отдельно какую-то key-value базу, в которой писать, для какого хита уже был клик, за последние несколько дней. Перед записью в ClickHouse смотреть в эту базу.

Добрый день! Скажите, можно ли создать копию ReplicatedMergeTree таблицы, но с другим партиционированием и потом переключить на нее Distributed таблицу?

Вы можете создать новую таблицу, вставить в неё данные (при изменении ключа партиционирования, единственный способ - INSERT SELECT). Если сделать это на всех серверах, то можно будет просто указать новое имя в Distributed таблице. Для этого удалите Distributed таблицу и создайте заново. Можно иметь ввиду, что Distributed таблица сама не хранит данные, а только "смотрит" на кластер.

Коллеги, добрый вечер, есть вопрос по clickhouse-cpp-lib, поскольку доки особо никакой нет, по коду не совсем ясно. Есть ли какой-то способ вызвать client.Select() без коллбека? Нужна блокировка, грубо говоря. Может быть какую-то другую функцию использовать?

Про clickhouse-cpp ничего не знаю. Можно спросить у @artmkin или самому посмотреть подробнее в коде.

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

получается, что вариант с view и с подзапросом работает совершенно одинаково: view - 1 rows in set. Elapsed: 51.246 sec. Processed 4.03 billion rows, 16.13 GB (78.71 million rows/s., 314.83 MB/s.) подзапрос - 1 rows in set. Elapsed: 51.235 sec. Processed 4.03 billion rows, 16.13 GB (78.73 million rows/s., 314.90 MB/s.) Напрямую к таблице вот - 1 rows in set. Elapsed: 0.973 sec. Processed 4.03 billion rows, 16.13 GB (4.14 billion rows/s., 16.58 GB/s.) Предикаты в запрос не включают поля из primary key, поэтому я вполне ожидаю full table scan, просто удивляет такая разница в производительности

При INSERT поток вставляемых данных разбивается на блоки не более max_insert_block_size строк, по-умолчанию = 1048576.

Все равно достаточно много, если строка жирная

получается, что вариант с view и с подзапросом работает совершенно одинаково: view - 1 rows in set. Elapsed: 51.246 sec. Processed 4.03 billion rows, 16.13 GB (78.71 million rows/s., 314.83 MB/s.) подзапрос - 1 rows in set. Elapsed: 51.235 sec. Processed 4.03 billion rows, 16.13 GB (78.73 million rows/s., 314.90 MB/s.) Напрямую к таблице вот - 1 rows in set. Elapsed: 0.973 sec. Processed 4.03 billion rows, 16.13 GB (4.14 billion rows/s., 16.58 GB/s.) Предикаты в запрос не включают поля из primary key, поэтому я вполне ожидаю full table scan, просто удивляет такая разница в производительности

Предикаты, не входящие в PRIMARY KEY, также могут использоваться для оптимизации, которая называется "PREWHERE". Суть её в том, что сначала читается часть нужных столбцов, производится частичная фильтрация данных, и потом читаются остальные столбцы, но только там, где условие выполнено. Для проверки, сравните скорость работы оригинального запроса, в зависимости от значения настройки optimize_move_to_prewhere (0 или 1).

Поправлю в ближайших версиях -- insert select будет без maxRows

Предикаты, не входящие в PRIMARY KEY, также могут использоваться для оптимизации, которая называется "PREWHERE". Суть её в том, что сначала читается часть нужных столбцов, производится частичная фильтрация данных, и потом читаются остальные столбцы, но только там, где условие выполнено. Для проверки, сравните скорость работы оригинального запроса, в зависимости от значения настройки optimize_move_to_prewhere (0 или 1).

изменил настройку, проверил через system.settings, изменение применилось, но результат тот же - к таблице быстро, к подзапросу медленно

Поправлю в ближайших версиях -- insert select будет без maxRows

На самом деле нам тоже надо поправить - ограничение на результат запроса не должно действовать на INSERT SELECT.

На самом деле нам тоже надо поправить - ограничение на результат запроса не должно действовать на INSERT SELECT.

Сделать Issue ? ?

Не обязательно, у меня внутри в трекере есть.

CollapsingMergeTree - довольно сложная вещь; им весьма сложно пользоваться корректным образом. Поэтому не рекомендую. В качестве возможного решения - сделать отдельно какую-то key-value базу, в которой писать, для какого хита уже был клик, за последние несколько дней. Перед записью в ClickHouse смотреть в эту базу.

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

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

Если достаточно дедупликации в фоне, которая производится в неизвестное время и не полностью, то можете использовать ReplacingMergeTree. От увеличения количества столбцов в ключе проблемы не будет. Мержи не станут существенно сложнее.

Если достаточно дедупликации в фоне, которая производится в неизвестное время и не полностью, то можете использовать ReplacingMergeTree. От увеличения количества столбцов в ключе проблемы не будет. Мержи не станут существенно сложнее.

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

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

Да, это так. Разница будет неравномерной по времени.