Lightweight UPDATE и Patch Parts

ClickHouse 25.7 ввёл стандартный SQL UPDATE через механизм Patch Parts — delta-части с изменёнными значениями. В 26.3 LTS (март 2026) эта функциональность стала официально доступна. Бенчмарки показывают ускорение до 1000-1600x по сравнению с ALTER TABLE UPDATE для точечных обновлений.

Механизм Patch Parts

Вместо перезаписи затронутых колонок целиком, UPDATE создаёт небольшие patch parts — дельта-части, содержащие только изменённые строки:

1. UPDATE создаёт patch part с новыми значениями изменённых строк
2. Patch part виден в SELECT немедленно (объединяется на лету)
3. При следующем merge patch part материализуется в основную часть

-- Стандартный SQL UPDATE (ClickHouse 25.7+ / 26.3 LTS)
UPDATE events SET payload = 'redacted' WHERE user_id = 12345;

-- Результат виден немедленно:
SELECT payload FROM events WHERE user_id = 12345;
-- Результат: 'redacted'

Сравнение: Patch Parts vs ALTER TABLE UPDATE

Производительность: до 1000x быстрее

Официальные бенчмарки ClickHouse (блог 25.7):

Таблица: 100M строк, обновление 500 строк

ALTER TABLE UPDATE:  ~4.2 секунды
UPDATE (patch parts): ~2.8 миллисекунды

Ускорение: ~1500x

Разница объясняется масштабом операции:

• ALTER TABLE UPDATE — перезаписывает все затронутые колонки во всех частях
• UPDATE (patch parts) — создаёт один маленький файл с новыми значениями

Ограничения Patch Parts

Механизм Patch Parts эффективен до ~10% строк таблицы. При большем объёме:

-- Эффективно: обновление 500 пользователей из 10M (0.005%)
UPDATE events SET email = '[email protected]' WHERE user_id IN (1, 2, 3, ..., 500);

-- Неэффективно: обновление 2M пользователей из 10M (20%)
-- Вместо этого используйте mutations или ETL:
ALTER TABLE events UPDATE email = '[email protected]' WHERE toDate(event_time) < '2024-01-01';

Legacy-синтаксис и apply_mutations_on_fly

Если вы работаете с версиями до 25.7 или с таблицами, где patch parts недоступны:

-- Legacy: мутационный UPDATE (все версии ClickHouse)
ALTER TABLE events UPDATE payload = 'redacted' WHERE user_id = 12345;

-- Мониторинг выполнения:
SELECT * FROM system.mutations
WHERE table = 'events' AND NOT is_done
ORDER BY create_time DESC;

-- Немедленная видимость legacy mutations (настройка сессии):
SET apply_mutations_on_fly = 1;
-- После этого SELECT увидит результат mutation до её завершения

apply_mutations_on_fly = 1 включает merge-on-read для мутаций: читатели видят результат мутации сразу, не дожидаясь физического завершения. Цена — небольшой overhead на CPU при чтении.

Практический сценарий: редактирование PII

-- Сценарий: GDPR-запрос на удаление персональных данных
-- 300 пользователей из 50M — идеальный кандидат для patch parts

-- Шаг 1: UPDATE (patch parts)
UPDATE user_events
SET
    email = '[email protected]',
    phone = 'DELETED',
    ip_address = '0.0.0.0'
WHERE user_id IN (
    SELECT user_id FROM gdpr_deletion_requests
    WHERE processed = 0
    LIMIT 300
);

-- Шаг 2: Отметить запросы как обработанные
UPDATE gdpr_deletion_requests SET processed = 1
WHERE processed = 0
LIMIT 300;

-- Шаг 3: Проверка (немедленно, без ожидания merge)
SELECT email, phone FROM user_events WHERE user_id = 42;
-- Результат: '[email protected]', 'DELETED'

Ключевые выводы

1. UPDATE t SET col = val WHERE expr (25.7+/26.3 LTS) создаёт Patch Part — дельта-файл с изменёнными строками.
2. Patch parts видны в SELECT немедленно; физически объединяются при merge.
3. Ускорение до 1000-1600x по сравнению с ALTER TABLE UPDATE для точечных изменений.
4. Эффективен до ~10% строк таблицы; для больших объёмов — ALTER TABLE UPDATE или ETL.
5. apply_mutations_on_fly = 1 включает немедленную видимость для legacy mutations (ALTER TABLE UPDATE).