зато описаны в исходниках

зато описаны в исходниках

жирно

зато описаны в исходниках

большое спасибо за помощь

лошара я крч ;)

это нормально, все начинали...

Привет! KX на Red Hat, норм? Или лучше не пробовать?

У нас 2 кластера по 15 узлов на CentOS. Нареканий нет

Привет! KX на Red Hat, норм? Или лучше не пробовать?

он мне кажется на любой оси будет ок , у него какой то привязки особой к осям нет

он мне кажется на любой оси будет ок , у него какой то привязки особой к осям нет

к selinux есть скорей всего )

ну у меня убунту там нет селинукс и все работает так что и к селинуксу нет привязки

подскажите, можно ли как то добиться такого результата ? (последовательность interval_num нужна для каждого id своя по аналогии PARTITION BY) : date, id, interval_num, status, time_min, time_max "2018-10-02", 2, 1, 0,"2018-10-02 00:00:02", "2018-10-02 00:07:01" "2018-10-02", 2, 2, 1,"2018-10-02 00:09:01", "2018-10-02 00:13:02" "2018-10-02", 2, 3, 3,"2018-10-02 00:15:01", "2018-10-02 00:17:01" "2018-10-02", 2, 4, 0,"2018-10-02 00:18:02", "2018-10-02 00:20:01" "2018-10-02", 2, 5, 1,"2018-10-02 00:21:01", "2018-10-02 00:22:01" из таких входных данных: "date","id","status","timestamp" "2018-10-02",2,0,"2018-10-02 00:00:02" "2018-10-02",2,0,"2018-10-02 00:01:01" "2018-10-02",2,0,"2018-10-02 00:02:01" "2018-10-02",2,0,"2018-10-02 00:03:02" "2018-10-02",2,0,"2018-10-02 00:04:01" "2018-10-02",2,0,"2018-10-02 00:05:02" "2018-10-02",2,0,"2018-10-02 00:06:01" "2018-10-02",2,0,"2018-10-02 00:07:01" "2018-10-02",2,1,"2018-10-02 00:09:01" "2018-10-02",2,1,"2018-10-02 00:10:02" "2018-10-02",2,1,"2018-10-02 00:11:01" "2018-10-02",2,1,"2018-10-02 00:12:01" "2018-10-02",2,1,"2018-10-02 00:13:02" "2018-10-02",2,3,"2018-10-02 00:15:01" "2018-10-02",2,3,"2018-10-02 00:16:02" "2018-10-02",2,3,"2018-10-02 00:17:01" "2018-10-02",2,0,"2018-10-02 00:18:02" "2018-10-02",2,0,"2018-10-02 00:19:01" "2018-10-02",2,0,"2018-10-02 00:20:01" "2018-10-02",2,1,"2018-10-02 00:21:01" "2018-10-02",2,1,"2018-10-02 00:22:01"

У нас такое на селекте в одной таблице есть, есди из селекта убрать limit или order by, помогает

У нас лимита и так нет :)

У нас 2 кластера по 15 узлов на CentOS. Нареканий нет

+1, также на центосе. Раньше держали пол-кластера на центос7, пол-кластера на центос-6 и тоже без проблем

У нас лимита и так нет :)

Там issue открытое есть на проблему

Да, я читал, только у нас расчеты встали, быстрый фикс нужен, думаем откатиться пока

у нас зукипер упал с OutOfMemory, после того как его подняли появилась такая ошибка. Можно руками создать ноду в зукипере?

Ни у кого не было таких ошибок в зукипере? Не могу понять причину Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread "SyncThread:0" Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread "NIOServerCxn.Factory:0.0.0.0/0.0.0.0:32181" Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread "SessionTracker"

Ни у кого не было таких ошибок в зукипере? Не могу понять причину Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread "SyncThread:0" Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread "NIOServerCxn.Factory:0.0.0.0/0.0.0.0:32181" Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread "SessionTracker"

Закончился Java Heap, вылетел OOM. Если heap больше 2Gb, и ошибка продолжает появляться - надо расчехлять явасятские тулзы и пристально изучать.

