Можете уточнить как эти параметры влияют. Я их меняю, но не вижу разницы, в логе по прежнему сыпится ReplicatedMergeTreeQueue): Not executing log entry for part 20180119_20180122_0_6_1 because source parts size (43.08 MiB) is greater than the current maximum (4.45 MiB) И команду удаления не проходят

На самом деле эти параметры позволяют чуть меньше ушатывать сервер при insert select, обычно этого достаточно. Эта запись в логе означает что, условно, сейчас работают несколько тредов на мерж которые суммарно превышают max_bytes_to_merge_at_min_space_in_pool, там немного сложнее, но примерно так. Как только будут ресурсы сервер эти куски помержит. Если критично, можно копаться дальше, если нет то можно понизить уровень логирования с debug на какой-нибудь более приемлемый.

Т.е. они влияют косвено

На самом деле эти параметры позволяют чуть меньше ушатывать сервер при insert select, обычно этого достаточно. Эта запись в логе означает что, условно, сейчас работают несколько тредов на мерж которые суммарно превышают max_bytes_to_merge_at_min_space_in_pool, там немного сложнее, но примерно так. Как только будут ресурсы сервер эти куски помержит. Если критично, можно копаться дальше, если нет то можно понизить уровень логирования с debug на какой-нибудь более приемлемый.

Таких записей в логе много, и судя по всему из-за этого у меня мутация зависает примерно посередине. Вот и хочу разобраться как делать INSERT INTO чтобы таких больших блоков не появлялось

дайте CREATE TABLE всех таблиц и представлений, тогда будет понятней

CREATE TABLE log.AggregateEventsLog ( SysRowDate Date, SysRowKey FixedString(36), EntityID FixedString(36) ... ) ENGINE = Distributed(central, 'log', 'EventsLog') CREATE TABLE log.EventsLog ( SysRowDate Date, SysRowKey FixedString(36), EntityID FixedString(36), ... ) ENGINE = ReplicatedMergeTree( '/clickhouse/tables/{shard}/EventsLog', '{replica}', SysRowDate, (EntityID, SysRowKey), 8192 )

Товарищи, нигде в документации не нашел информацию о том могут ли в репликами быть разные версии кликхауса? Например такой кейс возможен при обновлении

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

насколько помню раньше точно не могли

и это на мой взгляд правильно

Товарищи, нигде в документации не нашел информацию о том могут ли в репликами быть разные версии кликхауса? Например такой кейс возможен при обновлении

Могуг, разные версии КХ совместимы на уровне протокола. В некоторых (очень редких) случаях могут вноситься изменения, нарушающие эту совместимость, информация об этом и инструкции обновления при этом будут появляться в changelog.

а как обновлять кластер тогда? весь разом? это было бы странно

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

а как обновлять кластер тогда? весь разом? это было бы странно

Алексей говорил, что в яндексе тоже реплики обновляют по очереди.

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

а это реально быстрый процесс

> We don't recommend using POPULATE, since data inserted in the table during the view creation will not be inserted in it. А как лучше всего достигать consistent views, если POPULATE не позволяет этого, а без него только новые данные попадают в view?

Там вопрос только в том как правильно "инициализировать" данные в матвью. Можно создать матвью без populate, сохранив момент создания матвью (все данные "новее" будут автоматически приезжать в матвью) а потом доинициализировать старшие данные с помощью INSERT ... SELECT ... WHERE timestamp < mat_view_creation_ts.

Всем привет, может сталкивался кто-то, добавлял табличку ReplicatedMergeTree на одной из нод, таббикс повис, а после рестарта стали валиться ошибки вида 2018.07.11 09:36:57.253583 [ 1 ] <Warning> ZooKeeper: Error on attempt 0: connection loss. Retry 2018.07.11 09:37:07.254277 [ 1 ] <Warning> ZooKeeper: Error on attempt 1: connection loss. Retry 2018.07.11 09:37:17.257471 [ 1 ] <Warning> ZooKeeper: Error on attempt 2: connection loss. Retry 2018.07.11 09:37:17.259287 [ 1 ] <Error> Application: zkutil::KeeperException: connection loss, path: /clickhouse После это CH падает.

