Обзор
Различия между обновлением данных в ClickHouse и OLTP базах данных
Когда речь заходит об обновлениях, ClickHouse и OLTP базы данных значительно различаются из-за своих основных проектных философий и целевых случаев использования. Например, PostgreSQL, ориентированная на строки, ACID-соответствующая реляционная база данных, поддерживает надежные и транзакционные операции обновления и удаления, обеспечивая согласованность и целостность данных через механизмы, такие как контроль конкурентности с несколькими версиями (MVCC). Это позволяет безопасно и надежно вносить изменения даже в условиях высокой конкуренции.
С другой стороны, ClickHouse - это колоночная база данных, оптимизированная для аналитики с высокой нагрузкой на чтение и операций только на добавление с высокой пропускной способностью. Хотя она нативно поддерживает обновления и удаление на месте, их необходимо использовать осторожно, чтобы избежать высокого ввода-вывода. В качестве альтернативы таблицы могут быть перестроены, чтобы преобразовать операции удаления и обновления в добавленные операции, которые обрабатываются асинхронно и/или во время чтения, таким образом, отражая акцент на высокой пропускной способности при загрузке данных и эффективной производительности запросов, а не на манипуляции с данными в реальном времени.
Методы обновления данных в ClickHouse
Существует несколько способов обновления данных в ClickHouse, каждый из которых имеет свои преимущества и характеристики производительности. Вы должны выбрать подходящий метод в зависимости от вашей модели данных и объема данных, которые вы собираетесь обновить.
Для обоих операций, если количество поданных мутаций постоянно превышает количество мутаций, которые обрабатываются в фоновом режиме за некоторый интервал времени, очередь нематериализованных мутаций, которые необходимо применить, будет продолжать расти. Это приведет к ухудшению производительности запросов SELECT.
В общем, операции обновления должны выполняться осторожно, и очередь мутаций должна быть тщательно отслежена с помощью таблицы system.mutations. Не выполняйте обновления часто, как в OLTP базах данных. Если у вас есть требования к частым обновлениям, смотрите ReplacingMergeTree.
| Метод | Синтаксис | Когда использовать |
|---|---|---|
| Обновление мутаций | ALTER TABLE [table] UPDATE | Используйте, когда данные необходимо немедленно обновить на диске (например, для соблюдения требований). Негативно влияет на производительность SELECT. |
| Легкое обновление | ALTER TABLE [table] UPDATE | Включите, используя SET apply_mutations_on_fly = 1;. Используйте, когда обновляете небольшие объемы данных. Строки немедленно возвращаются с обновленными данными во всех последующих запросах SELECT, но изначально они помечаются как обновленные только на диске. |
| ReplacingMergeTree | ENGINE = ReplacingMergeTree | Используйте, когда обновляете большие объемы данных. Этот механизм таблицы оптимизирован для дедупликации данных при слиянии. |
| CollapsingMergeTree | ENGINE = CollapsingMergeTree(Sign) | Используйте, когда часто обновляете отдельные строки или в сценариях, когда необходимо поддерживать последнее состояние объектов, которые со временем меняются. Например, отслеживание активности пользователей или статистики статей. |
Вот краткое резюме различных способов обновления данных в ClickHouse:
Обновления мутаций
Обновления мутаций можно выполнить с помощью команды ALTER TABLE … UPDATE, например:
Эти операции требуют большого ввода-вывода, переписывая все части, соответствующие выражению WHERE. Процесс не обеспечивает атомарности - части заменяются на мутированные части, как только они готовы, и запрос SELECT, который начинает выполняться во время мутации, будет видеть данные из частей, которые уже были мутированы, наряду с данными из частей, которые еще не были мутированы. Пользователи могут отслеживать состояние прогресса через таблицу systems.mutations. Это операции с высоким вводом-выводом и должны использоваться экономно, так как могут повлиять на производительность SELECT кластера.
Читать далее о мутациях обновления.
Легкие обновления
Легкие обновления предоставляют механизм для обновления строк так, чтобы они обновлялись немедленно, и последующие запросы SELECT автоматически возвращали измененные значения (это приводит к дополнительным затратам и замедляет запросы). Это эффективно решает ограничение атомарности обычных мутаций. Мы показываем пример ниже:
Обратите внимание, что для легких обновлений все еще используется мутация для обновления данных; она просто не материализуется немедленно и применяется во время запросов SELECT. Она все равно будет применяться в фоновом режиме как асинхронный процесс и несет те же тяжёлые затраты, что и мутация, и, следовательно, является операцией с высоким вводом-выводом, которая должна использоваться экономно. Выражения, которые можно использовать с этой операцией, также ограничены (смотрите здесь для подробностей).
Читать далее о легких обновлениях.
Сжимающее дерево слияния
Исходя из идеи, что обновления являются дорогими, но вставки могут быть использованы для выполнения обновлений,
табличный движок CollapsingMergeTree
может быть использован вместе с колонкой sign как способ указать ClickHouse обновить конкретную строку, сжимая (удаляя)
пару строк со знаками 1 и -1.
Если -1 вставляется в колонку sign, вся строка будет удалена.
Если 1 вставляется в колонку sign, ClickHouse сохранит строку.
Строки для обновления идентифицируются на основе ключа сортировки, используемого в операторе ORDER BY () при создании таблицы.
Вышеупомянутое обновление требует, чтобы пользователи поддерживали состояние на стороне клиента. Хотя это наиболее эффективно с точки зрения ClickHouse, работать с этим на большом масштабе может быть сложно.
Мы рекомендуем прочитать документацию
по CollapsingMergeTree
для более полного обзора.