в качестве эксперимента выставили heap в 4Gb, не помогло(

в качестве эксперимента выставили heap в 4Gb, не помогло(

смотрите дамп,может у вас permgen/metaspace переполнены

ну и настройки гц

Ни у кого не было таких ошибок в зукипере? Не могу понять причину Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread "SyncThread:0" Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread "NIOServerCxn.Factory:0.0.0.0/0.0.0.0:32181" Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread "SessionTracker"

Откуда у вас столько данных в зукипере? Ощущение что вы часть реплик выключили и не очистили ЗК от них и копится инфа для реплик в ЗК и из за этого переполнение памяти

сейчас проверим

Откуда у вас столько данных в зукипере? Ощущение что вы часть реплик выключили и не очистили ЗК от них и копится инфа для реплик в ЗК и из за этого переполнение памяти

У меня такая же проблема, зукипер сильно раздулся. Я действительно выключил несколько серверов, не удалив там таблицы. Зукипер надо вручную чистить в такой ситуации?

Ну либо включить и удалить, либо вручную

Всем привет У нас с @k0st1an сейчас есть следующая ситуация Есть кластер с таблицей в которой 100 млрд. событий и каждый месяц приходит еще 30 млрд. Ранее разбиение на партции происходило только на основе месяца Сейчас возможно задать кастомный ключ партиционирования ( https://clickhouse.yandex/docs/ru/operations/table_engines/custom_partitioning_key/ ) Большая часть запросов у нас на 1-2 дня и 90% запросов попадает в рамки недели Я не очень разбираюсь в деталях организации партиционирования в КХ, поэтому вопросы к сообществу: 1. Влияет ли изменение ключа партиционирования положительно в нашем случае на производительность (потому что сейчас заметна разница при выборке на 20 дней из месяца и всего месяца в сторону кратного прироста производительности на размерах всей месячной партиции) 2. Как выглядит сам переход изменения ключа партиционирования для старых данных? (т.е. неужно ли создавать таблицу новую рядом и туда все перегонять запросом или можно оставить старые партиции с ключом в месяц) 3. Есть ли какая-либо ощутимая деградация производительности//проблемы в случае мелкого партиционирования (к примеру мы выбрали ключ партициогнирования в 1 день и делаем выборку по 90 дням) Спасибо большое!

Всем привет У нас с @k0st1an сейчас есть следующая ситуация Есть кластер с таблицей в которой 100 млрд. событий и каждый месяц приходит еще 30 млрд. Ранее разбиение на партции происходило только на основе месяца Сейчас возможно задать кастомный ключ партиционирования ( https://clickhouse.yandex/docs/ru/operations/table_engines/custom_partitioning_key/ ) Большая часть запросов у нас на 1-2 дня и 90% запросов попадает в рамки недели Я не очень разбираюсь в деталях организации партиционирования в КХ, поэтому вопросы к сообществу: 1. Влияет ли изменение ключа партиционирования положительно в нашем случае на производительность (потому что сейчас заметна разница при выборке на 20 дней из месяца и всего месяца в сторону кратного прироста производительности на размерах всей месячной партиции) 2. Как выглядит сам переход изменения ключа партиционирования для старых данных? (т.е. неужно ли создавать таблицу новую рядом и туда все перегонять запросом или можно оставить старые партиции с ключом в месяц) 3. Есть ли какая-либо ощутимая деградация производительности//проблемы в случае мелкого партиционирования (к примеру мы выбрали ключ партициогнирования в 1 день и делаем выборку по 90 дням) Спасибо большое!

Мы как раз сейчас переводим похожую схему хранения - с месяца на дни. 1. Перевод чтения. Создаём таблицу с такой же структурой, но с партицированием по дням. Называем её table_new (старая - называется table_old, например). Считаем, что чтение из Distributed(cluster, schema, table_old), это меняем на Distributed(cluster, schema, table_merge), где table_merge имеет ENGINE Merge(schema, 'table_*')

Там, где пишем в таблицу, меняем просто имя таблицы, куда идёт инсерт

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

Всем привет У нас с @k0st1an сейчас есть следующая ситуация Есть кластер с таблицей в которой 100 млрд. событий и каждый месяц приходит еще 30 млрд. Ранее разбиение на партции происходило только на основе месяца Сейчас возможно задать кастомный ключ партиционирования ( https://clickhouse.yandex/docs/ru/operations/table_engines/custom_partitioning_key/ ) Большая часть запросов у нас на 1-2 дня и 90% запросов попадает в рамки недели Я не очень разбираюсь в деталях организации партиционирования в КХ, поэтому вопросы к сообществу: 1. Влияет ли изменение ключа партиционирования положительно в нашем случае на производительность (потому что сейчас заметна разница при выборке на 20 дней из месяца и всего месяца в сторону кратного прироста производительности на размерах всей месячной партиции) 2. Как выглядит сам переход изменения ключа партиционирования для старых данных? (т.е. неужно ли создавать таблицу новую рядом и туда все перегонять запросом или можно оставить старые партиции с ключом в месяц) 3. Есть ли какая-либо ощутимая деградация производительности//проблемы в случае мелкого партиционирования (к примеру мы выбрали ключ партициогнирования в 1 день и делаем выборку по 90 дням) Спасибо большое!

а в чем смысл переезда ?

а в чем смысл переезда ?

Retention по дням, например :)

Ну либо включить и удалить, либо вручную

спасибо! удалил вручную директории реплик в ЗК, кликхаус понял и почистил логи, круто ?

у нас большая часть запросов на 1-2 дня, а партиция на месяц мне моя логика подсказывает, что в случае партиции на 1 день запрос будет быстрее и меньше нагружать систему если что у нас ключ определен по дню тоже: ENGINE = ReplicatedMergeTree('/clickhouse/tables/{cluster}/{shard}/event', '{replica}', day, (type, group_id), 8192)

а сейчас он медленный ?

а сейчас он медленный ?

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

Всем привет! Может быть тут уже обсуждали... Есть таблица с движком kafka, есть materalized view, который из нее вычитывает. Обнаруживаю, что во вьюхе встречаются дубликаты. Причем, если вычитать из топика кафки консольным клиентом - там дубликатов нет. Похоже, что кликхаус вычитывает по несколько раз. С чем может быть связано?

ну проверьте просто на пару запросов в тестовой табличке есть ли вообще выигрыщ

вопрос в том, что логика подскзавает, что должен быть выигрыш но, возможно, кто-то в сообществе уже делал подобную работу, поэтому в первую очередь имеет смысл уточнять, чем гонять 10-ки млрд записей

теоретически все будет хуже пожато , а так наверно зависит от данных и запросов

вопрос в том, что логика подскзавает, что должен быть выигрыш но, возможно, кто-то в сообществе уже делал подобную работу, поэтому в первую очередь имеет смысл уточнять, чем гонять 10-ки млрд записей

Логика говорит одно, но попробовать стоит.Еще КХ сжимает/индексирует данные в рамках куска, с меньшими по времени партициями их будет сильно больше, а тут и файликов открыть нужно по более и все такое ;)

Добрый день. Подскажите, пожалуйста, что не так с синтаксисом? CREATE TABLE IF NOT EXISTS `dictionary` ( date Date, version UInt64, key String, value UInt32 ) ENGINE = ReplicatedReplacingMergeTree('/clickhouse/tables/{shard}/dictionary', '{replica}') PARTITION BY toYYYYMM(date) ORDER BY (key) SAMPLE BY key SETTINGS ver=version; Выдаёт ошибку ver=version; Expected one of: number, NULL, literal, string literal

vesion же написано)

Очепятка, пока сюда копировал, дело не в ней)

Привет. столкнулся с потерей небольшой доли данных в материализованных вьюшках. Общая конфигурация - запись в Distributed-таблицу, таблица разбита на 4 шарда по две реплики. К основной таблице цепляется 4 вьюшки. Запись в исходную таблицу - 10-15 запросов в минуту, в Distributed-таблицу произвольного сервера. Сверяю данные - получается, что некоторые куски во вьюшках пропадают. Разные в каждой вьюшке и каждом шарде. Увидел в changelog, что это может быть при таймауте ZK - проапдейтил сервера на актуальную версию. Кажется, что проблем стало меньше - но все равно остались. Вот сегодня увидел один такой потерянный блок. @ztlpn кому можно такое направить?

хм: Include not found: /etc/clickhouse-server/dist-table.xml -rw-r----- 1 clickhouse clickhouse 664 окт 1 15:55 /etc/clickhouse-server/dist-table.xml

вопрос в том, что логика подскзавает, что должен быть выигрыш но, возможно, кто-то в сообществе уже делал подобную работу, поэтому в первую очередь имеет смысл уточнять, чем гонять 10-ки млрд записей

Более компактные (например дневные) партиции на самом деле удобнее (если данных много). Проще всякие операции производить. Значительно меньше данных нужно читать если указываешь "дневной" диапазон данных. Больше шансов что нужные данные не будут вытеснены из кэша. Замеченные минусы: ощутимо дольше стартует / рестартует сервер (первый раз после 5 минут ожидания думал что - всё, я окончательно убил КХ, но ничего, встал). Чуть хуже жмет данные, но не критично. При запросах на широкий диапазон дат есть (незначительная) деградация производительности.

Ну и плюс такой что дневными партициями данными можно довольно легко "жонглировать" (намного проще чем месячными). Например очистить колонку, удалять по дням, "перезалить" целый день, можно даже "перезалить" колонку с помощью DEFAULT выражения (CLEAR COLUMN / OPTIMIZE).

Более компактные (например дневные) партиции на самом деле удобнее (если данных много). Проще всякие операции производить. Значительно меньше данных нужно читать если указываешь "дневной" диапазон данных. Больше шансов что нужные данные не будут вытеснены из кэша. Замеченные минусы: ощутимо дольше стартует / рестартует сервер (первый раз после 5 минут ожидания думал что - всё, я окончательно убил КХ, но ничего, встал). Чуть хуже жмет данные, но не критично. При запросах на широкий диапазон дат есть (незначительная) деградация производительности.

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

Мы как раз сейчас переводим похожую схему хранения - с месяца на дни. 1. Перевод чтения. Создаём таблицу с такой же структурой, но с партицированием по дням. Называем её table_new (старая - называется table_old, например). Считаем, что чтение из Distributed(cluster, schema, table_old), это меняем на Distributed(cluster, schema, table_merge), где table_merge имеет ENGINE Merge(schema, 'table_*')

Спасибо!

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

Да никаких подводных камней, только если данных много то ждать долго пока скопируются, и место на диске нужно прилично :) Ну разве что: при больших INSERT ... SELECT иногда лучше "подкручивать" размеры блоков.

