Всем привет! Описываю конфиг внешнего словаря, там нужно указать null_value для атрибута. Какой валидный null_value для DateTime? Такой вариант падает с ошибкой: <attribute> <name>start_time</name> <type>DateTime</type> <null_value>NULL</null_value> </attribute> .

<null_value>0000-00-00 00:00:00</null_value>

<null_value>0000-00-00 00:00:00</null_value>

Спасибо!

Коллеги, есть кластер два шарда по две реплики. Шардирование и репликация через zookeeper. Страшен ли clickhous`у split brain реплик в каждом шарде в случае когда данные льются постоянно на обе реплики, а связь между репликами оборвалась? Или после восстановления связи просто все безболезнено синхронизируется? Есть ли у zookeeper`а какие-то общие данные, которые могут поломаться в таком случае?

Если оборвалась связь между репликами, то они синхронизируются после восстановления. Если оборвалась связь с ЗуКипером, то таблицы перейдут в режим read_only

Оказалось, что в запросах потерян ордеринг по дате, с ним и первый запрос падает по памяти:) Без ордеринга такие запросы не имеют смысла, но просто чтобы воспроизвести ситуацию, сделала совсем простой вариант - без ордера и только с одним типом ивентов. На нём можно увидеть, что есть разница по памяти. https://gist.github.com/svpetrova/b82880ceeba395d0ffa26356d78bd84b

Попробуйте уменьшить max_block_size для этого селекта. В том примере который вы прислали - при уменьшении до 1024 использование памяти при чтении из таблицы ниже чем в первом примере. Кстати там этот rand() который вы используете в примере - "не совсем" случаен :)

В КХ если агрументы функции отсуствуют или = константе, то функция вычисляется один раз.

Поэтому rand умеет принимать агрументы :)

Too large array size while reading from ZooKeeper такое вываливается на старте и сервер останавливается нужно ноду дропать руками?

Коллеги, есть кластер два шарда по две реплики. Шардирование и репликация через zookeeper. Страшен ли clickhous`у split brain реплик в каждом шарде в случае когда данные льются постоянно на обе реплики, а связь между репликами оборвалась? Или после восстановления связи просто все безболезнено синхронизируется? Есть ли у zookeeper`а какие-то общие данные, которые могут поломаться в таком случае?

Это полностью Ок. Split brain - штатная ситуация. Сначала обе реплики будут содержать неполные данные, потом нальют недостающие данные друг с друга. Если какая-то реплика не видит по сети кворума zookeeper нод, то на неё не получится вставлять данные.

Спасибо

А как себя поведет КХ если я вставляю блок данных из разных партиций, но ДО лимита в 1 млн строк (что бы данные одним блоком отправились с клиента) и вот возникла ошибка во время вставки, либо вставка была прервана, то данные запишутся частично или нет? Просто у меня сейчас подозрение, что если данные из разных партиций, то он частично пишет данные. Т.е. я отправляю запрос на инсерт большого куска данных ДО 1 млн строк и у меня как-то каждую секунду увеличивается количество строк в таблице (пишу в один поток).

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

Too large array size while reading from ZooKeeper такое вываливается на старте и сервер останавливается нужно ноду дропать руками?

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

это вообще неиспользуемая таблица, в нее писали последний раз месяца два назад

непонятно, почему началось какое-то движение там

zk ls: WatchedEvent state:SyncConnected type:None path:null 2018-09-19 14:42:43,714 [myid:] - WARN [main-SendThread(localhost:2181):ClientCnxn$SendThread@1168] - Session 0xc004dc897660047 for server localhost/127.0.0.1:2181, unexpected error, closing socket connection and attempting reconnect java.io.IOException: Packet len18875288 is out of range! at org.apache.zookeeper.ClientCnxnSocket.readLength(ClientCnxnSocket.java:113) at org.apache.zookeeper.ClientCnxnSocketNIO.doIO(ClientCnxnSocketNIO.java:79) at org.apache.zookeeper.ClientCnxnSocketNIO.doTransport(ClientCnxnSocketNIO.java:366) at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1145) WATCHER:: WatchedEvent state:Disconnected type:None path:null Exception in thread "main" org.apache.zookeeper.KeeperException$ConnectionLossException: KeeperErrorCode = ConnectionLoss for /clickhouse/tables/0/table_foo_replicated/log at org.apache.zookeeper.KeeperException.create(KeeperException.java:102) at org.apache.zookeeper.KeeperException.create(KeeperException.java:54) at org.apache.zookeeper.ZooKeeper.getChildren(ZooKeeper.java:1541) at org.apache.zookeeper.ZooKeeper.getChildren(ZooKeeper.java:1569) at org.apache.zookeeper.ZooKeeperMain.processZKCmd(ZooKeeperMain.java:732) at org.apache.zookeeper.ZooKeeperMain.processCmd(ZooKeeperMain.java:600) at org.apache.zookeeper.ZooKeeperMain.run(ZooKeeperMain.java:363) at org.apache.zookeeper.ZooKeeperMain.main(ZooKeeperMain.java:291)

