Всем привет. Есть ли какие-то оганичения по количеству возвращаемых строк через HTTP для пользователя readonly? У пользоваетля квота - default, она вроде не имеет ограничений из коробки. Пытаюсь в табло через веб конектор выгрузить миллион записей. Сто тысяч получается выгружать

Ограничений по-умолчанию нет. Можно сколько угодно выгружать.

Ну да, тут строка. Под записью, имхо, подразумевается действие, глагол.

Конечно было бы более правильно говорить записи, чтобы не было неоднозначности. Но по привычке часто говорим "строки". Особенно тяжело переводчикам, которые должны выбирать между row, record, line, string и как правило всё путается :)

А если места недостаточно, вылезет ошибка? Запускал, работало довольно долго, поменял месяц - отработало менее чем за секунду, при этом данных там больше.

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

Сейчас выбираем вариант доклада для Highload++. Надо не просто так, а чтобы проголосовали :) (например, вы). О чём вы хотите больше послушать? Есть, например, такой вариант: Эффективное использование ClickHouse. ClickHouse чуть более года доступен в open-source. За это время накоплен опыт его использования в российских и зарубежных компаниях. В некоторых из них объёмы данных и нагрузки превышают те, с которыми мы имеем дело в Яндексе. Так как ClickHouse является специализированной системой, при его использовании важно учитывать особенности его архитектуры. В своём докладе я расскажу о примерах типичных ошибок при использовании ClickHouse, которые могут привести к неэффективной работе. На примерах из практики будет показано, как выбор той или иной схемы обработки данных может изменить производительность на порядки.

Отлично

Сейчас выбираем вариант доклада для Highload++. Надо не просто так, а чтобы проголосовали :) (например, вы). О чём вы хотите больше послушать? Есть, например, такой вариант: Эффективное использование ClickHouse. ClickHouse чуть более года доступен в open-source. За это время накоплен опыт его использования в российских и зарубежных компаниях. В некоторых из них объёмы данных и нагрузки превышают те, с которыми мы имеем дело в Яндексе. Так как ClickHouse является специализированной системой, при его использовании важно учитывать особенности его архитектуры. В своём докладе я расскажу о примерах типичных ошибок при использовании ClickHouse, которые могут привести к неэффективной работе. На примерах из практики будет показано, как выбор той или иной схемы обработки данных может изменить производительность на порядки.

Да, хорошая тема! Я думаю тут какую тему не тронь, все будет актуально. Так же хотелось бы больше узнать вообще о внутреннем устройстве самого движка, который непосредственно работает с данными. Чем больше знаешь о внутренностях, тем лучше можно писать запросы, которые работают эффективней.

С удовольствием расскажу.

Я чем больше узнаю из бесед в этом чате, тем больше интереса появляется к КХ )

Я чем больше узнаю из бесед в этом чате, тем больше интереса появляется к КХ )

аналогично

У кого-то завелся Superset? У меня то 'DatetimeTZDtype' object has no attribute 'char', то Failed to start remote query on a worker. Tell your administrator to verify the availability of the message queue. Базы и таблицы видит, а ни один запрос не работает

Сейчас выбираем вариант доклада для Highload++. Надо не просто так, а чтобы проголосовали :) (например, вы). О чём вы хотите больше послушать? Есть, например, такой вариант: Эффективное использование ClickHouse. ClickHouse чуть более года доступен в open-source. За это время накоплен опыт его использования в российских и зарубежных компаниях. В некоторых из них объёмы данных и нагрузки превышают те, с которыми мы имеем дело в Яндексе. Так как ClickHouse является специализированной системой, при его использовании важно учитывать особенности его архитектуры. В своём докладе я расскажу о примерах типичных ошибок при использовании ClickHouse, которые могут привести к неэффективной работе. На примерах из практики будет показано, как выбор той или иной схемы обработки данных может изменить производительность на порядки.

Было бы интересно! Но только пожалуйста без банальностей типа 'КХ не для OLTP'.

Встретился с такой ошибкой <Debug> MemoryTracker: Peak memory usage (for query): 61.62 MiB. 2017.08.31 14:19:20.423407 [ 5 ] <Debug> MemoryTracker: Peak memory usage (for user): 61.62 MiB. 2017.08.31 14:19:20.423415 [ 5 ] <Debug> MemoryTracker: Peak memory usage (total): 61.62 MiB. . Посмотрел настройку max_memory_usage, она 10 GB по умолчанию. Настройки стандартные.