@mfilimonov, спасибо!

Привет. столкнулся с потерей небольшой доли данных в материализованных вьюшках. Общая конфигурация - запись в Distributed-таблицу, таблица разбита на 4 шарда по две реплики. К основной таблице цепляется 4 вьюшки. Запись в исходную таблицу - 10-15 запросов в минуту, в Distributed-таблицу произвольного сервера. Сверяю данные - получается, что некоторые куски во вьюшках пропадают. Разные в каждой вьюшке и каждом шарде. Увидел в changelog, что это может быть при таймауте ZK - проапдейтил сервера на актуальную версию. Кажется, что проблем стало меньше - но все равно остались. Вот сегодня увидел один такой потерянный блок. @ztlpn кому можно такое направить?

Вдогонку - практически каждый час вижу в err-логах записи про проблемы с ZK. Можно ли что-то с этим сделать? Попробовал увеличить время сессии с ZK, пока особых результатов не видно. Пример записей в err-логе: <Error> zkutil::EphemeralNodeHolder::~EphemeralNodeHolder(): Code: 999, e.displayText() = ZooKeeperImpl::Exception: Session expired (Session expired), e.what() = ZooKeeperImpl::Exception, Stack trace: <Error> zkutil::EphemeralNodeHolder::~EphemeralNodeHolder(): Code: 999, e.displayText() = ZooKeeperImpl::Exception: Session expired (Session expired), e.what() = ZooKeeperImpl::Exception, Stack trace: <Warning> SrcViews..inner.ViewName1 (ReplicatedMergeTreeRestartingThread): ZooKeeper session has expired. Switching to a new session. <Error> SrcViews..inner.ViewName1 (StorageReplicatedMergeTree): void DB::StorageReplicatedMergeTree::queueUpdatingTask(): Code: 999, e.displayText() = ZooKeeperImpl::Exception: Session expired (Session expired), e.what() = ZooKeeperImpl::Exception, Stack trace: <Error> SrcViews..inner.ViewName2 (StorageReplicatedMergeTree): void DB::StorageReplicatedMergeTree::mutationsUpdatingTask(): Code: 999, e.displayText() = ZooKeeperImp l::Exception: Session expired (Session expired), e.what() = ZooKeeperImpl::Exception, Stack trace:

<Error> SrcData.TableName1 (ReplicatedMergeTreeAlterThread): void DB::ReplicatedMergeTreeAlterThread::run(): Code: 999, e.displayText() = ZooKeeperImpl::Exception: Session expired (Session expired), e.what() = ZooKeeperImpl::Exception, Stack trace:

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

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

Вдогонку - практически каждый час вижу в err-логах записи про проблемы с ZK. Можно ли что-то с этим сделать? Попробовал увеличить время сессии с ZK, пока особых результатов не видно. Пример записей в err-логе: <Error> zkutil::EphemeralNodeHolder::~EphemeralNodeHolder(): Code: 999, e.displayText() = ZooKeeperImpl::Exception: Session expired (Session expired), e.what() = ZooKeeperImpl::Exception, Stack trace: <Error> zkutil::EphemeralNodeHolder::~EphemeralNodeHolder(): Code: 999, e.displayText() = ZooKeeperImpl::Exception: Session expired (Session expired), e.what() = ZooKeeperImpl::Exception, Stack trace: <Warning> SrcViews..inner.ViewName1 (ReplicatedMergeTreeRestartingThread): ZooKeeper session has expired. Switching to a new session. <Error> SrcViews..inner.ViewName1 (StorageReplicatedMergeTree): void DB::StorageReplicatedMergeTree::queueUpdatingTask(): Code: 999, e.displayText() = ZooKeeperImpl::Exception: Session expired (Session expired), e.what() = ZooKeeperImpl::Exception, Stack trace: <Error> SrcViews..inner.ViewName2 (StorageReplicatedMergeTree): void DB::StorageReplicatedMergeTree::mutationsUpdatingTask(): Code: 999, e.displayText() = ZooKeeperImp l::Exception: Session expired (Session expired), e.what() = ZooKeeperImpl::Exception, Stack trace:

Такая же хрень была, когда zk жили вместе с кх на одних серваках. Большая нагрузка на диски и сеть, зукиперам было плохо (из мониторинга что помню - высокий latency был). Как отселили на виртуалки, проблем нет.

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

Такая же хрень была, когда zk жили вместе с кх на одних серваках. Большая нагрузка на диски и сеть, зукиперам было плохо (из мониторинга что помню - высокий latency был). Как отселили на виртуалки, проблем нет.

интересно, а почему ошибка? Вот в тех же логах вижу примерно ожидаемое: <Warning> SrcViews..inner.TTViewDailyAdv (ReplicatedMergeTreeRestartingThread): ZooKeeper session has expired. Switching to a new session.

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

в другом дц это где ? пинг очень короткий ?

30ms

в другом дц это где ? пинг очень короткий ?

30ms

почекайте логи зукипера , судя по всему они теряют друг друга

посмотрю.

latency и Outstanding Requests тоже в норме?

latency и Outstanding Requests тоже в норме?

outstanding requests есть единичные.

Добрый день. Тестирую запросы ALTER ... DELETE и возникает какое-то непонятное поведение БД. Может кто сталкивался. Есть две отдельные реплецируемые таблицы (пусть будет Т1 и Т2 - каждая реплецируется отдельно), к обеем был был выполнен запрос ALTER ... DELETE WHERE ... ON CLUSTER ... оба запроса прошли без ошибок в system.mutations стоит is_done. Через некоторое время выполнен запрос вставки (вставка велась через distributed таблицу) с полями, которые попадают под "WHERE" в предыдущем ALTER DELETE, таблицы остались пустые. После выполнения TRUNCATE TABLE в таблицу Т1 данные записались (но опять же до первого удаления) а для таблицы Т2 TRUNCATE не сработал: Code: 48. DB::Exception: Received from localhost:9000, 127.0.0.1. DB::Exception: Can't proxy this query. Unsupported query type. Удаление этой таблицы и повторное ее созданиее не исправляет данной ошибки, но если повторно создать таблицу с, допустим, еще одним полем, то TRUNCATE отрабатывает без ошибок.

Добрый день. Тестирую запросы ALTER ... DELETE и возникает какое-то непонятное поведение БД. Может кто сталкивался. Есть две отдельные реплецируемые таблицы (пусть будет Т1 и Т2 - каждая реплецируется отдельно), к обеем был был выполнен запрос ALTER ... DELETE WHERE ... ON CLUSTER ... оба запроса прошли без ошибок в system.mutations стоит is_done. Через некоторое время выполнен запрос вставки (вставка велась через distributed таблицу) с полями, которые попадают под "WHERE" в предыдущем ALTER DELETE, таблицы остались пустые. После выполнения TRUNCATE TABLE в таблицу Т1 данные записались (но опять же до первого удаления) а для таблицы Т2 TRUNCATE не сработал: Code: 48. DB::Exception: Received from localhost:9000, 127.0.0.1. DB::Exception: Can't proxy this query. Unsupported query type. Удаление этой таблицы и повторное ее созданиее не исправляет данной ошибки, но если повторно создать таблицу с, допустим, еще одним полем, то TRUNCATE отрабатывает без ошибок.

