Соррян :)

/subscribe

/subscribe

/subscribe requires exactly 2 arguments

всем привет. а есть где-нибудь инфа о том, как много оставляет дубликатов ReplacingMergeTree?

До компакта - undefined, после компакта - без дубликатов

из своего небольшого опыта

т.е. вставлял дубликаты, видел что count() растёт, потом в какой-то момент схлопывается

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

Я впервые добрался до непосредственно работы с КХ. Подскажите, есть ли возможность импортировать CSV, но при этом одну колонку указать "снаружи" (т.е. в самом csv ее нет, но она одинакова для всех записей, находящихся в CSV)?

Я впервые добрался до непосредственно работы с КХ. Подскажите, есть ли возможность импортировать CSV, но при этом одну колонку указать "снаружи" (т.е. в самом csv ее нет, но она одинакова для всех записей, находящихся в CSV)?

ты можешь колонку добавить в таблицу потом с нужным default значением

Она разная для разных CSV

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

Подскажите плиз, можно ли настроить INTO OUTFILE чтобы он завершал строки WINдово CRLF ?

Привет!

Подскажите пожалуйста, есть ли какой быстрый способ получить список уникальных значения в столбце? стандартные способы через GROUP BY и DISTINCT занимаю 22 и 31 секунду соотвественно. БД на 6 миллиардов строк Запрос простой вида SELECT destinct(item) FROM table WHERE id = 1

такого как на скрине ведь не должно быть, да?

если 2 гига оперативки - должно быть.

шаг 1 - запустить make без -j

Под UUID оптимизации нет

Скажи, пожалуйса, а ODBC драйвера для PG не умеет в UUID и способов кроме как конвертировать в строчку нет?

Подскажите пожалуйста, есть ли какой быстрый способ получить список уникальных значения в столбце? стандартные способы через GROUP BY и DISTINCT занимаю 22 и 31 секунду соотвественно. БД на 6 миллиардов строк Запрос простой вида SELECT destinct(item) FROM table WHERE id = 1

Более быстрых способов нет.

Более быстрых способов нет.

благодарю!

если 2 гига оперативки - должно быть.

да, видимо проблема в RAM, спасибо

каковы шансы принятия пул реквеста о добавлении кастомной агрегатной функции uniqpghll (имя обсуждаемо), которая совместима с форматом хранения postgres-hll? стоит ли реализовывать?

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

спасибо.

https://github.com/yandex/ClickHouse/releases/v1.1.54255-testing was tagged

Было бы не плохо сделать runningDifference с группировкой :)

Что бы внутри группы считалась дельта

Это не очень сложно реализовать - см. для примера реализацию функции arrayEnumerateUniq. Пока не собирались делать.

У меня к сожалению навыков кодинга на cpp нет, но парень в команде когда то писал :) если получится сделать что-то годное, то закинет pr

Я смотрел код самоой runningDifference, он проще некуда

Да, но с группами будет существенно сложнее.

Было бы не плохо сделать runningDifference с группировкой :)

Дык это основное. Надо бы посмотреть как пример на windowJoin в kdb :)

Я посмотрел как movingSum сделать , с ходу не очень удалось понять как правильно блоки склеить, так как порядок не очень понятно где определить. Если я правильно понимаю то по этой же причини и anyLast недетерминирован.

Да, у нас при выполнении запроса не предусмотрены функции, которые зависят от порядка блоков. Такие как runningDifference сделаны в виде исключения.

Но теоретически можно самому информацию об этом положить в результат?

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

А может ещё и третий вариант - через window агрегацию.

Не совсем понял, что функции могут реализовывать самостоятельно. Вариант максимум - реализовать window функции, другие варианты получаются неудобными.

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

https://github.com/yandex/ClickHouse/releases/v1.1.54256-testing was tagged

https://github.com/yandex/ClickHouse/releases/v1.1.54257-testing was tagged

https://github.com/yandex/ClickHouse/releases/v1.1.54258-testing was tagged

Подскажите пожалуйста, есть ли какой быстрый способ получить список уникальных значения в столбце? стандартные способы через GROUP BY и DISTINCT занимаю 22 и 31 секунду соотвественно. БД на 6 миллиардов строк Запрос простой вида SELECT destinct(item) FROM table WHERE id = 1

Сейчас подумал, что в качестве не гарантированно точного варианта можно ещё попробовать использовать LIMIT 1 BY cityHash64(columns...)

https://ru.stackoverflow.com/questions/694305/clickhouse-%d0%b1%d1%8b%d1%81%d1%82%d1%80%d0%b0%d1%8f-%d0%b2%d1%8b%d0%b1%d0%be%d1%80%d0%ba%d0%b0-%d1%83%d0%bd%d0%b8%d0%ba%d0%b0%d0%bb%d1%8c%d0%bd%d1%8b%d1%85-%d0%b7%d0%bd%d0%b0%d1%87%d0%b5%d0%bd%d0%b8%d0%b9/694411#694411

Коллеги, привет. Кому удалось реализовать bulk заливку данных в КликХаус с помощью Pentaho Data Integration? Обычные Table Output и Execute SQL Script льют по одной записи и крайне медленно. Данные беру из PostgreSQL.

✌️

✌️

Ой, у нас Talend