Уровень логирования поменяйте, это не ошибка, а отладочная информация

в папке detached появились файлы типа ignored_20170706_20170706_233265_233265_0. ничего же страшного не случится, если их выкосить? в доке написано После того, как запрос будет выполнен, вы можете самостоятельно сделать что угодно с данными в директории detached, например, удалить их из файловой системы, или ничего не делать.

в папке detached появились файлы типа ignored_20170706_20170706_233265_233265_0. ничего же страшного не случится, если их выкосить? в доке написано После того, как запрос будет выполнен, вы можете самостоятельно сделать что угодно с данными в директории detached, например, удалить их из файловой системы, или ничего не делать.

Да, всё что в директории detached можно удалять.

Было бы интересно! Но только пожалуйста без банальностей типа 'КХ не для OLTP'.

Разумеется.

Народ, подскажите, никак не догоню. Вот есть кластер из 4х нод 2 шарда по две реплики. Distributed-таблицу где делать? а. Рандомно выбрать один сервер главным, создать на нем и через него ходить. б. Создать на одном, оно само реплицируется, ходить на любой. в. Создать на любом, но ON CLUSTER name, ходить на любой. г. Создать на всех репликах одного шарда, ходить через любую реплику этого шарда. д. Создать руками везде.

Проще всего создать на всех серверах. Это либо "в" либо "д". Варианты "а" и "г" тоже допустимы.

но у а и г меньше точек входа, значит отказоустойчивость. Ясно. Спасибо!

Такой вариант. Есть у меня long id-шки. будут они писаться в лог-файлы/таблицы (причем в целом, надеюсь, в порядке возрастания). но таблиц будет много, скажем 1-10 тыс. потом нужно находить с помощью join-ов id-шки которые есть в заданном наборе таблиц, например найти только те id-шки которые в tbl_1, tbl_3, tbl_6, tbl_10 таблицах одновременно. в таблицах кроме id-шек больше ничего не будет. Для такого случая ClickHouse - подходит / не подходит / это overkill и из пушки по воробьям / что-то другое.

Такой вариант. Есть у меня long id-шки. будут они писаться в лог-файлы/таблицы (причем в целом, надеюсь, в порядке возрастания). но таблиц будет много, скажем 1-10 тыс. потом нужно находить с помощью join-ов id-шки которые есть в заданном наборе таблиц, например найти только те id-шки которые в tbl_1, tbl_3, tbl_6, tbl_10 таблицах одновременно. в таблицах кроме id-шек больше ничего не будет. Для такого случая ClickHouse - подходит / не подходит / это overkill и из пушки по воробьям / что-то другое.

Если абстрагироваться от ClickHouse, почему не писать все в одну таблицу ?

Проще всего писать их в одну таблицу типа MergeTree. Ключом сделать пару (id таблицы, id значения). (Также придётся иметь столбец с датой - можете туда писать что-нибудь полезное или любую константную дату). ClickHouse подходит.

Если абстрагироваться от ClickHouse, почему не писать все в одну таблицу ?

индексов по отдельным колонкам у ClickHouse нету

А правильно я понимаю, что при установке у шарда <weight>0</weight> данные, которые вставляются через Distributed-таблицу, туда писаться не будут?

Да.

Спасибо. А насколько нормально перекидывать старые данные на реплики с HDD, если они будут редко использоваться?

Имеется ввиду - на шарды с HDD. Полностью нормально.

есть 4к строк запросов вида: alter table $dbName.track_sharded detach partition $partName в файле, который скармливается клиенту так: cat alters|while read a; do clickhouse-client —query="$a"; done через некоторое время выполнения получаю: Code: 49. DB::Exception: Received from localhost:9000, 127.0.0.1. DB::Exception: Logical error: newly allocated block number is zero. что может быть?

есть какие-то оценки по точности вероятностных структур? https://clickhouse.yandex/docs/en/agg_functions/index.html?highlight=uniq#uniq-x

