есть, но мы хотим переместить данные с блинов на ssd

коллега с другой конторы заставляет сохранять всё в git в виде дата_migration_name.sql, потом просто пулит репу и так же фором все sql-ки загоняет в кх-клиента... К моему стыду у меня тож такое есть, но я по лени наверное тащу с соседней реплики и седаю )

Коллеги, кто может уточнить:
move_factor — доля свободного места, при превышении которого данные начинают перемещаться на следующий том, если он есть (по умолчанию 0.1).

Речь о новых данных? То есть вся следующая запись пойдет на следующий том?

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

добрый день,
Подскажите, пожалуйста, элегантное решение в борьбе с дубликатами данных. На оракле активно пользовался виртуальным столбцом rowid для таких целей, а в КХ кроме констатации "даблы есть" не могу пока ничего придумать:
"select a,b,c,count(*)
from t
group by a,b,c
having count(*)>1"

Final, не?

deduplicate

спасибо! по ощущению то, что надо

final больше подходит, спасибо

он ужасно дорогой

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

Юристам нужна наша помощь по логотипу, просьба потратить минутку на короткрий опрос: https://forms.yandex.ru/surveys/10022588.cef650836a35cf646d91bf2e532696e9660a2427/

————

12 сентября будет доклад «Две низкоуровневые оптимизации, которые я сделал вчера»: https://ya.cc/t/cIBI-3yECj5JF

аренда мангалов 100%

а этот опрос точно стоит проходить людям, знакомым с кликхаусом?

похоже на спички

Не разрешают зарегистрировать логотип, потому что тривиальный? :)

я не помню, что я ел вчера на обед, а тут вопрос про август 2019 🙂

Как вы думаете, если бы вы участвовали в этом опросе до 19.08.2019 г., то ответили бы так же или по-другому?

Кто-то быкует за плагиат логотипа?

Добрый день, уважаемое сообщество!

Ребята, пожалуйста помогите разобраться с проблемой.
Дано: Есть несколько больших таблиц ReplicatedMergeTree, в которые с помощью МВ переливаются данные из таблиц с Kafka движком.
и есть ещё одна таблица - t4 c движком MergeTree. В t4 начинаем перекачивать данные через jdbc коннектор батчами по 100 000 строк. Через некоторое время в логах КХ появляются сообщения вида:

<Error> DynamicQueryHandler: Code: 241, e.displayText() = DB::Exception: Memory limit (total) exceeded: would use 27.61 GiB (attempt to allocate chunk of 4197660 bytes)

После чего почти сразу в лог прилетают сообщения вида:

<Error> void DB::StorageKafka::threadFunc(): Code: 242, e.displayText() = DB::Exception: Table is in readonly mode, Stack trace (when copying this message, always include the lines below)

Опытным путём мы выяснили, что блочится не та таблица, в которую льются данные - t4, а самые большие по объёму таблицы ReplicatedMergeTree, в которые данные довольно не спешно переливаются из таблиц с Kafka движком.

Разблокировать таблицы получается только перезагрузкой clickhouse.

Почему таблицы переходят в readonly mode? И что можно сделать, чтобы этого избежать?

Прям интересно кто страйк кинул на плагиат)