Pull to refresh

Comments 7

А вот это точно правдиво?

ReplacingMergeTree предлагает дедубликацию по ключу сортировки (секция ORDER BY в DLL таблицы), которая в данном случае не применима, так как в рамках задачи нужно не просто удалять дубли по ключу, а выбирать из дублей подходящую строку (исходя из timestamp в имени файла)

timestamp из названия файла нельзя парсером подтащить в виде значения в поле insertTime? или просто использовать MATERIALIZE колонку с таймстемпом вставки и её потом использовать как аргумент. Да и без аргумента replacing движок оставляет только смую последнюю вставленную строку. Пробблема движка в том только, что удаляет он не сразу и при выборке из таблицы дубли могут ещё оставаться и их надо чистить селектом.

Ну или я не так понял задачу))

И одна опечатка -

-- Перемещение партиции из промежуточной в чистовую таблицу:

ALTER TABLE clean MOVE PARTITION {partKey} TO TABLE clean;

Тут всё таки из tmp в clean, а не из clean в clean.

В остальном очень интересно, спасибо.

Благодарим за обратную связь!

> timestamp из названия файла нельзя парсером подтащить в виде значения в поле insertTime?

Нет, всё-таки insertTime отражает время фактической вставки в таблицу с "сырыми" данными. По этому полю потом таблица очищается по TTL. Может так выйти, что в обработку попадёт файл с timestamp в имени = неделя назад (а TTL = 3 суток) и данные из этого файла уйдут в молоко.
К слову, парсер вставляет timestamp из имени файла в отдельное поле (скажем, field3) и потом "Очиститель" делает вот так при сборке чистой партиции:
ORDER BY field1, field2, field3, ...
LIMIT 1 BY field1, field2, field3, ...;

> Да и без аргумента replacing движок оставляет только самую последнюю вставленную строку.

Нам как раз нужно было оставлять не самую свежую строку, а ту, у которой timestamp в имени файла самый ранний. При этом файлы могут поступать в обработку в любом порядке, т.е. не привязанном к timestamp из имени ...

Опечатку поправили, спасибо за внимательность)

Самую первую можно оставлять с "инвертированной" датой. Вычитать из какого-то таймстемпа в UInt64 в далёком будущем текущий и получится, что у каждой новой записи аргумент будет меньше, чем у самой первой. И она удалится.

Спасибо, идею поняли, поправили)

Подскажите, пожалуйста, в каком месте и для решения какого вопроса предлагаете использовать ReplicatedMergeTree?"

Sign up to leave a comment.