а с ним остановилась вся работа кластера

в логах ЗуКипера: java.lang.OutOfMemoryError: GC overhead limit exceeded

по связке zookeeper java.lang.OutOfMemoryError: GC overhead limit exceeded - гугл ничего полезного не выдал

на машине зукипера установлено 8 Гб рама

по связке zookeeper java.lang.OutOfMemoryError: GC overhead limit exceeded - гугл ничего полезного не выдал

zookeeper тут и не при чем, просто в гугле: java GC overhead limit exceeded

Здравствуйте, подскажите пожлуйста где можно скачать ClickHouse ODBC драйвер для Windows?

Привет! Помнится, несколько месяцев назад была бага с отваливающейся репликацией, если хост указан в виде ip. В чейнжлоге не нашел, это пофиксили?

Здравствуйте, подскажите пожлуйста где можно скачать ClickHouse ODBC драйвер для Windows?

https://github.com/yandex/clickhouse-odbc/releases

Спасибо

Добрый день! Есть задача изменить у табличек Engine c ReplicatedSummingMergeTree на ReplicatedMergeTree. Делаю детач таблицы, захожу в zkCli, делаю get /clickhouse/metadata/.../metadata, вижу вот такое: metadata format version: 1 date column: event_date sampling expression: index granularity: 8192 mode: 2 sign column: primary key: event_ts, user_id, src_ip, dst_ip, host, method, url, user_agent вопрос: как правильно изменить метаданные?(в primary_key надо оставить только src_ip, event_ts) пытаюсь пересоздать с нуля и сделать set /clickhouse.. <параметр>, но не получается их собрать вместе, точнее когда делаю гет, то вижу тлько последнее значение. Может кто подскажет как сразу несколько строк в set засунуть? Спасибо

Коллеги, а расширить первичный ключ (было одно поле,нужен кортеж) на лету у мерджтри можно или пересоздавать таблицы с перезаливкой?

Коллеги, а расширить первичный ключ (было одно поле,нужен кортеж) на лету у мерджтри можно или пересоздавать таблицы с перезаливкой?

Менять первичный ключи нельзя https://clickhouse.yandex/docs/ru/query_language/queries.html?highlight=%D0%BF%D0%B5%D1%80%D0%B2%D0%B8%D1%87%D0%BD%D1%8B%D0%B9#alter "Отсутствует возможность удалять столбцы, входящие в первичный ключ или ключ для сэмплирования (в общем, входящие в выражение ENGINE)."

Спасибо, буду перезаливать данные тогда

Менять первичный ключи нельзя https://clickhouse.yandex/docs/ru/query_language/queries.html?highlight=%D0%BF%D0%B5%D1%80%D0%B2%D0%B8%D1%87%D0%BD%D1%8B%D0%B9#alter "Отсутствует возможность удалять столбцы, входящие в первичный ключ или ключ для сэмплирования (в общем, входящие в выражение ENGINE)."

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

Всем привет, может кто сталкивался с проблемой в tableau, при попытке получить данные из КХ вываливается такая ошибка HTTP status code: 500 Received error: Code: 62, e.displayText() = DB::Exception: Syntax error: failed at position 8 (line 1, col 8): {fn LTRIM({fn CONVERT(Custom_SQL_Query.offer_category, SQL_VARCHAR)})} AS offer_category, Custom_SQL_Query.platform AS `plat. Unrecognized token, e.what() = DB::Exception Unable to create extract

Привет. Столкнулся с очень странной проблемой потери данных в одном из Meterialized view на одном из шардов. Детальнее описана вот в этой теме только что - https://groups.google.com/d/topic/clickhouse/DpRGKhJgB_8/discussion У меня вообще нет идей, куда копать, и что теперь делать, кроме отказа от этого VIEW. Он, конечно, не очень нужный, но начинаю опасаться, что это повторится где-то еще. Куда стоит посмотреть?

Всем привет, может кто сталкивался с проблемой в tableau, при попытке получить данные из КХ вываливается такая ошибка HTTP status code: 500 Received error: Code: 62, e.displayText() = DB::Exception: Syntax error: failed at position 8 (line 1, col 8): {fn LTRIM({fn CONVERT(Custom_SQL_Query.offer_category, SQL_VARCHAR)})} AS offer_category, Custom_SQL_Query.platform AS `plat. Unrecognized token, e.what() = DB::Exception Unable to create extract