Там вопрос только в том как правильно "инициализировать" данные в матвью. Можно создать матвью без populate, сохранив момент создания матвью (все данные "новее" будут автоматически приезжать в матвью) а потом доинициализировать старшие данные с помощью INSERT ... SELECT ... WHERE timestamp < mat_view_creation_ts.

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

Всем привет, может сталкивался кто-то, добавлял табличку ReplicatedMergeTree на одной из нод, таббикс повис, а после рестарта стали валиться ошибки вида 2018.07.11 09:36:57.253583 [ 1 ] <Warning> ZooKeeper: Error on attempt 0: connection loss. Retry 2018.07.11 09:37:07.254277 [ 1 ] <Warning> ZooKeeper: Error on attempt 1: connection loss. Retry 2018.07.11 09:37:17.257471 [ 1 ] <Warning> ZooKeeper: Error on attempt 2: connection loss. Retry 2018.07.11 09:37:17.259287 [ 1 ] <Error> Application: zkutil::KeeperException: connection loss, path: /clickhouse После это CH падает.

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

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

Другие не трогал пока, одну ноду мучаю

ну проверьте с нее коннект до зукипера через телнет

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

Не знаю какой там юзкейс у вас, но если представить себе что таблица имеет размер в несколько терабайт и данные в неё валятся со скоростью сотен тысяч строк в секунду, то идея "лока на запись" в эту таблицу пока инициализируется матвью (а оно при большой исходной таблице может часами инициализироваться) - выглядит так себе. Это можно сделать без локов, но задача не очень простая. Workaround существует и довольно тривиален, поэтому я так понимаю эта задача не приоритетна. Если вы считаете иначе - код Кликхауса открыт, пулл-реквесты принимаются :)

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

мерджи и создание новых партов* всё валить в один новый парт. вью проинициализировать из старых + текущих. потом снять лок на парты. всё.

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

Отличная идея. Можем расчитывать на пулл-реквест? :)

Не знаю какой там юзкейс у вас, но если представить себе что таблица имеет размер в несколько терабайт и данные в неё валятся со скоростью сотен тысяч строк в секунду, то идея "лока на запись" в эту таблицу пока инициализируется матвью (а оно при большой исходной таблице может часами инициализироваться) - выглядит так себе. Это можно сделать без локов, но задача не очень простая. Workaround существует и довольно тривиален, поэтому я так понимаю эта задача не приоритетна. Если вы считаете иначе - код Кликхауса открыт, пулл-реквесты принимаются :)

У нас как раз юзкейс где можно остановить запись т.к. стримим из кафки, а вот каждому аналитику объяснять как делать заполнение после создания вьюшки - это боль

Отличная идея. Можем расчитывать на пулл-реквест? :)

