или не прав я?

там не в ML ребята поотвечали, надо прояснить ситуацию, должно заработать в итоге. сейчас бежать надо, а то жена злая из-за потерянной субботы то еще удовольствие

интересное поведение парсера запросов: :) select tuple(1), (1), tuple(1,2), (1,2) SELECT tuple(1), 1, (1, 2), (1, 2) ┌─tuple(1)─┬─1─┬─tuple(1, 2)─┬─tuple(1, 2)─┐ │ (1) │ 1 │ (1,2) │ (1,2) │ └──────────┴───┴─────────────┴─────────────┘

тут получается неоднозначность: либо expr := '(' expr ')', либо tuple := '(' expr* ')'. КХ в случае одного выражения предпочитает первый вариант, для второго смысла есть возможность явным образом обернуть выражение в tuple. если бы дефолтное поведение было бы считать любое выражение в скобках туплом, было бы [еще] неудобнее. можно КЗ грамматику сочинить для этого места, но не уверен что от этого станет проще жить.

cудя по этому http://www.ustream.tv/recorded/92500137 clickhouse является отличной альтернативой, примерно как мы заменили es на clickhouse

А что там? Видео чейчас не посмотрю. 8 месяцев назад в Uber никто не знал про ClickHouse. Сейчас уже есть по крайней мере один человек, который знает. Одна из особенностей - работа с geospatial данными.

нвидиа тоже хотят кликхаус потрогать похоже https://www.linkedin.com/jobs/view/279200146/ Conduct performance and durability research of several distributed database systems, including ClickHouse, MapD and possibly others

осталось понять как их сливать

сливать можно через gsutils. Мы тоже применяем такой подход. Более того, есть возможность замаунтить данные из coldline storage непосредственно в КХ используя gcsfuse

нвидиа тоже хотят кликхаус потрогать похоже https://www.linkedin.com/jobs/view/279200146/ Conduct performance and durability research of several distributed database systems, including ClickHouse, MapD and possibly others

У нас на митапе в Минске был сотрудник nvidia и рассказывал про то, как они используют ClickHouse.

что-то темнят) в вакансии-то написано что внедрять надо)

зато благодаря кликхаусу я узнал как теперь убеждать хостеров что видеокарты мне нужны не для майнинга - говорить что у меня mapd :)

Можно выставить max_rows_to_read = ..., read_overflow_mode = 'break'

так идея то была в том что бы кликхаус заканчивал читать, когда выполнен лимит на результат, а не лимит на количество прочитанных строк. допустим в запросе SELECT name FROM clients GROUP BY name LIMIT 2 по сути нужно прочитать ровно столько записей что бы к ключах для group by было 2 значения. Сколько строк прочитать потребуется - неизвестно. Но явно не все... А текущая имплементация будет читать все. И понятно, что обычно к group by прилагаются каутнеры, и тогда надо читать все. group by без каунтеров, но с лимитом хотелось использовать для предварительного запроса, что бы сказать что фильтр достаточен для того что бы результатов было адекватное количество.

А как узнать какие строки надо прочитать и что в оставшихся не остались уникальные имена?

так идея то была в том что бы кликхаус заканчивал читать, когда выполнен лимит на результат, а не лимит на количество прочитанных строк. допустим в запросе SELECT name FROM clients GROUP BY name LIMIT 2 по сути нужно прочитать ровно столько записей что бы к ключах для group by было 2 значения. Сколько строк прочитать потребуется - неизвестно. Но явно не все... А текущая имплементация будет читать все. И понятно, что обычно к group by прилагаются каутнеры, и тогда надо читать все. group by без каунтеров, но с лимитом хотелось использовать для предварительного запроса, что бы сказать что фильтр достаточен для того что бы результатов было адекватное количество.

Просто в вашем примере нужен не group by, а distinct, иначе вы хотите странного от group by