Подскажите-помогите, нода одна из реплик сперва было Code: 32, e.displayText() = DB::Exception: Attempt to read after eof По удаляли файлы на которые ругалось Теперь DB::Exception: Cannot create table from metadata file /opt/clickhouse/metadata/aggr//summing_group_views_sharded.sql, error: DB::Exception: The local set of parts of table summing_group_views_sharded doesn't look like the set of parts in ZooKeeper. There are 0 unexpected parts (0 of them is not just-written), 0 unexpectedly merged parts, 0 missing obsolete parts, 27 missing parts, stack trace: Как можно полечить это ?

Ой, у нас Talend

А с ним бодро льется из коробки и без танцев с бубном?

А с ним бодро льется из коробки и без танцев с бубном?

Станцевали один раз, и сейчас батчами по 100к — бодро

Всем привет, периодически падают ноды с ошибками - DB::Exception: Resource temporarily unavailable. - на какие показатели смотреть нужно?

Всем привет. Есть две реплики одной таблицы test_table. В remote_servers настроен кластер из одного шарда и этих двух реплик. На обеих репликах создана Distributed таблица distributed_table, которая смотрит на этот кластер. Если выполнять запрос вида select *, hostName() from distributed_table; на одном из серверов с репликой test_table, то всегда будет возвращаться имя этого сервера вне зависимости от настройки load_balancing, т.е. балансировки, по сути, нет. Если создать такую же Distributed таблицу на третьем сервере, на котором нет реплики test_table, то будет возвращаться случайным образом имя одного из серверов с репликой, что является для меня ожидаемым поведением. Отсюда вопрос: как обойтись без третьего сервера в роли балансировщика, чтобы при отправке запроса на одну из реплик этот запрос перенаправлялся на случайную реплику?

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

хм, а вот можно ли в http интерфейсе компрессировать запросы zstd?

насчет zstd не знаю, но gzip-ом нормально запросы компрессятся. Указываешь в заголовке запроса Content-Encoding: gzip и жмешь тело запроса с помощью gzip

ERROR: S client not available

и CH их поймет?

да, мы так экономим траф при вставке данных в кликхаус

см https://github.com/yandex/ClickHouse/blob/37985d3cb8d14fa0cad7b9868930b9e3e5e6a412/dbms/src/Server/HTTPHandler.cpp#L352

ok, учтем у себя.

судя по исходникам, zstd для сжатия тела http-запросов не поддерживается, но ничто не мешает добавить такую поддержку )

Можно указать в запросе параметр decompress, тогда ClickHouse будет рассчитывать, что тело сжато во внутреннем формате. Там можно использовать zstd.

Сжимать можно утилитой clickhouse-compressor, но это конечно менее удобно, чем gzip

gzip мне нафиг не нужен

он работает медленнее, чем слать несжатое по гигабиту

Добрый день, постоянно растет число в такой ошибке: 2017.07.20 13:16:25.393475 [ 66 ] <Error> ZooKeeper: There are 100000 active watches. There must be a leak somewhere. Сейчас 100000 active watches, за день на 10к прирост. Что делать и кто виноват?

Подскажите-помогите, нода одна из реплик сперва было Code: 32, e.displayText() = DB::Exception: Attempt to read after eof По удаляли файлы на которые ругалось Теперь DB::Exception: Cannot create table from metadata file /opt/clickhouse/metadata/aggr//summing_group_views_sharded.sql, error: DB::Exception: The local set of parts of table summing_group_views_sharded doesn't look like the set of parts in ZooKeeper. There are 0 unexpected parts (0 of them is not just-written), 0 unexpectedly merged parts, 0 missing obsolete parts, 27 missing parts, stack trace: Как можно полечить это ?

Создать файл sudo -u clickhouse touch /opt/clickhouse/flags/force_restore_data и запустить.

https://clickhouse.yandex/docs/en/table_engines/replication.html?highlight=force_restore_data#recovery-after-failures

https://github.com/yandex/ClickHouse/releases/v1.1.54259-testing was tagged

таблица ReplicatedReplacingMergeTree, 2 шарда 2 реплики, поверх нее есть Distributed-таблица. Когда мне нужно перелить месяц (в источнике данные поменялись), я дропаю июль например, и заливаю данные заново в Distributed. Проблема в том, что часть данных отбрасывается, видимо посчитав за дубли, вследствие чего данные заливаются не полностью, приходится пересоздавать таблицу. Как можно этого избежать?

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

похоже что это вот это вот: Блоки данных дедуплицируются. При многократной записи одного и того же блока данных (блоков данных одинакового размера, содержащих одни и те же строчки в одном и том же порядке), блок будет записан только один раз. Это сделано для того, чтобы в случае сбоя в сети, когда клиентское приложение не может понять, были ли данные записаны в БД, можно было просто повторить запрос INSERT. При этом не имеет значения, на какую реплику будут отправлены INSERT-ы с одинаковыми данными. То есть, обеспечивается идемпотентность INSERT-ов. Это работает только для последних 100 вставленных в таблицу блоков.

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

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

https://github.com/yandex/ClickHouse/releases/v1.1.54260-testing was tagged

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

Это известный баг - при DROP PARTITION не очищается информация для дедубликации блоков. Есть неудобный способ это обойти...

Всем привет, кликхаус заведется с одной репликой?)

У меня работает

/unsubscribe yandex/ClickHouse

/unsubscribe yandex/ClickHouse

/unsubscribe requires exactly 3 arguments

/unsubscribe yandex/ClickHouse all

/unsubscribe yandex/ClickHouse all

Success!

/subscribe yandex/ClickHouse stable

/subscribe yandex/ClickHouse stable

Success!