на плюсах не пишу( хотя возможно стоит начать

Аналогичная проблема с крестами :D

У нас как раз юзкейс где можно остановить запись т.к. стримим из кафки, а вот каждому аналитику объяснять как делать заполнение после создания вьюшки - это боль

"Каждому аналитику". Сорри, но если их много - то правильно ли было бы если бы все они могли менять структуру базы, выполняя DDL, на произвольное количество времени останавливая запись (для всех остальных)?

Если остановка записи допустима - то значит допустимо и отсутствие самых свежих данных в матвью. Отсюда вопрос - правда ли в этом кейсе необходим матвью?

Угу, на нашем объёме это минуты, плюс они не меняют структуру, они заводят под себя вьюшки, этакий self service

Eventual consistency здесь ок, а вот матвьюшки очень нужны т.к. исходный поток - события юзера, где потеря одного события может полностью исковеркать результат :(

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

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

смотря что вы имеете в виду

На каждом сервере есть таблицы в system

смотря что вы имеете в виду

Ну задетектить что нода упала

Мы это делаем другим способом

zabbix например

Он ещё и в нотификацию умеет

Eventual consistency здесь ок, а вот матвьюшки очень нужны т.к. исходный поток - события юзера, где потеря одного события может полностью исковеркать результат :(

У нас аналитики пишут запросы, а view / matview добавляют программисты. Если какой-то запрос аналитиков оказывается настолько замечательным что захотим его видеть в realtime - тогда и создается mat view. У матвью на самом деле есть немало ограничений, и поэтому далеко не из каждого запроса аналитиков можно сделать matview. Объяснять им какие есть ограничения и что можно считать в realtime, а что нет - в общем вещь не тривиальная. Если ваши аналитики настолько опытны в кликхаус, что понимают ограничения матвью, то и workaround с "ручным" populate для mat view не должен составлять проблемы.

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

Используйте внешние инструменты - nagios / zabbix / Pandora. Для метрик - например Grafana. См. https://www.altinity.com/blog/2018/4/20/clickhouse-monitoring-with-graphite https://groups.google.com/forum/#!topic/clickhouse/iwIWWPwneqM

Это на самом деле часть философии UNIX - каждый инструмент должен делать одну вещь, но должен делать её хорошо. Кликхаус - это база данных для аналитики. И делает это хорошо :)

А для мониторинга есть другие инструменты :)

возможно ли для типа float64 в функции toString, например, указать нужное количество цифр после запятой?

возможно ли для типа float64 в функции toString, например, указать нужное количество цифр после запятой?

можно так select toString(round(1234.5678, 2))

спасибо, но мне нужно нулями заполнить недостающие

Поделитесь, пожалуйста, Вашим опытом как правильно поддерживать масштабируемость и расширяемость ClickHouse c точки зрения DevOps. Мы переезжаем на новое железо - сейчас в CH 4 ноды (2 реплики 2 шарда + куча намешанных решений, большая разрозненность). Есть желание держать гомогенный кластер: все таблицы distributed, две реплики. Насколько это хорошая идея? Добавление нового железа в кластер должно быть относительно простым (возможно c апдейтом weights). Кластер может расти до десятков нод, мой вопрос: как правильно организовать фреймворк конфигов для реплик/шардов - или в любом случае это ручные изменения в .xml ?

С ручными изменениями - уже на двух серверах начинается боль - типа тут поправили, а там забыли. Почти все можно автоматизровать с помощью соотвествующих инструментов типа puppet / chef / ansible / salt / cfengine

Мы ансиблом рулит, он генерит конфиги кх

Мы ансиблом рулит, он генерит конфиги кх

Самописное что-то?

нет ансибл не самописный

нет ансибл не самописный

я имею в виду модули конечно же)

вроде не использую

там же конфиг простой

пару циклов и готово

ну и в целом у нас по себе кх простой

,

Похоже на то. https://github.com/yandex/ClickHouse/blob/d5f8e4a1a511fd0f55c9db3674056b5878e0e0d3/dbms/src/Storages/MergeTree/ReplicatedMergeTreeBlockOutputStream.cpp#L259 @milovidov_an действительно нельзя >1 кворумного инсерта одновременно?

Увы, нельзя. И это засада, если всё строится на обязательной кворумной записи, как у нас, например - больше одного потока записи не пустишь. И воркеры, которые иногда просыпаются чтобы внести корректировки в данные, в результате иногда спотыкаются - приходится это учитывать и повторять операцию.

Есть 2 таблички одинаковой структуры с частично дублирующимися записями, как скопировать данные в третью, но что бы все строки были уникальными. Кто знает?

CollapsingMergeTree ?

Есть 2 таблички одинаковой структуры с частично дублирующимися записями, как скопировать данные в третью, но что бы все строки были уникальными. Кто знает?

Например так: create table_c engine=... as select ... from (select * from table_a union all select * from table_b) group by ...

или insert as (select ... union select ...)

так если union all, то дубликаты не удалятся

так группирнуть надо

чтоб дубликаты схлопнуть

Или движок Merge https://clickhouse.yandex/docs/en/table_engines/merge/ с последующим GROUP BY.

таблички GraphiteMergeTree Спасибо, буду пробовать.

Увы, нельзя. И это засада, если всё строится на обязательной кворумной записи, как у нас, например - больше одного потока записи не пустишь. И воркеры, которые иногда просыпаются чтобы внести корректировки в данные, в результате иногда спотыкаются - приходится это учитывать и повторять операцию.

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

Возможно так сделано чтобы не было колизий с фоновыми слияниями.

так если union all, то дубликаты не удалятся

"Only UNION ALL is supported. The regular UNION (UNION DISTINCT) is not supported."

Поэтому UNION ALL + GROUP BY

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

Спасибо обоим. Ушёл думать о том, как жить дальше.