Вот это - проблемная нода: /clickhouse/tables/0/table_foo_replicated/log У ней накопилось слишком много детей, потому что у таблицы table_foo_replicated есть заброшенная реплика. > это вообще неиспользуемая таблица, в нее писали последний раз месяца два назад Не могу ничего сказать. Лог обновляется только при записи в таблицу.

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

а почему тогда create table p(a Int64, b Int64) engine=MergeTree partition by a%103 order by tuple(); insert into p select number,throwIf(number=999998) from numbers(1000000); select count() from p; 0 rows in set. Elapsed: 0.001 sec. потому что insert select и select обламывается?

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

Эх :( спасибо! Будем думать как быть

Эх :( спасибо! Будем думать как быть

Если используете Replicated таблицу, то после ошибки, следует просто повторить весь батч.

Если используете Replicated таблицу, то после ошибки, следует просто повторить весь батч.

Не, обычная таблица (

Вот это - проблемная нода: /clickhouse/tables/0/table_foo_replicated/log У ней накопилось слишком много детей, потому что у таблицы table_foo_replicated есть заброшенная реплика. > это вообще неиспользуемая таблица, в нее писали последний раз месяца два назад Не могу ничего сказать. Лог обновляется только при записи в таблицу.

а что значит “заброшенная”? если я просто выведу машину из кластера, этого недостаточно?

а почему тогда create table p(a Int64, b Int64) engine=MergeTree partition by a%103 order by tuple(); insert into p select number,throwIf(number=999998) from numbers(1000000); select count() from p; 0 rows in set. Elapsed: 0.001 sec. потому что insert select и select обламывается?

Думаю, что да. После SELECT блоки сначала склеиваются до max_insert_block_size. До этого момента есть исключение. В результате ничего не вставляется. До разбиения блоков по партициям, дело не доходит.

а что значит “заброшенная”? если я просто выведу машину из кластера, этого недостаточно?

Да, раньше было недостаточно. Потому что, если сервер исчез - наверное он может подняться. И случай, когда сервер исчез навсегда, от этого не отличается. В ZooKeeper остаётся запись о реплике, и для реплики накапливаются логи. Недавно сделали доработку на эту тему: https://github.com/yandex/ClickHouse/blob/master/CHANGELOG_RU.md#%D0%A3%D0%BB%D1%83%D1%87%D1%88%D0%B5%D0%BD%D0%B8%D1%8F-1 И теперь проблем с заброшенными репликами нет :)

Привет! Можете подсказать merge() и union слишком различаются по производительности? При union'е распараллеливается запрос или нет?

И тот и другой распараллеливаются. Для маленького числа (несколько) таблиц разницы либо не будет, либо UNION ALL будет быстрее. Для большого количества таблиц лучше merge.

Спасибо!

Попробуйте уменьшить max_block_size для этого селекта. В том примере который вы прислали - при уменьшении до 1024 использование памяти при чтении из таблицы ниже чем в первом примере. Кстати там этот rand() который вы используете в примере - "не совсем" случаен :)

Спасибо, действительно, с уменьшенным max_block_size работает! И за пример с WITH и сортировкой массива большое спасибо!))

Кто-нибудь может подсказать, когда добавят табличную функцию MySQL ?

Для SELECTа из MySQL

Для SELECTа из MySQL

Дак она есть давно вроде бы

Дак она есть давно вроде бы

В Changelog-ах нет

В Changelog-ах нет

Там как правило много чего нет

У нас относительно свежий КХ (18.10), в нем нет её

Не хотелось бы обновляться просто так

есть табличная функция mysql, есть engine mysql

У нас относительно свежий КХ (18.10), в нем нет её

Уточните чего у вас нет? Уже давно естсь такое CREATE TABLE users ( _id String, username Strin) ENGINE = MySQL('localhost:3306', 'admin_stat', 'users', 'root', '') И делать селекты из users как из обычной КХ таблицы

Табличной функции

Релиз ClickHouse 1.1.54337, 2018-01-18 Добавлены табличные функции mysql и odbc и соответствующие движки таблиц MySQL, ODBC для обращения к удалённым базам данных. Функциональность в состоянии "бета". select * from system.table_functions where lower(name) like '%mysql%'