Посмотри какой именно запрос формирует табло к КХ. Help -> Settings and Performance -> Start performance recording Если понятнее не станет, то прямо в custom_sql нужно сделать преобразования к нужным типам, чтобы odbc этим не занимался. Также проверь, что у тебя последняя версия odbc-драйвера.

Привет. Столкнулся с очень странной проблемой потери данных в одном из Meterialized view на одном из шардов. Детальнее описана вот в этой теме только что - https://groups.google.com/d/topic/clickhouse/DpRGKhJgB_8/discussion У меня вообще нет идей, куда копать, и что теперь делать, кроме отказа от этого VIEW. Он, конечно, не очень нужный, но начинаю опасаться, что это повторится где-то еще. Куда стоит посмотреть?

@milovidov_an, @ztlpn это не может быть продолжением проблем репликации, исправленными перед НГ? Я уже обновлялся до всех вставок, версия 1.1.54327.

Посмотри какой именно запрос формирует табло к КХ. Help -> Settings and Performance -> Start performance recording Если понятнее не станет, то прямо в custom_sql нужно сделать преобразования к нужным типам, чтобы odbc этим не занимался. Также проверь, что у тебя последняя версия odbc-драйвера.

- Версия odbc последняя - Запросы в custom_sql выполняются без ошибок Но при использование агрегации в Табло ошибки сразу появляются, например посчитать сумму валится ошибка, при агрегации Табло сама делает приведение типов и как итог ошибка HTTP status code: 500 Received error: Code: 62, e.displayText() = DB::Exception: Syntax error: failed at position 12 (line 1, col 12): {fn CONVERT(Custom_SQL_Query.amount, SQL_BIGINT)}) AS sum_amount FROM ( SELECT purchase, offer, SUM(. Unrecognized token, e.what() = DB::Exception

а можно целиком запрос показать ?

а можно целиком запрос показать ?

SELECT SUM({fn CONVERT(Custom_SQL_Query.amount, SQL_BIGINT)}) AS sum_amount FROM ( SELECT purchase_date, offer_category, SUM(amount) AS amount, COUNT(DISTINCT purchase_id) AS purchase_id FROM purchase_stat WHERE (purchase_date >= toDate('2017-01-01')) AND (offer_category = 1) GROUP BY purchase_date, offer_category ) Custom_SQL_Query HAVING (COUNT(1) > 0)

Табло генерирует враппер-куери поверх кастом куери. Во враперах оно достаёт поля используемые в отчетах.

Оно также производит преобразование типов

Полагаю {fn convert... big_int} не распознается кх

сделал просто подсчет записей и все отработало без ошибок SELECT COUNT(Custom_SQL_Query.amount) AS sum_amount FROM ( SELECT purchase_date, offer_category, SUM(amount) AS amount, COUNT(DISTINCT purchase_id) AS purchase_id FROM purchase_stat WHERE (purchase_date >= toDate('2017-01-01')) AND (offer_category = 1) GROUP BY purchase_date, offer_category ) Custom_SQL_Query HAVING (COUNT(1) > 0)

Попробуйте использовать другой тип для этого поля

Вы также можете подсчитать это значение в самой куере

сделал просто подсчет записей и все отработало без ошибок SELECT COUNT(Custom_SQL_Query.amount) AS sum_amount FROM ( SELECT purchase_date, offer_category, SUM(amount) AS amount, COUNT(DISTINCT purchase_id) AS purchase_id FROM purchase_stat WHERE (purchase_date >= toDate('2017-01-01')) AND (offer_category = 1) GROUP BY purchase_date, offer_category ) Custom_SQL_Query HAVING (COUNT(1) > 0)

?

Попробуйте использовать другой тип для этого поля

пробовал разные преобразования, но все валится

ни у кого больше проблем с CONVERT() не возникало ?

Нашел проблему, мой косяк

пытался получить данные в Live режиме

в режиме Extract все работает

нет, проблемы в odbc драйвере, уже частично исправлены, в следующем релизе должно будет работать

импортирую в FixedString строку вида \x00\x00\x00 - в формате TSV нормально, в CSV ругается 'Code: 131. DB::Exception: Too large value for FixedString'. Подскажите, пожалуйста - это баг, или фича?

нет, проблемы в odbc драйвере, уже частично исправлены, в следующем релизе должно будет работать

А у вас появился разработчик на одбс? Алексей говорил его собирались нанять

совсем только на odbc - нет. А проблему этого запроса я уже исправляю.

совсем только на odbc - нет. А проблему этого запроса я уже исправляю.

?

Ребят, а подскажите где искать/установить настройку experimental_allow_extended_storage_definition_syntax И такой вопрос если в новом синтаксисе для партиционирования я укажу поле которое имее тип Date без функций, партиционирование же по дням будет? CREATE TABLE default.test ( ed Date DEFAULT today(), id String, ge Array(UInt64) DEFAULT array(1148), ai Array(String) DEFAULT array(''), bf Int64 ) ENGINE = MergeTree PARTITION BY ed ORDER BY (ed, ge, ai)

Ребят, а подскажите где искать/установить настройку experimental_allow_extended_storage_definition_syntax И такой вопрос если в новом синтаксисе для партиционирования я укажу поле которое имее тип Date без функций, партиционирование же по дням будет? CREATE TABLE default.test ( ed Date DEFAULT today(), id String, ge Array(UInt64) DEFAULT array(1148), ai Array(String) DEFAULT array(''), bf Int64 ) ENGINE = MergeTree PARTITION BY ed ORDER BY (ed, ge, ai)

Просто запрос set experimental_allow_extended_storage_definition_syntax=1

благодарю

Привет. Столкнулся с очень странной проблемой потери данных в одном из Meterialized view на одном из шардов. Детальнее описана вот в этой теме только что - https://groups.google.com/d/topic/clickhouse/DpRGKhJgB_8/discussion У меня вообще нет идей, куда копать, и что теперь делать, кроме отказа от этого VIEW. Он, конечно, не очень нужный, но начинаю опасаться, что это повторится где-то еще. Куда стоит посмотреть?

Судя по логам, при вставке в этот MV почему-то включается агрегация с экономией памяти. Это возможно в двух случаях: если включена агрегация во внешней памяти или если агрегация идёт из Distributed таблицы и включена настройка distributed_aggregation_memory_efficient. Именно такой способ агрегации при вставке даёт много блоков (в 256 раз больше), отсюда и ошибки too many parts.

Судя по логам, при вставке в этот MV почему-то включается агрегация с экономией памяти. Это возможно в двух случаях: если включена агрегация во внешней памяти или если агрегация идёт из Distributed таблицы и включена настройка distributed_aggregation_memory_efficient. Именно такой способ агрегации при вставке даёт много блоков (в 256 раз больше), отсюда и ошибки too many parts.

Агрегация - из локальной таблицы. Опция выключена. Вьюшка - не самая большая, неясно, почему именно она не влезает. Да и суммарный объем данных за месяц там сравним с RAM сервера, не говоря уже про отдельные блоки вставки. <!-- Default settings. --> <default> <!-- Maximum memory usage for processing single query, in bytes. --> <max_memory_usage>26000000000</max_memory_usage> <max_bytes_before_external_group_by>9000000000</max_bytes_before_external_group_by> <max_bytes_before_external_sort>9000000000</max_bytes_before_external_sort> <!-- <aggregation_memory_efficient_merge_threads>2</aggregation_memory_efficient_merge_threads>--> <!-- Use cache of uncompressed blocks of data. Meaningful only for processing many of very short queries. --> <use_uncompressed_cache>0</use_uncompressed_cache> <load_balancing>random</load_balancing> </default>

┌─name────────────────────────────────────────┬─value─┬─changed─┐ │ distributed_aggregation_memory_efficient │ 0 │ 0 │

Ага, внешняя агрегация включена. Осталось понять, почему она срабатывает

второй вопрос, который мне гораздо интереснее - куда молча теряется 1-2% данных ?

объем бакетов, видно в логах - крошечный.

ls -alhS 20180112_20180112_977266_977266_0|head -n 10 total 864K drwxr-x--- 1750 clickhouse clickhouse 268K Jan 12 19:24 .. drwxr-x--- 2 clickhouse clickhouse 4.0K Jan 12 19:16 . -rw-r----- 1 clickhouse clickhouse 3.0K Jan 12 19:16 checksums.txt -rw-r----- 1 clickhouse clickhouse 2.8K Jan 12 19:16 columns.txt -rw-r----- 1 clickhouse clickhouse 1.2K Jan 12 19:16 country_region.bin -rw-r----- 1 clickhouse clickhouse 1.2K Jan 12 19:16 browser_combined.bin -rw-r----- 1 clickhouse clickhouse 1.1K Jan 12 19:16 os_version.bin -rw-r----- 1 clickhouse clickhouse 968 Jan 12 19:16 browser_name.bin -rw-r----- 1 clickhouse clickhouse 719 Jan 12 19:16 region.bin

То есть, конкретное значение max_bytes_before_external_group_by вряд ли на что-то влияет.

а какая у вас версия?

1.1.54327

напомню, что при таком же конфиге на таком же сервере такая же, но нереплицируемая вьюшкам - такого эффекта не дает. и ошибок нет, и данные не теряются.

А приведите пожалуйста конфиг кластера и DDL таблиц (можно в личку)

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

Спасибо, посмотрю

Возможно, это тоже будет интересно: 2018.01.12 20:35:08.855316 [ 1679 ] <Trace> virtual DB::MergingAndConvertingBlockInputStream::~MergingAndConvertingBlockInputStream(): Waiting for threads to finish 2018.01.12 20:35:08.856471 [ 1679 ] <Trace> InterpreterSelectQuery: FetchColumns -> Complete 2018.01.12 20:35:08.857878 [ 1679 ] <Trace> Aggregator: Aggregating 2018.01.12 20:35:08.858632 [ 1679 ] <Trace> Aggregator: Aggregation method: concat 2018.01.12 20:35:09.100571 [ 1679 ] <Trace> Aggregator: Converting aggregation data to two-level. 2018.01.12 20:35:09.120882 [ 1679 ] <Debug> Aggregator: Writing part of aggregation data into temporary file /home/clickhouse/tmp/tmp9257xpgaaa. ... 2018.01.12 20:35:09.293185 [ 1679 ] <Trace> Aggregator: Max size of temporary block: 373 rows, 6144.211 MiB. 2018.01.12 20:35:09.294223 [ 1679 ] <Trace> Aggregator: Written part in 0.190 sec., 83664 rows, 38.541 MiB uncompressed, 3.837 MiB compressed, 483.040 uncompressed bytes per row, 48.086 compressed bytes per row, compression rate: 10.045 (440637.099 rows/sec., 202.985 MiB/sec. uncompressed, 20.207 MiB/sec. compressed) 2018.01.12 20:35:09.294297 [ 1679 ] <Trace> Aggregator: Aggregated. 386881 to 0 rows (from 666.505 MiB) in 0.436 sec. (886610.078 rows/sec., 1527.422 MiB/sec.) 2018.01.12 20:35:09.294543 [ 1679 ] <Trace> AggregatingBlockInputStream: Will merge 1 temporary files of size 3.83673 MiB compressed, 38.5409 MiB uncompressed. 2018.01.12 20:35:09.296101 [ 1679 ] <Trace> Aggregator: Merging partially aggregated blocks (bucket = 0). 2018.01.12 20:35:09.296917 [ 1679 ] <Trace> Aggregator: Merged partially aggregated blocks. 300 rows, 11.982 MiB. in 0.001 sec. (408062.776 rows/sec., 16298.055 MiB/sec.) 2018.01.12 20:35:09.305924 [ 1679 ] <Debug> SrcViews..inner.TTViewDailyOther (Replicated OutputStream): Wrote block with 300 rows 2018.01.12 20:35:09.356575 [ 46 ] <Debug> SrcViews..inner.TTViewDailyOther (ReplicatedMergeTreeQueue): Pulling 1 entries to queue: log-0005443378 - log-0005443378 2018.01.12 20:35:09.412908 [ 1679 ] <Trace> SrcViews..inner.TTViewDailyOther (Data): Renaming temporary part tmp_insert_20180112_20180112_1108518_1108518_0 to 20180112_20180112_986931_986931_0.

а вот чуть выше - видимо в том же треде про другие вьюшки 2018.01.12 20:35:07.842162 [ 1679 ] <Trace> virtual DB::MergingAndConvertingBlockInputStream::~MergingAndConvertingBlockInputStream(): Waiting for threads to finish 2018.01.12 20:35:07.843464 [ 1679 ] <Trace> InterpreterSelectQuery: FetchColumns -> Complete 2018.01.12 20:35:07.844831 [ 1679 ] <Trace> Aggregator: Aggregating 2018.01.12 20:35:07.845848 [ 1679 ] <Trace> Aggregator: Aggregation method: concat ... 2018.01.12 20:35:08.044220 [ 1679 ] <Trace> Aggregator: Aggregated. 386881 to 31957 rows (from 666.505 MiB) in 0.199 sec. (1940853.057 rows/sec., 3343.635 MiB/sec.) 2018.01.12 20:35:08.044336 [ 1679 ] <Trace> Aggregator: Merging aggregated data 2018.01.12 20:35:08.137043 [ 1679 ] <Debug> SrcViews..inner.TTViewDailyAdv (Replicated OutputStream): Wrote block with 31957 rows ... 2018.01.12 20:35:08.248910 [ 1679 ] <Trace> SrcViews..inner.TTViewDailyAdv (Data): Renaming temporary part tmp_insert_20180112_20180112_63248_63248_0 to 20180112_20180112_5151_5151_0. 2018.01.12 20:35:08.408776 [ 41 ] <Debug> SrcViews..inner.TTViewDailyAdv (ReplicatedMergeTreeQueue): Pulling 1 entries to queue: log-0000688941 - log-0000688941 2018.01.12 20:35:08.410417 [ 1679 ] <Trace> virtual DB::MergingAndConvertingBlockInputStream::~MergingAndConvertingBlockInputStream(): Waiting for threads to finish 2018.01.12 20:35:08.411557 [ 1679 ] <Trace> InterpreterSelectQuery: FetchColumns -> Complete 2018.01.12 20:35:08.412672 [ 1679 ] <Trace> Aggregator: Aggregating 2018.01.12 20:35:08.413405 [ 1679 ] <Trace> Aggregator: Aggregation method: concat ... 2018.01.12 20:35:08.564700 [ 1679 ] <Trace> Aggregator: Aggregated. 386881 to 5813 rows (from 666.505 MiB) in 0.152 sec. (2545816.836 rows/sec., 4385.846 MiB/sec.) 2018.01.12 20:35:08.564853 [ 1679 ] <Trace> Aggregator: Merging aggregated data 2018.01.12 20:35:08.587263 [ 1679 ] <Debug> SrcViews..inner.TTViewDailyBidders (Replicated OutputStream): Wrote block with 5813 rows 2018.01.12 20:35:08.694259 [ 1679 ] <Trace> SrcViews..inner.TTViewDailyBidders (Data): Renaming temporary part tmp_insert_20180112_20180112_63248_63248_0 to 20180112_20180112_5151_5151_0.