Обзор
Различия между обновлением данных в 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. Это операции с интенсивным использованием I/O и должны использоваться экономно, так как они могут повлиять на производительность кластерного SELECT.
Читать далее о обновляющих мутациях.
Легковесные Обновления
Легковесные обновления предоставляют механизм для обновления строк так, чтобы они обновлялись немедленно, а последующие запросы SELECT автоматически возвращали измененные значения (это влечет за собой накладные расходы и замедляет запросы). Это эффективно решает проблему ограничения атомарности обычных мутаций. Мы показываем пример ниже:
Обратите внимание, что для легковесных обновлений мутация все еще используется для обновления данных; она просто не материализуется немедленно и применяется во время запросов SELECT. Она все равно будет применена в фоновом режиме как асинхронный процесс и имеет такие же большие накладные расходы, как и мутация, и, следовательно, является операцией с интенсивным использованием I/O, которую следует использовать экономно. Выражения, которые могут быть использованы с этой операцией, также ограничены (см. здесь для подробностей).
Читать далее о легковесных обновлениях.
Collapsing Merge Tree
Исходя из идеи, что обновления дороги, но вставки могут быть использованы для выполнения обновлений,
движок таблиц CollapsingMergeTree
может использоваться вместе со столбцом sign как способом сообщить ClickHouse обновить конкретную строку, объединяя (удаляя)
пару строк со знаком 1 и -1.
Если -1 вставлен в столбец sign, вся строка будет удалена.
Если 1 вставлен в столбец sign, ClickHouse сохранит строку.
Строки для обновления идентифицируются на основе ключа сортировки, используемого в операторе ORDER BY () при создании таблицы.
Вышеуказанный подход к обновлению требует, чтобы пользователи поддерживали состояние на стороне клиента. Хотя это наиболее эффективно с точки зрения ClickHouse, это может быть сложно в больших масштабах.
Рекомендуем ознакомиться с документацией
по CollapsingMergeTree
для более полного представления.