так идея то была в том что бы кликхаус заканчивал читать, когда выполнен лимит на результат, а не лимит на количество прочитанных строк. допустим в запросе SELECT name FROM clients GROUP BY name LIMIT 2 по сути нужно прочитать ровно столько записей что бы к ключах для group by было 2 значения. Сколько строк прочитать потребуется - неизвестно. Но явно не все... А текущая имплементация будет читать все. И понятно, что обычно к group by прилагаются каутнеры, и тогда надо читать все. group by без каунтеров, но с лимитом хотелось использовать для предварительного запроса, что бы сказать что фильтр достаточен для того что бы результатов было адекватное количество.

Для этого есть (мои любимые) опции - max_rows_to_group_by и group_by_overflow_mode (для последней посмотрите значения 'any' и 'break').

В утилиту для миграций https://github.com/mattes/migrate добавили поддержку ClickHouse

А как узнать какие строки надо прочитать и что в оставшихся не остались уникальные имена?

Так limit же. Читать по порядку. Столько сколько нужно, но не больше. Если хочется видеть первые N уникальных значений, то зачем читать остальные. В моем примере первые 2 уникальных имени вполне могут встретится в первых паре строчек. Незачем после этого читать остальной миллиард.

А ещё можно DISTINCT + LIMIT N или LIMIT 1 BY columns LIMIT N.

Просто в вашем примере нужен не group by, а distinct, иначе вы хотите странного от group by

Верно, спасибо. С distinct даже запрос звучит логичнее. А вот "LIMIT 1 BY columns LIMIT N" не помогло без дополнительных флагов. Все равно все читает.

репост https://medium.com/@f1yegor/clickhouse-aggregatefunctions-and-aggregatestate-e3fd46b7be74

Отличная статья!

а по движкам не планируется ?

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

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

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

Добрый день, господа. Не до конца понятен механизм sample. У меня есть таблица с просмотрами страниц, ключ сэмплирования - sipHash64(user_id). Если я сделаю SAMPLE 0.1 - я получу все данные по десятой части user_id? Или часть данных по 10% user_id? То есть по сути это аналог global in ( SELECT user_id FROM table SAMPLE 0.1 WHERE dt …) ?

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

А как при создании базы указать ей движок Dictionary? Или он проставляется автоматически, если создать базу с именем "Dictionary" ?

Примерно так: CREATE DATABASE dict ENGINE = Dictionary dict - имя базы

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

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

постучите на 8123 порт. КХ должен ответить ОК

также есть системные метрики в бд system

/stat@combot

combot.org/chat/-1001080295593

/stat@combot

combot.org/chat/-1001080295593

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

если пользуетесь Grafana, то можете попробовать следить за состоянием по дашбордам https://grafana.com/dashboards/882 https://grafana.com/dashboards/869

постучите на 8123 порт. КХ должен ответить ОК

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

Не уверен. Просмотрите логи и сделайте какой-нибудь SELECT count() за длительный период

Не уверен. Просмотрите логи и сделайте какой-нибудь SELECT count() за длительный период

ясно, спасибо

хотелось бы понять насколько оптимальна запись в AggregatingMergeTree, если хочется собирать данные по часам - везде в примерах по датам И насколько там адекватно использовать GROUP BY во вложенных запросах, Насколько адекватным будет использование такой VIEW: CREATE MATERIALIZED VIEW default.AggregatedEvent ENGINE = AggregatingMergeTree(date, (hour, eventId, suid, date), 8192) AS SELECT toStartOfHour( toDateTime( time ) ) hour eventId, suid, any(date) date, countState() count, uniqState(ufa) AS unique, avgState(metric1) AS metric1, avgState(metric2) AS metric2, avgState(metric3) AS metric3 FROM ( SELECT sessionId, time, eventId, date, metric1, metric2, metric3 FROM ( SELECT sessionId, time, eventId, date FROM Event ) ANY LEFT JOIN ( SELECT sessionId, avg(metric1) metric1, avg(metric2) metric2, avg(metric3) metric3 FROM Flow GROUP BY sessionId ) USING sessionId ) ANY LEFT JOIN ( SELECT id sessionId, suid, ufa FROM Init ) USING sessionId GROUP BY hour, eventId, suid;

Добрый день. Кликхаус еще не поддерживает решардинг?