О, спасибо. Я смотрел в system.functions

О, спасибо. Я смотрел в system.functions

Так это из changelog'а же фраза

Ок, тогда такой вопрос. Использую табличную функцию mysql и получаю SELECT * FROM mysql('url:port', 'dbname', 'tablename', 'user', 'password') Received exception from server (version 18.10.54405): Code: 90. DB::Exception: Received from URL, IP DB::Exception: Empty list of columns passed. 0 rows in set. Elapsed: 0.080 sec. Что за лист колонок? В доках https://clickhouse.yandex/docs/ru/single/#mysql_1 про это ничего не сказано.

Всем привет, появилась проблема при запросах с табличной функцией odbc Code: 33, e.displayText() = DB::Exception: Cannot read all data. Bytes read: 239145. Bytes expected: 67905586., e.what() = DB::Exception Пробывал на MSSQL, PostgreSQL. Вроде началось после 18.12.17, никто не сталкивался?

всем, привет. Сталкивались ли вы с проблемами таймаутов в запросах? Делаю запрос из нативного клиента и он выполняется за 560+ секунд

тоже самое из питона валится по таймауту, хотя они выставлены в корректные значения

Коллеги, подскажите, как правильно, задать последовательность ключей при создании MergeTree. Есть три потенциальные колонки для ключа со следующими кардиналитити (кол-во уникальных значений/ общее кол-во строк): col1 - 0.001 col2 - 0.005 col3 - 0.010 Как правильнее будет сделать для большинства кейсов (в запросах могут присутсвовать все ключи или только некоторые с равной вероятностью). 1. (col1, col2, col3) так? 2. (col3, col2, col1) или так?

как правильно оживлять таблицы, для которых пропали данные в зк?

А по перфомансу string и fixed string сильно разные?

И еще e num)

А по перфомансу string и fixed string сильно разные?

https://www.youtube.com/watch?v=rqf-ILRgBdY Тут хорошо рассказывали.

Всем привет, появилась проблема при запросах с табличной функцией odbc Code: 33, e.displayText() = DB::Exception: Cannot read all data. Bytes read: 239145. Bytes expected: 67905586., e.what() = DB::Exception Пробывал на MSSQL, PostgreSQL. Вроде началось после 18.12.17, никто не сталкивался?

А можно подробностей -- конфиг драйверов, сам запрос?

select id from odbc('DSN=mssql;UID=xxx;PWD=yyy;', orders) заметил что если писать select * то запрос работает

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

С каким движком?

всем, привет. Сталкивались ли вы с проблемами таймаутов в запросах? Делаю запрос из нативного клиента и он выполняется за 560+ секунд

Может быть это тайм-аут сети/http клиента? Не самого кликхауса?

ODBC, такой есть, параметры как у табличной функции. Создаётся через create table, в конце ENGINE = ODBC(...)

Вообщем сломались запросы с явным указанием колонок, и обмануть с помощью подзапроса тоже не получается select id from (select * from odbc(...))

ODBC, такой есть, параметры как у табличной функции. Создаётся через create table, в конце ENGINE = ODBC(...)

В доках про него ничего нет, но видимо он аналогичен движку MySql, я правильно понимаю?

Да, так и есть. В любом случае проверю табличную функцию.

Коллеги, подскажите, как правильно, задать последовательность ключей при создании MergeTree. Есть три потенциальные колонки для ключа со следующими кардиналитити (кол-во уникальных значений/ общее кол-во строк): col1 - 0.001 col2 - 0.005 col3 - 0.010 Как правильнее будет сделать для большинства кейсов (в запросах могут присутсвовать все ключи или только некоторые с равной вероятностью). 1. (col1, col2, col3) так? 2. (col3, col2, col1) или так?

1 будет скорее всего будет лучше жаться и скорее всего будет лучше справляться с поиском по частичному ключу. В общем случае после ключей с высоким кардиналити добавлять что-то ещё обычно довольно бессмысленно.

Спасибо

Спасибо

Тут в документации есть про выбор PK: https://clickhouse.yandex/docs/ru/operations/table_engines/mergetree/#_5

А уже появилась возможность создавать пользовательские кастомные функции (udf user define function) ? Или весь странный кастом выносить в апп слой, например если нужна алгебра на OpenCl GPU

Да, так и есть. В любом случае проверю табличную функцию.

Через таблицу работает

Ок

