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