Добрый день. Кликхаус еще не поддерживает решардинг?

https://clickhouse.yandex/docs/en/single/index.html#document-table_engines/resharding

По состоянию на июнь 2016, перешардирование находится в состоянии “бета”: тестировалось лишь на небольшом объёме данных - до 5 ТБ.

Ребят, а cityHash64 возвращает UInt64 ?

SELECT toTypeName(cityHash64(1)) ┌─toTypeName(cityHash64(1))─┐ │ UInt64 │ └───────────────────────────┘

Спасибо, до toTypeName то я и не догадался)

Ребят, в логе вот такое сыпит... 2017.07.10 18:26:26.863597 [ 35 ] <Warning> cursometr.r_statements (StorageReplicatedMergeTree, CleanupThread): Couldn't remove 20160823_20160823_41_41_0 from ZooKeeper: no node 2017.07.10 18:26:26.865027 [ 35 ] <Warning> cursometr.r_statements (StorageReplicatedMergeTree, CleanupThread): Couldn't remove 20160713_20160725_65_65_0 from ZooKeeper: no node 2017.07.10 18:26:26.866409 [ 35 ] <Warning> cursometr.r_statements (StorageReplicatedMergeTree, CleanupThread): Couldn't remove 20160607_20160607_73_73_0 from ZooKeeper: no node 2017.07.10 18:26:26.867537 [ 35 ] <Warning> cursometr.r_statements (StorageReplicatedMergeTree, CleanupThread): Couldn't remove 20160531_20160531_123_123_0 from ZooKeeper: no node 2017.07.10 18:26:26.868712 [ 35 ] <Warning> cursometr.r_statements (StorageReplicatedMergeTree, CleanupThread): Couldn't remove 20160408_20160426_113_113_0 from ZooKeeper: no node 2017.07.10 18:29:56.969884 [ 35 ] <Warning> cursometr.r_statements (StorageReplicatedMergeTree, CleanupThread): Couldn't remove 20160801_20160801_43_43_0 from ZooKeeper: no node 2017.07.10 18:29:56.970923 [ 35 ] <Warning> cursometr.r_statements (StorageReplicatedMergeTree, CleanupThread): Couldn't remove 20160701_20160727_67_67_0 from ZooKeeper: no node 2017.07.10 18:29:56.971951 [ 35 ] <Warning> cursometr.r_statements (StorageReplicatedMergeTree, CleanupThread): Couldn't remove 20160609_20160610_75_75_0 from ZooKeeper: no node 2017.07.10 18:29:56.972878 [ 35 ] <Warning> cursometr.r_statements (StorageReplicatedMergeTree, CleanupThread): Couldn't remove 20160506_20160516_125_125_0 from ZooKeeper: no node 2017.07.10 18:29:56.973902 [ 35 ] <Warning> cursometr.r_statements (StorageReplicatedMergeTree, CleanupThread): Couldn't remove 20160408_20160409_115_115_0 from ZooKeeper: no node 2017.07.10 18:30:56.984354 [ 35 ] <Warning> cursometr.r_statements (StorageReplicatedMergeTree, CleanupThread): Couldn't remove 20170207_20170207_531_531_0 from ZooKeeper: no node 2017.07.10 18:30:56.985260 [ 35 ] <Warning> cursometr.r_statements (StorageReplicatedMergeTree, CleanupThread): Couldn't remove 20170130_20170130_643_643_0 from ZooKeeper: no node 2017.07.10 18:30:56.986052 [ 35 ] <Warning> cursometr.r_statements (StorageReplicatedMergeTree, CleanupThread): Couldn't remove 20161109_20161109_1047_1047_0 from ZooKeeper: no node 2017.07.10 18:30:56.986892 [ 35 ] <Warning> cursometr.r_statements (StorageReplicatedMergeTree, CleanupThread): Couldn't remove 20160523_20160523_127_127_0 from ZooKeeper: no node 2017.07.10 18:30:56.987757 [ 35 ] <Warning> cursometr.r_statements (StorageReplicatedMergeTree, CleanupThread): Couldn't remove 20160411_20160411_117_117_0 from ZooKeeper: no node 2017.07.10 18:31:26.989589 [ 35 ] <Warning> cursometr.r_statements (StorageReplicatedMergeTree, CleanupThread): Couldn't remove 20170424_20170424_6035_6035_0 from ZooKeeper: no node 2017.07.10 18:31:26.990801 [ 35 ] <Warning> cursometr.r_statements (StorageReplicatedMergeTree, CleanupThread): Couldn't remove 20170313_20170330_1817_1817_0 from ZooKeeper: no node 2017.07.10 18:31:26.991890 [ 35 ] <Warning> cursometr.r_statements (StorageReplicatedMergeTree, CleanupThread): Couldn't remove 20160912_20160929_27_27_0 from ZooKeeper: no node 2017.07.10 18:31:26.992787 [ 35 ] <Warning> cursometr.r_statements (StorageReplicatedMergeTree, CleanupThread): Couldn't remove 20160802_20160802_45_45_0 from ZooKeeper: no node 2017.07.10 18:31:26.993745 [ 35 ] <Warning> cursometr.r_statements (StorageReplicatedMergeTree, CleanupThread): Couldn't remove 20160712_20160714_69_69_0 from ZooKeeper: no node 2017.07.10 18:31:26.994727 [ 35 ] <Warning> cursometr.r_statements (StorageReplicatedMergeTree, CleanupThread): Couldn't remove 20160606_20160615_77_77_0 from ZooKeeper: no node 2017.07.10 18:31:26.995676 [ 35 ] <Warning> cursometr.r_statements (StorageReplicatedMergeTree, CleanupThread): Couldn't remove 20160526_20160526_129_129_0 from ZooKeeper: no node

