DT
и дропать её при перезапуске?
Ага
Size: a a a
2020 May 24
MG
костыльное, конечно, решение :) но спасибо за идею
AK
К сожалению, это немного не то. Мне надо перелить большую таблицу из хайва. Я запускаю копирование на множестве воркеров. Часть воркеров помирает и перезапускается кластером заново. Проблема в том, что до того, как погибнуть, воркеры успели что-то залить в клик. А клик не транзакционный, поэтому данные остаются. И когда воркер перезапускается и начинает лить заново, данные дублируются. Как раз этого я хочу избежать.
Если вставляются одни и те же блоки записей в одном и том же порядке, то должна работать дедупликация
AT
ну так вам один раз перелить - один раз закостылил и забыл ))
DR
Всем привет, недавно стала возникать проблема - некоторые запросы блокируются и блокируют собой всю таблицу, висят в processlist бесконечно и ничего не происходит, нагрузки на сервере нет, kill query становится в очередь и ничего не стопает. Спасает только перезапуск. Подскажите в какую сторону копать?
DT
Если вставляются одни и те же блоки записей в одном и том же порядке, то должна работать дедупликация
Ну это нужно быть уверенным, что будут одинаковые блоки
DT
Но тоже хорошая идея
AK
Хотя похоже, что это для replicated
DT
Но сделать репликатед таблицу не так сложно
E
К сожалению, это немного не то. Мне надо перелить большую таблицу из хайва. Я запускаю копирование на множестве воркеров. Часть воркеров помирает и перезапускается кластером заново. Проблема в том, что до того, как погибнуть, воркеры успели что-то залить в клик. А клик не транзакционный, поэтому данные остаются. И когда воркер перезапускается и начинает лить заново, данные дублируются. Как раз этого я хочу избежать.
костыльно, но ты можешь заливать и периодически делать optimize table, чтобы схлопнуть дублирующиеся ключи.
Либо предоставить это самому движку - он будет этим заниматься в фоне, а дубликаты убирать на уровне запроса (вьюха какая-нибудь).
Но может это все неправильно - я всего месяц кликхаус мучаю. Возможно это антипаттерн :)
Либо предоставить это самому движку - он будет этим заниматься в фоне, а дубликаты убирать на уровне запроса (вьюха какая-нибудь).
Но может это все неправильно - я всего месяц кликхаус мучаю. Возможно это антипаттерн :)
DT
костыльно, но ты можешь заливать и периодически делать optimize table, чтобы схлопнуть дублирующиеся ключи.
Либо предоставить это самому движку - он будет этим заниматься в фоне, а дубликаты убирать на уровне запроса (вьюха какая-нибудь).
Но может это все неправильно - я всего месяц кликхаус мучаю. Возможно это антипаттерн :)
Либо предоставить это самому движку - он будет этим заниматься в фоне, а дубликаты убирать на уровне запроса (вьюха какая-нибудь).
Но может это все неправильно - я всего месяц кликхаус мучаю. Возможно это антипаттерн :)
Как одноразовое действие вполне ок
AT
К сожалению, это немного не то. Мне надо перелить большую таблицу из хайва. Я запускаю копирование на множестве воркеров. Часть воркеров помирает и перезапускается кластером заново. Проблема в том, что до того, как погибнуть, воркеры успели что-то залить в клик. А клик не транзакционный, поэтому данные остаются. И когда воркер перезапускается и начинает лить заново, данные дублируются. Как раз этого я хочу избежать.
а как воркеры льют из хайва в клик? JDBC? и еще где сами данные лежат? HDFS?
MG
Al T
а как воркеры льют из хайва в клик? JDBC? и еще где сами данные лежат? HDFS?
да, все так.
MG
Al T
а как воркеры льют из хайва в клик? JDBC? и еще где сами данные лежат? HDFS?
Я пришел к тому, что выкачиваю паркеты из hdfs и лью кликхаус клиентом, но там сложности с распаковкой паркетов. Поэтому параллельно пробую jdbc.
AT
да, все так.
может еще попробовать через HDFS Engine лить из клика через insert into select ?
MG
Al T
может еще попробовать через HDFS Engine лить из клика через insert into select ?
Не очень понял, можешь поподробнее?
AT
AT
можно читать и писать в HDFS
AT
и в таком случае просто делать insert into SELECT