Добрый день! Столкнулась с такой задачей по связи mongobd и внешних словарей. Можно ли как-то описать словарь, чтобы вытащить в атрибут вложенное поле или поле элемента массива? Например есть коллекция со структурой {"name" : "user", "details" : {"sex" : "male", "age" : 20}, "languages" : [{"name" : "java", "lines" : 10000}, {"name" : "c", "lines" : 6000}]}. Во-первых, интересует, как сделать атрибутом словаря, например, пол. Во-вторый, возможно ли сделать словарь из элементов массива languages с соответствующими атрибутами name и lines? В документации подобного не нашла, буду крайне признательна за ответ.

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

как долго нужно ждать для удаления данных с системной таблици system.mutations ?

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

как долго нужно ждать для удаления данных с системной таблици system.mutations ?

Пока parts_to_do не опуститься до 0 и is_done не станет 1

Ага, это значит, что мутация полностью выполнилась. Но сама запись о мутации будет висеть.

а кто нибудь расширял зукипер с 3 нод до 5 ? нет ли каких то проблем?

Есть способ выполнить OPTIMIZE TABLE, который падает по памяти? Code: 241. DB::Exception: Received from localhost:9000, ::1. DB::Exception: Memory limit (for query) exceeded: would use 12.11 GiB (attempt to allocate chunk of 131072 bytes), maximum: 12.11 GiB: (while reading column originalUrl): (while reading from part /clickHouse/clickhouse/data/default/prodstats/20160715_20160715_61128_61128_0/ from mark 0 with max_rows_to_read = 8192). Размер указаного парта на диске 2.1 Мб

Странно. Он вроде во время слияний сильно память не ест. Или у вас какие-то сложные агрегации при слияниях? Да и размер части небольшой...

Странно. Он вроде во время слияний сильно память не ест. Или у вас какие-то сложные агрегации при слияниях? Да и размер части небольшой...

Я на такое поведение натыкался при обычных запросах, что-то типа SELECT url FROM table WHERE id = 1 LIMIT 1 и такой запрос выедал 10 Гб и падал. Хотя видно что вернуть должно одну запись. И куда делись 10 Гб - не ясно (до сих пор)

может парт битый? select <не помню как размер посмотреть> from prodstats where _part = '20160715_20160715_61128_61128_0'

или в system.parts на этот кусок глянуть

Есть способ выполнить OPTIMIZE TABLE, который падает по памяти? Code: 241. DB::Exception: Received from localhost:9000, ::1. DB::Exception: Memory limit (for query) exceeded: would use 12.11 GiB (attempt to allocate chunk of 131072 bytes), maximum: 12.11 GiB: (while reading column originalUrl): (while reading from part /clickHouse/clickhouse/data/default/prodstats/20160715_20160715_61128_61128_0/ from mark 0 with max_rows_to_read = 8192). Размер указаного парта на диске 2.1 Мб

select sum(cityHash64(originalUrl)) from default.prodstats where _part = '20160715_20160715_61128_61128_0'

может парт битый? select <не помню как размер посмотреть> from prodstats where _part = '20160715_20160715_61128_61128_0'

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

да по идее норм

Ну сумма и сумма :) главное что прочиталось. А в логах сервера нет чего-то интересного?

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

я бы попробовал отцепить этот part и сделать optimize без него

ну или просто сделать detach partition и attach partition, может прочекает этот кусок, если что отцепит, скачает с другой реплики...

Ну сумма и сумма :) главное что прочиталось. А в логах сервера нет чего-то интересного?

Таблица prodstats типа ReplacingMergeTree, сегодня перезалили большой кусок данных за несколько месяцев из прошлого, залили не сильно большими кусками и словили ошибку "Too much parts". Стали выполнять ручками OPTIMIZE TABLE и словили указаную выше ошибку

ну или просто сделать detach partition и attach partition, может прочекает этот кусок, если что отцепит, скачает с другой реплики...

У нас нет репликации (похоже это очередной сигнал сделать её)

я бы попробовал отцепить этот part и сделать optimize без него

Спасибо, буду пробовать

Странно. Он вроде во время слияний сильно память не ест. Или у вас какие-то сложные агрегации при слияниях? Да и размер части небольшой...

Это больше всего и напрягает. Спасибо