2017.07.10 18:32:57.098041 [ 35 ] <Warning> cursometr.r_statements (StorageReplicatedMergeTree, CleanupThread): Couldn't remove 20160526_20160527_131_131_0 from ZooKeeper: no node 2017.07.10 18:32:57.099395 [ 35 ] <Warning> cursometr.r_statements (StorageReplicatedMergeTree, CleanupThread): Couldn't remove 20160407_20160407_119_119_0 from ZooKeeper: no node

Это я так понял какие то проблемы с репликацией?

Два метра таких логов лежит

у меня такое же сыпит

и проблем вроде нет

если проверять через count или подобное

Добрый день, господа. Не до конца понятен механизм sample. У меня есть таблица с просмотрами страниц, ключ сэмплирования - sipHash64(user_id). Если я сделаю SAMPLE 0.1 - я получу все данные по десятой части user_id? Или часть данных по 10% user_id? То есть по сути это аналог global in ( SELECT user_id FROM table SAMPLE 0.1 WHERE dt …) ?

Апну вопрос :)

Вот была статья недавно на эту тему: http://www.3manuek.com/clickhousesample

Доброго времени суток!

Скажите, это нормально что запрос на 30% проц забивает. А 10 одновременных ложит Кликхаус. Может надо что то донастроить. В какую сторону смотреть?

Скажите, это нормально что запрос на 30% проц забивает. А 10 одновременных ложит Кликхаус. Может надо что то донастроить. В какую сторону смотреть?

Приведите примеры запросов

SELECT date_added, count() as visits, sum(cost) as cost, sum(income) as incm, sum(income>0) as conv FROM roiorbit_visit ALL LEFT JOIN roiorbit_conversion USING hash

А где тут секция GROUP BY?

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

GROUP BY date_added

CREATE TABLE IF NOT EXISTS roiorbit_visit ( date_added Date DEFAULT toDate(event_time), event_time DateTime, user_id UInt64, campaign_id UInt64, offer_id UInt64, prelanding_id UInt64, adnetwork_id UInt64, source String, promo String, country String, device_type UInt8, os String, osversion String, browser String, browser_version UInt8, device_brand String, device_model String, hash String, cost Float64 ) ENGINE = MergeTree(date_added, (hash), 8192)