А уже появилась возможность создавать пользовательские кастомные функции (udf user define function) ? Или весь странный кастом выносить в апп слой, например если нужна алгебра на OpenCl GPU

Нет и не предвидится. Довольно легко можно дописать что-то своё до кода КХ если можете C++. Если это что-то нужное не только вам - можно сделать пулл реквест и добавить функцию к основному коду. Ещё как вариант (оч. медленный) можно внешнюю логику подцепить как словарь (http/executable), и тогда можно в чем угодно ее написать.

Нет и не предвидится. Довольно легко можно дописать что-то своё до кода КХ если можете C++. Если это что-то нужное не только вам - можно сделать пулл реквест и добавить функцию к основному коду. Ещё как вариант (оч. медленный) можно внешнюю логику подцепить как словарь (http/executable), и тогда можно в чем угодно ее написать.

хорошо было бы хотя бы сделать вычисления лямбды над arrays

хорошо было бы хотя бы сделать вычисления лямбды над arrays

Ну arrayMap вроде как уже давным-давно есть ? https://clickhouse.yandex/docs/en/query_language/functions/higher_order_functions/

Ну arrayMap вроде как уже давным-давно есть ? https://clickhouse.yandex/docs/en/query_language/functions/higher_order_functions/

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

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

Да, наверное что-то типа arrayMapWithAccumulator или arrayInplaceModify могли бы порой быть полезны .

Да, наверное что-то типа arrayMapWithAccumulator или arrayInplaceModify могли бы порой быть полезны .

+1

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

Ну вообще говоря можно. Через логарифмы в суммы перевести. Есть еще arrayReduce — но она недоделана. Вот ее бы доделать

Мы недавно начали использовать версию 18.14.12 вместо 1.1.54388 на 1/3 кластера и заметили увеличенное количество ошибок вида Memory limit (total) exceeded: would use 30.00 GiB (attempt to allocate chunk of 2097152 bytes), maximum: 30.00 GiB когда мы вставляем в ClickHouse Подскажите пожалуйста, в новой версии или в предыдущей - могло ли измениться значительно потребление памяти или другая причина почему мы ловим такие ошибки? Ошибки видны только на 1/3 кластера где новая версия, старые 2/3 кластера нету таких ошибок @milovidov_an @kochetovnicolai

а у этого на текуший момент какой статус? https://github.com/yandex/ClickHouse/issues/520 вот этот совет отсюда (https://groups.google.com/forum/#!topic/clickhouse/uq9891JyV7M) все еще актуален? кх 12.14 Write <background_pool_size>4</background_pool_size> at /profiles/default in users.xml file and restart the server.

что-то сегодня у меня одни сплошные проблемы, и я все транслирую сюда)

Мы недавно начали использовать версию 18.14.12 вместо 1.1.54388 на 1/3 кластера и заметили увеличенное количество ошибок вида Memory limit (total) exceeded: would use 30.00 GiB (attempt to allocate chunk of 2097152 bytes), maximum: 30.00 GiB когда мы вставляем в ClickHouse Подскажите пожалуйста, в новой версии или в предыдущей - могло ли измениться значительно потребление памяти или другая причина почему мы ловим такие ошибки? Ошибки видны только на 1/3 кластера где новая версия, старые 2/3 кластера нету таких ошибок @milovidov_an @kochetovnicolai

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

какой лучший способ посмотреть исторически сколько запросов выполнялось? возможно ли через query_log?

а у этого на текуший момент какой статус? https://github.com/yandex/ClickHouse/issues/520 вот этот совет отсюда (https://groups.google.com/forum/#!topic/clickhouse/uq9891JyV7M) все еще актуален? кх 12.14 Write <background_pool_size>4</background_pool_size> at /profiles/default in users.xml file and restart the server.

На 10 GB сети, репликация может использовать несколько соединений и из-за этого существенно тормозить диски. Это актуально, но возникает далеко не всегда (должно совпасть несколько условий). Если вы подтверждаете все проблемы - что у вас 10 GBit сеть, что диски перегружены, и что репликация использует слишком много соединений (метрики ReplicatedFetch и ReplicatedSend в system.metrics), при этом версия ClickHouse достаточно свежая, то стоит уменьшить background_pool_size.

какой лучший способ посмотреть исторически сколько запросов выполнялось? возможно ли через query_log?

Самый простой - если выгружаются метрики (в конфиге, секция graphite). Если нет - можно и через query_log. Сейчас напишу...

The allocator has been replaced: jemalloc is now used instead of tcmalloc. In some scenarios, this increases speed up to 20%. However, there are queries that have slowed by up to 20%. Memory consumption has been reduced by approximately 10% in some scenarios, with improved stability. With highly competitive loads, CPU usage in userspace and in system shows just a slight increase. #2773 Могло ли это повлиять отрицательно на размер потребляемой памяти?