дедупликация, если делаете тесты, выключайте ее. trucate видимо баг, я бы завел ишью, если воспроизводится.

дедупликация, если делаете тесты, выключайте ее. trucate видимо баг, я бы завел ишью, если воспроизводится.

"replicated_deduplication_window_seconds" - вы этот параметр имеете ввиду?

ребята. а подскажите вопрос

есть 3 реплики

но почему то одна равна сумме двух остальных

тоесть на первой все 22 партишена. на второй 2 и на третьей 20

значит репликация видимо работает в одну сторону , смотрите ошибки в логах

"replicated_deduplication_window_seconds" - вы этот параметр имеете ввиду?

да, оно по умолчанию M(SettingUInt64, replicated_deduplication_window_seconds, 7 * 24 * 60 * 60) /** one week */ и получается что один и тот же блок нельзя вставить в тестовой среде, где нет других инсертов. (в зукипере складывается 100 (по умолчанию) хешсумм вставленных блоков.

Всем привет! Может быть тут уже обсуждали... Есть таблица с движком kafka, есть materalized view, который из нее вычитывает. Обнаруживаю, что во вьюхе встречаются дубликаты. Причем, если вычитать из топика кафки консольным клиентом - там дубликатов нет. Похоже, что кликхаус вычитывает по несколько раз. С чем может быть связано?

кликхаус читает с at least once гарантией

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

==> дубликаты

да, оно по умолчанию M(SettingUInt64, replicated_deduplication_window_seconds, 7 * 24 * 60 * 60) /** one week */ и получается что один и тот же блок нельзя вставить в тестовой среде, где нет других инсертов. (в зукипере складывается 100 (по умолчанию) хешсумм вставленных блоков.

Т.е. нужно будет один блок данных удалить (50к-100к строк) а следом вставить с большим/меньшим кол-вом строк, которые попадают под условие удаления, то они не вставятся пока данный параметр (replicated_deduplication_window_seconds) не будет установлен в 0?

кликхаус читает с at least once гарантией

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

на уровне кода это не реализовано

смотри, чтобы иметь exactly once, кликхаус должен вместе с данными сохранять offset

и читать не из того что закоммичено в kafka, а смотреть в себя что есть и начинать чтение строго со своего offset

в коде на это даже намека нет ?

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

а операции MAX MIN по колонке эффективно работают?

Т.е. нужно будет один блок данных удалить (50к-100к строк) а следом вставить с большим/меньшим кол-вом строк, которые попадают под условие удаления, то они не вставятся пока данный параметр (replicated_deduplication_window_seconds) не будет установлен в 0?

вставляем в таблицу 500 строк, хешсумма от этого блока записывается в зукипер. после этого можно делать что угодно: * ничего * удалить alter delete * дропнуть таблицу и снова создать * транкейтнуть дедупликация не позволить вставить блок с такой же хешсуммой, если между инсертами было меньше ста любых других инсертов и прошло меньше недели.

вставляем в таблицу 500 строк, хешсумма от этого блока записывается в зукипер. после этого можно делать что угодно: * ничего * удалить alter delete * дропнуть таблицу и снова создать * транкейтнуть дедупликация не позволить вставить блок с такой же хешсуммой, если между инсертами было меньше ста любых других инсертов и прошло меньше недели.

Спасибо за инфу.

а операции MAX MIN по колонке эффективно работают?

нет, все полностью сканируется.

а операции MAX MIN по колонке эффективно работают?

тут проще самому сделать небольшую надстройку и будет работать на наносекунды.

Connecting to 104.248.44.235:9440 as user USER. Code: 32. DB::Exception: Attempt to read after eof

пичаль беда

в коде на это даже намека нет ?

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

1 партицию читать должен 1 consumer

1 партицию читать должен 1 consumer

Например: 10 партиций, читают с 5 серверов - все ОК. 1 упал - ребалансировка и все поехало если не наворачивать сложную логику в сервере КХ. А так упал и упал

Спасибо за инфу.

Вообще список блоков для дедупликации хранится тут select * from system.zookeeper where path='<путь к таблице в ZooKeeper>/blocks/' Truncate этот список чистит, и удаление партиции кажется тоже