UPDATE (причем ну очень медленного). А если не нужен update?
Какие еще есть варинаты? Задача такая: млрд записей. Каждый день добавляется по 10млн. Вот из этих 10млн могут быть дубли. Нужно добавить 10млн без этих дублей.
А что плохого в том, чтобы проверить раз в день 10М строк на дубликаты? 10M ids легко помещаются в хеш таблицу для IN. И это явно лучше, чем последующие развлечения с ReplacingMT & final. Если бы у вас было 10M в секунду, то можно было бы подумать над вариантами, но в день?
тогда уж проще сделать ReplacingMergeTree с партициями по дням / неделям и запускать optimize table ... partition ...
проще - тут не самый хороший ориентир. Если есть возможность обойтись без ReplacingMT - стоит это сделать. Несмотря на все последние оптимизации типа do_not_merge_across_partitions_select_final. Вот захочется вам потом добавить индексов или проекций - а у вас ReplacingMT. И уж совершенно точно партиции по дням и optimize по крону - это самое последнее, когда иначе уже никак.
а чем вариант "раз в день проверять на дубликаты" (и что делать с обнаруженными, удалять мутациями?) поверх обычного MergeTree удобнее для проекций?
"раз в день проверять на дубликаты и удалять мутациями" - это конечно полная чушь. Изначально человек спросил как ему вставлять раз в день 10М строк в ярдную табличку. Так вот эту проверку можно делать непосредственно в момент вставки. И не вставлять. И не писать на диск. И не оптимизировать потом.
Я начало пропустил, а insert_deduplicate=1 не пойдет ?
Собственно settings insert_deduplicate=1 в конце
это про дедупликацию целиком инсертов, а не отдельных строк
Так в конце инсерта пишется надстройка и понеслась
а, вы об этом это можно, только тут не надо забывать, что в системе нет никаких локов, тем более exclusive locks, зато есть фантомы, так что с таким подходом возможны неприятные сюрпризы, если "писателей" в базу будет больше одного или если параллельно вставке какая-нибудь мутация будет в процессе
спасибо. попробую.
Обсуждают сегодня