есть 4к строк запросов вида: alter table $dbName.track_sharded detach partition $partName в файле, который скармливается клиенту так: cat alters|while read a; do clickhouse-client —query="$a"; done через некоторое время выполнения получаю: Code: 49. DB::Exception: Received from localhost:9000, 127.0.0.1. DB::Exception: Logical error: newly allocated block number is zero. что может быть?

Вроде недавно исправляли. Можно обновиться.

есть какие-то оценки по точности вероятностных структур? https://clickhouse.yandex/docs/en/agg_functions/index.html?highlight=uniq#uniq-x

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

Вроде недавно исправляли. Можно обновиться.

а без обновления есть решение? :) типа после какого-то количества строк делать слип на какое-то время?

а без обновления есть решение? :) типа после какого-то количества строк делать слип на какое-то время?

Такое возникает при удалении партиции, для которой нет данных. Можете просто пропустить их.

не совсем. если пустить повторно всю команду - ошибки смещаются дальше по списку.

и все последующие команды выдают эту ошибку

А есть какие-то известные проблемы со вставкой в MATHERIALIZED колонки через Distributed таблицу? Имею CREATE TABLE logs_node( created_at DateTime, created_date Date MATERIALIZED toDate(created_at) ) ENGINE = ReplicatedMergeTree(....); и CREATE TABLE logs AS logs_node ENGINE = Distributed(...) при попытке вставки cat file.csv | clickhouse-client --host clickhouse --query="INSERT INTO logs(created_at) FORMAT CSV" получаю Code: 44. DB::Exception: Received from clickhouse:9000, 10.254.141.47. DB::Exception: Cannot insert column created_date. при такой же вставке в локальную нереплицированную таблицу все было хорошо.

Скудненкий мессадж... DB::Exception: Cannot insert column created_date

ощущение, что в distributed таблице он его не хочет вычислять из created_at