разный аллокатор согласно system.build_options

The allocator has been replaced: jemalloc is now used instead of tcmalloc. In some scenarios, this increases speed up to 20%. However, there are queries that have slowed by up to 20%. Memory consumption has been reduced by approximately 10% in some scenarios, with improved stability. With highly competitive loads, CPU usage in userspace and in system shows just a slight increase. #2773 Могло ли это повлиять отрицательно на размер потребляемой памяти?

Это не может повлиять на величину отслеживаемой потребляемой памяти, так как она не зависит от аллокатора. Может повлиять на RSS, который содержит также куски памяти, которые алокатор кэширует, а не отдаёт системе (оставляет в "куче"). В остальном, jemalloc чуть-чуть менее прожорлив, чем tcmalloc.

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

select query_start_time + arrayJoin(range(toUInt64(ceil(query_duration_ms / 1000)))) AS time, count() FROM system.query_log WHERE event_time >= '2015-07-31 11:14:00' AND event_time < '2015-07-31 11:16:00' AND event_date = '2015-07-31' AND type IN (2, 4) GROUP BY time ORDER BY time

На 10 GB сети, репликация может использовать несколько соединений и из-за этого существенно тормозить диски. Это актуально, но возникает далеко не всегда (должно совпасть несколько условий). Если вы подтверждаете все проблемы - что у вас 10 GBit сеть, что диски перегружены, и что репликация использует слишком много соединений (метрики ReplicatedFetch и ReplicatedSend в system.metrics), при этом версия ClickHouse достаточно свежая, то стоит уменьшить background_pool_size.

нет, у меня 1GB-сеть и не загружен диск, просто #520 - единственный баг, который ищется по DB::Exception: Cannot write to ostream at offset N

причем они (оффсеты) повторяются периодически

и background_pool_size выставил в 4, ничего не поменялось

нет, у меня 1GB-сеть и не загружен диск, просто #520 - единственный баг, который ищется по DB::Exception: Cannot write to ostream at offset N

У вас другая проблема.

@milovidov_an в среднем новая версия имеет меньшее количество выполняющихся запросов чем старая, процентов так на 20% но это не совсем объясняет как оно негативно влияет на ту ошибку про память

@milovidov_an в среднем новая версия имеет меньшее количество выполняющихся запросов чем старая, процентов так на 20% но это не совсем объясняет как оно негативно влияет на ту ошибку про память

Посмотрите в SHOW PROCESSLIST. Правда ли, что в сумме потребление оперативки достигает 30 GB? Или это враньё из-за неправильного подсчёта, на который недавно жаловались?

нет, у меня 1GB-сеть и не загружен диск, просто #520 - единственный баг, который ищется по DB::Exception: Cannot write to ostream at offset N

Я не нашёл вашего предыдущего сообщения с описанием ошибки. А в каком контексте это возникает?

Я не нашёл вашего предыдущего сообщения с описанием ошибки. А в каком контексте это возникает?

Посмотрел логи повнимательнее - последовательность примерно такая: // это все в одном треде логируется (MergerMutator): Merging 8 parts: from 20180919_20180919_432419_432419_0 to 20180918_20180919_432426_432426_0 into tmp_merge_20180918_20180919_432419_432426_1 (MergerMutator): Selected MergeAlgorithm: Horizontal (MergerMutator): Merge sorted 288 rows (Data): Undoing transaction. Removing parts: 20180918_20180919_432419_432426_1 (StorageReplicatedMergeTree): DB::StorageReplicatedMergeTree::queueTask()::<lambda(DB::StorageReplicatedMergeTree::LogEntryPtr&)>: Code: 999, e.displayText() = Coordination::Exception: Transaction failed (No node): Op #4, path: /clickhouse/tables/1/table_replicated/replicas/node2/parts/20180918_20180919_432419_432426_1, e.what() = Coordination::Exception // дальше такая ошибка из другого треда InterserverIOHTTPHandler: Code: 24, e.displayText() = DB::Exception: Cannot write to ostream at offset 4032160 и так по кругу

оффсеты повторяются время от времени, как и имена src/dest кусков для мержа

зукипер?

@milovidov_an потребление памяти запросами не выглядит так что доходит до 30 GiB, всего лишь 7 GiB суммарно в течении интервала а что за проблема с неправильным подсчетом памяти? есть детали / github issue

https://github.com/yandex/ClickHouse/issues/3143