CREATE TABLE IF NOT EXISTS roiorbit_conversion ( date_added_c Date DEFAULT toDate(event_time_c), event_time_c DateTime, hash String, conversion UInt8, income Float64 ) ENGINE = MergeTree(date_added_c, (event_time_c, hash, conversion), 8192)

первая таблица около 150 млн строк

вторая 1.5 млн строк

четырехядерный Xeon E5-1620 v2 CPU 3.70GHz, 64GD RAM, 3*300 SSD, 500 mbps

2017.07.10 18:32:57.098041 [ 35 ] <Warning> cursometr.r_statements (StorageReplicatedMergeTree, CleanupThread): Couldn't remove 20160526_20160527_131_131_0 from ZooKeeper: no node 2017.07.10 18:32:57.099395 [ 35 ] <Warning> cursometr.r_statements (StorageReplicatedMergeTree, CleanupThread): Couldn't remove 20160407_20160407_119_119_0 from ZooKeeper: no node

Такие предупреждения возникают в случае, если кусок был записан в файловую систему, но не был добавлен в ZK. Это нормальная ситуация, например, если часто вставляются дубликаты данных (они игнорируются при вставке), или если при вставке была ошибка при работе с ZK. Корректность работы при этом не нарушается.

Такие предупреждения возникают в случае, если кусок был записан в файловую систему, но не был добавлен в ZK. Это нормальная ситуация, например, если часто вставляются дубликаты данных (они игнорируются при вставке), или если при вставке была ошибка при работе с ZK. Корректность работы при этом не нарушается.

Слава богу, а то я уже подумал, что проблема с репликацией

Скажите, это нормально что запрос на 30% проц забивает. А 10 одновременных ложит Кликхаус. Может надо что то донастроить. В какую сторону смотреть?

По-умолчанию, ClickHouse старается использовать все ядра, без учёта hyper-threading. В top на Linux это выглядит как 100% умножить на количество использованных ядер, а во всяких мониторингах - как 50% всего CPU. А что значит, что 10 одновременных запросов кладут ClickHouse? Если надо, чтобы запрос использовал меньше CPU, то уменьшите настройку max_threads.

Привет. Короткий вопрос разработчикам: какую роль выполняет zookeeper? В доке написано : To enable replication ZooKeeper is required. ClickHouse will take care of data consistency on all replicas and run restore procedure after failure automatically. It's recommended to deploy ZooKeeper cluster to separate servers. ` Короче для использования репликации подключить зукипер. в зукипере просто хранятся настройки реплик или зукипер делает что то еще для репликации?

зукипер делает что-то еще.

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

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

А что значет очередь? сами данные или метаданные?

Метаданные. Информация о том, что появился кусок данных - с каким-то названием, чексуммой и т. п.

DB::Exception: Cannot read from istream, e.what() = DB::Exception - а вот такое вообще откуда берется? )

Пишу примерно 6 миллионов строк в минуту, батчи разных размеров от 10 строк до 10 000 строк

DB::Exception: Cannot read from istream, e.what() = DB::Exception - а вот такое вообще откуда берется? )

Это значит, что сервер не прочитал все отправляемые в него данные из-за того, что разорвалось соединение с клиентом.

Т.е. проблема в сети получается?

Либо в сети, либо в клиенте.

Странно, но у меня канал в сторону кликхауса не загружен даже на 5 мегабит. Ладно, буду клиент колупать

Пишу примерно 6 миллионов строк в минуту, батчи разных размеров от 10 строк до 10 000 строк

Меньше 1000 писать не лучшая идея. У меня при таком использовании фоновые мерджы диск начинают утилизировать жестко (нагрузка на диск под 100%)

По другому пока никак ( Руки не дошли напилить вставку через буффер

На GitHub есть готовый батчер для ClickHouse. Сам не проверял, как он работает.

А можно ссылочку?

Сейчас поищу...

Я просто не нашел ничего (

Вчера видел, но почему-то не могу легко найти на Github...

https://github.com/nikepan/clickhouse-bulk

Спасибо большое за ссылку!

А зачем батчер? Почему не buffer?