Всем добрый день. У меня опять вопрос по ALTER TABLE UPDATE. Я оптимизировал запросы, но после успешного применения мутаций итоговая цифра выглядит не так как я ожидал - такое ощущение, что часть мутаций не применилась. Вопрос - если несколько мутаций работают с одним чанком, может ли возникнуть ситуация, когда они конкурируют и перезатирают результат работы друг друга? Или мутации применяются строго по очереди?

Выложена презентация с Субботника по базам данных в Екатеринбурге (который проходил в четверг). https://yandex.github.io/clickhouse-presentations/database_saturday_2018_2/pipeline/# Видеозаписи не было.

Если реплики есть, то может что с ZK в этот момент и сервер не получает задач на мерж (если на нем есть таблицы не лидеры).

если что не так с зк таблица по идее должна перейти в риад онли

1 исключено, второе возможно, также с зукипером пока не перешли на nvme... Но в процессе. То есть в принципе это не страшно?

советую проверить, что в этот момент у вас все вставки успешно проходят

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

Хоть ты книгу пиши, почему зукипер нельзя в докер, почему зукипер нельзя на сервер, где что-то ещё работает... ?

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

А если он на докере, но кроме 1 инстанса ЗК больше ничего на этой машине нет и не будет?

А еще вопрос - можно ли штатными средствами конвертнуть 2014-09-21T09:44:28+0400 (ISO8601) в DateTime?

https://github.com/yandex/ClickHouse/issues/3418 и функция есть с besteffort

select parseDateTimeBestEffortOrZero('2014-09-21T09:44:28+0400') 2014-09-21 05:44:28

красота!

есть только тонкость у КХ с таймзонами, КХ хранит TZ для колонки, поэтому тип скорее всего будет не DateTime, а DateTime+4, в смысле будет приводится к типу таймзоны первой строки, бред, я уже сам запутался.

Интересно, но т.е. если TZ всегда одинаковая то проблем быть не должно?

а почему не привести к utc naive перед инсертом?

Доброго дня. Все пытаюсь подружить kafka и clickhouse и разобраться с параметрами max_insert_block_size, stream_flush_interval_ms и max_block_size. Симптомы такие - сlickhouse забирает из kafka данные, но данные в целевую таблицу через materialized view отправляются только при наборе 65536 строк. Это также хорошо видно и со стороны kafka, CONSUMER LAG на каждом из трех consumer достигает 65536. Но правильное ли это поведение? В документации сказано "Если блок не удалось сформировать за stream_flush_interval_ms миллисекунд, то данные будут сброшены в таблицу независимо от полноты блока.". Настройки все дефолтные, на всякий проверил так. stats-1 :) select * from system.settings where name='stream_flush_interval_ms'; SELECT * FROM system.settings WHERE name = 'stream_flush_interval_ms' ┌─name─────────────────────┬─value─┬─changed─┬─description────────────────────────────────────────┐ │ stream_flush_interval_ms │ 7500 │ 0 │ Timeout for flushing data from streaming storages. │ └──────────────────────────┴───────┴─────────┴────────────────────────────────────────────────────┘ Т.е. по идеи каждые 7.5 секунд данные должны сбрасываться? но поведения такого не наблюдаю. При перезагрузке процесса - данные сразу сбрасываются.

Но за это путь "вникуда"

есть только тонкость у КХ с таймзонами, КХ хранит TZ для колонки, поэтому тип скорее всего будет не DateTime, а DateTime+4, в смысле будет приводится к типу таймзоны первой строки, бред, я уже сам запутался.

Всем добрый день. У меня опять вопрос по ALTER TABLE UPDATE. Я оптимизировал запросы, но после успешного применения мутаций итоговая цифра выглядит не так как я ожидал - такое ощущение, что часть мутаций не применилась. Вопрос - если несколько мутаций работают с одним чанком, может ли возникнуть ситуация, когда они конкурируют и перезатирают результат работы друг друга? Или мутации применяются строго по очереди?

Не-а. В этом случае будет обычный DateTime без таймзоны. Легко проверить: select toTypeName(parseDateTimeBestEffortOrZero('2014-09-21T09:44:28+0400')) as l;. Храниться будет как unix timestamp. Отображаться будет в таймзоне по умолчнанию. И кстати таймзону невозможно однозначно определить смещению в конкретный момент времени.

ок, я бы вообще оторвал TZ везде в КХ, особенно в jdbc драйвере, сплошная и бесконечная головная боль.

пусть TZ занимается клиент (приложение) select now(), toString(now()) 2018-10-19 09:46:40.0 2018-10-19 12:46:40

today() - 10

Тогда now() - 86400 * 10

:) select now() - interval 10 day; SELECT now() - toIntervalDay(10) ┌─minus(now(), toIntervalDay(10))─┐ │ 2018-10-09 16:39:33 │ └─────────────────────────────────┘

ODBC откуда куда?

в выборку добавьте hostName()

А какая версия и можно ли сам запрос?

А какая версия и можно ли сам запрос?

select version();

А какая версия и можно ли сам запрос?

К сожалению сам запрос отправить не можем. Конфидицеальная корпоративная информация.

это из-за Union. попробуйте обернуть второй запрос в select union all select * from (второй запроc) без полного воспроизведения create table / insert/select без шансов починить.

Я только второго уровня телепат. Пока не знаю.

@kshvakov посмотрите пожалуйста, у нас при многоразовом выполнение одного селекта, после 30-70 раз, падает ClickHouse сервер

"Block structure mismatch" на 18.14.9 вылезло. Рецепта ремонта не было еще случайно? Кластер чистый, исключительно для тестов.

Эксперементально выяснилось, что ошибка появляется в случаях когда в where есть условия над колонкам типа string. Если обернуть колонку в toString() то запрос не падает. О_о

возможно toString не дает заталкивать в prewhere что с ошибкой если set optimize_move_to_prewhere = 0 set enable_optimize_predicate_expression = 0 и если потом переместить предикат в prewhere

после set -ов ошибка уходит на базовом запросе. после перемещения в prewhere также нет ошибки (сессию не менял, настройки в 0, верно?)

Всем привет Есть два старых и два новых clickhouse сервера: везде версии одинаковые. Создаем таблицу на старом сервере - она реплицируется на новый. Создаем на новом - не реплицируется с ошибкой: DB::Exception: Cannot read all data. Bytes read: 0. Bytes expected: 8 Репликация новый -> новый так же не запускается с такой же ошибкой. Вопрос - что означает эта ошибка и куда нужно копать? - версии идентичные вплоть до ревизии - iptables и тд точно верные - конфиги правильные - из отличий: добавил опцию listen_reuse_port 1 на новых репликах, так как не стартовал

В конфигах, связанных с зукипером, указаны все 4 сервера?