Хотя структура скопирована верно.... SHOW CREATE TABLE logs ┌─statement───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐ │ CREATE TABLE test.logs ( created_at DateTime, created_date Date MATERIALIZED toDate(created_at)) ENGINE = Distributed(k8scluster, \'test\', \'logs_node\', rand()) │ └─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘ 1 rows in set. Elapsed: 0.101 sec.

Есть вопросик. Одна из реплик пытается фетчить данные с умершей реплики. Нашел партиции в бекапе преаттачил. В очереди все равно фетч висит. Просто дропнуть из очереди?

В инструкции нету инфу по движку Dictionary. Подскажите как создавать с ним таблицу. Еще лучше - если есть пример. Заранее спасибо!

https://clickhouse.yandex/docs/ru/dicts/index.html

New database engine Dictionary

Из release notes

Как это юзать - нет доки

New database engine Dictionary

Можно ссылку?

https://www.altinity.com/blog/2017/7/20/clickhouse-release-1154245

CREATE DATABASE IF NOT EXISTS dictionaries ENGINE = Dictionary

больше всего интесуют параметры после ENGINE = Dictionary

Или они не нужны?

а то, как сейчас она работает вас не устраивает?

не нужны

просто это выполнить и появится словари как таблицы

Бомба! Спасибо!!! Это просто божественно!!!!!

Джойн можно будет?

Джойн можно будет?

А зачем? Он почти везде работает медленно.

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

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

Вроде нет. А что вы туда пишете?

А есть какие-то известные проблемы со вставкой в MATHERIALIZED колонки через Distributed таблицу? Имею CREATE TABLE logs_node( created_at DateTime, created_date Date MATERIALIZED toDate(created_at) ) ENGINE = ReplicatedMergeTree(....); и CREATE TABLE logs AS logs_node ENGINE = Distributed(...) при попытке вставки cat file.csv | clickhouse-client --host clickhouse --query="INSERT INTO logs(created_at) FORMAT CSV" получаю Code: 44. DB::Exception: Received from clickhouse:9000, 10.254.141.47. DB::Exception: Cannot insert column created_date. при такой же вставке в локальную нереплицированную таблицу все было хорошо.

Да, есть. Суть в том, что если в локальной таблице поле тоже MATERIALIZED, то она не позволяет вставить то, что ей отправляет Distributed таблица. Для решения можно заменить MATERIALIZED на DEFAULT.

в смысле что? статистику

Есть вопросик. Одна из реплик пытается фетчить данные с умершей реплики. Нашел партиции в бекапе преаттачил. В очереди все равно фетч висит. Просто дропнуть из очереди?

Если реплика совсем умерла, то можно удалить её запись в ZK. Через некоторое время записи в очереди репликации об отсутствующих кусках, удалятся тоже.

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

Была аналогичная задача. Легко решилась с помощью LVM. Надо только, что бы диски были близкими по характеристикам

И на кой так много? Может проще это архивировать?

Была аналогичная задача. Легко решилась с помощью LVM. Надо только, что бы диски были близкими по характеристикам

диск не в лвм к сожалению

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

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

диск не в лвм к сожалению

Но ... новый диск можно с LVM сделать, перенести данные, и потом второй (старый) диск подцепить под LVM. Это, кажется, надежнее чем манёвры с линками ...

диск один и он же системный.

с одним разделом

Всем привет, а нет ли в CH возможностей работы с гео-данными?

Есть ограниченная возможность - функции greatCircleDistance, pointInEllipses. (Документация пока только в комментариях в коде.) Сейчас в разработке ещё одна секретная функция на ту же тему.

если вместо мертвого узла в кластере, подсунуть узел с таким же именем и конфигом, но другим ипом, он подхватится?

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

если вместо мертвого узла в кластере, подсунуть узел с таким же именем и конфигом, но другим ипом, он подхватится?

Да. Детали: 1. В ClickHouse вечный DNS кэш. Придётся перезапустить все серверы, которые работают с новым. 2. Если используется запись в Distributed таблицы, то данные накопленные ранее на ФС (если такие есть), отправлены на новую реплику не будут.

Да. Детали: 1. В ClickHouse вечный DNS кэш. Придётся перезапустить все серверы, которые работают с новым. 2. Если используется запись в Distributed таблицы, то данные накопленные ранее на ФС (если такие есть), отправлены на новую реплику не будут.

по 1. - если я поменяю конфиг и сделаю SIGHUP, этого достаточно будет?

DNS кэш не сбрасывается по SIGHUP.

Да, есть. Суть в том, что если в локальной таблице поле тоже MATERIALIZED, то она не позволяет вставить то, что ей отправляет Distributed таблица. Для решения можно заменить MATERIALIZED на DEFAULT.

спасибо

При подключении к КХ через ODBC (версия драйвера от 24.08) возникает ошибка выполнения запроса CAST(Custom_SQL_Query.date AS DATE) AS tdy_date_ok похоже тип данных неверно подставляется, вместо Date пишет DATE

это как-то на уровне драйвера исправляется?

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

DNS кэш не сбрасывается по SIGHUP.

и еще один вопрос, кликхаус за натом без проблем будет работать? Если я решу таким образом проблему смену IP у ноды

Да. Детали: 1. В ClickHouse вечный DNS кэш. Придётся перезапустить все серверы, которые работают с новым. 2. Если используется запись в Distributed таблицы, то данные накопленные ранее на ФС (если такие есть), отправлены на новую реплику не будут.

а если писать напрямую в шарды, то догонит? или я не правильно понял смысл пункта 2?

Есть ограниченная возможность - функции greatCircleDistance, pointInEllipses. (Документация пока только в комментариях в коде.) Сейчас в разработке ещё одна секретная функция на ту же тему.

а проверить попадание точки в полигон?

Проще всего писать их в одну таблицу типа MergeTree. Ключом сделать пару (id таблицы, id значения). (Также придётся иметь столбец с датой - можете туда писать что-нибудь полезное или любую константную дату). ClickHouse подходит.

А как правильнее (ID) или (Date,ID) ?

Или по Dete по любому есть индекс?

привет. не могу сделать quick start на xenial, как можно вылечить? =/

Konstantin Надо сдлеать: sudo apt-key adv --keyserver keyserver.ubuntu.com --recv E0C56BD4 а потом ставить кликхаус

Konstantin Надо сдлеать: sudo apt-key adv --keyserver keyserver.ubuntu.com --recv E0C56BD4 а потом ставить кликхаус

вроде бы так и делаю

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

а ключ кто будет прописывать?

не -- recv, а --recv

а ключ кто будет прописывать?

какой именно ключ? разве E056BD4 не ключ? =/